被动告警的局限性
依靠用户投诉或错误日志告警的被动监控，通常比实际故障晚 5~15 分钟。在这段时间里，受影响的用户已经开始流失或转向竞品。主动探针是将这个窗口压缩到分钟级甚至秒级的关键。
探针类型与检测维度
- ICMP Ping：检测网络层可达性，开销最低，但无法反映应用层状态
- TCP 连接探针：验证端口监听，能发现服务进程崩溃
- HTTP(S) 探针：模拟真实请求，验证端到端可用性
- 协议层握手探针：完成完整的 VPN 握手，最接近真实用户体验
探针部署架构
探针服务应该部署在与节点物理位置不同的地点。从同一机房探测同一机房，无法发现上游链路问题。理想的架构是：
- 在多个地理位置部署轻量探针服务
- 每个探针服务同时探测所有节点
- 多地结果取最大值作为"全球可达性"指标
- 单地探测失败但其他地正常 → 说明是区域性链路问题
告警梯度设计
不是所有异常都应该直接 PagerDuty 打电话。合理的梯度：
- 延迟升高 20%：记录，暂不告警
- 连续 2 次探测失败：降权，同时发 Slack 通知
- 连续 5 次探测失败：自动下线节点，触发 PagerDuty
健康监控的目标不是"知道节点挂了"，而是"在用户感知之前就修好"。