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