Datadog 监控最佳实践 - 针对重要事项发出警报
本文是Datadog“高效监控”系列的第2篇，后面还会有第3篇《Datadog 监控最佳实践 - 调查性能问题》。第一篇可以参考《Datadog 监控最佳实践 - 收集正确的数据》。
自动警报对于监控至关重要。它们使您能够发现基础设施中任何地方的问题，以便您可以快速确定其原因并最大限度地减少服务降级和中断。指标和其他一些度量手段有助于可观察性，警报呢，会引起人们的注意。
但警报并不总是那么有效。特别是，真正的问题常常被淹没在喧闹的警报声中。本文介绍了一种有效警报的简单方法，无论所涉及的系统规模如何。简而言之：
- 保持警惕；明智地响应
- 对症状告警，而非对原因告警
本系列文章源自我们为客户监控大型基础设施的经验。它还借鉴了Brendan Gregg、Rob Ewaschuk 和 Baron Schwartz 的工作。
何时提醒某人
警报应以简单的语言传达有关您的系统的特定信息：“两个 Cassandra 节点已关闭”或“90% 的 Web 请求的处理和响应时间超过 0.5 秒”。在尽可能多的系统中自动发出警报可以让您快速响应问题并提供更好的服务，而且还可以使您免于持续手动检查指标，从而节省时间。
警报紧急程度
并非所有警报都具有相同程度的紧急程度。有些需要立即人工干预，有些需要最终人工干预，有些则指出未来可能需要关注的领域。所有警报至少应记录到一个中心位置，以便于与其他指标和事件关联。
低严重等级的设置为 record
许多警报不会与服务问题相关，因此人们可能永远不需要意识到它们。例如，当支持面向用户的服务的数据存储开始提供查询服务的速度比平时慢得多，但还没有慢到足以对整体服务的响应时间产生明显的影响时，应该会生成一个低紧急性警报，该警报记录在您的监控系统以供将来参考或调查，但不会中断任何人的工作。毕竟，网络拥塞等暂时性问题通常会自行消失。但是，如果服务开始返回大量超时，基于警报的数据将为您的调查提供宝贵的背景信息。
中严重等级的设置为 notification
下一个等级是针对确实需要干预但不是立即干预的问题。也许数据存储的磁盘空间不足，应该在接下来的几天内进行扩展。发送电子邮件和/或在服务所有者的聊天室中发布通知是传递这些警报的完美方式 - 两种消息类型都非常明显，但它们不会在半夜吵醒任何人或扰乱工程师的工作流程。
高严重等级的设置为 page
最紧急的警报应接受特殊处理并升级到 page 以紧急请求人工关注。例如，您的 Web 应用程序的响应时间应该有一个内部 SLA，该 SLA 至少与最严格的面向客户的 SLA 一样严格。任何响应时间超过内部 SLA 的情况都需要立即引起注意，无论何时。
别惊动熟睡的工程师
每当您考虑设置警报时，请问自己三个问题来确定警报的紧急程度以及应如何处理：
1、这个问题是真的吗？ 这看起来似乎很明显，但如果问题不真实，通常不应生成警报。下面的示例可以触发警报，但可能并不是真正问题的症状。对此类事件发出警报（或者更糟的是进行寻呼）会导致警报疲劳，并可能导致更严重的问题被忽视：
- 测试环境中的指标超出范围
- 一台服务器的工作速度非常慢，但它是集群的一部分，可以快速故障转移到其他机器，而且它会定期重新启动
- 计划升级导致大量计算机报告脱机
如果问题确实存在，则应该生成警报。即使警报未链接到通知，也应将其记录在监控系统中以供以后分析和关联。
2、这个问题需要注意吗？ 如果您可以合理地自动响应问题，那就自动响应。叫某人离开工作、睡觉或私人时间，会带来非常实际的成本。如果问题确实存在并且需要引起注意，则应生成警报，通知可以调查并解决问题的人员。通知至少应通过电子邮件、聊天或工单系统发送，以便接收人可以确定其优先级。
3、这个问题紧急吗？ 并非所有问题都是紧急情况。例如，可能比正常百分比稍高的系统响应速度非常慢，或者可能稍微增加的查询比例返回过时的数据。这两个问题可能都需要尽快解决，但不是在凌晨 4:00 解决。另一方面，如果关键系统无法以可接受的速度工作，工程师应立即查看。如果症状真实存在，需要引起注意且紧急，则应该生成一个紧急告警。
针对症状告警
page 值得特别提及：它们对于传递信息非常有效，但如果过度使用，或者如果它们链接到设计不良的警报，它们可能会造成相当大的破坏。一般来说，当您负责的系统停止正常工作（有一个可接受的吞吐、延迟、错误率）时，page 是最合适的警报类型。这些都是您想要立即了解的问题。
“您的系统停止做有用的工作”这一事实是一种症状，也就是说，它是各类原因、各类问题导致的一个结果、一个症状。例如：如果您的网站在过去三分钟内响应非常缓慢，那就是一种症状。可能的原因包括数据库延迟高、应用程序服务器出现故障、Memcached 关闭、高负载等。只要有可能，就围绕症状而不是原因配置告警。哪些指标适合作为症状配置告警？请参考《Datadog 监控最佳实践 | 收集正确的数据》。
对症状进行告警，通常都会体现用户面临的真实问题，而非一些假设的或内部的问题。除了症状类告警，另一类就是那些潜在原因的告警比如 Web 服务器高负载，如果您的网站仍然响应很快，用户根本不关心服务器是否高负载，而您的工程师也会很反感这类实际不影响用户的内部问题，而且，这类告警可能无需人工介入就自动恢复了。
耐久的告警定义
针对症状告警的另一个好处，是因为这类告警通常都是耐久的。不管底层的系统架构如何变化，只要系统没有按照预期工作，即便你没有更新告警定义，也仍然可以收到告警提醒。换言之，如果你的告警依赖于太底层的指标，那么当系统架构发生变化时，你的告警可能会失效。
规则的例外：早期的预警信号
有时，即使系统运行良好，也有必要让人们注意一小部分指标。早期预警指标反映了严重症状很快出现并需要立即干预的可能性很高。
磁盘空间就是一个典型的例子。与耗尽可用内存或 CPU 不同，当磁盘空间耗尽时，系统不太可能恢复，并且系统可能只有几秒钟的时间硬停止。当然，如果你可以提前通知某人，那么就没有必要在半夜吵醒任何人。更好的是，您可以预测磁盘空间不足的情况，并根据您可以擦除的数据（例如其他地方存在的日志或数据）构建自动修复。
结论：认真对待症状
- 仅当系统出现紧急问题、或者资源耗尽时，才应该发出严重警报。别动不动啥告警都打电话。
- 设置您的监控系统，以便在检测到基础设施中的实际问题时记录警报，即使这些问题尚未影响整体性能。该记录的还是要记录，以便后续分析。这类告警不要用强打扰的媒介。
原文：https://www.datadoghq.com/blog/monitoring-101-alerting/
