告警

我们建议您阅读 Rob Ewaschuk 在 Google 的观察所提出的 关于告警的思考 。

总结一下：保持告警简单，告警症状，提供良好的控制台以方便诊断根本原因，并避免出现无事可做的页面。

命名

告警规则的命名没有严格的限制，因为告警名称可以包含任意数量的 Unicode 字符，就像其他标签值一样。但是，社区已经倾向于  使用 驼峰命名法  作为其告警名称。

告警内容

尽量减少告警数量，通过告警与最终用户痛苦相关的症状来告警，而不是试图捕捉导致痛苦的所有可能方式。告警应链接到相关的控制台，并方便用户找出是哪个组件出了问题。

允许告警有一定的缓冲时间，以应对短暂的异常。

在线服务系统

通常在尽可能高的堆栈层级上告警高延迟和错误率。

只在堆栈中的一个点上告警延迟。如果较低层级的组件比预期慢，但整体用户延迟是正常的，那么就没有必要告警。

对于错误率，应告警用户可见的错误。如果堆栈下方存在可能导致此类故障的错误，则无需单独告警它们。但是，如果某些故障是用户不可见的，但否则严重到需要人工干预（例如，您损失了很多钱），则需要针对这些故障添加告警。

您可能需要针对不同类型的请求设置告警，如果它们的特性不同，或者低流量请求的问题会被高流量请求淹没。

离线处理

对于离线处理系统，关键指标是数据通过系统所需的时间，因此如果时间过长导致用户受到影响，则应发出告警。

批处理作业

对于批处理作业，如果作业最近没有成功运行，并且这会导致用户可见的问题，那么发出告警是有意义的。

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

容量

虽然这不会导致即时用户影响，但接近容量通常需要人工干预，以避免将来发生故障。

元监控

确保监控系统正常运行至关重要。因此，需要设置告警来确保 Prometheus 服务器、Alertmanager、PushGateway 和其他监控基础设施可用且运行正常。

一如既往，如果可能的话，告警症状而不是原因，这有助于减少噪音。例如，一个从 PushGateway 到 Prometheus 再到 Alertmanager 最后到电子邮件的黑盒测试比对每个环节单独告警要好。

用外部黑盒监控来补充 Prometheus 的白盒监控，可以捕获那些否则不可见的潜在问题，并且在内部系统完全失败时还可以作为一种备用方案。