任何服务都离不开监控系统，对于管理维护服务的组织来说，监控是必备技能之一。近几年来，容器化、微服务、云原生等方式成为流行的现代架构思想，这给监控系统带来了不小的挑战。具体来说，监控系统需要在动态的云环境或者基于容器的微服务中快速、自动地识别对象的生命周期，并持续地提供近实时的监控检测。

如果我们在指标和指标聚合之上做监控，那么有很多监控方法可供使用，下面我们主要讲讲以下两种监控方法：

Brendan Gregg的USE（Utilization、Saturation和Error）方法，侧重于主机级监控。
Google的四个黄金指标，专注于应用程序级监控。

监控方法提供的指导原则可以让你缩小范围并专注于所收集的海量时间序列中的特定指标。上述两个监控框架，一个侧重于主机级性能，一个侧重于应用程序级性能，结合使用可以获得一个相当全面的环境视图，帮助你解决任何问题。

USE方法

USE是使用率（Utilization）、饱和度（Saturation）和错误（Error）的缩写，该方法是由Netflix的内核和性能工程师Brendan Gregg开发的。USE方法建议创建服务器分析清单，以便快速识别问题。
可以利用从你的环境中收集的数据，对照清单来确定常见的性能问题。

USE方法可以概括为：针对每个资源，检查使用率、饱和度和错误。该方法对于监控那些受高使用率或饱和度的性能问题影响的资源来说是最有效的。让我们快速查看每个术语的定义以帮助理解。

资源：系统的一个组件。在Gregg对模型的定义中，它是一个传统意义上的物理服务器组件，如CPU、磁盘等，但许多人也将软件资源包含在定义中。
使用率：资源忙于工作的平均时间。它通常用随时间变化的百分比表示。
饱和度：资源排队工作的指标，无法再处理额外的工作。通常用队列长度表示。
错误：资源错误事件的计数。

我们将这些定义结合起来创建一份资源清单，并采用一种方法来监控每个要素：使用率、饱和度和错误。它们是如何起作用的呢？假设我们有一个严重的性能问题，想深入了解以便诊断。参考我们的清单并检查每个被监控组件的各个要素。在这个示例中，我们将从CPU开始：

CPU使用率随时间的百分比。
CPU饱和度，等待CPU的进程数。
错误，通常对CPU资源不太有影响。

然后是内存：

内存使用率随时间的百分比。
内存饱和度，通过监控swap测量。
错误，通常不太关键，但也可以捕获。

其他组件以此类推，直到我们找到了问题的瓶颈或信号。

Google的四个黄金指标

Google的四个黄金指标来自Google SRE手册，它们采用与USE类似的方法，指定要监控的一系列通用指标类型。此方法中的指标类型主要关注的不是系统级的时间序列数据，更多是针对应用程序或面向用户的部分：

延迟：服务请求所花费的时间，需要区分成功请求和失败请求。例如，失败请求可能会以非常低的延迟返回错误结果。

流量：针对系统，例如，每秒HTTP请求数，或者数据库系统的事务。
错误：请求失败的速率，要么是HTTP 500错误等显式失败，要么是返回错误内容或无效内容等隐式失败，或者基于策略原因导致的失败—例如，强制要求响应时间超过30ms的请求视为错误。
饱和度：应用程序有多“满”，或者受限的资源，如内存或IO。这还包括即将饱和的部分，例如正在快速填充的磁盘。
黄金指标使用起来很简单。依次选择对应的高阶指标，然后为它们设置警报。如果其中一个指标出现问题，那么警报就会响起，然后你可以去诊断或解决问题。

警报和通知

警报和通知是监控工具的主要输出。那么警报和通知之间有什么区别呢？警报会在某些事件发生（如指标达到阈值）时触发。然而，这并不意味着有人被告知此事件发生，这是通知的来源。通知接收警报并告知某人或某事：通过发送电子邮件、发送短信或者创建工单等。看起来这应该是一个非常简单的领域，但它通常包含很多复杂因素，并且很难实施和管理。

要建立一个出色的通知系统，需要考虑以下基础信息：

哪些问题需要通知
谁需要被告知
如何告知他们
多久告知他们一次
何时停止告知以及何时升级到其他人

如果配置不当，导致生成了过多通知，那么人们将无法对它们采取任何行动，甚至可能将它们忽略掉。我们都有过这样的故事：收件箱中充满了来自监控系统的成千上万封通知邮件。有时，你会因为收到很多通知而出现警报疲劳，并且忽略它们（或者更糟糕的是，对通知邮件直接全选→删除）。因此，你可能会错过真正的重要通知。

最重要的是，你需要考虑通知内容。通常当出现问题或者有事件需要你注意时，通知是唯一的途径。它们需要简洁、清晰、准确，易于理解并且可操作。设计有价值、有意义的通知至关重要。让我们通过一个示例来看看通知内容为什么很重要。以下是Nagios关于磁盘空间的通知。

代码清单1-1　Nagios通知样例

想象一下，你刚刚在凌晨3点36分收到这条通知。它都告诉了你哪些信息？首先，这是一个主机磁盘空间警报，并且/data目录存储已达到91％。乍一看这很有价值，但实际上并没有那么实用。首先，这是由一个存储空间突增导致的？还是逐渐增长的结果？增长速度是多少？（1 GB分区上9％的可用磁盘空间与1 TB磁盘上9％的可用磁盘空间完全不同。）你可以忽略这类通知或将其静音吗？还是需要立即采取行动？如果没有其他上下文，那么采取的行动就会受到限制，你需要投入相当多的时间来收集上下文。

在我们的框架中，将重点关注以下内容：

使通知清晰、准确、可操作。使用由人而不是计算机编写的通知在清晰度和实用性方面有显著差异。
为通知添加上下文。通知应包含组件的其他相关信息。
仅发送有意义的通知。

在这里给出的最简单的建议是记住“通知是供人而不是计算机阅读的”，请用心地设计它们。

作者介绍：

詹姆斯·特恩布尔（James Turnbull）是一位作家和工程师。他最近出版的书包括《The Packer Book》《The Terraform Book》和《The Art of Monitoring》，以及关于开源容器虚拟化技术的《The Docker Book》，还有关于开源日志工具的《The Logstash Book》。詹姆斯还撰写了两本关于Puppet的书：《Pro Puppet》和《Pulling Strings with Puppet》。同时他还是另外三本书的作者：《Pro Linux System Administration》《Pro Nagios 2.0》和《Hardening Linux》。

他目前是Empatico公司的首席技术官，并且曾担任过Kickstarter公司的首席技术官、Docker公司服务和支持副总裁、Venmo公司工程副总裁以及Puppet公司技术运营副总裁。他喜欢品尝美食、喝酒、读书、摄影和养猫。

本文节选自《Prometheus 监控实战》，更多内容请点击此处查看。

相关阅读：

Prometheus 监控实战（一）：监控机制

创作场景

Prometheus 监控实战（二）：监控方法论与报警通知