我们建议您阅读 我的告警理念，该理念基于 Rob Ewaschuk 在 Google 的观察结果。
概括来说：保持告警简单，告警症状，使用良好的控制台来帮助确定原因，并避免在没有可执行操作的情况下发送告警。
告警规则的命名没有严格的限制，因为告警名称可以包含任意数量的 Unicode 字符，就像任何其他标签值一样。但是，社区已经形成共识，使用 驼峰命名法 来命名告警。
尽量减少告警数量，通过告警与最终用户痛点相关的症状，而不是试图捕捉所有可能导致痛点的途径。告警应链接到相关的控制台，并方便确定哪个组件出现故障。
允许告警中存在一定的松弛度，以适应小的波动。
通常在尽可能高的堆栈层级上告警高延迟和错误率。
在堆栈中的一个点上仅针对延迟发送告警。如果较低层级的组件比预期慢，但整体用户延迟正常，则无需发送告警。
对于错误率，针对用户可见的错误发送告警。如果堆栈中更下层的错误会导致此类故障，则无需单独对其发送告警。但是，如果某些故障对用户不可见，但严重到需要人工干预（例如，您损失了很多钱），则添加针对这些故障的告警。
如果不同类型的请求具有不同的特性，或者低流量类型的请求中的问题会被高流量请求淹没，您可能需要针对不同类型的请求设置告警。
对于离线处理系统，关键指标是数据通过系统需要多长时间，因此如果数据处理时间过长导致用户受到影响，则发送告警。
对于批处理作业，如果批处理作业最近没有成功完成，并且这会导致用户可见的问题，则发送告警。
这通常至少需要足够的时间来完成批处理作业的两次完整运行。对于每 4 小时运行一次且需要 1 小时的作业，10 小时将是一个合理的阈值。如果您无法承受单个作业失败，请更频繁地运行该作业，因为单个作业失败不应需要人工干预。
虽然不是导致用户立即受到影响的问题，但接近容量通常需要人工干预以避免在不久的将来发生中断。
确信监控工作正常非常重要。因此，设置告警以确保 Prometheus 服务器、Alertmanagers、PushGateways 和其他监控基础设施可用并正常运行。
与以往一样，如果可以告警症状而不是原因，这有助于减少噪音。例如，从 PushGateway 到 Prometheus 到 Alertmanager 再到电子邮件的告警黑盒测试，比每个组件上的单个告警更好。
使用外部黑盒监控补充 Prometheus 的白盒监控可以捕获其他方式不可见的故障，并在内部系统完全失败时作为后备方案。
本文档是 开源的。请通过提交问题或拉取请求来帮助改进它。