Windows
macOS
Android
iOS
节点可用性监控的难点，不是把“能不能访问”显示在面板上，而是判断一次失败究竟来自节点本身、探针所在网络，还是中间依赖。单个地点、单个协议、单次检测都可能得出片面结论。要让告警真正帮助排障，必须同时处理误报和监控盲区。
先区分节点故障与探测路径故障
北京办公室访问失败，并不等于上海用户也无法访问；一台位于云厂商机房的探针失败，也可能只是该机房到目标网络的临时路由异常。因此，节点可用性监控至少要记录探针地点、运营商或网络类型、检测协议、失败时间和连续失败次数。
探针布局可以采用“同区域加密、跨区域验证”的方式：核心业务所在区域安排多个探针，外部用户较多的业务再增加不同城市或不同网络的探针。多个探针同时失败，说明目标节点或公共依赖出现问题的可能性更高；只有一个探针失败，则应优先检查探针网络、出口策略和本地解析结果。
用分层检测避免单一指标误判
第一层：网络与端口
基础检测适合判断节点是否有响应，例如 TCP 连接是否能够建立、目标端口是否接受连接。这一层速度快，通常能在数秒内发现主机离线、端口未监听或安全策略拒绝连接，但它无法证明应用返回了正确内容。
第二层：协议与服务状态
对 HTTPS 服务，应检查状态码、响应时间、证书有效期和必要响应头；对邮件服务，则要区分连接成功与实际投递能力。检查时不要只把所有非 200 响应都判为故障。例如需要登录的页面可能稳定返回 401 或 403，这些状态在权限设计正确时并不代表节点不可用。
第三层：关键业务流程
业务探测应选择无副作用的公开流程，例如打开商品目录、查询只读数据或完成一笔可回滚的测试操作。不要频繁创建真实订单、发送外部邮件或修改用户资料。业务探测更接近真实用户，但执行成本和维护成本也更高，适合核心路径，不适合把所有页面都纳入。
把失败确认机制写进告警规则
节点可用性监控不宜采用“一次失败立即通知所有人”的规则。瞬时丢包、连接池抖动、短时发布和探针自身重启都会造成孤立失败。更稳妥的做法是将检测结果分为正常、观察和故障三个状态，并分别设置恢复条件。
- 单次检测失败时记录事件，先进入观察状态，不立即升级为高优先级事故。
- 在约 30 秒至数分钟的观察窗口内重新检测，具体间隔根据服务重要性和故障影响调整。
- 若同一探针连续失败，同时其他探针正常，检查探针网络、路由和本地策略。
- 若多个地点在连续两个或更多检测周期内失败，再触发高优先级告警，并附带失败类型和影响范围。
- 恢复时也要求连续成功若干次，避免服务刚恢复又短暂失败时反复发送恢复、故障通知。
告警内容应直接包含目标节点、探针位置、最近一次成功时间、失败阶段和关联变更。只写“服务不可用”的通知，无法帮助值班人员判断是连接失败、响应超时，还是业务断言不成立。
重点排查四类监控盲区
- 区域盲区：只有一个城市的探针时，无法判断其他用户是否受到影响。
- 协议盲区：只做端口探测时，应用可能已经返回错误页面，但监控仍显示正常。
- 依赖盲区：节点本身在线，却因数据库、对象存储、消息队列或第三方支付接口异常而无法完成业务。
- 权限盲区：匿名访问正常，不代表登录用户、特定角色或受限网络中的用户也能正常使用。
依赖检查不应简单地把所有下游服务都绑定成一个红色告警。可以为核心依赖设置独立指标，并在业务探测结果中标注“节点在线、依赖异常”这类状态。这样既能定位故障边界，也能避免多个系统同时告警造成告警风暴。
用数据复盘调整阈值
阈值没有适用于所有服务的固定答案。低延迟内部服务可以采用较短检测周期；跨公网、依赖较多的业务则应结合历史响应时间、网络波动和发布窗口设置超时。通常应分别观察连接耗时、首字节耗时、完整响应耗时和失败比例，而不是只保留一个平均值。
每月复盘一次误报和漏报：统计哪些告警没有形成实际故障、哪些用户投诉未被探测发现，并检查探针是否覆盖真实访问来源。若某个检查长期只产生噪声，可降低其告警级别；若真实事故中基础检测正常而业务失败，则应补充更接近用户路径的合成监控。
常见问题
节点可用性监控只做 Ping 可以吗？
不建议。Ping 只能反映网络层的一部分情况，目标可能禁用 ICMP，也可能网络可达但应用已经异常。至少应增加端口、协议和关键业务检查。
探针越多越好吗？
不是。探针数量应覆盖主要用户区域和网络类型，同时控制维护成本。没有明确覆盖目标的重复探针，通常只会增加数据量。
如何降低短暂抖动造成的误报？
采用连续失败、跨探针确认和恢复确认，并为发布、扩容等已知变更设置清晰的观察窗口。
什么时候需要业务级检测？
当端口和协议检查正常，但用户仍可能无法完成核心操作时，就应增加无副作用的业务流程检测。
可靠的节点可用性监控不是追求“永不报警”，而是让每次报警都包含足够的定位信息，并让真正影响用户的故障不被单点探针和单一指标掩盖。