快速开始

[UlricQin]

前言

cprobe 是一个缝合怪，整合 Prometheus 服务发现的能力以及各类 Exporter 的能力，预期是做一个 All-in-One 的探针采集器。为何有此想法呢？主要是社区里各类 Exporter 的设计参差不齐，使用不同的传参方式，不同的配置方式，配置文件缺少INCLUDE机制，认证信息的管理各异，使用不同的日志库，有的Exporter和目标实例之间是一对多的关系，有的是一对一的关系等等，两个字概括，就是”混乱“。要是能有一个统一的采集器把这些能力集成起来，统一规范化设计就好了，cprobe 应运而生。

对比

社区有一些其他采集器，比如 grafana-agent，也是一个缝合怪，也是把各类 Exporter 的能力整合在一起，但是整合的非常生硬，缺少统一化设计，对目标实例的服务发现支持较弱；telegraf 和 categraf 则自成一派，指标体系没有拥抱 Prometheus exporter 生态，相关仪表盘、告警规则资源匮乏，另外服务发现机制做的也不好。datadog-agent 确实比较完备，但是生态上也是自成一派，服务于自身的 SaaS 服务，较少有开源用户采用。

以我当前的认知，监控数据的采集大抵需要三个角色，一个是部署在所有的目标机器上的，比如使用 categraf，中心端需要两个采集器，一个用于采集 Prometheus 协议的端点数据，可以使用 vmagent 或 Prometheus agent mode，另外一个用于采集所有非 Prometheus 协议的端点数据，计划就是 cprobe。

当前进展

cprobe 刚刚起步，目前主要是在完善基础框架，框架层面已经达到 GA 的水平，当然，为了便于测试整个流程，也已经把 mysql_exporter 整合了进来。这个时候的代码是最为简单清晰的最小功能集，如果大家想要参与，建议阅读此时的代码。

代码仓库：https://github.com/cprobe/cprobe

项目文档偷个懒，会直接放到 issues 里，打上不同的标签。大家如果有建议和 PR 的想法，请先提 issue。cprobe 会尽量完善文档，会成立面向研发人员和资深用户的交流群（加群联系我的微信：picobyte，备注 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 的方式暴露更多调试信息。另外就是完善中英文文档。当然，大家如有建议也欢迎留言给我们。