Categraf 是一款 All-in-One 的开源的 telemetry 数据采集器，支持指标、日志采集；支持 Tracing 数据的收集；支持物理机、虚拟机、交换机、容器、K8s、多种中间件/数据库的数据采集，支持混合云架构、云原生架构、多云架构。汇聚领域最佳实践，开箱即用。

对比

Categraf 和 Telegraf、Exporters、Grafana-Agent、Datadog-Agent 等的关系是什么？

• Telegraf 是 InfluxDB 生态的产品，因为 InfluxDB 是支持存储字符串类型的 value，所以 Telegraf 采集的很多 field 是字符串类型，另外 InfluxDB 的设计，允许 labels 是非稳态结构，比如 result_code 标签，有时其 value 是 0，有时其 value 是 1，在 InfluxDB 中都可以接受。但是上面两点，在以 Prometheus 为代表的、符合 OpenMetrics 标准的时序库中，处理起来就很麻烦。
• Prometheus 生态有各种 Exporters，但是设计逻辑都是一个监控类型一个 Exporter，甚至一个实例一个 Exporter，生产环境就可能会部署特别多的 Exporters，管理起不方便。
• Grafana-Agent import 了大量 Exporters 的代码，没有裁剪，没有优化，没有最佳实践在产品上的落地，有些中间件，仍然采取的是一个 Grafana-Agent 一个目标实例，导致会有很多的 Grafana-Agent 进程在运行，管理起来也很不方便。
• Datadog-Agent 确实是集大成者，但是大量代码是 Python 的，整个发布包也比较大，有不少历史包袱，而且生态上是自成一派，和云原生生态、开源社区相对割裂。

所以，Categraf 确实又是一个轮子，期望解决和规避上面分析提到的一些弊端，Categraf的设计目标：

• 开源、开放、遵循 OpenTelemetry 标准；
• 拥抱 Prometheus 开源生态，支持 remote_write 写入协议，支持将数据写到类似于 Promethues、M3DB、VictoriaMetrics、InfluxDB、Open-Falcon、TDengine等时序数据库；
• 指标数据只采集数值，不采集字符串，标签维持稳态结构；
• 采用 All-in-One 的设计理念，所有的采集工作用一个 Agent 搞定；
• 采用 Go 语言编写，静态编译依赖少，容易分发，易于安装；
• 尽可能落地最佳实践，不需要采集的数据无需采集，针对可能会对时序库造成高基数的问题在采集侧做出规避处理；
• 针对常用的采集对象，在提供采集能力的同时，配套整理出监控大盘和告警规则模版，用户可以直接导入使用；