4.4度量指标
Metrics with Purpose
度量指标
第5章介绍了当系统出现错误受到威胁时如何使用SLI指标进行监控和警报。SLI指标是您在基于SLO的警报触发时要检查的第一个指标。这些指标应显示在服务的信息中心中,最好位于其登陆页上。
在排查SLO触发的原因时,您很可能无法从SLO仪表板获得足够的信息。这些仪表板显示您触发了SLO阀值,但不一定知道为什么。监控仪表板应该显示哪些数据呢?
我们发现以下指南有助于度量指标的实施。这些指标应提供合理的监控,使您可以排查生产问题,并提供有关您服务更详细的信息。
Intended Changes
预期的变化
在诊断基于SLO的警报时,您需要能够从通知您用户影响问题的警报指标转移到告知您导致这些问题的指标。 您服务的最新的更改可能导致新的错误。添加监控,通知您生产中的任何变化。要确定触发器,我们建议如下:
监控二进制文件的版本。
监控命令行标志, 特别是当您使用这些标志启用和禁用服务功能时。
- 如果将配置数据动态推送到服务, 则监控此动态配置的版本。
如果系统中的某个服务未进行版本控制, 那您应该监控上次生成或打包的时间戳。
当您尝试将停机与部署相关联时, 查看与警报链接的图表/仪表板要比在事后通过CI / CD(持续集成/持续交付)系统日志更容易。
Dependencies
依赖
即使您的服务没有更改,其任何依赖项都可能变化或出现问题,因此您还应该监控来自直接依赖项的响应。
根据每个依赖项的字节,延迟和响应代码导出请求和响应大小是合理的。在选择要绘制的指标时,请牢记四个黄金指标。您可以在度量标准上使用其他标签,以通过响应代码,RPC(远程过程调用)方法名称和对应业务名称将其分解。
理想情况下,您可以制作一次底层RPC客户端库来导出他们的度量指标到仪表盘,而不是要求每个RPC客户端库导出它们。 规范客户端库提供了更高的一致性,并允许您自动监控新的依赖项。
您有时会遇到提供非常有限的API的依赖项,其中所有功能都可通过名为Get,Query或某些等于无效的单个RPC获得,并且实际命令被指定为此RPC的参数。客户端库中的单个检测点与此类依赖关系不符:您将观察到延迟的高低变化和一些百分比的错误,这些错误可能可以也可能不可以表明此API的某些部分完全失败。 如果这种依赖关系很重要,那么您有几个选择可以很好地监控它:
导出单独的度量值为依赖项量身定做, 以便这些度量值可以解释收到的请求以获取实际信号。
请依赖项所有者重构以支持导出单独的 RPC 服务和方法功能分离的更通用的 API。
Saturation
饱和度
监控和跟踪服务所依赖的每种资源的使用情况是最终目标。某些资源具有您不能超过的硬性限制,例如分配给您的应用程序的RAM,磁盘或CPU配额。 其他资源(如打开文件描述符,任何线程池中的活动线程,队列等待时间或写入的日志量)可能没有明确的硬限制,但仍需要管理。
根据使用的编程语言,您应该监控额外的资源:
在 Java 中: 堆和 metaspace 大小, 以及更具体的度量指标, 具体取决于您使用的垃圾回收机制
在 Go 中: goroutines 的数量
这些语言本身为跟踪这些资源提供了不同的支持。
除了在5章中所述的重大事件上发出报警外, 您还可能需要为特定资源设置报警, 例如:
当资源有硬件限制时
当超过使用阈值时会导致性能下降
您应该拥有监控指标来跟踪所有资源 - 甚至在资源处于服务管理良好状态下。 这些指标在容量和资源规划中至关重要。
Status of Served Traffic
服务通信状态
最好添加度量值或度量标签, 以允许仪表板按状态码区分服务的请求量 (除非服务用于 SLI 目的的度量值已经包括此信息)。以下是一些建议:
对于 HTTP 请求, 监控所有响应状态码, 即使它们没有提供足够的警报信息, 因为有些可能是由错误的客户端行为触发的。
如果您对用户设置速率限制或配额限制, 则监控由于缺少配额而拒绝多少请求的统计。
此数据的图表可以帮助您识别在生产环境更新迭代过程中出现异常错误的时间。
Implementing Purposeful Metrics
目标度量指标实现
每个导出的指标都应该有作用。不要因为生成简单而只导出少量的指标。相反,请考虑如何使用这些指标。 度量指标的设计或缺乏设计将会影响您的监控系统。 理想情况下,用于报警的度量指标仅在系统出现问题状态时发生显着变化,并且在系统正常运行时不会发生变化。另一方面,调试指标没有这些要求 - 它们旨在提供有关触发警报时发生的情况的原因。良好的调试指标将指向系统可能导致问题的某些方面。编写事后调查时,请考虑哪些其他指标可以让您更快地诊断问题。