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

上一节给大家介绍了监控指标在code层面的数据结构，这一节讲解一下监控数据从采集到传输到处理的整个架构流程，大部分监控系统都超脱不了这个架构，理解本篇，就理解了大部分监控系统的架构啦。

一、数据采集

这块的手段比较多样，整体上会有这么几种情况，下面挨个讲解。

1，在目标机器上部署agent

这种是最常见的方式，互联网公司大都采用这种方式，agent部署上去，就可以自动采集一些cpu、内存、磁盘、io、网络相关的系统基础指标。

除了这些基础指标，一些集成度高的agent也可以进程、端口、日志、执行插件、甚至作为探针去采集一些中间件的指标。这些非基础指标的采集，通常是需要用户指定的，比如要采集日志，具体是采集哪个文件的日志，agent显然是不知道的，要采集哪个端口，agent显然也是不知道的。用户指定的话，会有两种方式，一种是给agent指定特定的配置文件，另一种是在web端做配置，然后agent与server通信拉取这些配置。web上做配置更易用一些，但是有时要采集的内容配置起来很麻烦，web的表现能力略弱，此时一般用配置文件就很典型。

2，不准在机器上部署agent

有些偏传统的企业，是不准在机器上部署agent的，说是为了安全考虑，但是允许监控服务端作为探针，通过ssh的方式登录目标机器执行脚本，然后脚本要被审查，都允许被人家ssh上来了，还说安全，唉，客户就是上帝~

另一种就是把机器当做网络设备那样处理，开启snmpd，通过snmp的方式来读取监控数据，此时，snmpd其实就充当了监控的agent。

3，网络设备通常是走snmp

网络设备上一般会有snmpd，监控服务端作为探针，可以连上去，通过snmp协议读取监控数据。

网络设备的日志一般也会通过syslog推出来，监控的服务端来分析这些syslog数据，产生告警事件。

4，数据库中间件类监控

数据库中间件类的监控，也是比较典型的一个大类。

数据库的监控通常是需要数据库连接地址和用户名密码，然后搞个探针服务，周期性的连到数据库上，执行一些命令读取监控数据，比如 `show global status` 一下，或者在之前的章节里简单提过的例子，即 Redis 的 `info` 指令。

其他的中间件也类似，比如tomcat，会暴露status接口，读取这个接口就可以获取监控指标。

二、数据传输

数据传输一般有两种手段，push模型和pull模型，比如大名鼎鼎的Prometheus，就是pull模型，哪里有监控数据，哪里就要暴露http接口，遵照一个特定的Prometheus的规范，Prometheus就会周期性的读取这些接口拉取数据。

Nightingale就是push模型，agent采集到数据之后，主动推给server。采用push模型的监控系统比较多。即使是Prometheus主推pull模型，也会提供一个pushgateway来应对push场景。

什么叫push场景？典型的就是短周期任务，比如写个cron脚本，定期去跑，每次收集一些数据，推给服务端，然后脚本退出。因为脚本不是一个一直在监听的http server，所以没法采用pull的方式。

在大规模微服务监控的场景，push模型对naming的依赖比较小，只要知道server的地址，采集到数据之后直接推送即可。pull模型要知道所有目的端http地址，如果有很多服务，这些服务最好是注册到一个统一的naming，然后拉取的时候就可以从naming中得知目标地址，否则每上线一个服务就去手工配置一下拉取地址，一般人恐怕都受不了。

机房网络分区隔离怎么办？

这是个典型问题，监控服务端部署在中心机房，大部分都有专线与中心机房互联互通，直接推送监控数据即可。但是，有些机房网络比较特殊，不能随便连接到服务端，此时一般的做法就是做代理。

在隔离网络区域找一台机器，打通这台机器到服务端的链路，在这台机器部署代理，该机器的agent连到代理服务器，代理服务器将请求转发给中心。

三、数据接收和转发

监控数据被称为时序数据，大企业量很大，一般一台机器很难存储，所以服务端通常会有多台机器，组成一个存储集群。server接收到数据之后，就需要转发给存储集群。所以server端一般不会只有一个模块，而是按照功能做拆分，不同的模块负责不同的事情，比如数据接收和转发就是一个单独的模块，Open-Falcon里称为transfer。

但是，开源软件需要易于部署才能易于推广，多个模块的理解成本显然更高，所以把多个模块合并在一起，减少服务端模块的数量，也是个典型做法。在笔者所在的公司，数据接收和转发是一个小模块，部署在容器里，部署了500多个容器，体量巨大。

数据除了转发给时序数据库做存储，还有一些其他的地方可能也需要拿到监控数据，做一些分析之类的，此时为了扩展方便，server一般会支持把监控数据推送给kafka一份，这样谁想消费谁来对接kafka即可。

监控数据一个很重要的功能，是用于做告警分析判断，所以server拿到数据之后一般会转发一份给告警引擎，当然，这种做法是数据触发式的。还有些告警引擎是周期性轮询时序库读取数据的，那种设计模式，就不需要接收server的数据转发了。

四、时序数据存储

监控数据是周期性采集的，而且每条数据都带有时间戳，故而被称为时序数据，在数据库这个领域，有多种数据库的分类，时序数据库是其中一种重要的分类。特别是近几年IoT的兴起，大家对时序数据库的关注也越来越高。

常见的时序数据库，有很多，比如OpenTSDB、InfluxDB、M3DB、Prometheus、VictoriaMetrics、TimescaleDB、TDEngine等等。

Nightingale马上发布v5版本，在v5版本，如果是单机部署测试，建议用Prometheus做存储，如果是上生产环境，对容灾要求很高，建议是M3DB，我们自研的时序库在索引的处理上还有些不够好，当前不建议，后续待我们优化好了索引处理，也可以用我们自研的时序库。

五、告警判断

告警判断逻辑，通常有两种方式，一个是数据触发式，就像Open-Falcon那样的，监控数据上报上来，引擎来判断，这个数据关联了哪些策略，然后挨个比对阈值。另一种方式是周期性检查，比如用户总共配置了1000条规则，判断频率是10s，那就每10s执行一次查询，把数据查询出来做阈值比对。

数据触发式，好处是即时性好，来了数据立马做比对，但是通常只能针对单指标。周期性判断的方式，告警规则可以支持比较复杂丰富的表达式，针对多个指标做计算之类的，相对更灵活，但是即时性不好。

六、事件处理

告警引擎产生告警事件，告警事件的处理可以很简单，就是直接发送告警通知给告警接收人即可。也可以弄的比较复杂，比如支持事件降噪、归并、丰富、规整、升级、认领、重复通知、关联分析等等。

事件的这个复杂的处理逻辑其实是挺有用的，而且是很通用的，Nightingale需要，Zabbix也需要，Prometheus也需要，所以笔者的建议是把事件的分析处理独立为一个单独的产品好好去打磨，就不要让监控系统来承担这个职责。一般企业都会同时用多个监控系统，省的重复造轮子。

好了，今天的介绍就是这么多。把整个监控系统的核心逻辑都给大家介绍了下，监控看图部分没啥可讲的，就没有段落介绍，希望可以帮到你。