Prometheus告警实践

完整译文请访问：告警。

点击这里获取云原生干货https://www.coderdocument.com/resource_credential.html?code=云原生干货

对什么告警

目标是尽可能少地触发告警，通过关联终端用户痛点来触发告警，而不是试图捕捉所有可能触发告警的条件。告警应该链接到相关的控制台，以便于找出哪个组件有问题。

可以对告警保持一定的宽容，以适应小幅波动。

在线服务系统

尽可能对高延迟和高错误率情况触发告警。

在堆栈中某一点的延迟只显示一个页面。如果较低级别的组件延迟较高，但是总体来说，延迟良好，那么就不需要添加页面。

有关错误率，只对“用户可见错误”提供页面。如果有错误会使堆栈挂掉而引发故障，则不需要分别对它们提供分页。但是，如果有些故障用户不可见，但是严重到需要人工参与（例如，错误导致损失很多钱），则需要添加相关页面。

如果不同类型的请求具有不同的特征，你可能需要分别对它们发出告警，否则低流量类型的请求中的问题将被高流量请求淹没。

离线处理

对于离线处理系统，关键指标是系统处理数据所需的时间，因此如果数据处理耗时很长，会对用户造成影响，则添加页面。

批处理作业

对于批处理作业，如果批处理作业最近没有成功，则需要添加页面，而且这将引发用户可见的问题。

这通常需要足够的时间执行两次完整的批处理作业。对于每4小时运行一次、需要1小时的作业，10小时是合理的阈值。如果你无法接受一次运行失败，请更频繁地运行作业，因为一次失败应该不需要人工进行干预。

容量

虽然容量问题不会立即对用户造成影响，但容量不足通常需要人工进行干预，以避免在不久的将来出现停机。

元监控

重要的是要确认监控正在发挥作用。因此，要有告警，以确保Prometheus服务器、Alertmanager、PushGateway和其他监控基础设施是可用的并且正常运行。

与往常一样，如果能够根据症状而不是原因触发告警，这有助于降噪。例如，从PushGateway到Prometheus，再到Alertmanager，再到电子邮件的告警黑盒测试比各自告警要更合适。

使用外部墨盒监控来补充Prometheus的白盒监控，可以捕捉到原本不可见的问题，也可以在内部系统完全故障时用作回调。

及时获取更多精彩文章，请扫码关注如下公众号《云原生之家》：