我想上传Datadog的联合创始人Alexis之前在博客中公开的监控理念翻译稿。

监控入门：关注重要事项的警报

这篇文章是关于有效监控的系列之一。请务必查看该系列的其他部分：收集正确的数据和调查性能问题。

这篇文章是「有效监控：监控101」系列的一部分。建议您一起阅读此文章的其他部分，例如「收集正确的数据」和「调查性能问题」。

自动警报对于监控至关重要。它们使您能够在基础设施的任何位置发现问题，以便迅速确定原因并最小化服务的退化和中断。

在监视系统中，自动化的警报通知是必不可少的。通过自动化的警报，我们可以意识到基础设施中出现的问题，找出问题的根源，以最小化影响服务质量降低和中断的可能性。

然而，警报并不总是如其应有的有效。尤其是真正的问题经常会在嘈杂的警报声中被忽略。本文描述了一种简单的方法来有效地进行警报，无论所涉及的系统规模如何。

概括而言：

大胆地发出警报；谨慎地进行页面呼叫
页面提示症状，而不是原因

然而，警報有時可能是無效的，不符其原本意圖。尤其是在警報頻繁觸發的情況下，很多真正需要解決的問題往往被忽視。本文將解釋一種簡單有效的方法來觸發警報。

1. 设置警报和准确通知

 

基于迹象的通知。

这一系列的文章是基于我们对客户大规模基础设施监控的经验，并且借鉴了Brendan Gregg、Rob Ewaschuk和Baron Schwartz的工作。

该系列文章是根据Datadog对客户大规模基础设施进行监控的经验而构建的，参考了Brendan Gregg、Rob Ewaschuk和Baron Schwartz的博客文章。

何时通知某人（或无人）

报警应该用简单的语言传达关于你的系统的特定信息，比如“两个Cassandra节点已宕机”或者“90%的网页请求处理和响应时间超过0.5秒”。尽可能地对系统进行报警自动化能够使你快速应对问题、提供更好的服务，并且还能节省时间，不再需要持续手动检查指标。

警告需要用具体明确的语言来传达系统的状况。例如，“Cassandra节点停机了2台”或者“90%的web请求的响应时间超过0.5秒”。通过尽可能自动化系统的许多警报，我们可以迅速应对故障，并提供更好的服务。此外，解脱出手动检查度量的持续，可以节省大量时间。

警报紧急程度的不同层级

不是所有的警报都具有同样的紧急程度。有些需要立即人工干预，有些需要最终人工干预，还有一些指出需要将来关注的领域。所有的警报至少应被记录在一个中央位置，以便与其他指标和事件进行简单的关联。

所有的警报并不需要相同的紧急程度。其中一些需要立即人工干预，一些需要人工干预产生结果，还有一些指出了需要以后留意并解决的问题。所有的警报都需要在最低限度下记录在一个地方，并能与其他度量指标和事件进行协作。

报警记录（低严重性）

许多警报可能与服务问题无关，所以甚至可能不需要人手介入。例如，当支持用户界面服务的数据存储开始比平常慢很多地提供查询，但并没有足够地影响到整体服务的响应时间时，应该生成一个低紧急性的警报，记录在您的监控系统中以供将来参考或调查，但不会中断任何人的工作。毕竟，可能是网络拥塞等暂时性问题导致的，通常会自行解决。但如果出现重大问题，比如服务开始返回大量超时，基于警报的数据将为您的调查提供宝贵的背景信息。

如果支持用户面对面服务的数据存储查询处理的时间比平常要长，但对于整个服务的响应时间来说并没有显著的差异，那么这些警报可以作为低紧急度处理，不需要中断任何人的工作。这些警报将作为后续的审查和调查材料记录在监控系统中。毕竟，像网络负载过高这样的一时性问题通常会自然解决。相反，如果系统出现严重问题，比如大量超时发生，之前记录的数据将提供宝贵的调查背景。

中文原生译文：中度严重的警报通知。

下一级别的警报紧急性适用于需要干预但并非立即处理的问题。也许数据存储器的磁盘空间即将耗尽，需要在接下来的几天内进行扩容。通过发送电子邮件和/或在服务所有者的聊天室中发布通知，可以完美地传递这些警报——这两种形式的消息都非常显眼，但不会在深夜叫醒任何人或打乱工程师的工作流程。

以下是对该段话的汉语本地化翻译：

下一级别的警报紧急程度需要人为介入，但并不需要立即处理的是对于不需要立即对其采取措施的故障等级。例如，如果数据存储使用的磁盘剩余空间不足，需要在数天内进行补充。将邮件发送或在服务所有者的聊天室发布通知是这类警报最佳的传递方式。这两种类型的消息具有较高的可视性，但不会在深夜打扰任何人，也不会妨碍工程师的思考。

警报作为页面显示（高级别）。

最紧急的警报应该得到特殊对待，并被升级到页面（如 “寻呼机 “）上，以紧急请求人工关注。例如，您的网络应用的响应时间应该具有至少与您最严格面向客户的服务级别协议一样激进的内部服务级别协议。无论何时，任何响应时间超过您内部服务级别协议的情况都应该立即引起注意。

对于需要最高紧急性的警报，需要进行特殊处理，以立即引起人们的注意，例如通过传呼机（电话联系或寻呼机联系）进行升级。例如，对于网页应用程序的响应时间，应该设定至少考虑最严厉客户的服务级别协议。对于超过内部服务级别协议标准的网页应用程序响应时间的增加，无论是哪个时间点，都需要迅速回应。

何时让一个正在睡觉的工程师继续睡着。

每次你考虑设置警报时，请问自己三个问题来确定警报的紧急程度和处理方式。

在考虑设置警报时，你可以通过以下三个问题来确定警报的紧急性和处理方式。

这个问题是真实的吗？看起来很明显，但是如果问题并非真实存在，通常不应产生警报。下面的示例可能会触发警报，但可能并非真正的问题症状。对于这些情况的警报（甚至是呼叫），会导致警报疲劳，更严重的问题可能会被忽略：

1. 测试环境中的指标超出范围。
2. 单个服务器的工作速度非常慢，但它是一个具有快速故障切换到其他机器的群集的一部分，而且会定期重启。
3. 计划升级导致大量机器报告离线。

如果问题确实存在，应该产生警报。即使警报没有与通知相关联，也应该在监控系统中记录以供后续分析和关联使用。

这个问题需要关注吗？如果您可以合理地自动处理问题的响应，应该考虑这样做。将人从工作、睡眠或个人时间中召唤出来确实存在非常真实的成本。如果问题确实存在并需要关注，应该生成一个通知，通知可以让能够调查和解决问题的人收到。至少，通知应该通过电子邮件、聊天或票务系统发送，以便收件人可以根据优先级回应。

这个问题是否紧急？并非所有问题都是紧急的。例如，也许系统响应的比正常情况稍微慢一些，或者查询返回的数据可能略有过时。这两个问题可能需要尽快解决，但不必在凌晨4点处理。另一方面，如果一个重要系统停止以可接受的速率工作，工程师应该立即查看。如果症状是真实存在的，需要关注且紧急，应该触发一个呼叫。

1. 这个问题是真实的吗？听起来可能很明显，但是如果问题并没有真实出现，通常不应该触发警报。在以下的例子中，可以触发警报，但可能不是真实问题的迹象。在这种情况下，触发警报或者进行分页操作会导致人们习惯于警报，并引起更严重的忽视问题。如果这些问题是真实存在的，应该触发警报。即使警报并未与通知相关联，这些问题应该记录在监控系统中以供后续分析和融合之用。

这个问题需要关注吗？如果有合理的可能性，可以考虑自动化处理问题，并且实际上应该考虑自动化。从工作、睡眠和个人时间中召唤某人是一项付出实际成本的行为。如果出现的问题是真实问题，需要人的干预，那么应该向能够调查和修复问题的人员触发警报及通知。这些通知应该被发送至最低限度的电子邮件、聊天和工单系统，以让接收者能够确定优先级。

这个问题紧急吗？并不是所有的问题都是紧急情况。例如，系统响应需要稍长时间或者响应查询使用旧数据的数量略有增加，这些都是较低紧急度的问题。这些问题都需要解决，但并不需要在凌晨4点。相反，如果核心系统无法处理接受的操作，则工程师需要立即处理。如果出现真实问题，需要人的干预，并且有紧急性，那么应该进行分页。

症状页面

页面值得特别提及：它们非常有效地传递信息，但如果过度使用或与设计不佳的警报相关联，它们可能会产生很大的干扰。总体而言，在您负责的系统停止以可接受的吞吐量、延迟或错误率执行有效工作时，页面是最合适的警报类型。这些都是您希望立即了解的问题。

在以下显示的情况下，页面特别重要：页面非常有效地传递信息。但是，如果使用过度或与不正确考虑的警报相关联，它会非常具破坏性。通常，页面是指您负责的系统在吞吐量、延迟和错误率超过可接受范围时的适当警报。这些是马上需要知道的故障类型。

你的系统停止了有用的工作，这是一个症状，也就是说它表明可能存在各种不同的问题引起的。例如：如果你的网站在过去的三分钟里响应非常慢，那就是一个症状。可能的原因包括数据库延迟高、应用服务器故障、Memcached关停、负载过高等等。尽可能地，将你的页面建立在症状之上，而不是原因之上。请参阅我们的《数据收集》配套文章，了解一个度量框架，它有助于将症状和原因分开。

实际上，系统不再执行有益的工作是一种症状。这些症状可能是多种不同原因导致的故障迹象。例如，如果最近3分钟内的网站响应非常缓慢，那就是一种症状。可能的原因可能是数据库查询时间过长，应用服务器停止运行，Memcached停止运行，或者负载过高。因此，在页面设置时，尽可能基于症状而不是原因。有关详细信息，请参阅关于数据收集的[附属文章链接]以进行症状和原因的区分框架。

症状分页真实地呈现出往往面向用户的问题，而非假设或内部问题。将症状，比如网站响应缓慢，与可能引起该症状的原因进行分页，比如网络服务器负载过高。如果网站仍然快速响应，您的用户将不会知道或关心服务器负载，而您的工程师也会因为一些只有内部可察觉，并且可能会自然恢复正常的问题而受到打扰。

基于症状，我们页面化的目的是将用户正面遇到的实际问题显现出来，而不是虚设或内部问题。以“网站响应慢”这一症状为基础的页面与以“服务器负载高”这一可能原因为基础的页面进行对比，如果网站能够快速响应，用户会对服务器是否负载高并不敏感，也不会在意。而工程师也不会因为只有内部人员能够理解且可以通过不干预自行恢复的事情而感到愤慨。

持久的警报定义

另一个使用症状警报的好处是，这些触发症状的提醒通常是持久的。这意味着无论底层系统架构如何变化，如果系统的工作状态出现问题，即使不更新警报定义，您也能收到相应的页面提醒。

基于征候的另一个好处是征候警报具有较长的持久性。无论基础系统发生了变化与否，如果系统没有按预期进行工作，即使没有更新警报设置，您仍然可以收到适当的页面。

规则的例外：预警信号

即使系统运行良好，有时仍有必要引起人们对一小部分指标的注意。预警指标反映了严重症状即将出现并需要立即干预的可能性非常高。

即使系统功能正常，有时候也需要人的注意来引起对一些指标的关注。早期警戒指标是指那些可能在严重状态发生之前迅速出现的迹象，需要人类快速干预。

磁盘空间是一个经典的例子。与内存或CPU的空闲不足不同，当磁盘空间不足时，系统不太可能恢复，并且你可能只有几秒钟的时间，然后系统就会彻底停止运行。当然，如果你能提前通知有足够时间的人，那么就没有必要在深夜叫醒任何人。更好的办法是，你可以预见到某些情况下磁盘空间会不足，并根据可以删除的数据（如日志或其他地方存在的数据）构建自动修复机制。

磁盘的剩余空间是一个典型的例子。与可用内存和CPU不同的是，一旦磁盘的剩余空间用尽，系统将无法自动恢复到正常状态，而且系统停止可能只有几秒钟。当然，还可以花费很长的时间通知某人。这样，就不需要在半夜把某人叫醒。更好的方法是预测磁盘容量不足的情况，并采取措施自动删除日志数据或已备份的数据等可以丢弃的数据的方法来规避问题。

結論：對症狀嚴肅對待。

只有在检测到系统工作出现紧急问题的症状，或者即将达到关键有限资源限制时，发送页面信息。
建立您的监控系统，以便在检测到基础设施中出现真实问题时记录警报，即使这些问题尚未对整体性能产生影响。

• システム内に緊急性の高い問題の徴候が検知された時、又は、重大な危機を発生させる要素を持った有限なリソースの限界が近い場合にページを送信します。

 

まだ全体のパフォーマンスに影響を与えていない場合でも、インフラ内で考慮するべき問題をアラートが検知した際は、そのアラートを記録するように監視システムを設定しておきます。

我们希望听到您在将此框架应用于您自己的监测实践中的经验。如果它起作用良好，请在Twitter上告诉我们！有任何问题、更正、补充、投诉等，请在GitHub上告诉我们。

请分享您通过本框架学到的东西并将其应用到曾经独立实践的监控体系中，以及对新的监控体系的经验。如果通过采用该框架改善了监控效果，希望您能在Twitter上@datadoghq并发推文告知。此外，如果有任何问题、修正、追加、投诉或其他事项，请通过Github的问题页面与我们联系。