技巧 #11：代理日志记录与可用性监控怎么做
代理用得好不好，不能靠感觉判断。把每一次经过代理的请求都记录下来，再对成功率、响应时间做统计和告警，是维持代理长期可用的基本功。本篇给出一套可以直接落地的代理监控方案。
第一步：设计代理访问日志的字段
每条日志至少要包含时间戳、代理节点标识、目标地址、状态码、耗时和错误原因，缺一项都会让后续统计失真。建议用 JSON 格式输出，方便直接写入日志平台：
{"ts":"2026-02-07T10:12:33+08:00","proxy":"sg-node-03","url":"https://example.com/api","status":200,"cost_ms":812,"error":""}成功率统计：分维度才有意义
只算一个总成功率会掩盖问题。正确做法是按代理节点、目标站点、时间段三个维度分别统计，并且把失败分成两类看待：
- 网络层失败： 连接超时、被重置，说明代理本身不可用，应立即从可用池摘除。
- 应用层失败： 403、429 等状态码，说明代理能通但被目标站点识别，需要降频或更换出口。
经验阈值：单个节点在五分钟窗口内成功率低于 90%，就应该移出轮换队列，避免拖垮整体任务。
响应时间趋势比单次数值更重要
记录每次请求的完整耗时，并尽量区分连接耗时与传输耗时。观察按小时聚合的 P95 响应时间趋势，如果某节点从 500 毫秒缓慢劣化到 3 秒，说明它正在被限速或负载过高，应当提前下线，而不是等到完全超时才处理。
告警规则与值班响应
- 成功率告警： 池内可用节点占比低于 60% 时立即告警，这是任务中断的前兆。
- 延迟告警： 全池 P95 响应时间连续 15 分钟高于 2 秒触发提醒。
- 静默期： 每次告警后设置 10 分钟静默，避免重复通知刷屏，掩盖新出现的问题。
把这些指标接入现有的监控面板，代理池的健康状况就可以一目了然，问题定位也能精确到具体节点与时间段，而不是盲目地整批更换代理。
Article ID: 71
（本文仅供技术交流，请遵守法律法规）