招贤令:一起来搞一个新开源项目

发布时间:2024年01月04日

我想搞一个新的开源项目,想邀请同道中人一起来搞。目标是做一个探针式监控采集器,使用 Go 语言编写,欢迎感兴趣的朋友一起来搞。

名词解释

探针式监控采集器,这里的探针式是啥意思?

这是我的个人叫法,监控数据采集器姑且可以分成两种,一种是本地式,部署到要监控的目标机器上,采集 CPU、内存、磁盘、IO、网络、eBPF 相关的指标,因为这些指标只能在机器上采集,需要读取本机的?/proc?等目录内容,所以,采集器必须部署到要监控的目标机器上,称为本地式;另一种采集器称为探针式,用于采集远端监控对象的数据,比如通过 SNMP 采集网络设备的监控数据,通过 HTTP 采集 ElasticSearch 的监控数据,通过 TCP 连上 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,备注:探针采集器-公司-姓名。

关于我以及动机

我是秦晓辉,从 14 年开始搞监控、可观测性相关的事情,是 Open-Falcon、Nightingale、Categraf 的创始研发。这么多年了,想为行业留下点东西,新项目大概率会使用 GPL 协议,纯种开源,希望能够帮助到更多的人。

文章来源:https://blog.csdn.net/n9ecommunity/article/details/135383407
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。