目前业界比较流行的监控方法论有 Google 的四个黄金指标、RED 方法、USE 方法。
Google 的四个黄金指标
Google 的四个黄金指标着眼点在服务监控，这四个指标分别是延迟、流量、错误和饱和度。
延迟：服务请求所花费的时间，比如用户获取商品列表页面调用的某个接口，花费 30 毫秒。这个指标需要区分成功请求和失败请求，因为失败的请求可能会立刻返回，延迟很小，会扰乱正常的请求延迟数据。
流量：HTTP 服务的话就是每秒 HTTP 请求数，RPC 服务的话就是每秒 RPCCall 的数量，如果是数据库，可能用数据库系统的事务量来作为流量指标。
错误：请求失败的速率，即每秒有多少请求失败，比如 HTTP 请求返回了 500 错误码，说明这个请求是失败的，或者虽然返回的状态码是 200，但是返回的内容不符合预期，也认为是请求失败。
饱和度：描述应用程序有多“满”，或者描述受限的资源，比如 CPU 密集型应用，CPU 使用率就可以作为饱和度指标。
有了这个方法论的指导，我们就知道服务监控应该重点关注哪些指标了。
如果要为某个服务配置监控大盘，监控大盘里就要包含上述这几类指标。如果要配置告警规则，也要重点照顾这几类指标。可以这么说，只要上述这些指标都是正常的，这个服务就是健康的。反之，如果这些指标有问题，服务就是不健康的，并且大概率已经影响了上游服务甚至终端用户。
RED 方法
（Request）Rate：请求速率，每秒请求数。
（Request）Errors：错误，每秒错误请求数。
（Request）Duration：延迟，每个请求的延迟分布情况。
三个英文单词取首字母组成 RED 方法，姑且可以看做是 Google 四个黄金指标的简化版。
USE 方法
USE 是使用率（Utilization）、饱和度（Saturation）、错误（Error）的缩写，主要用于分析资源问题。
什么是资源？在 Gregg 对模型的定义中，是指传统意义上的物理服务器组件，比如 CPU、硬盘等，但现在很多人已经扩展了资源的范围，把一些软件资源也包含在内。下面我们对使用率、饱和度、错误做一个更详细的解释。
使用率：这个我们最熟悉，比如内存使用率、CPU 使用率等，是一个百分比。
饱和度：资源排队工作的指标，无法再处理额外的工作。通常用队列长度表示，比如在 iostat 里看到的 aqu-sz 就是队列长度。
错误：资源错误事件的计数。比如 malloc() 失败次数、通过 ifconfig 看到的 errors、dropped 包量。有很多错误是以系统错误日志的方式暴露的，没法直接拿到某个统计指标，此时可以进行日志关键字监控。
监控对象的类别
业务监控
这类指标是管理层非常关注的，代表企业营收，或者跟客户主流程相关，类似 BI 数据。不过相比 BI 数据，业务监控指标有两点不同。对精确度要求没有那么高：因为监控只要发现趋势异常就可以，至于是从 5000 变成了 1000 还是变成了 1001，没有什么区别。对实时性要求很高：很多 BI 数据可能是小时级别或天级别的，这个时效性无法满足监控的需求，监控是希望越早发现问题越好，要是一个小时才发现问题，黄花菜都凉了。
《 运维监控系统实战笔记》学习笔记 Day10
