一、监控指标的作用

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

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

二、监控对象的层级

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

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

三、监控指标的选择

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

3.1 应用程序内外

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

3.2 通用指标类型

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

其中，RED强调用户视角，有错误那用户就在界面上看到了，延时大则界面加载慢，而USE强调资源视角。二者结合才能还原系统全貌。当然他们还只是在应用系统的外部看现象，如果需要看内部详情，那就需要调用链加持。

3.3 指标分解选择

具体指标类型选择上，可以结合性使用RED + USE覆盖应用和资源，选择Rate（请求量）、Errors（错误数）、Duration（时延）、Utilization（利用率）和Saturation（待处理任务队列），不用纠结到底采用哪一套模型/方法。
上述指标类型都比较笼统，针对某类监控对象在这几个方面应该选择哪些具体的指标，一般有两个方向。一是从工具提供的指标清单上去筛选，二是想办法得到需要的指标，二者都可以结合实际经验和业务需要，特别是既有故障的处理痛点，进一步的去完善和优化。
指标目的不要局限于监控告警本身，如果为了业务运营，可以不启用告警策略，虽然它是通过监控通道获取的。我的一个实践原则是：宁缺毋滥，快速补充。

四、参考文档

The Four Golden Signals
The RED Method: How to Instrument Your Services(PPT)
The USE Method
How to Monitor the SRE Golden Signals