夜莺社区很多新朋友会问，夜莺能监控什么什么么？其实夜莺啥都可以监控，又啥都不能监控。因为夜莺自身不参与监控数据的采集，你可以使用 telegraf、categraf 等各类采集器采集数据存入时序库，之后，夜莺就可以对时序库里的数据做分析、告警。换句话说，夜莺不在意你用什么采集器，只要能把数据存入时序库就行。
那么接下来问题来了，市面上有很多监控数据采集器，各自有哪些优缺点，如何选型？本文就来唠唠这个话题。如果有错误或遗漏，欢迎大家在评论区留言。
核心摘要
- 夜莺本身不负责采集，关键是选择合适的采集器把数据写入时序库，再由夜莺做分析和告警。
- Telegraf 插件丰富，适用面广，但和 Prometheus 生态的大盘、规则复用不如原生 Exporter 顺手。
- Categraf 更贴近夜莺生态，适合作为机器层面主力采集器，并复用夜莺内置规则、仪表盘和机器元信息。
- Prometheus Exporter 生态资料多、整合好，但不同 Exporter 的配置、启动和日志方式不统一。
- OpenTelemetry 和 Grafana Alloy 更偏多信号采集与 Pipeline 统一，但也带来配置体系、稳定性和生态复用方面的取舍。
选型先看三个问题
选择监控数据采集器，不应该只看“支持插件多不多”。更现实的判断顺序是：
- 现有后端是什么：Prometheus 生态、夜莺、InfluxDB、Datadog，还是多套系统并存。
- 主要采集对象是什么：主机、数据库、中间件、业务指标、日志、链路，还是网络设备。
- 运维成本能否接受：配置方式是否统一、仪表盘和告警规则能否复用、采集器升级和排障是否可控。
如果只用一个采集器覆盖所有场景，往往会很别扭。更常见的做法是选一个主力采集器，再用其他采集器补齐特殊场景。
术语解释：采集器、Exporter 和 Agent
本文里的“采集器”是泛称，指负责从主机、应用、中间件、数据库、网络设备或业务系统采集遥测数据的组件。Exporter 通常指 Prometheus 生态中把目标状态暴露成指标接口的组件；Agent 通常指运行在机器或环境中的采集进程，可以负责指标、日志、链路等一种或多种数据。
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 生态整合
快速对比
| 采集器 | 更适合的场景 | 主要注意点 |
|---|---|---|
| Telegraf | 插件需求多、已有 Influx 生态或需要 all-in-one 采集 | 插件质量参差，Prometheus 生态资料复用不够顺手 |
| Categraf | 夜莺生态、机器监控、希望复用内置规则和仪表盘 | 日志采集能力存在原文提到的限制 |
| Prometheus Exporter | 已经使用 Prometheus 生态，希望复用大盘和告警规则 | 多个 Exporter 的配置和运维体验不统一 |
| Datadog Agent | 已经使用或评估 Datadog 体系 | 指标命名和传输协议与 Prometheus 生态不同 |
| OpenTelemetry | 希望多信号统一、减少供应商绑定 | 仍在快速迭代，部分指标采集难复用现有规则 |
| Grafana Alloy | Grafana 体系、多信号 Pipeline 和统一配置体验 | 需要学习 Alloy DSL，也继承部分 OpenTelemetry 取舍 |
| Zabbix agent | 存量 Zabbix 环境、老操作系统支持 | 生态封闭，和 Prometheus 生态整合成本高 |
总结
市面上有很多监控数据采集器，各自都有优缺点，选型时需要根据自己的需求来选择。通常一个采集器没法搞定所有问题。建议主推一个，这个主力采集器覆盖不了的场景，可以使用其他采集器来补充。
对于夜莺用户，一个务实路径是：机器层面优先考虑 Categraf，Prometheus 生态已有的服务继续复用 Exporter，特殊数据源再按插件成熟度选择 Telegraf、OpenTelemetry、Alloy 或其他 Agent。这样既能降低迁移成本，也能保留已有规则和仪表盘资产。
FAQ
Q1：夜莺是否要求必须使用某个采集器？ A：不要求。夜莺不参与采集，只要数据能进入时序库，夜莺就可以做分析和告警。但如果使用夜莺生态，Categraf 在机器元信息、内置规则和仪表盘上更顺手。
Q2：Telegraf 和 Categraf 怎么选？ A：Telegraf 插件多、适用面广；Categraf 更贴近夜莺生态。夜莺用户如果只替换一类采集器，原文建议至少把机器层面的监控采集器换成 Categraf。
Q3：Exporter 是否能替代 all-in-one 采集器？ A：不完全能。Exporter 和 Prometheus 生态整合好，但不同 Exporter 的配置和运行方式不一致。all-in-one 采集器更强调统一部署和统一配置。
Q4：是否应该一次性统一所有采集器？ A：通常不建议。更稳妥的方式是确定一个主力采集器，再让其他采集器补充主力覆盖不到的场景。
