监控服务是否正常响应、并在出问题时告警，目的是在客户之前发现真实故障，同时避免狼来了式的误报。指南梳理了 HTTP、keyword、heartbeat、TCP 四类检查的适用场景，以及如何用确认阈值和跨区域共识消除误报。
HTTP 检查通过请求 URL 并按状态码和耗时判断响应，适合网站和 API；keyword 检查在 HTTP 基础上断言响应体中是否包含特定词，200 但渲染错误页也会被判为宕机；heartbeat 是反向逻辑，cron 任务或 worker 每次运行 ping 监控端，预期窗口内未收到即视为宕机，适合没有公网 URL 的服务；TCP 检查则面向数据库、邮件服务器等非 HTTP 服务，直接连接主机和端口。
检查间隔通常为 1-2 分钟，单次失败很少能证明宕机——网络抖动、服务器卡顿、部署重启都可能造成瞬时故障。正确做法是要求连续多次失败才开启事件、连续多次成功才解除事件，确认窗口吸收瞬时抖动，同时快速捕获真实持续故障。宕机中途的短暂恢复不应拆成两个事件，确认恢复后再次失败则应视为新事件。
误报的另一大来源是检查的 vantage point：检查点与目标服务之间的网络问题，看起来和宕机完全一样。确认阈值能解决瞬时版本，但持续的区域性路径问题仍可能被单点误判。最强防御是从多个区域检查，且仅当多个区域一致时才开启事件。Sentivel 的做法是：配置两个及以上区域的监控会从每个区域分别检查，各区域结果先合并为共识结论再决定是否开启事件，单区域网络问题不会触发误报。配合 flap 阈值，一次宕机必须同时满足持续性和多区域可见才会告警。
监控的确认状态应驱动状态页上对应组件，让客户看到真实状态而无需人工切换。新监控在证明自己之前应显示为预热中，而不是过早显示绿色。
常见问题：HTTP 与 heartbeat 的区别在于前者主动请求 URL 并判断响应，后者由任务主动 ping 监控端、缺少预期 ping 即为信号；避免误报需连续失败才开启事件、连续成功才解除；检查频率通常 1-2 分钟一次，更频繁能更快发现但增加负载和成本，需配合确认阈值防止频率转化为噪音。
原文发布于
#开发者 #工具 #UptimeMonitoring #SRE #DevOps #Sentivel #监控
@DevToolboxHub