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