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

ゝ一世哀愁。 2022-10-16 07:50 207阅读 0赞

上一节给大家介绍了监控指标在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执行一次查询，把数据查询出来做阈值比对。

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

**六、事件处理**

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