础设施与应用监控之收集度量指标
当然从大的层面来说，还需要确保运行的服务器是稳定的前提。
了解系统状态对于确保应用程序和服务的可靠性和稳定性至关重要。有关部署的运行状况和性能的信息不仅可以帮助您的团队对问题做出反应，而且还可以让他们放心地进行更改。获得这种洞察力的最佳方法之一是使用强大的监控系统，该系统可收集指标，可视化数据，并在事情出现故障时向操作员发出警报。
监测的黄金信号
在极具影响力的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队列深度
该网络信号可以是这样的：
- 延迟：网络驱动程序队列
- 流量：每秒传入和传出的字节或数据包
- 错误：网络设备错误，丢包
- 饱和度：溢出，丢弃数据包，重新传输的段
对于为客户提供服务的应用程序，四个黄金信号通常可以很容易地选择：
- 延迟：完成请求的时间
- 流量：每秒服务请求数
- 错误：处理客户端请求或访问资源时发生的应用程序错误
- 饱和度：当前使用的资源的百分比或数量
需要跟踪的一些更重要的指标是与依赖项相关的指标。这些通常最好通过与各个组件相关的饱和度指标来表示。例如，应用程序内存利用率，可用连接数，打开的文件句柄数或活动的工作者数可以帮助您了解在物理服务器上下文中应用的配置的效果。
四个黄金信号主要是为分布式微服务设计的，因此它们采用客户端 - 服务器架构。对于不使用客户端 - 服务器架构的应用程序，相同的信号仍然很重要，但可能需要稍微重新考虑“流量”信号。这基本上是对繁忙程度的衡量，因此找到一个足以代表您的应用程序的指标将起到同样的作用。具体情况取决于您的程序正在做什么，但一些常规指标可能是每秒处理的操作或数据的数量。
衡量服务器集群及其通信的度量标准
大多数服务（尤其是在生产环境中运行时）将跨越多个服务器实例以提高性能和可用性。这种复杂程度的增加了额外的处理，这对于监控非常重要。分布式计算和冗余系统可以使您的系统更加灵活，但基于网络的协调比单个主机内的通信更脆弱。强大的监控可以帮助减轻处理不太可靠的通信信道的一些困难。
除了网络本身，对于分布式服务，服务器组的运行状况和性能比应用于任何单个主机的相同措施更重要。虽然服务与它们在受限于单个主机时运行的计算机密切相关，但冗余多主机服务依赖于多个主机的资源，同时与任何一台计算机上的直接依赖性保持分离。
Prometheus监控的最佳实践——关于监控的3项关键指标
什么是Prometheus监控？
对于分布式服务就非常需要使用到Prometheus监控，尤其是在Kubernetes中监控应用程序这方面。应用程序运行在容器上并由Kubernetes负责调度，在此环境中它们是高度自动化并且动态的。传统的监控工具一般是基于服务器，只监控静态的服务，所以当要在这种动态环境监控应用程序时，传统的监控工具往往很难满足这一需求。
这时就需要Prometheus出马了。
Prometheus是一个开源项目，最初由SoundCloud的工程师开发。它专门用于监控那些运行在容器中的微服务。每经过一个时间间隔，数据都会从运行的服务中流出，存储到一个时间序列数据库中，这个数据库之后可以通过PromQL语言查询。另外，因为数据是以时间序列存储的，当出现问题时，可以根据这些时间间隔进行诊断，另外还可以预测基础设施的长期监控趋势—-这是Prometheus的两大功能。
该检测什么？
在搭建Prometheus监控时，确定需要收集的指标类型十分重要，这些指标和应用程序相关。选择的指标可以简化故障发生时排除故障的流程，并且还可以在服务和基础设施上保持很高的稳定性。为帮助理解instrument的重要性，定义了一个称之为RED方法的系统。
RED方法遵循Four Golden Signals中提及的原则，聚焦于检测最终用户在使用web服务时关心的东西。
在RED方法中，我们通过监控三项关键指标来管理架构中的每个微服务：
- （Request）Rate – 你的服务所服务的每秒的请求数
- （Request）Errors – 每秒失败的请求数
- （Request）Duration – 每个请求所花费的时间，用时间间隔表示
RED方法希望由Rate、Errors、Duration三项指标涵盖最典型的Web服务问题。同时这些指标还能够反映出请求的错误率。通过这三项指标，我们就能监测到通常情况下会影响客户体验的问题。
如果想要获得更细节的信息，还需要用到Saturation指标。Saturation指标用在USE（Utilization Saturation and Errors）方法中，它指的是一种带有额外作业的资源，而该资源不能够提供服务，因此必须添加到队列中以备后续处理。
从上到下评估的系统有助于确定运行可靠和高性能服务所需的关键组件和交互。四个黄金信号可以成为构建指标的最佳起点，以最好地指示系统的运行状况。
USE和RED方法
对比两种方法，USE方法更侧重于监控的性能，并以此为出发点寻找影响性能问题的根本原因以及其他系统的瓶颈。
在理想状态下，我们可以在监控应用程序时同时使用USE和RED方法。
为什么要对每个服务衡量相同的指标？
从监控的角度来看，如果能处理好每项服务，你的运营团队就可以在此基础上继续扩展服务。
扩展性对运营团队意味着什么？
从这个角度看待问题，一个团队可以支持多少个服务。在理想状态下，一个团队可以支持的服务数量和团队规模无关，而取决于其他因素，比如SLA协议的响应类型以及是否需要全天候覆盖等等。
如何将可支持的服务数量与团队规模去藕化？
让每一个服务都变得一样。这既减少了团队针对特定的服务进行培训的数量，还减少了在高压事件响应场景或者所谓“认知负载”这些针对特定服务的特殊情况发生时，呼叫者需要记录的内容。
容量规划?
考虑QPS（每秒查询次数）和延迟
局限性
事实上，RED仅适用于请求驱动的服务——比如，它在处理面向批处理的服务或者流服务时会发生错误。对于请求驱动它也不是完全适用，当需要监控其他东西——比如主机CPU&内存或者缓存资源时，USE方法表现的更好。
