常见的监控数据采集器有哪些？各有什么优缺点

夜莺社区很多新朋友会问，夜莺能监控什么什么么？其实夜莺啥都可以监控，又啥都不能监控。因为夜莺自身不参与监控数据的采集，你可以使用 telegraf、categraf 等各类采集器采集数据存入时序库，之后，夜莺就可以对时序库里的数据做分析、告警。换句话说，夜莺不在意你用什么采集器，只要能把数据存入时序库就行。

那么接下来问题来了，市面上有很多监控数据采集器，各自有哪些优缺点，如何选型？本文就来唠唠这个话题。如果有错误或遗漏，欢迎大家在评论区留言。

1. Telegraf

Telegraf 是 InfluxData 开源的一个数据采集器，主要是配合 InfluxDB 使用，当然也可以和 Prometheus 生态对接。它的优点是：

• 支持非常非常多输入插件和输出插件，适用场景广泛。你能想到的采集需求，它基本都有。
• 数据结构设计很优雅，笔者认为比 Prometheus 的格式要好，小巧精悍，表意丰富。

缺点是：

• 插件很多，很多插件的质量参差不齐，因为没有人可以对所有采集方向都熟悉，很多时候代码 review 也难以看出不妥的地方，使用时需要多加注意。
• Telegraf 和 InfluxDB 的整合很好，但是和 Prometheus 生态的整合不太好，如果去 Grafana 里搜索大盘，可以看出，Telegraf 的大盘数量比较少，需要自己动手折腾。

2. Categraf

Telegraf 主要是为了 Influx 生态，Categraf 则主要是为了夜莺生态，为了和夜莺更丝滑打通，势必需要攒一个新的采集器。Categraf fork 了很多 Telegraf 的代码，也 fork 了很多 Exporter 的代码，向上游致敬！Categraf 想做 All-in-one 的采集器，而很多逻辑没必要重复造轮子，所以出现这种情况。

Categraf 的优点是：

• 和夜莺深度整合。比如夜莺的很多内置告警规则、仪表盘都是针对 Categraf 的，机器列表里的机器元信息也是通过 Categraf 特殊采集的。即便你不想更换原来的采集器又想使用夜莺，那也建议至少把机器层面的监控数据采集器换成 Categraf，这样可以避免很多不必要的麻烦。
• Categraf 不但整合了常见采集插件，还整合了 mtail、datadog-agent 的日志采集器，对 snmp、mysql 等常见采集器做了生产级优化。

Categraf 的缺点是：

• Categraf 的日志采集不支持 agent 侧的 Pipeline，不支持通过 HTTP 的方式直接写入 ElasticSearch，对于一些中小型企业来说，可能会有点麻烦。中大型企业势必会引入 Kafka 以及服务端 Pipeline 的方式来处理日志数据。

3. Prometheus 各类 Exporter

这倒不是一个软件了，而是一批软件，比如 Blackbox Exporter、Node Exporter、JMX Exporter、MySQL Exporter 等等。它们的优点是：

• 由于是 Prometheus 生态的，和 Prometheus 的整合非常好，生态繁荣资料多，通常都能较为方便找到对应的仪表盘和告警规则。

缺点是：

• Exporter 是不同人写的，配置方式有差异，启动方式有差异，日志打印方式有差异，不一致感比较强
• 有些 Exporter 和监控目标是一对一的，感觉不太方便，好在很多 Exporter 都已改造为一对多的方式了

前段时间笔者还做过一个开源项目，把常用的 Exporter 整合到一起，叫做 Cprobe，其特点是：

• 一个二进制，集成了众多 Exporter，统一了配置方式、日志打印
• Cprobe 中的所有插件（Exporter）都是一对多的关系，即一个插件可以同时采集多个监控目标
• 由于监控不同的目标可能需要不同的配置，而相同的配置又希望复用，所以 Cprobe 设计了很好用的配置文件复用机制

4. Datadog Agent

Datadog 是可观测性领域的领头羊，这个毋庸置疑，他们开源的 Agent 也是很值得尝试的，但是 Datadog-agent 有自己的数据传输协议，比如指标数据并非是遵照 Prometheus remote write 协议的，要想和 Datadog-agent 整合，就需要服务端能够接收 Datadog-agent 的数据格式。Datadog-agent 的优点是：

• 稳定可靠
• 支持丰富的采集插件

缺点是：

• 有自己的指标命名方式，和 Prometheus 的指标命名不同，所以 Prometheus 生态的仪表盘、告警规则等不能直接使用

5. OpenTelemetry

各个厂商提供的采集器协议不同、指标名称不同，给客户带来很大的困扰。而且厂商迁移时也很麻烦，各个厂商都觉得自己的服务端能力更厉害，如果采集侧没有供应商绑定了，那就对自己有利。所以，各大厂商就聚在一起，想统一化采集侧。于是 OpenTelemetry 这样的项目就诞生了。

OpenTelemetry 的优点是：

• 无供应商锁定，几乎所有供应商都支持 OpenTelemetry 的协议，即可以接收 OpenTelemetry-Collector 推过来的数据
• 同时支持指标、日志、跟踪等多种数据类型

OpenTelemetry 的缺点是：

• 目前仍处于快速迭代阶段，很多功能还不够稳定
• 指标方面老想重复造轮子，很多插件采集的数据无法复用现有的告警规则和仪表盘

6. Grafana Alloy

Grafana 之前做过一个项目叫 Grafana-agent，想把各种 Exporter 整合起来，后来放弃了，重新搞了 Alloy，Alloy 不但替代了 Grafana-agent，也替代了 Promtail。Grafana Alloy 的定位，现在算是 OpenTelemetry 的一个发行版，基于 OpenTelemetry 做了修改。

Grafana Alloy 的优点是：

• 同时支持指标、日志、跟踪等多种数据类型
• 按照自己的 DSL 重新组织采集侧的 Pipeline，体验更为一致

Grafana Alloy 的缺点是：

• OpenTelemetry 的无供应商锁定优势，在 Alloy 这个发行版上就不适用了
• Grafana Alloy 设计的 DSL 和 OpenTelemetry 的配置方式不同，需要重新学习
• OpenTelemetry 的缺点，部分插件不稳定、瞎造轮子等，Grafana Alloy 也都有

7. Zabbix agent

Zabbix agent 用户很多，所以也列到这里。但是 Zabbix agent 算是上个时代的产物了，生态封闭，难以和 Prometheus 生态整合。有些人想把 Zabbix agent 采集的数据转发给 Prometheus 生态，从技术上可以实现，但是交付成本很高，所以开源领域一般不提供，商业监控产品中会有这类能力。比如 Flashcat 这种要整合各类监控产品的，就会提供这类能力。

Zabbix agent 的优点是：

• 成熟稳定
• 支持的操作系统比较多，比如 AIX 之类的老古董操作系统也支持

Zabbix agent 的缺点是：

• 各类中间件、数据库等采集的指标偏少、灵活度差一些
• 业务层面的指标基本绝缘
• 生态封闭，难以和 Prometheus 生态整合

总结

市面上有很多监控数据采集器，各自都有优缺点，选型时需要根据自己的需求来选择。通常一个采集器没法搞定所有问题。建议主推一个，这个主力采集器覆盖不了的场景，可以使用其他采集器来补充。