这章开始讲解监控指标的采集，采集的范围就太广了，任何一个需要监控的目标都有的讲，开源的中间件数据库有几百个，每个都要讲解相关的采集知识意义不大，我们也没有这么广的知识面。后面主要讲解采集框架和常用采集插件，会侧重原理讲解，大家理解了原理，就可以举一反三了解其他的采集插件了，也可以自定义采集插件。

指标采集方式概述

不同的监控目标，其监控指标的采集方法不尽相同，不过总结起来会有如下几类：

1、通过文件系统
OS层面很多监控数据都是通过文件系统的接口暴露的，比如Linux的/proc目录，这个目录下暴露了很多监控指标，比如内存大小、内存使用率、CPU时间、进程、文件句柄等

2、通过系统调用
典型的比如硬盘分区使用率，就需要statfs的系统调用

3、通过命令调用
很多命令的输出内容很有价值，可以从中解析出指标数据，举例，老版本的 Open-Falcon 曾经使用了一种方法来判断端口是否在监听，就是用的命令：ss -tlnp 然后解析命令输出即可

4、通过接口查询
很多中间件会暴露查询接口，调用这些接口就可以获取到监控数据，比如tomcat、rabbitmq，但是这些接口没有规范，每个中间件都不尽相同，mysql、redis、snmp也可以姑且算作是通过接口查询，比如mysql的监控数据很多是来自show global status的输出，redis的监控数据很多是来自info的输出，snmp采集网络设备则是各种的snmpget、snmpwalk。

Prometheus出来之后，制定了一种接口协议，可以通过HTTP的方式暴露出监控数据，只要内嵌Prometheus的SDK，暴露相关指标是较为容易的，比如rabbitmq 3.8之后的版本，就支持了Prometheus协议的指标暴露方式，这是一个巨大的进步，未来支持该协议的中间件越来越多，采集起来就会容易很多，甚至可以自动探测。

5、黑盒探测方式
典型的是通过ICMP、TCP、UDP、HTTP方式对目标做探测，看看目标是否响应，如果响应的话可以检查响应内容是否符合预期，比如监控机器是否能PING通，监控某个域名是否能访问等。

6、监控目标主动推送
前面几条都是监控采集器主动去目标那里采集数据，也可以反其道而行，监控系统定义好规范，由监控目标主动推送，典型的是statsd的埋点，业务程序通过statsd的SDK埋点，然后通过udp的方式推送给statsd。

采集器部署方案

根据上文总结的常用指标采集方式，可以推断出采集器的部署方式，通常分为两种，一种是就近部署，一种是远程探测。通过文件系统或者通过系统调用这种方式获取监控数据，那只能把采集器部署在目标机器上；而通过接口查询方式或者通过黑盒探测方式，采集器就可以放在中心，统一去远端采集了。

就近部署方式架构样例

每个机器上部署客户端采集器，我们建议的采集器是categraf，采集本机的CPU、内存、磁盘、IO、网络等指标，采集到之后通过HTTP方式推给夜莺的Server端。

远程探测方式架构样例

公有云提供的rds或者redis等服务，我们是无法登录rds或redis实例所在的机器的，这种情况只能用远程探测的方式，我们可以部署多个采集器，分担一下采集压力，比如使用categraf来做采集器，某个特定的categraf用于采集所有的rds实例，另一个categraf用于采集所有的redis。

关于推拉模型

监控数据推拉模型，是一个监控领域经常讨论的话题，监控数据采集到之后，是通过调用监控服务端的接口推给服务端（推的方式）？还是被监控对象提供接口，等着监控系统来拉取（拉的方式）？This is a question.

这个小节，对于监控新手估计难以有共鸣，大家就当看个乐，或许面试的时候会聊到，对于资深监控玩家，应该会有强烈共鸣。

大部分监控系统都是采用的推的方式，特别是SaaS服务型，比如Datadog，APPDynamic，NewRelic，开源的比如 Zabbix、Open-Falcon 都是推模型，拉模型最典型的是 Prometheus。我们聊聊推拉模型的优缺点：

推的方式，优点：

  • 架构比较简单，只要知道服务端地址和协议，就可以推
  • 监控平台作为数据被动接收方，接收数据的组件无状态，可以较为方便水平扩展

推的方式，缺点：

  • 如果数据一开始就没推上来，从监控平台角度较难感知到
  • 需要事先知道监控服务端地址才能接入，如果某个组件是先于监控系统部署的，可能就需要重启这个组件，把推送地址改好了才能上报监控数据

拉的方式，优点：

  • 很容易感知目标监控对象是否存活，拉不到数据就说明目标有问题
  • 被监控的服务可以先部署，后面再部署监控系统，不重启被监控的服务也可以对其监控

拉的方式，缺点：

  • 需要一个注册中心，拿到目标地址列表，架构上相对复杂
  • 监控系统要提供抓取器，抓取器的扩容，可能会带来管理上的复杂度

场景举例：

比如 RabbitMQ、Zookeeper、nginx_vts 这些组件可能会先于监控系统部署，等后面监控系统部署完了之后，如何与其交互呢？这些组件都直接内嵌了 Prometheus SDK，提供 Prometheus 协议的 metrics 数据，监控系统部署完了，就直接去拉取其 metrics 接口数据即可，方便！这是拉模式的最典型妙用。

Kubernetes 中部署的业务容器，每个都集成了监控SDK，对于超大规模集群，这些业务监控数据的抓取是个很痛苦的事情，要想各种分片方法，让这些业务直接通过监控服务端接口推数据，或者提供 metrics 接口，用 sidecar 来抓，然后 sidecar 再推给服务端，这个方式扩展起来就非常容易了，这是推的方式的好处。

当然了，推拉模式并不是非黑即白，什么场景就用什么，一切皆是工具手段，架构设计才是最关键的。

本章就介绍到这里，该系列文章教程会持续更新，欢迎关注本公众号，后续内容会持续放出，欢迎一键三连，给笔者继续更新下去的动力 ????

本文由mdnice多平台发布