监控指标监控指标有哪些

转载

mob64ca140761a4 2024-02-10 14:37:24

一、监控指标的作用

一个故障/问题都有其生命周期，大致划分为故障预防、故障发生、故障感知、故障定位、故障恢复和故障复盘，或者说围绕故障发生，需要做其他5个阶段的事。故障预防除了基本的系统性措施外，前瞻性的一点是基于指标值趋势性预测的故障预测。故障发生的一个表象就是某个/些指标的值超出某个范围。故障感知在于知晓故障发生，不论是用户报障还是告警通知。之后就进入了故障的定位和恢复阶段，找到原因并解决问题，而重大故障一般还会有复盘/回溯的惯例。

Created with Raphaël 2.3.0 故障预防故障发生故障感知故障定位故障恢复故障复盘

监控指标贯穿故障的整个生命周期，是故障表象的内在和告警的本质，有故障则指标值不正常、没故障则指标值正常，反过来同样，类似于核磁共振，身体的问题一定为在某个/些指标上有所体现。指标是监控的三大件(指标、日志、调用链)之一，是运维主动侧面的雷达和依据，是感知状态、发现故障的眼睛。理论上讲，任何一个故障，一定有至少一个指标出现异常。指标的形态可以是原子指标，也可以是复合指标，比如上述从故障发生到恢复故障的总体耗时就是指标MTTR(故障平均恢复时长，Mean Time To Recovery)。

运维监控覆盖监控对象的整个后生命周期，除了面向故障处理，还可以支撑持续运营。监控的一个重要构成就是数据探测和采集，方式和工具多种多样，只是拿到的数据的运用范围可以不仅仅是运维。

二、监控对象的层级

监控指标是监控对象的运行态固有属性，监控对象在哪里，监控指标就在哪里，不论你知道不知道，管它不管它。按照云的分层逻辑，从下到上大致划分为IaaS基础设施层、PaaS中间件平台层、SaaS应用软件层、DaaS数据服务层，一层一层解耦。而传统的监控局限于IaaS层，关注资源层面的对象和指标。当前主流是服务化，所依托的下层在上层视角不可见、不关心、不在乎，越往上层业务属性越强，负责不同层级的团队和用户所关注的指标范围也有所区别。

DaaS	完整性、有效性、一致性、及时性、准确性	用户、业务

SaaS	进程、端口、API、日志、调用链

PaaS	数据库、中间件

IaaS	服务器、OS、网络、存储、端侧设备

在企业私有部署场景下，监控几乎是全栈的，以便多层级全方位的去感知、定位，这就涉及到动态权衡的监控覆盖度。也就是通过全方位监控(有人称之为立体化监控)，任何一个故障的发生应当伴随至少一个相关联的告警，否则就定性为无告警故障或者称之为用户(牺牲体验)先于IT团队发现问题并报障。

三、监控指标的选择

上面梳理了监控对象的分布情况，可谓杂七杂八一大堆，再加上微服务、容器等技术，对应的指标也是成千上万。理想情况下，无所不监，但考虑到复杂度、成本、效益和责任主体等因素，监控指标一定要有的放矢。比如有的告警无关痛痒，那可以考虑不启用这类告警、不采集相关指标数据、甚至不监控那个对象，从而让整个监控简单、低负载、少成本。总体而言，有如下几个监控指标选择的模型可供参考。

3.1 对象观测视角

首先是技术视角。资源服务于上层应用，关注资源其实是把应用当黑盒子，类似利用率、请求量和日志等都属于此类，通俗地讲就是知其然，看它吃进去了什么、拉出来了什么。如果深入应用内部，把应用作为白盒子来检测，那就需要调用链来解剖识别各个服务之间的上下游调用依赖与彼此影响关系，它看到的就不仅仅是出入口，更多的是内部的来龙去脉，在代码级别定位问题，达到知其所以然的目的。前者更多的是运维视角，后者更多的是开发视觉，在DevOps方式下，二者结合才能发挥更好的效果。

其次是用户视角。用户不关心你的服务器有多少、程序开发得如何，他唯一看到的是与他交付的界面，比如Web、API。Gartner 2020 Market Guide for Digital Experience Monitoring所谓的DEM就是一切站在用户视角论IT监测，交互得快不快、成功率高不高等方面的体验就是IT产品好坏的标准。[备注：DEM已逐渐融入APM(应用性能)，但业界产品层面独立或融合的形态不一。]

最后是业务视角。想让运维贴近业务，就要把运维语言转化为业务语言，就像一把菜刀，切菜功能、性能考虑到了，也要顾及有多少人下单、从哪里下的单、一天使用了几次，是哪些群体在用，又用了多少资源来造这把菜刀……，而这些数据，运维是有方法来获取的，从而让运维逐渐运营化。

3.2 通用指标模型

目前有三个较流行的实践，包括Google SRE的四个黄金指标、据此衍生收敛的RED和更久远的USE方法。四个黄金指标与RED差别在于有无饱和度、和USE中的饱和度意义不相同。

出处	年份	领域	模型	指标
Google	2015-	通用	四个黄金指标 The Four Golden Signals	Latency - 时延，处理请求所需时间，区分成与败、快与慢 Traffic - 流量，系统负载，如QPS、I/O、会话数 Errors - 错误，每秒请求错误数，区分显式、隐式错误和业务规则 Saturation - 饱和度，服务中断或性能急速下降的临界值/上限(阈值)
Tom Wilkie @Grafana	2015	服务	RED	Rate - QPS Errors - 每秒请求错误数 Duration - 请求时延
Brendan Gregg	2012	资源	USE	Utilization - 利用率，百分之多少的时间都在忙 Saturation - 饱和度，还有多少任务等待处理 Errors - 错误数

其中，RED强调用户视角，有错误那用户就在界面上看到了，延时大则界面加载慢，而USE强调资源层面。

3.3 指标分解选择

具体指标类型选择上，可以结合使用RED + USE来覆盖应用(PaaS + SaaS)和资源(IaaS)，选择Rate（请求量）、Errors（错误数）、Duration（时延）、Utilization（利用率）和Saturation（待处理任务队列）这几个类型/侧面。在考虑了技术视角和用户视角的同时，也别忽略按需多站在业务视角思考和拓展，不论你提供的产品或服务在上面四个层级中的哪一个。

上述指标类型都比较笼统，针对某类监控对象在这几个方面应该选择哪些具体的指标，一般有两个方向。一是从工具提供的指标清单上去筛选，二是想办法得到所需指标，哪怕需要复杂加工才能得到，二者都可以结合实际经验和业务需要去进一步完善和优化。我的一个实践原则是：宁缺毋滥，按需补充。