简介

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

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

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

监控的金色信号

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

时延

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

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

流量

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

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

错误

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

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

饱和度

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

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

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

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

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

• 单个服务器组件
• 应用程序和服务
• 服务器集合
• 环境依赖性
• 端到端体验

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

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

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

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

Brendan Gregg，是一位有影响力的性能工程师，他概述了从LINUX系统获取核心指标以满足框架需求的许多方法，他称之为Use Method for Performance analysis(u Use，** S** aturation，and* ** e** erors)]。由于使用方法和四个黄金信号之间有显著的重叠，我们可以使用他的一些建议作为起点，以确定应该从服务器组件收集哪些数据。

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

• 延迟 ：CPU调度器的平均或最大延迟
• 流量 ：CPU使用率
• 错误 ：处理器特定的错误事件、出现故障的CPU
• 饱和度 ：运行队列长度

对于 内存 ，信号可能看起来像这样：

• 时延 ：(无-难以找到好的测量方法，且不可操作)
• 流量 ：正在使用的内存量
• 错误 ：内存不足错误
• 饱和 ：OOM杀手级事件、交换使用率

对于 存储设备 ：

• 时延 ：读写平均等待时间(wait)
• 流量 ：读写I/O级别
• 错误 ：/sys/devices中文件系统错误、磁盘错误
• 饱和度 ：I/O队列深度

网络 信号可能如下所示：

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

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

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

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

虽然上一节中的指标详细说明了各个组件和操作系统的功能和性能，但这里的指标将告诉我们应用程序能够多好地执行我们要求它们完成的工作。我们还想知道我们的应用程序依赖于什么资源，以及它们管理这些限制的情况如何。

重要的是要记住，本节中的指标代表了我们上次能够使用的一般方法的偏离。 从这一点开始，最重要的指标将非常依赖于应用程序的特性、配置和机器上运行的工作负载。 我们可以讨论确定最重要指标的方法，但结果将取决于服务器具体被要求做什么。

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

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

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

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

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

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

除了网络本身，对于分布式服务，服务器组的运行状况和性能比应用于任何单个主机的相同措施更重要。当服务被限制在单个主机上时，服务与它们运行的计算机密切相关，而冗余的多主机服务依赖于多个主机的资源，同时保持与任何一台计算机的直接依赖关系。

这一级别的金色信号看起来与上一节中衡量服务运行状况的信号非常相似。但是，它们将考虑到集团成员之间所需的额外协调：

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

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

与外部部署和部署环境相关

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

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

应用于外部依赖项的金色信号可能如下所示：

• 延迟 ：从服务接收响应或从提供者提供新资源所需的时间
• 流量 ：对外推送的工作量，对外接口的请求量
• 错误 ：服务请求错误率
• 饱和度 ：账户受限资源使用量(实例、API请求、可接受成本等)

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

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

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

虽然前面描述的指标非常有用，但本节中的指标通常是设置警报的最重要的指标。为了避免响应疲劳，警报--尤其是页面--应该保留给对用户体验有明显负面影响的场景。通过使用在其他级别收集的指标向下钻取，可以调查这些指标出现的问题。

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

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

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

结论

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

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