介绍
了解系统状态对于确保应用程序和服务的可靠性和稳定性至关重要。 关于部署的健康状况和性能的信息不仅可以帮助您的团队对问题做出反应，还可以让他们安心地进行更改。 获得这种洞察力的最佳方法之一就是建立一个强大的监测系统，收集指标，可视化数据，并在事件似乎被破坏时提醒操作员。
在我们对度量，监控和警报指南的介绍中 ，我们讨论了一些监控软件和基础架构的核心概念。 指标是监控系统处理的主要材料，以建立被跟踪系统的内聚视图。 了解哪些组件值得监控，您应该关注哪些具体特性是设计系统的第一步，该系统可以提供关于软件和硬件状态的可靠的，可操作的见解。
在本指南中，我们将首先讨论一个用于确定最关键指标的流行框架。 之后，我们将介绍如何将这些指标应用到整个部署中的组件。 这个过程将首先关注个人服务器的基础资源，然后调整范围以涵盖越来越大的关注领域。
监测的黄金信号
在极具影响力的Google SRE（站点可靠性工程）书中 ，关于分布式系统监控的章节介绍了一个有用的框架，称为监控的四个黄金信号 ，代表了面向用户系统中最重要的衡量因素。 我们将在下面讨论这四个特征。
潜伏
延迟时间是衡量完成某个动作所需的时间。 具体如何测量取决于组件，但一些常见的类似物是处理时间，响应时间或旅行时间。
测量等待时间使您能够具体测量完成特定任务或操作所需的时间。 通过捕获各种组件的延迟，您可以构建系统不同性能特征的整体模型。 这可以帮助您找到瓶颈，了解哪些资源需要最多的时间才能访问，并注意何时行动突然花费比预期更长的时间。 SRE书的作者强调在计算延迟时区分成功和不成功请求的重要性，因为它们可能具有截然不同的配置文件，这些配置文件可能会歪曲服务的平均值。
交通
流量衡量组件和系统的“繁忙”。 这可以捕获服务的负载或需求，以便您了解系统当前正在执行多少工作。
持续高或低的流量数字可能表示该服务可能需要更多的资源，或者有问题阻止流量正确路由。 但是，在大多数情况下，流量费率对帮助理解通过其他信号出现的问题是最有用的。 例如，如果等待时间增加超出可接受的水平，能够将该时间框架与交通高峰相关联是有帮助的。 可以使用流量来了解可以处理的最大流量，以及在各个负载阶段服务如何降级或失败。
错误
跟踪错误以了解组件的健康状况以及它们无法适当地响应请求的频率非常重要。 某些应用程序或服务暴露在干净的现成接口中，但是可能需要额外的工作来收集来自其他程序的数据。
区分不同类型的错误可以更容易地查明影响应用程序的问题的确切性质。 这也让您灵活地提醒。 如果出现一种类型的错误，则可能需要立即收到警报，但对于另一种情况，只要速率低于可接受的阈值，您可能就不会担心。
饱和
饱和度测量给定资源的使用量。 百分比或分数通常用于具有明显总容量的资源，但是对于定义最差的资源可能需要更多的创造性测量。
饱和度数据提供有关服务或应用程序为了有效操作而依赖的资源的信息。 由于一个组件提供的服务可能被另一个组件所使用，所以饱和度是表示底层系统的容量问题的粘合度量标准之一。 因此，一层中的饱和度和等待时间问题可能对应于下层中的流量或误差测量的显着增加。
在整个环境中测量重要数据
使用四个金色信号作为指导，您可以开始考虑如何在整个系统层次结构中表达这些度量标准。 由于服务通常是通过在更基本的组件之上添加抽象层来构建的，因此应该设计度量标准以在部署的每个级别增加洞察力。
我们将看到常见分布式应用环境中存在的不同级别的复杂性：
- 单个服务器组件
- 应用程序和服务
- 服务器集合
- 环境依赖性
- 端到端的体验
上面的顺序扩展了每个后续层的抽象的范围和级别。
收集各个服务器组件的度量标准
要收集的基本级别度量标准与系统所依赖的基础计算机相关。 尽管在现代软件开发方面付出了相当大的努力来抽象出物理组件和低级操作系统的细节，但是每项服务都依赖于底层的硬件和操作系统来完成它的工作。 因此，密切关注机器的基础资源是理解系统健康状况的第一步。
在考虑在机器级收集哪些指标时，请考虑可用的单个资源。 这些将包括服务器硬件的表示以及操作系统提供的核心抽象，如进程和文件描述符。 从四个金色信号的角度来看每个组成部分，某些信号可能是显而易见的，而其他信号可能更难以推断。
具有影响力的性能工程师Brendan Gregg概述了从Linux系统获取核心度量的许多方法，以满足他称为USE方法进行性能分析 （使用，调整和反馈）的框架的需求。 由于USE方法和四个黄金信号之间存在显着的重叠，因此我们可以将他的一些建议作为跳出点来确定从服务器组件收集哪些数据。
要测量CPU ，以下测量可能是合适的：
- 延迟 ：CPU调度程序的平均或最大延迟
- 流量 ：CPU利用率
- 错误 ：处理器特定的错误事件，出现故障的CPU
- 饱和度 ：运行队列长度
对于内存来说 ，信号可能如下所示：
- 延迟 :(无 - 很难找到一个好的测量方法，而不是可操作的）
- 流量 ：正在使用的内存量
- 错误 ：内存不足错误
- 饱和度 ：OOM杀手事件，交换使用率
对于存储设备 ：
- 延迟 ：读取和写入的平均等待时间（
await） - 流量 ：读取和写入I / O级别
- 错误 ：文件系统错误，
/sys/devices磁盘错误 - 饱和度 ：I / O队列深度
网络信号可能如下所示：
- 延迟 ：网络驱动程序队列
- 流量 ：每秒传入和传出的字节或数据包
- 错误 ：网络设备错误，丢包
- 饱和 ：超限，丢包，重传段
除了物理资源的表示之外，收集与操作系统抽象有关的指标也是一个好主意。 属于这个类别的一些例子是文件句柄和线程数量。 这些不是物理资源，而是由操作系统设置的最高限制来防止进程过度扩展。 大多数可以使用ulimit这样的命令进行调整和配置，但是跟踪这些资源使用情况的变化可以帮助您检测到软件使用中潜在的有害变化。
收集应用程序和服务的度量标准
向上移动一层，我们开始处理在服务器上运行的应用程序和服务。 这些程序使用我们之前处理的单个服务器组件作为工作资源。 此级别的指标有助于我们了解单主机应用程序和服务的健康状况。 我们将分布式多主机服务分成了一个独立的部分，以阐明这些配置中最重要的因素。
虽然上一节中的指标详细介绍了各个组件和操作系统的功能和性能，但这里的指标将告诉我们应用程序能够如何执行我们所要求的工作。 我们也想知道我们的应用程序依赖哪些资源以及他们如何管理这些限制。
请记住，本节中的度量标准与我们上次能够使用的通用方法有所不同。 从这一点来看，最重要的指标将取决于您的应用程序的特征，配置以及您在计算机上运行的工作负载。 我们可以讨论确定最重要指标的方法，但是结果将取决于服务器被特定要求做什么。
对于为客户提供服务的应用程序，四个金色信号往往相当简单：
- 延迟 ：完成请求的时间
- 流量 ：每秒服务的请求数量
- 错误 ：处理客户端请求或访问资源时发生的应用程序错误
- 饱和度 ：当前正在使用的资源的百分比或数量
您需要跟踪的一些更重要的指标是与依赖项相关的指标。 这些通常可以通过与单个组件相关的饱和度度量来最好地表达。 例如，应用程序内存利用率，可用连接数，打开的文件句柄数或活动的工作者数可帮助您了解在物理服务器上下文中应用的配置的效果。
这四个金色信号主要是为了分布式微服务而设计的，所以他们采用了客户端 - 服务器架构。 对于不使用客户端 - 服务器架构的应用程序，相同的信号仍然很重要，但“交通”信号可能需要稍微重新考虑。 这基本上是一个繁忙程度的衡量标准，因此找到一个充分代表您的应用程序的指标就能达到同样的目的。 具体取决于你的程序在做什么，但是一些通用的替代品可能是每秒处理的操作或数据的数量。
衡量服务器集合及其通信的度量标准
大多数服务，尤其是在生产环境中运行时，将跨越多个服务器实例，以提高性能和可用性。 这种复杂程度的增加增加了对于监测重要的附加表面积。 分布式计算和冗余系统可以使您的系统更加灵活，但基于网络的协调比单个主机内的通信更为脆弱。 强大的监测可以帮助减轻处理不太可靠的通信信道的一些困难。
除了网络本身之外，对于分布式服务，服务器组的健康和性能比应用于任何单个主机的相同措施更重要。 虽然服务与被限制在单个主机上运行的计算机密切相关，但冗余多主机服务依赖于多个主机的资源，同时保持与任何一台计算机的直接依赖关系的解耦。
这个水平的金色信号看起来与上一部分测量服务健康状况非常相似。 但是，他们会考虑到小组成员之间所需的额外协调：
- 延迟时间 ：游泳池响应请求的时间，协调或与同龄人同步的时间
- 流量 ：池每秒处理的请求数
- 错误 ：处理客户端请求，访问资源或到达对等方时发生的应用程序错误
- 饱和度 ：当前正在使用的资源数量，当前以容量运行的服务器数量，可用的服务器数量。
虽然这些与单主机服务的重要度量有明确的相似性，但是每个信号在分布时都会变得复杂。 延迟成为一个更复杂的问题，因为处理可能需要多个主机之间的通信。 流量不再是单个服务器能力的函数，而是组的能力和用于分配工作的路由算法的效率的总结。 引入了与网络连接或主机故障有关的其他错误模式。 最后，饱和扩展到包括主机可用的组合资源，连接每个主机的网络链接以及正确协调对每台计算机所需依赖的访问的能力。
与外部依赖关系和部署环境相关的度量标准
收集的一些最有价值的指标存在于您的应用程序或服务的边界，而不在您的直接控制范围之内。 外部依赖关系，包括与您的托管服务提供商相关的依赖项以及您的应用程序依赖的任何服务。 这些资源代表了你无法直接管理的资源，但这会损害你保证自己服务的能力。
由于外部依赖性是关键资源，所以在全面停机的情况下，唯一可用的缓解策略之一是将操作切换到不同的提供者。 这只是商品服务的一个可行的策略，即使只是事先规划和与供应商的松散耦合。 即使缓解困难，对影响您的应用程序的外部事件的了解也是非常有价值的。
应用于外部依赖的金色信号可能看起来类似于以下内容：
- 延迟 ：收到服务响应或从提供程序提供新资源所需的时间
- 流量 ：推送到外部服务的工作量，对外部API请求的数量
- 错误 ：服务请求的错误率
- 饱和度 ：使用的帐户受限资源数量（实例，API请求，可接受的成本等）
这些度量标准可以帮助您识别您的依赖关系问题，提醒您即将发生资源耗尽，并帮助控制费用。 如果该服务有替代方案，则可以使用此数据来决定在度量指示发生问题时是否将工作移至不同的提供者。 对于灵活性较低的情况，这些指标至少可以用来提醒操作员对这种情况作出反应，并实施任何可用的手动减缓选项。
跟踪总体功能和端到端体验的度量标准
最高级度量跟踪用户与之交互的最外层组件的上下文中的系统请求。 这可能是负载均衡器或其他路由机制，负责接收和协调对您的服务的请求。 由于这代表了系统的第一个接触点，因此在此级别收集度量标准给出了总体用户体验的近似值。
虽然前面描述的指标非常有用，但本节中的指标通常是设置警报最重要的指标。 为避免响应疲劳，警报（特别是页面）应保留用于对用户体验有明显负面影响的场景。 用这些指标浮现的问题可以通过使用其他层面收集的指标进行深入研究来调查。
我们在这里寻找的信号与我们之前描述的单个服务类似。 主要区别在于我们收集的数据的范围和重要性：
- 延迟 ：完成用户请求的时间
- 流量 ：每秒用户请求的数量
- 错误 ：处理客户端请求或访问资源时发生的错误
- 饱和度 ：当前正在使用的资源的百分比或数量
由于这些度量与用户请求并行，所以这些度量的可接受范围之外的值可能表示直接的用户影响。 不符合面向客户或内部SLA（服务水平协议）的延迟，表明严重峰值或下降的流量，错误率的增加以及由于资源限制而无法服务请求都是相当直接的理由在这个级别。 假设指标是准确的，这里的值可以直接映射到您的可用性，性能和可靠性目标。
结论
在本指南中，我们首先讨论四个金色信号，这些信号对于发现和理解系统中有影响的变化是最有帮助的。 之后，我们将这些信号用作镜头来评估在部署的不同层次上跟踪的最重要因素。
从上到下评估您的系统可帮助确定运行可靠和高性能服务所需的关键组件和交互。 这四个金色信号可以成为衡量指标结构的一个很好的起点，以最好地表明系统的健康状况。 但是，请记住，尽管金色信号是一个很好的框架，但您必须了解与您的情况相关的其他指标。 收集您认为最有可能发出警告的数据，或在出现问题时帮助您排除故障。
