Skip to content

09 监控概论（上）：有哪些方法可以指导监控数据采集？

你好，我是秦晓辉。

前面几讲我们介绍了监控的一些原理和搭建方法，这一讲开始，我们进入监控实战部分，看看具体怎么监控不同类型的目标对象。我会先用两讲的时间讲一下监控方法论和典型的监控数据采集原理。

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

Google的四个黄金指标

Google的四个黄金指标着眼点在服务监控，这四个指标分别是延迟、流量、错误和饱和度。

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

有了这个方法论的指导，我们就知道服务监控应该重点关注哪些指标了。如果要为某个服务配置监控大盘，监控大盘里就要包含上述这几类指标。如果要配置告警规则，也要重点照顾这几类指标。

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

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

RED方法

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

三个英文单词取首字母组成RED方法，姑且可以看做是Google四个黄金指标的简化版，作者很逗，说为什么起名为RED呢？因为他们内部普遍应用USE方法，为了和USE相呼应，所以取了RED这个自认为响亮的名字。这个USE又是什么方法呢？下面我们就来介绍一下。

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协议，通过带外网络采集。

网络设备，典型的就是交换机、防火墙，一般是通过SNMP协议获取指标，比如交换机各个网口的流量、包量。也可以通过syslog的方式，把交换机的日志转存出来，到服务器上分析。

网络监控

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

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

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

到这里，监控的分类我们就介绍完了，你可以看一下自己公司的监控数据，查漏补缺。上面的分类主要是针对服务端的监控，还有一个大类是端监控，比如iOS应用，我们会关注是否卡顿、有没有崩溃、白屏之类的，这算是另一个领域，这里就不展开介绍了。

小结

我们这一讲关注的是监控方法论，因为监控对象很多，监控指标也很多，哪些指标比较重要就需要有一个指导性理论。从大类上来看，分为针对服务的Google四个黄金指标和RED方法，以及针对资源的USE方法。这些方法可以解答哪些指标更为重要这个问题。

对于监控覆盖完备性问题，我总结了一个监控分类图，共有业务、应用、组件、资源四个大类，当然还有端监控，如果这些类别的监控都建立起来了，监控体系就是相对完备的。

最后，我把这一讲的内容整理成了一张脑图，方便你理解记忆。

互动时刻

“因为监控数据不完备，导致线上环境出了问题却没有发现”这个情况时有发生。比如机器进程总数没有监控、nf_conntrack:table full没有监控、ulimit没有监控、MySQL允许的最大连接数没有监控等等。你可以把你遇到的情况也来留言分享一下，这个信息库非常有价值，也欢迎你把今天的内容分享给你身边的朋友，邀他一起学习。我们下一讲再见！