滴滴高级专家工程师保姆级运维监控科普（五）

忘是亡心i 2022-10-06 04:58 174阅读 0赞

在第一章里，我们对监控系统做了概要介绍，这一章，重点深入讲解监控数据采集。监控数据采集是整个监控系统的第一环节，小伙伴们搬个小板凳，注意听讲了。

来，开篇一张图，内容全靠编，监控指标全景蓝图：

![v2-fdeec0f27c78bfb1a42f4398805e8175\_b.jpg][v2-fdeec0f27c78bfb1a42f4398805e8175_b.jpg]

说是监控指标全景蓝图，略有噱头之嫌，其实缺少了链路和端的监控指标，这个图描述的主要是服务端相关的指标。

**一、资源层面**

这个层面的指标，主要是包括各种硬件设备、操作系统等，比如通过ipmi采集到的一些风扇转速、CPU温度，通过SNMP采集到的端口流量，通过部署客户端或执行脚本采集到的CPU、内存、硬盘、IO、网络相关的OS指标。

虚拟机一般是当做物理机类似的方式来对待，负载均衡F5、防火墙、交换机、一些商业化存储，大都会暴露SNMP的协议端口，通过SNMP去采集。

资源层面的监控系统相对较多，zabbix在这个方面比较擅长。具体的采集方式在之前的章节里有描述，这里就不展开了。

**二、组件层面**

组件层面的监控五花八门，比较常见的是组件自身暴露一些状态指标，如之前章节的文章所述。

很多中间件都是Java写的，所以JVM层面的监控也比较重要，比如YoungGC的平均耗时、当前活跃线程数、峰值线程数等。

作为监控系统的研发人员，坦白讲，要对所有的中间件都很熟悉，都知道应该采集哪些指标，确实非常困难。建议的做法，还是合作共建，监控系统的研发人员写平台，把平台的服务端做好，各块中间件的监控，还是由熟悉的同学去采集相关指标，按照监控系统的格式要求上报数据。比如DBA对mysql比较熟悉，知道mysql应该监控哪些指标，大数据运维人员对hadoop相关的指标比较熟悉，那就让专业的人干专业的事。

**三、应用层面**

图中应用层面的4个指标：访问成功率、访问耗时、访问流量、服务饱和度，一般称为应用的四个黄金指标，非常非常关键。

应用层面的监控即APM，Application Performance Monitor，采集方式多种多样，典型的推荐做法，是业务埋点，内嵌监控的SDK，写一些AOP的逻辑，每个请求结束的时候调用SDK埋个点。比如statsd生态，Nightingale v5版本会内置statsd的能力。

Prometheus生态也提供了一些SDK，可以内置Prometheus的SDK，暴露Prometheus相关协议的接口。

有些公司的业务方不方便埋点，此时就得退化一下，用日志的方式来代替，从日志里提取APM相关指标，比如nginx层面的access log，就是一个提取APM数据的良好的数据源。但是要处理日志就要上一套挺重的日志中心，这个成本很多公司也不愿意付出。对于这种场景，还有一个办法来解，就是让用户配置正则表达式，然后流式读取日志，利用正则提取指标数据。

**四、业务层面**

这个层面通常容易忽视，但是，其实是老板特别看重的一个方面，如果，作为运维人员，搞了一套业务指标的采集分析平台，升职加薪绝对有望了。

如果公司对稳定性要求较高，绝大部分服务都不会是单点，单个实例出现问题，比如CPU飙高了，或者IO用的比较高，老板是不会关注的。但是订单量下跌、交易量下跌，确是非常严重的。我司的全公司级别的消防群，就是只接收业务指标的告警。

业务指标的采集和应用层面的采集方法类似，基本也是靠业务埋点、日志提取，除此之外，业务指标还有一个重要的来源，就是数据库binlog，比如有个订单表，每插入一条数据，就认为订单量+1，那我只要从binlog中统计最近一分钟有多少insert语句，就可以得知最近一分钟的订单量。

OK，本小结是对监控数据采集做了一个概要介绍，后面的章节会以Nightingale v5举例，看各个方面的指标具体是怎么采集的。

[v2-fdeec0f27c78bfb1a42f4398805e8175_b.jpg]: /images/20221005/c4fc161913ad4acaaebead3968208268.png