我们建议你阅读基于 Rob Ewaschuk 在 Google 的观察所写的 My Philosophy on Alerting。
总结：保持告警简单，基于症状告警，提供良好的控制台以便定位原因，避免设置无需采取行动的告警页面。
命名
告警规则的命名没有严格的限制，因为告警名称可以包含任意数量的 Unicode 字符，就像其他标签值一样。然而，社区已经形成共识使用驼峰命名法（Camel Case）来命名告警。
告警什么
目标是尽可能少地设置告警，通过对与终端用户痛点相关的症状进行告警，而不是试图捕捉每一种可能导致问题的方式。告警应该链接到相关的控制台，并使排查出问题的组件变得容易。
在告警中留出余量以适应小的波动。
在线服务系统
通常在尽可能高的层级对高延迟和高错误率进行告警。
在一个层级中只对延迟进行呼叫告警。如果较低层级的组件比应有的速度慢，但整体用户延迟正常，则不需要呼叫告警。
对于错误率，对用户可见的错误进行呼叫告警。如果在更深层级存在会导致此类故障的错误，则不需要对它们单独进行呼叫告警。然而，如果某些故障不是用户可见的，但严重到需要人工介入（例如，你正在损失大量资金），则添加对这些情况的呼叫告警。
如果不同类型的请求具有不同的特征，或者低流量请求类型中的问题会被高流量请求淹没，你可能需要为不同类型的请求设置不同的告警。
离线处理
对于离线处理系统，关键指标是数据通过系统所需的时间，因此如果这个时间长到会造成用户影响，就应该发出呼叫告警。
批处理作业
对于批处理作业，如果作业最近未成功完成且这将导致用户可见的问题，发出呼叫告警是合理的。
通常，阈值应该至少足够批处理作业完整运行 2 次。对于每 4 小时运行一次、耗时 1 小时的作业，10 小时是一个合理的阈值。如果你无法承受单次运行失败，请更频繁地运行作业，因为单次失败不应该需要人工干预。
容量
虽然不会立即造成用户影响，但接近容量上限通常需要人工干预以避免不久后出现故障。
元监控
确信监控系统正在正常工作很重要。因此，应该设置告警以确保 Prometheus 服务器、Alertmanager、PushGateway 和其他监控基础设施可用且运行正常。
一如既往，如果可以对症状而非原因进行告警，这有助于减少噪音。例如，一个检测告警是否从 PushGateway 发送到 Prometheus 再到 Alertmanager 最后到邮件的黑盒测试，比每个组件单独的告警要好。
用外部黑盒监控来补充 Prometheus 的白盒监控，可以捕获那些否则不可见的问题，同时也可以作为内部系统完全失败时的后备方案。