持续监控实践之指标模型的创建

持续监控在DevOps实践中是非常重要的一环，选择监控的指标进行可视化的跟踪，能够对现状和趋势进行更好的把握，是有效的一种持续反馈的手段，在对于现状和趋势把握的基础之上也能够更好地进行持续改善。而在持续监控之中，监控指标非常之多，如何创建监控相关的指标模型，这篇文章则介绍一些常用的方法和其使用的场景。

Google的四类黄金指标

Four Golden Signals是Google针对分布式监控进行的经验总结，将需要重点关注的监控数据分为四类：

• 延迟（Latency）: 此类指标聚焦于请求所需要花费的时间的指标纬度。一般通过关注成功请求相应的延迟和失败请求相应的延迟的区别，过长的延迟会导致事件响应的时间推后，同时也会使得用户的体验变差，此类指标对于衡量和改善终端用户体验一般有重要的作用，同时延迟很多时候也是性能变差的一个重要外在显示，对于早期发现和定位性能问题也有一定的作用。

• 流量（Traffic）: 此类指标聚焦于系统所需要承受的用户或者交易的量级相关的指标纬度。比如基于Web的HTTP应用服务此类指标可能表现为TPS或者QPS。通过监控此类实施的用户交互和流量相关的指标数据，能够对于系统所承受的压力负载状况有一个更好地把握，同时对于所能能够承受的压力峰值也能有一个更为清晰的判断。

• 错误（Errors）: 此类指聚焦于系统错误相关的指标纬度。错误是任何系统都需要关注的内容，它不但能衡量系统的质量状况，同时也是后续事件管理需要开始的信号。错误一般分为显示错误和隐式错误两类，显示错误可能会直接体现为HTTP 500的错误返回，这类错误一般直接在诸如Nginx这样的应用服务器的日志中就能进行抓取和确认，而隐式错误则往往跟具体的业务应用相关，虽然返回了HTTP 200的正常值，但是有可能在业务上仍然是失败的，这类错误则一般需要根据具体情况在系统中埋点来实现。

• 饱和度（Saturation）: 此类指标聚焦于系统资源使用率的饱和状况的指标纬度。这类指标一般回答的是“某类会影响系统系统的资源离饱和（100%或者已经会影响到系统动作的程度）还有多远”的问题。因为一旦这些关键的资源达到饱和状态，整体系统性能就会出现明显下降，是监控系统中需要注意的指标类型。

这四类指标是Google SRE的经验积累，所观测的指标对于系统的可靠性非常重要，是监控系统创建时的有益参考。

RED方法

RED是Weave Cloud所提供的方法，这种方法完全以Google的4类黄金指标为基础，以应用请求相关的R（Rate：请求速率）、E（Error：请求错误）和D（Duration：请求耗时）三种关键指标为中心所创建监控体系的方法，被成为RED方法，对于云原生应用或者为微服务架构下的应用有很好地借鉴作用。

RED方法定义了微服务架构种所需要定义的三种指标：

• 请求速率(Request) Rate：每秒服务所需要处理请求数量
• 请求错误(Request) Errors： 每秒失败的请求数量
• 请求耗时(Request) Duration： 每个请求所消耗的时间

可以看到RED方法所聚焦的是终端用户在使用Web服务时所关注的三项内容，是以请求为中心的数据，而在讨论监控中所经常讨论的资源使用率相关的问题并不在RED方法中所包含，如果需要同时关注此部分内容时则需要考虑使用USE方法。

USE方法

USE方法的全称是Utilization Saturation and Errors Method，相较于RED方法，USE方法从资源使用率（Utilization）、资源饱和度（Saturation）和错误等指标纬度进行监控和分析，在帮助用户进行系统性能分析、资源瓶颈识别等方面有较好的效果。具体指标说明如下所示：

• 资源使用率：系统资源诸如CPU、内存、网络、磁盘IO等相关的使用率信息，某项资源长时间较高使用率通常是系统性能瓶颈的标志。
• 资源饱和度：资源一旦达到饱和程度将会显著影响系统性能，资源饱和度指标主要包括各种影响系统性能的指标信息。
• 错误：错误相关的指标统计信息。

使用USE方法可以进行资源性能瓶颈分析，使用流程如下所示：

RED方法 vs USE方法

可以看到使用RED方法或者USE方法都可以对服务进行监控，具体选择可根据如下特点进行：

• RED方法：主要适用于单纯关注与请求相关的指标数据
• USE方法：可以提供资源使用率和饱和度的指标信息，对于系统性能监控和性能瓶颈分析可以起到很好的作用。

辅助手段

除了在生产和测试环境中被动的等待和确认系统状况，还可以通过更为主动的方式进行持续的学习从而构建更加可靠的系统，而这些离不开一些主动的辅助手段，比如：

• 混沌工程（Chaos Engineering）: 更准确地来说，混沌工程是作为团队持续实验中的一项最佳实践而进行，这项最佳实践的目的就是为了更好地了解系统，尤其是系统的脆弱性，通过主动的向服务中诸如错误或者混乱状况，可以更好地观察系统在这种情形之下的表现。
• 游戏日（Game Days）: 混沌工程是为了帮助我们更好地了解系统，而游戏日则是为了更好地了解系统相关的人员如何协同作业。 游戏日实际上就是灾难或者故障的演习，通过游戏日则能更好地检验团队对于故障或者事件相应的弹性能力。而且通过游戏日的实践可以进行持续的改进。
• 合成监控（Synthetic Monitoring）: 合成监控的重点在于通过创建模拟的用户和用户行为来确认系统的运行状况，这是一种更加主动的方法，使得测试不再过度依赖于最终用户的使用，可以事先更好地对于可能出现的各种问题进行验证和结果确认，从而创建更好的系统。

参考内容

https://victorops.com/blog/sre-golden-signals-of-monitoring https://rancher.com/red-method-for-prometheus-3-key-metrics-for-monitoring/