我们建议您阅读 我的告警哲学，该文档基于 Rob Ewaschuk 在 Google 的观察。
总结：保持告警简单，基于症状告警，拥有良好的控制台以便精确定位原因，并避免出现无事可做的页面。
对于告警规则的命名没有严格的限制，因为告警名称可以包含任意数量的 Unicode 字符，就像任何其他标签值一样。然而，社区已经团结起来使用驼峰命名法来命名告警。
目标是尽可能少地设置告警，通过基于与最终用户痛点相关的症状进行告警，而不是试图捕捉可能导致痛点的每一种方式。告警应链接到相关的控制台，并使其易于找出哪个组件出现故障。
允许告警有一定的余量，以适应小的波动。
通常在堆栈中尽可能高的位置对高延迟和错误率进行告警。
仅在堆栈中的一个点对延迟进行告警。如果较低级别的组件比应有的速度慢，但总体用户延迟正常，则无需告警。
对于错误率，对用户可见的错误进行告警。如果堆栈中更低级别的错误会导致此类故障，则无需单独对它们进行告警。但是，如果某些故障不是用户可见的，但严重到需要人为干预（例如，您正在损失大量金钱），则需要针对这些故障添加告警。
如果不同类型的请求具有不同的特性，或者低流量类型的请求中的问题会被高流量请求淹没，您可能需要针对不同类型的请求设置告警。
对于离线处理系统，关键指标是数据通过系统所需的时间，因此如果该时间过长并导致用户影响，则进行告警。
对于批处理作业，如果批处理作业最近没有成功完成，并且这将导致用户可见的问题，则进行告警是有意义的。
这通常应该至少足够批处理作业完整运行 2 次的时间。对于每 4 小时运行一次且耗时 1 小时的作业，10 小时将是一个合理的阈值。如果您无法承受单次运行失败，请更频繁地运行作业，因为单次失败不应需要人为干预。
虽然这不会立即导致用户影响，但接近容量限制通常需要人为干预以避免在不久的将来发生中断。
重要的是要对监控工作充满信心。因此，设置告警以确保 Prometheus 服务器、Alertmanager、PushGateway 和其他监控基础设施可用且运行正常。
与往常一样，如果可以基于症状而不是原因进行告警，这有助于减少噪音。例如，黑盒测试告警从 PushGateway 到 Prometheus 到 Alertmanager 再到电子邮件是否正常工作，比单独针对每个组件设置告警更好。
用外部黑盒监控补充 Prometheus 的白盒监控可以捕获原本不可见的问题，并且在内部系统完全失败的情况下也可以作为后备方案。
本文档是 开源的。请通过提交 issue 或 pull request 来帮助改进它。