Alerting

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

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

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

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

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

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

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

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

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

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

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

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

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

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