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