运维监控系统实战笔记--9 （day 10)

内容来自《极客时间》 监控概论（上）：有哪些方法可以指导监控数据采集？

要监控的目标五花八门，怎样才能让监控数据更加完备，怎样才能知道哪些指标更加重要，解决这些问题都需要监控方法论的指导。目前业界比较流行的方法论有 Google 的四个黄金指标、RED 方法、USE 方法，下面我们一一介绍一下。

Google 的四个黄金指标

这四个指标分别是延迟、流量、错误和饱和度。

• 延迟：服务请求所花费的时间，比如用户获取商品列表页面调用的某个接口，花费 30 毫秒。这个指标需要区分成功请求和失败请求，因为失败的请求可能会立刻返回，延迟很小，会扰乱正常的请求延迟数据。
• 流量：HTTP 服务的话就是每秒 HTTP 请求数，RPC 服务的话就是每秒 RPCCall 的数量，如果是数据库，可能用数据库系统的事务量来作为流量指标。
• 错误：请求失败的速率，即每秒有多少请求失败，比如 HTTP 请求返回了 500 错误码，说明这个请求是失败的，或者虽然返回的状态码是 200，但是返回的内容不符合预期，也认为是请求失败。
• 饱和度：描述应用程序有多“满”，或者描述受限的资源，比如 CPU 密集型应用，CPU 使用率就可以作为饱和度指标。

可以这么说，只要上述这些指标都是正常的，这个服务就是健康的。反之，如果这些指标有问题，服务就是不健康的，并且大概率已经影响了上游服务甚至终端用户。

Google 的四个黄金指标主要是针对服务的监控，Weaveworks 的工程师认为饱和度这个指标比较高级，延迟、流量、错误这三个指标相对更重要，所以将其简化为 RED 方法，下面我们来看一下 RED 方法的定义。

RED 方法

• （Request）Rate：请求速率，每秒请求数。
• （Request）Errors：错误，每秒错误请求数。
• （Request）Duration：延迟，每个请求的延迟分布情况。

说为什么起名为 RED 呢？因为他们内部普遍应用 USE 方法，为了和 USE 相呼应，所以取了 RED 这个自认为响亮的名字。

USE 方法

USE 方法的提出者是大名鼎鼎的 Brendan Gregg，如果你没听过这个名字，也没关系，你应该听过火焰图吧，性能分析用的火焰图就是这位大哥发明的。你可以点开 USE 方法的官方介绍看看。

USE 是使用率（Utilization）、饱和度（Saturation）、错误（Error）的缩写，主要用于分析资源问题。什么是资源？在 Gregg 对模型的定义中，是指传统意义上的物理服务器组件，比如 CPU、硬盘等，但现在很多人已经扩展了资源的范围，把一些软件资源也包含在内。

• 使用率：这个我们最熟悉，比如内存使用率、CPU 使用率等，是一个百分比。
• 饱和度：资源排队工作的指标，无法再处理额外的工作。通常用队列长度表示，比如在 iostat 里看到的 aqu-sz 就是队列长度。
• 错误：资源错误事件的计数。比如 malloc() 失败次数、通过 ifconfig 看到的 errors、dropped 包量。有很多错误是以系统错误日志的方式暴露的，没法直接拿到某个统计指标，此时可以进行日志关键字监控。

USE 方法和 Google 四个黄金指标配合使用，我们就可以知道不同类别的监控对象应该关注的核心指标是什么了。那监控对象都有哪些类别呢？换句话说，我们做了哪些方面的监控才算是把监控体系建设完备了？下面我们就来梳理一下监控对象的类别。

监控分类

为了方便你理解，我画了一张图，把监控分成 4 个类别。

业务监控

这类指标是管理层非常关注的，代表企业营收，或者跟客户主流程相关，类似 BI 数据。不过相比 BI 数据，业务监控指标有两点不同。

• 对精确度要求没有那么高：因为监控只要发现趋势异常就可以，至于是从 5000 变成了 1000 还是变成了 1001，没有什么区别。
• 对实时性要求很高：很多 BI 数据可能是小时级别或天级别的，这个时效性无法满足监控的需求，监控是希望越早发现问题越好，要是一个小时才发现问题，黄花菜都凉了。

技术人员应该针对这类指标做高优保障，如果所有的指标都同等对待，重要的告警就容易被普通告警淹没，所以告警一定要分级对待。

很多公司的故障管理比较粗放，只要有报警事件产生，就认为是有故障，这是不对的。在微服务和云原生技术盛行的当下，某个机器的 CPU 飙高了，或者 IO 打满了，对最终用户的体验可能是没有任何影响的，但是核心业务指标异常，一定是故障，因为这类指标异常代表着最终用户体验受损，或者造成了直接资损。

作为中后台的团队，做的很多稳定性保障的工作不容易让管理层看到，业务指标是一个突破口，如果能够把这类指标梳理清楚，是很容易让老板看到我们的价值的。应用监控

应用监控

应用监控就是指对应用程序（Application）的监控，Google 的四个黄金指标、RED 方法主要就是针对应用监控的。

每个公司都应该有统一的 APM（Application Performance Management），也就是应用性能管理方案，从指标着手的话一般使用埋点机制来做，比如 StatsD、Prometheus SDK 等，或者直接分析接入层日志，从日志提取指标；从链路追踪着手的话可以使用 Zipkin、SkyWalking 等。

像 Java 这种字节码技术的语言，采用 JavaAgent 技术可以做到代码无侵入埋点。但是像 Go、C++ 这类语言，一般都是采用埋点机制来做，由统一的工具团队提供一些框架，在框架里内置埋点逻辑，这样普通研发人员也就基本不会有代码侵入的感觉了。

组件监控

这里我们把各类数据库、中间件、云平台，统称为组件，组件监控是非常考验知识广度的。一般监控系统的研发人员，很难把每个组件的机理都搞清楚，所以定义统一的接入数据规范，让专业的人去采集各个组件的数据是更合理的做法。

有个好现象是，很多组件的研发人员，已经开始让组件自身直接支持 Prometheus 协议，吐出 metrics 数据，除了 etcd、Kubernetes 这些云原生时代的组件，一些老的组件，比如 RabbitMQ、ZooKeeper 等，也在新版本里直接做了支持，

资源监控

基础资源的监控，主要是针对设备和网络，设备又分为服务器、网络设备，网络监控又分为连通性监控、质量监控、流量监控。

资源监控：一提起设备监控，你可能立马会想到 CPU、内存使用率监控，除了这些之外，如果我们想获取硬件模块的健康状况，比如电源电压、风扇转速、主板环境温度等，就需要走 IPMI 协议，通过带外网络采集。

设备监控：你可能立马会想到 CPU、内存使用率监控，除了这些之外，如果我们想获取硬件模块的健康状况，比如电源电压、风扇转速、主板环境温度等，就需要走 IPMI 协议，通过带外网络采集。网络设备，典型的就是交换机、防火墙，一般是通过 SNMP 协议获取指标，比如交换机各个网口的流量、包量。也可以通过 syslog 的方式，把交换机的日志转存出来，到服务器上分析。

网络监控：网络连通性监控最为常见，通过 ICMP 协议，部署探针机器，对目标设备做 PING 探测，能探通就表示能连通，探测失败就是连不通。当然，有些机器可能是禁 PING 的，此时就需要用 TCP 或 HTTP 之类的协议去探测了。

    PING 探测可以拿到丢包率和延迟数据，我们可以用这些数据分析网络质量。比如两个机房之间的专线，我们用 A 机房的探针去探测 B 机房的目的设备，就能轻易知道机房之间的网络质量情况。

最后是流量监控，也会用在多个地方，比如机器的网卡流量、交换机的网口流量、机房出口流量，也是整个监控体系的重要一环。

小结