Alerting

我们建议您根据Rob Ewaschuk在Google上的观察，阅读我的“基于警报的哲学”。

总结：保持警报简单，警惕症状，有良好的控制台允许精确定位原因，并避免有页面无关。

What to alert on

旨在尽可能少的警报，通过警告与最终用户疼痛相关的症状，而不是试图捕捉可能导致疼痛的每一种可能的方式。 警报应该链接到相关的控制台，并且很容易找出哪个组件有故障。

允许松动的警报以适应小的蓝牙。

在线服务系统

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

只有一个堆栈中的一点的延迟页面。 如果一个较低级别的组件比它应该更慢，但总体的用户延迟是好的，那么就不需要页面了。

对于错误率，页面上的用户可见错误。如果堆栈中存在将导致此类故障的错误进一步下降，则不需要单独打开它们。但是，如果某些故障不是用户可见的，但是其他方面的严重程度要求人员参与（例如，您损失了大量资金），请添加要发送的页面。

如果不同类型的请求具有不同的特征，您可能需要提供不同类型的请求，或者低流量请求中的问题将被高流量请求淹没。

离线处理

对于离线处理系统，关键指标是数据通过系统需要多长时间，因此，如果数据获取足够高以引起用户影响，那么页面。

批量工作

对于批处理作业，如果批处理作业最近没有成功，那么页面是有意义的，这将导致用户可见的问题。

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

容量

尽管不是立即造成用户影响的问题，但接近能力往往需要人为干预，以避免在不久的将来中断。

元监控

有信心监测工作很重要。 因此，提供警报以确保Prometheus服务器，Alertmanagers，PushGateways和其他监控基础设施可用并正常运行。

和往常一样，如果可以提醒症状而不是原因，这有助于减少噪音。 例如，一个黑匣子测试，从PushGateway到Prometheus到Alertmanager发送电子邮件的警报比每个警报更好。

使用外部黑盒监控来补充普罗米修斯的白盒监控可以捕获否则不可见的问题，并且还可以作为内部系统完全失败的后备。