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