cprobe 是一个缝合怪,整合 Prometheus 服务发现的能力以及各类 Exporter 的能力,预期是做一个 All-in-One 的探针采集器。为何有此想法呢?主要是社区里各类 Exporter 存在以下问题:
- 良莠不齐:有的 Exporter 写的非常棒,有的则并不完善,有些监控类别甚至有多个 Exporter,选择困难
- 写法各异:Exporter 所用的日志库、配置文件管理方式、命令行传参方式各异
- 倚重边车模式:有些 Exporter 和采集目标之间是一对一的关系,有几个采集目标就需要部署几个 Exporter,在 Kubernetes 环境下相对容易管理,在物理机虚拟机环境下管理起来就比较复杂了,而且多个 Exporter 还会带来资源成本的提升
- 配置文件切分:对于非边车模式的 Exporter,即一个 Exporter 对应多个采集目标的,通常很难做到不同的采集目标不同的配置,期望能有一种配置文件切分 INCLUDE 机制,不同的采集目标采用不同的配置
- 缺乏监控目标服务发现:对于支持 /probe 模式的 Exporter,服务发现就通过 Prometheus + relabel 模式来实现了,如果不支持 /probe 模式的 Exporter 则缺乏监控目标的服务发现机制
要是能有一个统一的采集器把这些能力集成起来,统一规范化设计就好了,cprobe 应运而生。
对比
社区有一些其他采集器,比如 grafana-agent,也是一个缝合怪,也是把各类 Exporter 的能力整合在一起,但是整合的非常生硬,缺少统一化设计,对目标实例的服务发现支持较弱;telegraf 和 categraf 则自成一派,指标体系没有拥抱 Prometheus exporter 生态,相关仪表盘、告警规则资源匮乏,另外服务发现机制做的也不好。datadog-agent 确实比较完备,但是生态上也是自成一派,服务于自身的 SaaS 服务,较少有开源用户采用。
以我当前的认知,监控数据的采集大抵需要三个角色,一个是部署在所有的目标机器上的,比如使用 categraf,中心端需要两个采集器,一个用于采集 Prometheus 协议的端点数据,可以使用 vmagent 或 Prometheus agent mode,另外一个用于采集所有非 Prometheus 协议的端点数据,计划就是 cprobe。
当前进展
cprobe 刚刚起步,目前主要是在完善基础框架,框架层面已经达到 GA 的水平,插件已经整合进来了 mysql_exporter、redis_exporter、kafka_exporter、blackbox_exporter。这个时候的代码是最为简单清晰的最小功能集,如果大家想要参与,建议阅读此时的代码。
代码仓库:https://github.com/cprobe/cprobe
安装
到 cprobe 的 releases 页面 https://github.com/cprobe/cprobe/releases 下载发布包。解包之后核心就是那个二进制 cprobe,通过如下命令安装:
./cprobe --install ./cprobe --start
如果是支持 systemd 的 OS,上面的安装过程实际就是自动创建了 service 文件,你可以通过下面的命令查看:
systemctl status cprobe
如果不是 systemd 的 OS,会采用其他进程管理方式,比如 Windows,会创建 cprobe 服务。
配置
解压缩之后应该可以看到 conf.d 目录,这是配置文件所在目录,未来的规划是 writer.yaml + 一堆插件目录,当然项目起步阶段,所以只有 writer.yaml + mysql,因为只有 mysql 一个插件得到支持。
writer.yaml 是配置 remote write 地址(不知道什么是 remote write 地址,请自行 Google:Prometheus remote write),可以配置多个,默认配置如下:
global: extra_labels: colld: cprobe writers: - url: http://127.0.0.1:9090/api/v1/write
这是一个极简配置,也基本够用,实际 writer.yaml 中还可以配置不同时序库后端的认证信息以及 relabel 的配置,同级目录下有个 backup.yaml 可以看到一些配置样例。
不同的插件的配置会散落在各个插件目录里,以 mysql 插件举例,相关配置在 conf.d/mysql
下面,入口文件是 main.yaml,用于定义需要采集的 mysql target,计划至少提供三种 service discovery 机制:static_configs、http_sd_configs、file_sd_configs,这个配置和 Prometheus 的 scrape 配置基本保持一致。
在 cprobe 场景下,cprobe 会直连监控目标,比如 mysql 的监控,Prometheus 是从 mysqld_exporter 获取监控数据,而 cprobe 是直连 mysql,所以 main.yaml 中要配置一些采集规则,即 scrape_rule_files。scrape_rule_files 是个数组,即可以把配置文件切分管理,这提供了极大的管理灵活性,各位自行发挥了。
mysql 的采集插件 fork 自 mysqld_exporter,所以相关指标体系、仪表盘都可以复用。当然,也做了一些改造,原来 mysqld_exporter 是一套采集规则应用到所有的 target,在 cprobe 这里,不同的 target 可以采用不同的 scrape_rules,修改了原来通过命令行传参的机制以支持并发。另外就是扩展了自定义 SQL 能力,通过自定义 SQL 来抓取更多监控指标。更多信息可以参考:mysql 插件文档。
后续规划
最核心的是增加更多插件,不同的插件要整理仪表盘、告警规则。框架层面,希望增加更多自埋点数据,通过 HTTP 的方式暴露更多调试信息。另外就是完善中英文文档。当然,大家如有建议也欢迎留言给我们。