Alerting 报警

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

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

旨在通过警告与最终用户疼痛相关的症状而不是试图捕捉可能导致疼痛的所有可能方式来尽可能少地发出警报。警报应链接到相关控制台，以便轻松找出哪个组件有故障。

允许松弛警报以适应小的昙花一现。

通常警告高延迟和错误率尽可能高。

仅限于堆栈中某一点的延迟。如果较低级别的组件比它应该慢，但整体用户延迟很好，那么就不需要分页。

有关错误率，请参阅用户可见错误页面。如果堆栈中存在导致此类故障的错误，则无需单独对其进行分页。但是，如果某些故障不是用户可见的，但在其他方面严重到需要人为参与（例如，您正在损失大量资金），请添加要发送的页面。

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

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

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

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

虽然不是造成直接用户影响的问题，但是接近容量通常需要人为干预以避免在不久的将来中断。

重要的是要确信监控工作正常。因此，请发出警报以确保Prometheus服务器，Alertmanagers，PushGateways和其他监控基础架构可用并正常运行。

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

通过外部黑盒监控补充对Prometheus的白盒监控可以捕获原本不可见的问题，并且在内部系统完全失效的情况下也可以作为后备。