Ping 监控

为什么还要用 ping，既然已在监控 HTTP？

HTTP 监控检查网站是否返回正确响应。Ping 监控检查机器是否完全可达。这是两个不同的问题，而这种差异在故障发生时很关键。如果 Web 应用崩溃，但服务器还存活，HTTP 检测失败—但 ping 能通过。这会立即缩小诊断范围。如果两者都失效，说明是网络或基础设施故障。如果只有 ping 失败，可能是防火墙开始拦截探测包，但用户端的 HTTP 仍然可用。

Ping 监控也是专为没有运行 HTTP 的主机设计的正确工具：数据库服务器、邮件服务器、负载均衡器后端应用服务器、VPN 网关、内部服务——只要你需要知道“这台机器活着且可访问”时都能用上。

为什么采用基于 TCP 的 ping？

传统的 ICMP ping（命令行里的“ping”）在桌面环境很好用，但用于云端监控却不够可靠。大多现代防火墙会屏蔽或限流 ICMP，尤其是来自公网的，所以 ICMP 超时既可能代表“服务器宕机”，也可能是“防火墙丢包”。这种不确定性对于告警工具来说是灾难。

DiagnoSEO Uptime Monitoring 使用基于 TCP 的 ping：检测会在已知端口（先是 80，之后回退至 443）尝试建立 TCP 连接，超时为 5 秒。如果收到 SYN/ACK，说明主机可达。如果没有——你将获得来自内核的真实错误码（如拒绝连接、超时、无路由至主机），大大加快了故障分流。

记录内容

每次 ping 都会记录结果（在线 / 离线）和 RTT 往返时间（毫秒）。这些数据会与 HTTP 监控的历史记录走同一数据管道——你可以查看最近检测的 sparkline 小图、24 小时及 30 天在线率百分比，还有过去 30 天的可用性热力图。当主机宕机时，会自动开启事件并发送告警至所有已开启的通知通道。

Ping 监控配置建议

• 使用较短的检测间隔：ping 检查消耗极小，计划允许时建议设置为 1-5 分钟。用很低成本实现更快故障发现。
• 结合端口监控使用：比如数据库监控 5432、邮件监控 25 时，请一并加端口监控。Ping 检查机器存活，端口监控服务是否监听。
• 关注 RTT 变化：每次检测都会记录响应时间。RTT 突然升高往往预示着全面故障前兆——设置阈值，提前捕捉这些异常，避免成为重大事件。
• 利用确认次数门槛：网络偶尔会波动。默认两次连错保护你不被误报困扰。

如何在仪表板中呈现

Ping 监视器会和 HTTP、端口、关键词、API 及心跳监控一起出现在同一列表。你可以对其打标签（比如“基础设施”、“内部”）、按状态筛选、按 RTT 排序，像其他监控一样暂停/恢复。所有告警都可通过（邮件、Telegram、Slack、Discord、短信）等渠道推送，并遵循同样的夜间静音和确认门槛规则。

配置方法

打开工具，点击“添加监控”，选择类型“Ping（TCP）”，粘贴主机名（如 db.internal.firma.com），设置间隔并保存。之后每一周期，监控会每分钟发起一次 TCP 连接，记录 RTT，并在主机无响应时通知你。

常见问题

• Ping 监控有什么用途？

  在第 3 层（网络层）检测可达性——即主机是否对 ICMP echo 有响应。适用于路由器、交换机、物联网设备、内网基础设施及所有不运行 HTTP 但需要被访问的设备。

• 为什么我的 AWS/云服务器 ping 检查总是失败？

  大多数云服务商默认在安全组或防火墙层阻止 ICMP。服务器自身健康，但不响应 ping。云端业务更推荐使用 HTTP 或 TCP 端口检查。如果确实需要 ping，可在安全组里明确允许 ICMP。

• ping 和端口（TCP）检查有何区别？

  ping 用的是 ICMP（没有端口，只测三层连通性）。TCP 端口检测会尝试连接特定端口——确认四层连接。主机可能 ping 得通但端口不通（防火墙拦截端口），或反之（ICMP 被屏蔽、端口开放）。

• 你们会记录 ping 的往返时间（RTT）吗？

  会——每次检测都会记录响应时间（往返）。这有助于发现网络性能下降：同一个主机 RTT 从 20ms 缓慢上升到 200ms，说明可能遇到路由或拥塞问题。

• 能否 ping 内部 IP？

  只有当该 IP 可被我们的检测服务器访问时（即公共 IP）才行。RFC1918 内网段（192.168.x.x、10.x.x.x、172.16-31.x.x）无法通过外部监控。若需监控内部基础设施，可在内网部署自托管 heartbeat 代理，由它来 ping 我们服务器。