网站健康检查需用requests.get()配timeout和异常捕获，记录响应时间并设阈值，配置外置JSON，日志双输出且结构化。
用 requests.get() 检查 HTTP 状态码是否正常
网站健康最基础的判断就是能否返回 200（或允许的其他成功码，如 301、302）。直接调用 requests.get() 并检查 r.status_code 即可，但要注意：默认会跟随重定向，可能掩盖真实目标页的异常；不设超时会卡死。
实操建议：
立即学习“Python免费学习笔记（深入）”；
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
- 始终传入
timeout=5（单位秒），避免单次请求拖垮整个监控循环 - 如需检测原始响应（比如想发现 302 跳转失败），加参数
allow_redirects=False - 别只认
200—— 若业务接受301或302，就用status_code in (200, 301, 302) - 捕获
requests.exceptions.RequestException（包含网络断、DNS 失败、连接拒绝等），它比单独抓ConnectionError更全面
用 time.time() 记录响应延迟并设置阈值告警
状态码正常 ≠ 网站健康。用户感知的是“快慢”，所以必须测响应时间。Python 没有内置的“请求耗时”字段，得自己计时。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 在
requests.get()前后各调一次time.time()，差值即为总耗时（含 DNS、TCP 握手、TLS、发送、等待、接收） - 阈值别设太死：内网服务可设
0.3秒，公网 API 建议2.0秒起，首页带资源渲染的页面慎用此法（应配 Puppeteer） - 注意
time.time()返回浮点秒，建议用round(elapsed, 3)输出便于阅读 - 不要用
time.perf_counter()—— 它精度高但不必要，且跨进程/线程行为不一致，简单脚本用time.time()更稳
把多个 URL 和配置写进 config.json 而不是硬编码
硬编码 URL 和阈值会导致每次改地址都要动代码，易出错且无法快速批量巡检。JSON 是最轻量、人眼可读、Python 原生支持的配置格式。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 配置文件结构示例：
{ "urls": [ { "name": "api-login", "url": "https://api.example.com/v1/login", "timeout": 3, "warn_latency": 1.5, "expect_status": [200] } ] } - 用
json.load(open("config.json"))读取，加try/except FileNotFoundError防止路径错导致脚本退出 - URL 名称（
name字段）必须唯一，后续日志和告警靠它识别是哪个服务挂了 - 避免在 JSON 里写注释 —— Python
json模块不支持，会报JSONDecodeError
用 logging 写入文件 + 控制台双输出，别用 print()
print() 在后台运行（比如 systemd 或 cron）时容易丢失，且无法按级别过滤、无法自动轮转。健康监控脚本必须留痕，否则出问题时无从排查。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 初始化日志器时，同时加
FileHandler("health.log")和StreamHandler() - 日志格式推荐：
"%(asctime)s %(levelname)-8s %(name)s %(message)s"，时间精确到毫秒，级别对齐，方便 grep - 错误时记
logger.error(f"FAIL {name}: {e} | latency={elapsed}s")，成功时记logger.info(f"OK {name}: {status} | latency={elapsed}s") - 每天生成新日志？用
TimedRotatingFileHandler，但简单脚本够用的话，直接定期mv health.log health.log.$(date +%F)更可控
