我们使用 icmp ping 从 AWS EC2 环境中的 icinga2 确定主机启动/关闭状态。这种方法效果很好，但我们遇到了一些问题，主机 ping 失败但其服务仍然正常。
我的同事认为亚马逊偶尔会限制 icmp 流量，而这正是导致我们发出错误警报的原因。
因此，有两个问题：
这是真的吗？亚马逊有时会限制 icmp 吗？
对于我们的监控系统来说，有没有比 icmp ping 更好的替代方案来判断主机是否启动/关闭？
当然，我们也监控服务，但是在主机（而不是服务）发生故障的情况下，监控主机启动/关闭很有用。
答案1
我对亚马逊的实施情况不太了解，所以我的回答只涉及一般行为。
有 RFC 建议限制节点生成的 ICMP 数据包，但这些建议不适用于路由器转发 ICMP 数据包。我不知道路由器对某些转发数据包的限制方式是否与其他数据包不同。
然而，为了实现负载平衡，通过不同的链路向不同的端口号发送数据包是许多硬件都具有的功能，如果使用此功能，则您的 ICMP 数据包完全有可能通过与发送到您的服务端口的数据包不同的物理网络路径进行路由。这可能是观察到差异的原因。
请注意，在正确配置的设置中，您应该期望看到 ICMP 回显请求比您的服务更可靠，而不是更不可靠。这本身就足以避免使用 ICMP 回显请求进行健康检查。
ICMP 回显请求更可靠的原因是它们具有更少的依赖性。ICMP 回显请求由内核网络堆栈回复，因此即使机器状况非常糟糕，您仍然能够响应 ICMP 回显请求。
答案2
通常有两种高级类型的检查用于监控在传统实例或虚拟机上运行的服务：主机级检查和服务级检查。
主机级别检查通常由代理和/或云提供商监控堆栈和监控指标（如 CPU 利用率、CPU 负载、可用内存、可用磁盘空间等）执行。
服务级别检查监控服务本身，通常是通过预定义的健康检查端点（例如）/healthcheck。您可以配置服务检查以对该端点执行 HTTP GET，如果没有提供 200 响应，则发出不良状态警报。
以下是设置健康检查时需要考虑的一些其他基本示例：
- 检查服务文档（或在你的服务中构建一个文档）以获取预先存在的健康检查端点
- 如果该服务是 Web 服务或具有任何 HTTP 端点，请考虑将其用作健康检查的目标。
- 如果服务将日志输出到磁盘或系统日志，您可以监视日志中是否存在指示故障的关键字，或监视在一定时间间隔内未更新的日志
- 如果服务前面有一个负载均衡器，例如 Amazon ELB 或 Google NLB，您可以根据它们提供的指标监控服务器的响应。
在大型分布式环境中，将统计数据收集到时间序列数据库（例如 Graphite 或 InfluxDB）中是很常见的。您的监控服务器会在一定时间内定期检查特定指标是否存在异常。
使用 ICMP 并不是理想的检查方式，因为它是主机级别检查的最基本形式。它不会报告服务本身的状态，应该是您的最后选择之一。
更新 我看到这个答案被标记为没有回答原始问题，这让我有点惊讶。我会更直接一点。出于我上面提到的原因，不要使用 ICMP 来监控主机级统计数据。