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