龙渊秦五

V1

2022/07/08阅读:14主题:默认主题

【连载】运维监控数据采集,必知必会

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

指标采集方式概述

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

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 再推给服务端,这个方式扩展起来就非常容易了,这是推的方式的好处。

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

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

分类:

后端

标签:

运维部署

作者介绍

龙渊秦五
V1