写了个站点可用性监控脚本,开源了
需求很简单:定时 curl 一批 URL,异常时发通知。
核心逻辑
import httpx, time
def check(url, timeout=10):
start = time.time()
try:
r = httpx.get(url, timeout=timeout, follow_redirects=True)
return {
"url": url,
"status": r.status_code,
"ms": round((time.time() - start) * 1000),
"ok": r.status_code < 400,
}
except Exception as e:
return {"url": url, "status": 0, "ms": -1, "ok": False, "err": str(e)}
特性
- ✓并发检查(httpx + asyncio)
- ✓连续失败 3 次才告警,避免误报
- ✓支持 Telegram / 企业微信 webhook
- ✓结果写 SQLite,可以出可用率报表
踩过的坑
- 不要用 HEAD 请求,很多站不支持
- 超时设 10 秒比较合适,太短会误判
- 一定要
follow_redirects=True,不然 301 全被判失败
代码在仓库里,MIT 协议,随便用。
学到了,明天就去改。
这个方案我用了半年,稳定。
认真回一下:1)测试时间最好标注清楚,不同时段结果差异很大;2)测速节点要说明是在哪个城市、什么运营商;3)单次测试意义不大,建议连续测一周取平均。做到这三点,测评的说服力会强很多。
晚高峰确实会掉速,我这边测下来大概掉 30%。
这家的客服响应挺快的,之前工单半小时就回了。
从技术角度看,这个方案的瓶颈主要在磁盘 IO 上。如果并发再高一点,建议换成 NVMe;如果内存够,可以把热点数据放 tmpfs,能明显提升响应速度。当然小流量站点没必要折腾到这个程度。
楼主用的什么系统?Debian 还是 Ubuntu?
我用的同款,IO 比你这个高一点,可能是批次差异。
求个测速脚本,谢谢!
说个反面案例:我去年买过一家类似的促销款,前三个月挺好,第四个月开始疯狂超售,晚上基本没法用,最后商家直接跑路,年付的钱打了水漂。所以现在我买没听过的商家一律先月付。
感谢分享,正好需要。
我用的同款,IO 比你这个高一点,可能是批次差异。
大佬,有推荐的便宜机器吗?预算 50 以内。
学到了,明天就去改。
这个思路不错,我之前是用另一种方式实现的,大概是:先在同城做一份冷备,再同步到异地。缺点是占用双倍空间,优点是恢复快。各有取舍吧。
实测确实如此,我用了一个月也是这样。
这个方案我用了半年,稳定。
认真回一下:1)测试时间最好标注清楚,不同时段结果差异很大;2)测速节点要说明是在哪个城市、什么运营商;3)单次测试意义不大,建议连续测一周取平均。做到这三点,测评的说服力会强很多。