了解系统状态对于确保应用程序和服务的可靠性和稳定性至关重要。有关部署运行状况和性能的信息不仅可以帮助您的团队对问题做出反应，还可以让他们放心地进行更改。获得这种洞察力的最佳方法之一是使用强大的监控系统，该系统可以收集指标、可视化数据并在出现问题时提醒操作员。

在我们对指标、监控和警报指南的介绍中，我们讨论了一些涉及监控软件和基础设施的核心概念。指标是监控系统处理的主要材料，用于构建被跟踪系统的内聚视图。了解哪些组件值得监控以及您应该查看哪些具体特征是设计一个系统的第一步，该系统可以提供有关您的软件和硬件状态的可靠、可操作的见解。

在本指南中，我们将首先讨论用于确定要跟踪的最关键指标的流行框架。之后，我们将介绍如何在整个部署过程中将这些指标应用于组件。此过程将首先关注单个服务器的基础资源，然后调整范围以涵盖越来越大的关注领域。

监控的黄金信号

在极具影响力的 Google SRE（站点可靠性工程）书中，关于监控分布式系统的章节介绍了一个有用的框架，称为监控的四个黄金信号，它代表了在面向用户的系统中要衡量的最重要的因素。我们将在下面讨论这四个特征中的每一个。

延迟

延迟是对完成操作所需时间的度量。具体如何测量取决于组件，但一些常见的类似物是处理时间、响应时间或行程时间。

测量延迟可让您具体衡量完成特定任务或操作所需的时间。捕获各种组件的延迟允许您构建系统不同性能特征的整体模型。这可以帮助您找到瓶颈，了解访问哪些资源需要最多的时间，并注意到操作突然花费的时间比预期的时间长。SRE 一书的作者强调在计算延迟时区分成功和不成功请求的重要性，因为它们可能具有非常不同的配置文件，可能会扭曲服务的平均值。

流量

流量衡量您的组件和系统的“繁忙程度”。这会捕获您的服务的负载或需求，以便您了解您的系统当前正在执行多少工作。

持续的高或低流量数字可能表明服务可能需要更多资源，或者问题阻止流量正确路由。但是，在大多数情况下，流量率对于帮助了解通过其他信号浮出水面的问题最有用。例如，如果延迟增加超过可接受的水平，能够将该时间范围与流量峰值相关联是有帮助的。流量可用于了解可以处理的最大流量以及服务在不同负载阶段如何降级或失败。

错误

跟踪错误以了解组件的健康状况以及它们未能正确响应请求的频率非常重要。某些应用程序或服务会在干净、现成的界面中暴露错误，但可能需要额外的工作来从其他程序收集数据。

区分不同类型的错误可以更轻松地查明影响应用程序的问题的确切性质。这也为您提供了警报的灵活性。如果出现一种类型的错误，您可能需要立即收到警报，但对于另一种错误，只要比率低于可接受的阈值，您就不会担心。

饱和

饱和度衡量给定资源的使用量。百分比或分数经常与具有明确总容量的资源一起使用，但对于没有明确定义的最大值的资源，可能需要更具创造性的测量。

饱和度数据提供有关服务或应用程序有效运行所依赖的资源的信息。由于一个组件提供的服务可能会被另一个组件使用，因此饱和度是暴露底层系统容量问题的粘合指标之一。因此，一层中的饱和和延迟问题可能与底层中流量或错误测量的显着增加相对应。

测量整个环境中的重要数据

使用四个黄金信号作为指导，您可以开始查看这些指标在整个系统层次结构中的表达方式。由于服务通常是通过在更基本的组件之上添加抽象层来构建的，因此应设计指标以在部署的每个级别添加洞察力。

我们将研究常见分布式应用程序环境中存在的不同级别的复杂性：

?单独的服务器组件?应用程序和服务?服务器集合?环境依赖?端到端体验

上面的顺序扩展了每个后续层的抽象范围和级别。

为单个服务器组件收集的指标

需要收集的基本级别指标是与您的系统所依赖的底层计算机相关的指标。尽管现代软件开发在抽象物理组件和低级操作系统细节方面付出了相当大的努力，但每项服务都依赖于底层硬件和操作系统来完成其工作。因此，密切关注机器的基础资源是了解系统健康状况的第一步。

在考虑在机器级别收集哪些指标时，请考虑可用的单个资源。这些将包括服务器硬件的表示以及操作系统提供的核心抽象，如进程和文件描述符。从四个黄金信号的角度来看每个组成部分，某些信号可能很明显，而其他信号可能更难以推理。

Brendan Gregg 是一位有影响力的性能工程师，他概述了许多从 Linux 系统获取核心指标的方法，以满足他称为性能分析（利用率、饱和度和错误）的 USE 方法的框架的需求。由于 USE 方法和四个黄金信号之间存在显着重叠，我们可以使用他的一些建议作为起点，以确定从服务器组件收集哪些数据。

要测量 CPU，以下测量可能是合适的：

?延迟：CPU 调度程序的平均或最大延迟?流量：CPU 利用率?错误：特定于处理器的错误事件、故障 CPU?饱和度：运行队列长度

对于内存，信号可能如下所示：

?延迟：（无 - 很难找到一种好的衡量方法且不可操作）?流量：正在使用的内存量?错误：内存不足错误?饱和度：OOM 杀手事件，交换使用

对于存储设备：

?延迟：读取和写入的平均等待时间（await）?流量：读写 I/O 级别?错误：文件系统错误、/sys/devices 中的磁盘错误?饱和度：I/O 队列深度

网络信号可能如下所示：

?延迟：网络驱动程序队列?流量：每秒传入和传出的字节或数据包?错误：网络设备错误、丢包?饱和度：溢出、丢包、重传段

除了物理资源的表示外，收集与强制执行限制的操作系统抽象相关的指标也是一个好主意。属于此类别的一些示例是文件句柄和线程计数。这些不是物理资源，而是由操作系统设置的上限构造，以防止进程过度扩展自身。大多数都可以使用 ulimit 之类的命令进行调整和配置，但跟踪这些资源使用的变化可以帮助您检测软件使用中潜在的有害变化。

为应用程序和服务收集的指标

向上移动一层，我们开始处理在服务器上运行的应用程序和服务。这些程序使用我们之前处理的单个服务器组件作为资源来完成工作。此级别的指标可帮助我们了解单主机应用程序和服务的运行状况。我们已将分布式多主机服务分成一个单独的部分，以阐明这些配置中最重要的因素。

虽然上一节中的指标详细说明了各个组件和操作系统的功能和性能，但此处的指标将告诉我们应用程序能够执行我们要求它们的工作的能力。我们还想知道我们的应用程序依赖哪些资源以及它们如何管理这些约束。

重要的是要记住，本节中的指标与我们上次能够使用的通用方法有所不同。从现在开始，最重要的指标将非常依赖于您的应用程序的特征、配置以及您在机器上运行的工作负载。我们可以讨论确定最重要指标的方法，但您的结果将取决于具体要求服务器执行的操作。

对于为客户服务的应用程序，四个黄金信号通常很容易挑选：

?延迟：完成请求的时间?流量：每秒服务的请求数?错误：处理客户端请求或访问资源时发生的应用程序错误?饱和度：当前正在使用的资源的百分比或数量

您需要跟踪的一些更重要的指标是与依赖项相关的指标。这些通常最好通过与单个组件相关的饱和度指标来表达。例如，应用程序内存利用率、可用连接、打开的文件句柄数量或活动的工作人员数量可以帮助您了解在物理服务器上下文中应用的配置的效果。

这四个黄金信号主要是为分布式微服务设计的，因此它们采用客户端-服务器架构。对于不使用客户端-服务器架构的应用程序，相同的信号仍然很重要，但“流量”信号可能需要稍微重新考虑。这基本上是对繁忙度的衡量，因此找到一个能够充分代表您的应用程序的指标将达到相同的目的。具体将取决于您的程序正在做什么，但一些通用的替代品可能是每秒处理的操作数或数据。

衡量服务器集合及其通信的指标

大多数服务，尤其是在生产环境中运行时，将跨越多个服务器实例以提高性能和可用性。这种增加的复杂程度增加了对监测很重要的额外表面积。分布式计算和冗余系统可以使您的系统更加灵活，但基于网络的协调比单个主机内的通信更脆弱。强大的监控可以帮助减轻处理不太可靠的通信渠道的一些困难。

除了网络本身，对于分布式服务，服务器组的健康和性能比应用于任何单个主机的相同措施更重要。虽然服务在局限于单个主机时与其运行的计算机密切相关，但冗余多主机服务依赖于多台主机的资源，同时与对任何一台计算机的直接依赖保持分离。

此级别的黄金信号与上一节中衡量服务健康状况的信号非常相似。但是，他们将考虑到组成员之间所需的额外协调：

?延迟：池响应请求的时间，与对等方协调或同步的时间?流量：池每秒处理的请求数?错误：处理客户端请求、访问资源或到达对等点时发生的应用程序错误?饱和度：当前使用的资源量、当前满负荷运行的服务器数量、可用的服务器数量。

虽然这些与单主机服务的重要指标有明确的相似之处，但每个信号在分布时都会变得更加复杂。延迟成为一个更复杂的问题，因为处理可能需要多个主机之间的通信。流量不再是单个服务器能力的函数，而是组能力和用于分配工作的路由算法效率的总结。引入了与网络连接或主机故障相关的其他错误模式。最后，饱和度扩展到包括主机可用的组合资源、连接每个主机的网络链接以及正确协调对每台计算机所需依赖项的访问的能力。

与外部依赖和部署环境相关的指标

要收集的一些最有价值的指标存在于您的应用程序或服务的边界，不受您的直接控制。外部依赖项，包括与您的托管服务提供商和您的应用程序构建依赖的任何服务相关的依赖项。这些代表您无法直接管理的资源，但会损害您保证自己服务的能力。

由于外部依赖关系代表关键资源，因此在完全中断的情况下唯一可用的缓解策略之一是将操作切换到不同的提供者。这只是商品服务的可行策略，即便如此，也只有事先规划并与提供商松散耦合。即使缓解困难，了解影响应用程序的外部事件也非常有价值。

应用于外部依赖的黄金信号可能类似于：

?延迟：从服务接收响应或从提供者提供新资源所需的时间?流量：推送到外部服务的工作量，向外部 API 发出的请求数?错误：服务请求的错误率?饱和度：使用的帐户限制资源量（实例、API 请求、可接受的成本等）

这些指标可以帮助您识别依赖关系的问题，提醒您即将发生的资源耗尽，并帮助控制费用。如果服务有替代方案，当指标表明出现问题时，该数据可用于决定是否将工作转移到不同的提供者。对于灵活性较差的情况，这些指标至少可以用来提醒操作员对这种情况做出响应并实施任何可用的手动缓解选项。

跟踪整体功能和端到端体验的指标

最高级别的指标在用户与之交互的最外层组件的上下文中跟踪通过系统的请求。这可能是一个负载均衡器或其他路由机制，负责接收和协调对您的服务的请求。由于这是与您的系统的第一个接触点，因此在此级别收集指标可提供整体用户体验的近似值。

虽然前面描述的指标非常有用，但本节中的指标通常是设置警报时最重要的指标。为避免响应疲劳，警报（尤其是页面）应保留用于对用户体验有明显负面影响的场景。可以通过使用在其他级别收集的指标进行深入研究来调查这些指标中出现的问题。

我们在这里寻找的信号类似于我们之前描述的单个服务的信号。主要区别在于我们在这里收集的数据的范围和重要性：

?延迟：完成用户请求的时间?流量：每秒用户请求数?错误：处理客户端请求或访问资源时发生的错误?饱和度：当前正在使用的资源的百分比或数量

由于这些指标与用户请求并行，因此超出这些指标可接受范围的值可能表明对用户有直接影响。不符合面向客户或内部 SLA（服务级别协议）的延迟、指示严重高峰或下降的流量、错误率增加以及由于资源限制而无法处理请求都是相当简单的推理在这个级别。假设指标准确，此处的值可以直接映射到您的可用性、性能和可靠性目标。

总结

在本指南中，我们首先讨论了最有助于发现和理解系统中具有影响力的变化的四个黄金信号。之后，我们使用信号作为镜头来评估在部署的不同层进行跟踪的最重要因素。

从上到下评估您的系统有助于确定运行可靠和高性能服务所需的关键组件和交互。这四个黄金信号可以成为构建指标以最好地指示系统健康状况的一个很好的起点。但是，请记住，虽然黄金信号是一个很好的框架，但您必须了解特定于您的情况的其他指标。收集您认为最有可能警告问题或帮助您在出现问题时进行故障排除的任何数据。