该帖子是有效监视系列文章的一部分。请确保检查本系列的其余部分：收集正确的数据并调查性能问题。
自动化警报对于监视至关重要。它们使您可以发现基础结构中任何地方的问题，以便您可以快速找出原因，并最大程度地减少服务降级和中断。要引用同伴帖子，如果度量标准和其他度量有助于观察性，则警报会引起人们对需要观察，检查和干预的特定系统的注意。
但是警报并不总是那么有效。特别是，真正的问题往往在嘈杂的警报中迷失了。本文介绍了一种有效警报的简单方法，无论涉及的系统规模如何。简而言之：
- 保持警惕；明智地翻页
- 关于症状而非原因的页面
本系列文章来自我们为客户监控大型基础架构的经验。它还借鉴了Brendan Gregg，Rob Ewaschuk和Schwartz的作品。
何时提醒某人（或没有人）
警报应使用通俗易懂的语言传达有关您的系统的特定信息：“两个Cassandra节点已关闭”或“所有Web请求中的90％处理和响应所需的时间超过0.5秒。” 在尽可能多的系统中自动执行警报，可以使您对问题做出快速响应并提供更好的服务，还可以使您免于连续手动检查指标的工作，从而节省了时间。
紧急程度的提醒
并非所有警报都具有相同的紧急度。有些需要立即的人工干预，有些需要最终的人工干预，而有些则指向将来可能需要关注的领域。至少应将所有警报记录到中央位置，以便与其他指标和事件轻松关联。
警报作为记录（严重性较低）
许多警报不会与服务问题相关联，因此人员甚至根本不需要意识到它们。例如，当一个支持面向用户服务的数据存储开始提供比平常慢得多的查询，但又慢到不足以使整体服务的响应时间产生明显差异时，这将生成一个低紧急警报，并记录在其中您的监控系统，以供将来参考或调查，但不会中断任何人的工作。毕竟，可能归咎于暂时性的问题（例如网络拥塞）通常会自行消失。但是，如果服务开始返回大量超时，则基于警报的数据将为您的调查提供宝贵的上下文。
警报作为通知（严重程度中等）
紧急警告的下一层是针对确实需要干预但并非立即需要解决的问题。数据存储可能磁盘空间不足，应该在接下来的几天内进行扩展。在服务所有者的聊天室中发送电子邮件和/或发布通知是传递这些警报的理想方法-两种消息类型都是高度可见的，但它们不会在深夜唤醒任何人，也不会破坏工程师的流程。
警报为页面（严重性高）
最紧急的警报应得到特殊处理，并逐步升级到一页（如“ 传呼机 ”中所示），以紧急请人注意。例如，您的Web应用程序的响应时间应具有一个内部SLA，该内部SLA至少应与最严格的面向客户的SLA一样积极。任何响应时间超过您内部SLA的情况，无论何时，都应立即引起注意。
什么时候让熟睡的工程师撒谎
每当您考虑设置警报时，都要问自己三个问题，以确定警报的紧急程度以及应如何处理：
-
这个问题是真的吗？看起来似乎很明显，但是如果问题不是真实的，则通常不应生成警报。以下示例
可以触发警报，但可能并非真正问题的征兆。对此类事件发出警报（或更糟糕的是传呼）会加剧警报疲劳，并可能导致更严重的问题被 忽略：- 测试环境中的指标超出范围
- 单个服务器的工作速度非常慢，但是它是群集的一部分，具有快速故障转移到其他计算机的功能，并且无论如何它都会定期重新启动
- 计划的升级导致大量计算机报告为脱机
如果问题确实是真实的，它应该生成警报。即使
警报未链接到通知，也应将其记录
在监视系统中，以供以后分析和关联。 -
这个问题需要注意吗？如果可以合理地 自动执行对问题的响应，则应考虑这样做。还有就是叫别人下班，睡觉，或离开一个非常真实成本的个人时间。如果问题是真实的*并且*需要引起注意，则应生成警报，通知可以调查和解决问题的人员。至少应通过电子邮件，聊天或票务系统发送通知，以便收件人可以优先考虑他们的响应。
- 这个问题紧急吗？并非所有问题都是紧急情况。对于
例如，也许适度比正常百分比越高系统的反应一直很慢，或者稍微升高
查询的份额正在返回过期数据。这两个问题可能都需要尽快解决，但不能在4:00 AM解决。另一方面，如果某个关键系统停止以可接受的速度进行工作，则工程师 应立即进行查看。如果症状是真实的*和*它 需要注意*和*迫切，它应该产生一个页面。
症状页面
特别值得一提的是：页面在传递信息方面非常有效，但是如果使用过度或链接到设计不当的警报，它们可能会造成破坏。通常，当您负责的系统停止以可接受的吞吐量，延迟或错误率进行有用的工作时，页面是最合适的警报。这些是您想立即知道的问题。
您的系统停止做有用的工作是一种症状 -即，这是一个问题的表现，可能有许多不同的原因。例如：如果您的网站在最近三分钟内响应非常缓慢，则是一种症状。可能的原因包括数据库等待时间长，应用程序服务器故障，Memcached关闭，高负载等等。只要有可能，就围绕症状而不是原因构建页面。请参阅有关数据收集的配套文章，以获取有助于区分症状和原因的度量标准框架。
在症状上分页显示的是实际的（通常是面向用户的）问题，而不是假设的或内部的问题。对症状的分页（例如，网站响应缓慢）与对症状的潜在原因（例如，Web服务器上的高负荷）进行分页。如果网站仍然快速响应，您的用户将不会知道或关心服务器的负载，并且您的工程师会因只在内部引起注意并且可能在没有干预的情况下恢复到正常水平而感到困扰。
持久的警报定义
记录症状的另一个很好的原因是症状触发的警报往往很持久。这意味着，无论底层系统体系结构如何变化，如果系统停止运行正常，即使没有更新警报定义，您也会获得适当的页面。
该规则的例外：预警信号
即使系统运行良好，有时也需要引起人们对少数指标的关注。预警指标反映出严重症状很快就会出现并需要立即干预的高概率。
磁盘空间是一个典型的例子。与耗尽可用内存或CPU不同，当磁盘空间不足时，系统将不太可能恢复，并且您可能只有几秒钟的时间才能硬停止系统。当然，如果您可以提前大量时间通知某人，则无需在深夜唤醒任何人。更好的是，您可以预料某些情况下磁盘空间将用尽，并根据您可以擦除的数据（例如日志或其他地方存在的数据）构建自动修复。
结论：认真对待症状
- 仅在检测到系统工作中出现紧急问题的症状或即将达到关键且有限的资源限制时，才发送页面。
- 设置您的监视系统，以便在检测到基础结构中的实际问题时记录警报，即使这些问题尚未影响整体性能
有问题，更正，补充，投诉等吗？请在GitHub上告诉我们。