告警

我们建议您阅读 My Philosophy on Alerting。它基于 Rob Ewaschuk 在 Google 的观察 -

总结就是: 保持告警简单，告警能够显示症结所在, 有良好的控制台可以查明原因，避免出现无用的页面

应该告警什么

通过报告用户疼痛的症状，而不是试图捕获可能引起疼痛的所有可能方式，以使告警尽可能少。警告应链接到相关的控制台，并易于确定哪个组件有故障。

允许告警有一个缓和时间，以适应可能出现的小尖头信号。

在线服务系统

通常会在堆栈中尽可能高的高延迟和错误率上发出警报。

仅在堆栈中的一点上有延迟进行告警。如果较低级别的组件的速度慢于应有的速度，但总体用户延迟很好，则无需告警。

有关错误率，请参见用户可见错误页面。 如果堆栈中有进一步导致错误的错误，则无需单独翻页。 但是，如果某些故障不是用户可见的，但严重到需要人工干预的程度(例如，您损失了很多钱)，请添加要在这些故障上发送的页面。

如果不同类型的请求具有不同的特征，则您可能需要告警，否则低流量类型的请求中的问题将被高流量请求淹没。

离线处理

对于离线处理系统，关键指标是数据通过系统需要多长时间，如果足够高以至于影响用户，则进行告警。

批处理作业

对于批处理作业，如果最近一次批处理作业还不成功，则可以告警，这将导致用户可见的问题。

通常，这至少应足够用于批处理作业的 2 次完整运行。对于每 4 小时运行一次且需要一个小时的工作，10 小时是一个合理的阈值。如果您无法承受单次运行失败，请更频繁地运行作业，因为单次失败不需要人工干预。

容量

虽然这不是引起立即影响用户的问题，但接近容量通常需要人为干预，以避免在不久的将来发生中断。

Metamonitoring

确保监控正在运行是重要的。因此，需要有告警以确保 Prometheus 服务，Alertmanagers，PushGateways 和其他监控基础结构可用并正确运行。

与往常一样，如果可以告警症结所在而不是原因，则有助于减少噪音。例如，从 PushGateway 到 Prometheus 到 Alertmanager 到邮件的黑盒测试告警比独立的每个告警都更好。

用外部黑盒监控来补充 Prometheus 的白盒监控可以捕获原本看不见的问题，且在内部系统完全故障的情况下也可以作为备用。