告警

我们建议你阅读基于 Rob Ewaschuk 在 Google 观察的基础上撰写的 My Philosophy on Alerting。

简而言之：保持告警机制相对简单，针对与用户痛点相关的症状进行告警，提供良好的控制台以帮助定位问题原因，并避免出现没有有效信息的页面。

命名规则

告警规则的命名没有严格的限制，可以包含任意数量的 Unicode 字符，就像其他标签值一样。但是，社区已经统一使用了驼峰命名法（Camel Case）来命名告警。

尽量减少告警的数量，通过针对与用户最关心的确切症状进行告警，而不是试图抓住所有用户可能会关注的边缘情况。告警应链接到相关控制台，使用户能够轻松确定故障的组件。

允许在告警的设置中留有一定余地，以应对短暂的波动。

通常情况下，在架构的较高层上对高延迟和错误率进行告警。

只需在架构中的一个点上进行延迟告警。如果低级组件运行速度低于预期，但整体用户延迟正常，就没有必要发出告警。

对于错误率，只需对用户可见的错误进行告警。如果架构下层存在导致此类失败的错误，就没有必要单独发出告警。然而，如果一些错误对用户不可见，但其严重程度足以需要人工介入（例如，正在损失大量资金），则应添加页面发送这些告警。

根据请求的不同类型可能需要不同的告警。低流量类型的请求出现的问题可能会被高流量请求掩盖。

对于离线处理系统，关键指标是数据通过系统所需的时间，因此当该时间足够长以影响用户时才进行告警。

对于批量作业，如果最近未能成功执行，且这会导致用户可以感知的故障，则应发出告警。

通常情况下，阈值应该大于或等于两次完整运行批量作业所需的时间。对于每4小时运行一次并耗时1小时的作业，10小时可能是合理的阈值。因为单次运行失败通常不需要人工干预，所以如果无法容忍单次失败，可以尝试更频繁地运行作业。

虽然可用空间接近容量上限不会立刻影响到用户，但通常我们需要进行人工干预以避免短期内发生容量短缺。

确保监控工作正常运行至关重要。因此，需要告警机制确保 Prometheus 服务器、Alertmanagers、PushGateways 以及其他监控基础设施可用并正确运行。

为了尽可能减少噪音，应始终尽可能在症状而非原因上发出告警。例如，在一个黑盒测试中，从 PushGateway 到 Prometheus 再到 Alertmanager 再到电子邮件发出的告警比分别在每个组件上单独发出的告警要更好。

通过外部黑盒监控补充 Prometheus 的白盒监控，可以帮助我们捕获内部系统完全失效时可能看不到的故障，并作为内部系统完全失效时的备用方案。

该文档基于 Prometheus 官方文档翻译而成。