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