核心要点
- cprobe 要解决的是 Prometheus Exporter 生态繁荣但体验分散的问题。
- 它定位为中心端探针式采集器，主要采集非 Prometheus 协议的端点数据，并和 vmagent 或 Prometheus agent mode 配合。
- 当前已经完成基础框架，并集成 mysql、redis、kafka、blackbox 等 exporter 能力。
- 配置上支持统一日志、配置文件切分、不同目标不同配置、file_sd/http_sd 服务发现和自定义采集规则。
- 后续重点是增加插件、整理仪表盘和告警规则、补充自监控与文档。
需求背景
监控数据采集领域，比如 Prometheus 生态有非常多的 Exporter，虽然生态繁荣，但是无法达到开箱即用的大一统体验，Exporter 体系的核心问题有：
- 良莠不齐：有的 Exporter 写的非常棒，有的则并不完善，有些监控类别甚至有多个 Exporter，选择困难
- 写法各异：Exporter 所用的日志库、配置文件管理方式、命令行传参方式各异，体验不一
- 倚重边车模式：有些 Exporter 和采集目标之间是一对一的关系，有几个采集目标就需要部署几个 Exporter，在 Kubernetes 环境下相对容易管理，在物理机虚拟机环境下管理起来就比较复杂了，而且多个 Exporter 还会带来资源成本的提升
- 配置文件切分：对于非边车模式的 Exporter，即一个 Exporter 对应多个采集目标的，通常很难做到不同的采集目标不同的配置，期望能有一种配置文件切分 INCLUDE 机制，不同的采集目标采用不同的配置
- 缺乏监控目标服务发现：对于支持
/probe模式的 Exporter，服务发现就通过 Prometheus + relabel 模式来实现了，如果不支持/probe模式的 Exporter 则缺乏监控目标的服务发现机制
| 问题 | 具体表现 | cprobe 想解决的方向 |
|---|---|---|
| Exporter 分散 | 不同组件有不同 exporter，部署和升级成本高 | 通过插件机制统一采集体验 |
| 配置割裂 | 日志、启动参数、配置格式各不相同 | 统一日志库、配置管理和配置切分 |
| 目标管理弱 | 多目标采集、目标发现和目标差异化配置不方便 | 支持 file_sd、http_sd 和不同目标不同配置 |
| 生态复用难 | 非 Prometheus 生态采集器指标命名不统一 | 尽量复用 Prometheus Exporter 生态资源 |
要是能有一个统一的采集器，把这些问题都解决掉，采用插件机制，All-in-One 采集所有监控目标，不同的插件体验一致，那该多好啊！cprobe 应运而生！
对比
社区有一些其他采集器，比如 grafana-agent，也是一个缝合怪，也是把各类 Exporter 的能力整合在一起，但是整合的非常生硬，缺少统一化设计，对目标实例的服务发现支持较弱；telegraf 和 categraf 则自成一派，指标体系没有拥抱 Prometheus exporter 生态，相关仪表盘、告警规则资源匮乏，另外服务发现机制做的也不好。datadog-agent 确实比较完备，但是生态上也是自成一派，服务于自身的 SaaS 服务，较少有开源用户采用。
以我当前的认知，监控数据的采集大抵需要三个角色，一个是部署在所有的目标机器上的，比如使用 categraf，中心端需要两个采集器，一个用于采集 Prometheus 协议的端点数据，可以使用 vmagent 或 Prometheus agent mode，另外一个用于采集所有非 Prometheus 协议的端点数据，计划就是 cprobe。
| 角色 | 典型工具 | 主要职责 |
|---|---|---|
| 主机本地采集 | Categraf | 采集主机本机 CPU、内存、磁盘、网络等数据 |
| Prometheus 协议端点采集 | vmagent 或 Prometheus agent mode | 抓取 exporter 暴露的 Prometheus 指标 |
| 非 Prometheus 协议端点采集 | cprobe | 直连 MySQL、Redis、Kafka、Blackbox 等目标或协议 |
当然，vmagent 和 cprobe 都是探针角色，理论上可以合二为一，未来也会考虑让 cprobe 支持采集 Prometheus 协议的端点数据，这样就可以把 vmagent 去掉了，不过 vmagent 确实工作的很好，而且已经有很多用户在使用了，所以这个计划暂时搁置。
当前进展
cprobe 刚刚起步，完成了基础框架的搭建，也集成了 mysql、redis、kafka、blackbox 这几个 exporter，代码已经公布到 github：
项目文档偷个懒，会直接放到 issues 里，打上不同的标签。大家如果有建议和 PR 的想法，请先提 issue。cprobe 会尽量完善文档，会成立面向研发人员和资深用户的交流群（加群联系我的微信：picobyte，备注 cprobe-公司名-姓名）。
这几个插件在整合的过程中，也做了一些改动，主要改动如下：
- 统一日志库，统一日志格式，统一日志级别控制
- 统一配置文件管理，支持配置文件切分
- 支持不同的采集目标不同的配置
- 支持采集目标的服务发现，目前主要是 file_sd 和 http_sd
- mysql 插件支持了自定义 sql
- kafka 插件原本是一个 Kafka 集群一个 exporter，现在可以一个 cprobe 监控多个 Kafka 集群
安装体验
到 cprobe 的 releases 页面 https://github.com/cprobe/cprobe/releases 下载发布包。解包之后核心就是那个二进制 cprobe，通过如下命令安装：
sudo ./cprobe -install
sudo ./cprobe -start
如果是支持 systemd 的 OS，上面的安装过程实际就是自动创建了 service 文件，你可以通过下面的命令查看：
systemctl status cprobe
如果不是 systemd 的 OS，会采用其他进程管理方式，比如 Windows，会创建 cprobe 服务。
配置
解压缩之后应该可以看到 conf.d 目录，这是配置文件所在目录。writer.yaml 外加一堆的插件配置目录。 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。target 的服务发现方式支持两种：file_sd 和 http_sd，当然，也支持 static_configs。
在 cprobe 场景下，cprobe 会直连监控目标，比如 mysql 的监控，Prometheus 是从 mysqld_exporter 获取监控数据，而 cprobe 是直连 mysql，所以 main.yaml 中要配置一些采集规则，即 scrape_rule_files。scrape_rule_files 是个数组，即可以把配置文件切分管理，这提供了极大的管理灵活性，各位自行发挥了。各个插件的配置目录下通常都会有个 doc 目录，里面会有个 README.md，README.md 中会对插件配置做说明。
后续规划
最核心的是增加更多插件，不同的插件要整理仪表盘、告警规则。框架层面，希望增加更多自埋点数据，通过 HTTP 的方式暴露更多调试信息。另外就是完善中英文文档。当然，大家如有建议也欢迎留言给我们。
FAQ
cprobe 和 vmagent 是什么关系？
文章中的定位是互补关系。vmagent 负责 Prometheus 协议端点数据采集，cprobe 负责非 Prometheus 协议的端点数据采集。未来 cprobe 理论上可以支持 Prometheus 协议端点，但当前计划暂时搁置。
cprobe 和 Categraf 是什么关系？
Categraf 更适合部署到目标机器本机，采集主机级指标；cprobe 更像中心端探针，面向远端数据库、中间件、网络探测等对象。
为什么强调服务发现和配置切分？
监控对象数量一多，手工维护目标和复制配置会很快失控。服务发现解决目标来源，配置切分解决不同目标复用和差异化管理。
小结
cprobe 的核心价值不是把多个 exporter 简单打包进一个二进制，而是尝试用统一插件、统一配置、服务发现和 Prometheus 生态兼容能力，重新组织远端监控对象的采集体验。它适合作为中心端探针，补齐 vmagent 或 Prometheus agent mode 不负责的非 Prometheus 协议采集场景。
