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