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