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