核心要点
- 新项目的目标是做一个探针式监控采集器，用 Go 语言编写，面向远端监控对象采集数据。
- 本地式采集器部署在被监控机器上，读取本机 CPU、内存、磁盘、IO、网络、eBPF 等数据；探针式采集器可以部署在任意能访问目标的位置。
- 项目希望拥抱 Prometheus Exporter 生态，同时解决 Exporter 数量多、部署分散、配置复用差、资产管理弱的问题。
- 新组件不会重复采集 Prometheus 协议端点数据，而是作为 vmagent 或 Prometheus 的补充，负责其他协议的数据采集。
- 当前阶段欢迎有开源项目经验、监控系统深度使用经验或愿意参与文档、测试、设计讨论的朋友加入。
我想搞一个新的开源项目，想邀请同道中人一起来搞。目标是做一个探针式监控采集器，使用 Go 语言编写，欢迎感兴趣的朋友一起来搞。
名词解释
探针式监控采集器，这里的探针式是啥意思？
这是我的个人叫法，监控数据采集器姑且可以分成两种，一种是本地式，部署到要监控的目标机器上，采集 CPU、内存、磁盘、IO、网络、eBPF 相关的指标，因为这些指标只能在机器上采集，需要读取本机的 /proc 等目录内容，所以，采集器必须部署到要监控的目标机器上，称为本地式；另一种采集器称为探针式，用于采集远端监控对象的数据，比如通过 SNMP 采集网络设备的监控数据，通过 HTTP 采集 ElasticSearch 的监控数据，通过 TCP 连上 MySQL、Redis 等采集对应的监控数据，这种采集器可以部署在任何地方，只要能访问到监控对象即可，姑且称为探针式。
| 类型 | 部署位置 | 典型采集对象 | 关键特点 |
|---|---|---|---|
| 本地式采集器 | 被监控机器本机 | CPU、内存、磁盘、IO、网络、eBPF | 依赖本机 /proc 等数据源，适合主机级指标 |
| 探针式采集器 | 任意能访问目标的位置 | SNMP 设备、Elasticsearch、MySQL、Redis | 通过远程协议访问目标，适合集中采集远端对象 |
市面上的产品
社区里已经有很多相关的产品了，但是或多或少都不如我意。举例：
Prometheus 生态有很多 Exporter，MySQL 的监控数据采集有 mysqld_exporter，Redis 的监控数据采集有 redis_exporter，但是 Exporter 太多了，管理这么多 Exporter 比较费劲。而且有些 Exporter 和监控实例之间甚至是一对一的关系，有多少实例就要部署多少 Exporter，在非容器环境下非常麻烦。
Grafana-agent 倒是把常用的 Exporter 整合到一起了，但是整合的非常生硬，只是二进制层面的，缺少产品层面的统筹设计。
Telegraf、Categraf、Datadog-agent 也是主打 All-in-One，但是并没有拥抱 Prometheus Exporter 生态，相关指标命名各异，导致缺少开箱即用的 Grafana 仪表盘。另外，这些采集器通常是以监控目标作为配置颗粒度，管理采集配置的时候，会发现有很多重复配置，配置文件相当冗长。
我期望的产品
- 还是要拥抱 Prometheus Exporter 生态，可以复用众多仪表盘
- 支持自动发现监控目标，比如网络设备就可以通过网段自动发现，当然，也期望能够支持 HTTP、Consul 等方式的目标发现
- 支持资产式管理监控目标，既可以用标签分类，也可以用目录分类，便于和 CMDB、服务树等整合打通
- 采集配置要能片段化管理，这样就更方便复用（方便经验沉淀分享），比如我自定义了一个 SQL，用于监控所有的 Postgres 的某个指标，那么这个 SQL 的配置就可以复用到所有的 Postgres 实例上
- 要支持数据的 enrichment 和 relabel 机制
- …
这些要求背后的共同目标，是让监控采集从“部署很多采集进程和复制很多配置”，变成“围绕资产、插件、配置片段和标签体系管理采集能力”。只有这样，经验才能复用，配置才能沉淀，采集目标变多之后才不会失控。
不重复造轮子
这个组件不准备采集 Prometheus 协议的指标数据，即不去采集各类 exporter 的数据，因为已经有 vmagent 了，当然，用 Prometheus 也可以抓取各类 exporter 的数据。这个新项目在部署的时候，可以和 vmagent 一起部署，sidecar 的模式，vmagent 来采集 Prometheus 协议的数据，新项目来采集其他协议的数据，新项目姑且可以看做是 vmagent 的补充。
欢迎加入
目前项目处在前期构思和搭架子的过程，欢迎感兴趣的朋友一起参与，不局限代码，也可以贡献想法、建议、文档、测试用例等。最好是之前有开源项目参与经验或者有监控系统深度使用的经验，有兴趣的朋友可以加我微信 picobyte，备注：探针采集器-公司-姓名。
如果你不确定自己能做什么，可以从这几类事情开始：
- 提供真实监控场景，说明现在 Exporter 或采集器哪里不好用。
- 参与插件设计，补充某类中间件、数据库或网络设备的采集需求。
- 整理仪表盘、告警规则和配置样例。
- 编写文档、测试用例，帮助项目降低使用门槛。
- 参与代码开发，完善框架、服务发现、enrichment、relabel 等能力。
关于我以及动机
我是秦晓辉，从 14 年开始搞监控、可观测性相关的事情，是 Open-Falcon、Nightingale、Categraf 的创始研发。这么多年了，想为行业留下点东西，新项目大概率会使用 GPL 协议，纯种开源，希望能够帮助到更多的人。
小结
这个项目想解决的不是“再写一个采集器”这么简单，而是重新梳理探针式监控采集器应该怎么管理目标、复用配置、兼容生态和服务真实生产环境。它会尽量站在 Prometheus 生态之上补短板，而不是重复已有能力。欢迎认同这个方向的朋友一起参与。
