基础设施与应用监控之收集度量指标

偏执的太偏执、 2022-05-10 03:16 283阅读 0赞

# 概述 #

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

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

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

# 监测的黄金信号 #

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

## Latency 延迟 ##

延迟是衡量完成操作所需时间的指标。测量方法的具体细节取决于组件，但一些常见的参考物是处理时间，响应时间或传输时间。

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

## Traffic 流量 ##

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

持续的高流量数字可能表示该服务可能需要更多资源，或者出现问题阻止了流量正确路由。但是，对于大多数情况，流量速率对于帮助理解问题最为有用。例如，如果延迟增加超出可接受的水平，则能够将该时间帧与流量峰值相关联是有帮助的。可以使用流量来了解可以处理的最大流量以及服务在各个负载阶段如何降级或失败。

## Error 错误 ##

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

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

## Saturation 饱和 ##

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

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

# 在整个环境中测量重要数据 #

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

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

*  单体服务器
 *  应用和服务
 *  集群服务器
 *  依赖外部环境
 *  端到端的体验

上面的排序是按层级不断扩展范围和级别。

## 收集单个服务器组件的度量标准 ##

要收集的基本级别度量标准是与系统所依赖的基础计算机相关的度量标准。虽然现代软件开发中的大量工作用于抽象物理组件和低级操作系统细节，但每个服务都依赖于底层硬件和操作系统来完成其工作。因此，密切关注机器的基础资源是了解系统健康状况的第一步。

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

布伦丹·格雷格，一个有影响力的性能工程师，列出了很多方法来获得从Linux系统核心指标以满足一个框架，他提出了USE性能分析方法（utilization, saturation, and errors）。由于USE方法与四个黄金信号之间存在显著重叠，因此我们可以将他的一些建议用作确定从服务器组件收集哪些数据的起点。

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

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

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

*  延迟 :(没有 - 很难找到一个好的测量方法而且不可操作）
 *  流量：正在使用的内存量
 *  错误：内存不足错误
 *  饱和度：OOM杀手事件，交换使用

对于存储设备：

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

该网络信号可以是这样的：

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

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

## 收集应用程序和服务的度量标准 ##

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

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

重要的是要记住，本节中的指标代表了我们上次能够使用的通用方法的隔离。从这一点开始，最重要的指标将非常依赖于应用程序的特征，配置以及计算机上运行的工作负载。我们可以讨论识别最重要指标的方法，但结果将取决于服务器的具体要求。

对于为客户提供服务的应用程序，四个黄金信号通常可以很容易地选择：

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

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

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

## 衡量服务器集群及其通信的度量标准 ##

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

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

此级别的黄金信号与上一节中测量服务运行状况的信号非常相似。但是，他们会考虑到小组成员之间需要的额外协调：

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

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

## 与外部依赖关系和部署环境相关的度量标准 ##

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

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

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

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

这些指标可以帮助您识别依赖项的问题，提醒您即将耗尽资源，并帮助控制开支。如果服务具有插入替代方案，则可以使用此数据来确定在度量指示发生问题时是否将工作移动到其他提供程序。对于灵活性较低的情况，指标至少可用于提醒操作员响应情况并实施任何可用的手动缓解选项。

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

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

虽然之前描述的指标非常有用，但本节中的指标通常是设置警报的最重要指标。为避免响应疲劳，警报（尤其是页面）应保留用于对用户体验具有可识别负面影响的方案。通过使用在其他级别收集的指标向下钻取，可以调查这些表现在外面的问题。

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

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

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