Windows
macOS
Android
iOS
很多团队以为节点还能响应，就代表服务仍然可用。实际上，节点可用性监控如果只检查网络连通，可能漏掉域名解析失败、TLS证书异常、应用进程失去响应、磁盘写满或依赖服务中断等问题。更可靠的做法，是把“主机在线”和“用户能否完成关键操作”分开判断。
误区一：只探测 IP 或只发送 Ping
ICMP响应只能说明目标对某类网络报文作出了回应，不能证明业务端口开放，更不能证明返回内容正确。部分防火墙会限制ICMP，反过来，某些主机即使应用已经停止，仍然可能继续响应Ping。
检测对象应至少分为三层：第一层检查网络可达性；第二层检查目标端口，例如443端口能否建立连接；第三层检查应用协议和结果，例如访问健康检查接口后，状态码是否符合预期、响应体是否包含固定字段。DNS解析也应单独验证，因为域名解析失败时，直接探测IP可能得出“正常”结论。
更稳妥的配置步骤
- 先确定用户实际使用的域名、端口和协议，不要只记录节点IP。
- 为网络、传输层和应用层分别建立探针。
- 对关键接口检查状态码、响应时间和必要的业务字段。
- 把证书过期、域名解析异常和应用返回错误设置为独立事件。
误区二：单个地点正常，就认定所有用户正常
一个探测点成功，不代表不同运营商、地区或网络出口都能访问。公网路径可能因为路由变化、跨境链路、运营商互联或本地DNS差异而出现分区故障。尤其是部署了多个接入区域的服务，某个区域的节点异常可能被其他区域的正常结果掩盖。
节点可用性监控应区分“全局故障”和“局部故障”。至少可以选择两个网络条件不同的探测位置，例如企业固定网络与移动网络，但不要把不同探针的结果简单平均。若只有一个区域失败，应触发区域性告警；若多数独立位置同时失败，再升级为全局事件。探针数量越少，越要明确告警结果的适用范围。
误区三：把一次超时直接当成故障
短暂丢包、连接建立过慢或服务器瞬时排队，都可能造成一次失败。若规则只要一次检测失败就告警，误报会迅速增加，值班人员也容易形成“告警疲劳”。但如果连续失败次数设置得过高，又可能错过持续时间很短但影响明显的故障。
建议同时设置失败次数、观察窗口和恢复条件。例如在连续5次、每次间隔约30秒的探测中失败3次再告警，通常比单次失败更稳健；对支付提交、登录等关键操作，则可以使用较短窗口和更高优先级。具体数值要结合业务容忍度、网络稳定性和服务的高峰负载调整，不能套用同一组阈值。
除了可用或不可用，还应记录响应时间分位情况。平均响应时间正常，并不表示尾部延迟没有问题。一个接口可能大多数请求在200毫秒内完成，却有少量请求超过数秒，这类情况往往更适合触发性能提醒，而不是直接标记节点宕机。
误区四：维护、发布和故障使用同一套告警
计划内重启、版本发布、域名切换或证书更换期间，节点短暂不可用是预期事件。如果没有维护窗口或静默规则，系统会产生大量无效告警；如果静默范围过大，又可能把同一时间发生的真实故障一并隐藏。
维护规则应绑定明确的节点、服务和开始结束时间，尽量避免使用覆盖整个集群的长期静默。发布结束后，要自动检查节点是否恢复、版本是否一致、健康接口是否正常。静默只是停止通知，不应删除原始探测记录，否则后续无法区分计划内变化和意外中断。
误区五：只告警“故障开始”，不告警“故障恢复”
没有恢复事件时，值班人员很难确认问题是否已经自行消失，也容易在处理工单时重复排查。节点可用性监控应为每类故障建立成对的触发与恢复条件，例如连续失败达到阈值后触发，连续成功达到阈值后恢复。
恢复条件不必与触发条件完全相同。对于网络抖动，可以要求连续2至3次成功后恢复，减少“恢复—再次失败”的通知震荡；对于证书过期或配置错误，则应以问题被修复、检查结果重新符合规则为准。告警内容还应包含目标、探测位置、检测类型、首次发生时间和最近一次结果。
误区六：忽略时间、身份和结果校验
探针时钟偏差、重复任务、缓存响应和代理层返回，都可能让监控结果失真。例如代理缓存了旧页面，表面上返回200状态码，但实际源站已经无法提供新内容；又如健康接口不需要鉴权，而真实业务接口因令牌失效已经全部失败。
排查时应核对以下信息：
- 探测时间是否使用统一时区和可靠的时间同步。
- 请求是否经过代理、缓存、负载均衡或重定向。
- 检查接口是否覆盖真实依赖，例如数据库、对象存储或消息队列。
- 返回状态码正常时，是否还需要校验内容、版本标识或业务结果。
一套可落地的复核流程
- 列出每个节点对外提供的关键服务，并区分主机、端口、协议和业务操作。
- 为重要服务配置至少一种外部探测，同时保留节点内部的进程和资源检查。
- 按服务影响程度设置不同告警阈值，避免所有服务共用固定次数。
- 加入维护窗口、告警去重、恢复通知和升级联系人。
- 每月至少抽查一次告警链路，确认通知渠道、值班人员和事件记录仍然有效。
真正有效的节点可用性监控，目标不是制造更多通知，而是在用户受到影响时尽快给出可信信号，在局部异常时准确说明范围，在恢复后留下完整记录。
常见问题
问：Ping正常但服务打不开，应该先查什么？
先检查目标端口和应用协议，再检查DNS、TLS握手、反向代理以及应用返回内容。Ping正常只能说明一种基础网络探测成功。
问：探针越多，结果就一定越可靠吗？
不一定。探针应覆盖不同网络条件，并且结果要按地区、运营商或接入区域分类；大量处在同一网络出口的探针，不能代表真正的独立观测。
问：如何降低误报而不延迟告警？
把短暂网络抖动与关键业务失败分开处理，对普通服务使用连续失败和恢复确认，对高风险操作设置更短的观察窗口。
问：健康检查接口应该检查多少内容？
基础接口可检查服务进程和核心依赖；关键业务还应通过受控测试验证真实流程，但要避免产生真实订单、扣款或不可逆写入。