简介
Categraf 是夜莺监控的默认数据采集 Agent，主打开箱即用和all-in-one，同时支持对metrics、log、trace 的收集，由夜莺监控核心开发团队开发。
Categraf的代码托管在两个地方：
- 中国计算学会确实开源平台：
- https://www.gitlink.org.cn/flashcat/categraf
- Github：
- https://github.com/flashcatcloud/categraf
对比
categraf和telegraf、exporters、grafana-agent、datadog-agent 有什么异同？
telegraf 是 influxdb 生态的产品，因为 influxdb 是支持字符串数据的，所以 telegraf 采集的很多 field 是字符串类型；另外 influxdb 的设计，允许 labels 是非稳态结构，比如 result_code 标签，有时其 value 是 0，有时其 value 是 1，在 influxdb 中都可以接受而在 prometheus 中不能很好支持；第三，telegraf从根本上缺乏对于service discovery 和 relabel 的支持。 这些都导致 telegraf 与 prometheus 生态的兼容性不佳。
prometheus 生态有各种 exporters，但是设计逻辑都是一个监控类型一个 exporter，甚至一个实例一个 exporter，生产环境可能会部署特别多的 exporters，管理起来略麻烦。同时社区维护的很多exporter数据采集质量参差不齐，缺乏治理，给后续使用带来了很大的不便。
grafana-agent import 了大量 exporters 的代码，没有裁剪，没有优化，没有最佳实践在产品上的落地，有些中间件，仍然是一个 grafana-agent 一个目标实例，管理起来也很不方便。
datadog-agent确实是集大成者，但是大量代码是 python 的，整个发布包也比较大，有不少历史包袱，而且生态上是自成一派，和社区相对割裂。
Categraf 确实又是一个轮子，目标：
- 采用 all-in-one 的设计，所有的采集工作使用一个 agent 来解决，包括metrics、log 和 trace ，并从数据采集的源头建立起三者的关联关系，保障好数据的质量；
- 开箱即用：针对常用的采集对象，在提供采集能力的同时，配套有默认的监控大盘和告警规则模板，用户可以直接导入并使用；
- 知识沉淀，尽可能落地最佳实践，不需要采集的数据无需采集，针对可能会对时序库造成高基数的问题在采集侧做出处理；
- 兼容prometheus生态，支持 remote_write 写入协议，支持将数据写入 promethues、M3DB、VictoriaMetrics、InfluxDB；
- 指标数据只采集数值，不采集字符串，标签维持稳态结构；
- 纯 Go 代码编写，静态编译依赖少，容易分发，易于安装；
Categraf 会作为快猫星云 SaaS 产品的重要组成部分，快猫星云技术团队也会投入研发力量，持续迭代。同时，欢迎更多的公司、更多研发人员参与共建，做成国内最开放、最好用的采集器。
安装
可以直接去 categraf releases 页面，下载编译好的二进制，也可自行编译，编译只需要一条命令：go build 当然，前提是机器上有 Go 环境。
如果是从老版本升级，也是建议大家查看 categraf releases 页面，每个版本改动了什么，升级时注意什么，都会在这里写清楚。
在目标机器部署，只需要 categraf 二进制、以及 conf 目录，conf 下有一个主配置文件：config.toml，定义机器名、全局采集频率、全局附加标签、remote write backend地址等；另外就是各种采集插件的配置目录，以input.打头，如果某个采集器 xx 不想启用，把 input.xx 改个其他前缀，比如 bak.input.xx，categraf 就会忽略这个采集器。
conf 目录下还提供了 categraf.service 文件样例，便于大家使用 systemd 托管 categraf。如果对 systemd 不熟悉，建议学习一下课程：
测试
我们经常会需要测试某个采集器的行为，临时看一下这个采集器输出哪些监控指标，比如配置好了 conf/input.mysql/mysql.toml 想要看看采集了哪些 mysql 指标，可以执行命令：./categraf --test --inputs mysql
这个命令会去连接你配置的 mysql 实例，执行SQL收集输出，将输出的内容做格式转换，最终打印到 stdout，如果我们在 stdout 正常看到了 mysql 相关监控指标，则说明一切正常，否则就是哪里出了问题，大概率是 conf/input.mysql/mysql.toml 配置的有问题。
如果修改了某个采集器的配置，需要重启 categraf 或者给 categraf 进程发送HUP信号，发送HUP信号的命令，举例：kill -HUP pidof categraf``
另外，categraf 支持哪些命令行参数，可以通过 ./categraf --help 查看。
插件说明
采集插件的代码，在代码的 inputs 目录，每个插件一个独立的目录，目录下是采集代码，以及相关的监控大盘JSON（如有）和告警规则JSON（如有），Linux相关的大盘和告警规则没有散在 cpu、mem、disk等采集器目录，而是一并放到了 system 目录下，方便使用。
插件的配置文件，放在conf目录，以input.打头，每个配置文件都有详尽的注释，如果整不明白，就直接去看 inputs 目录下的对应采集器的代码，Go 的代码非常易读，比如某个配置不知道是做什么的，去采集器代码里搜索相关配置项，很容易就可以找到答案。
配置说明
这里对 config.toml 的每项配置做出解释：
[global]
对于每个采集器的配置，不在这里一一赘述，只讲一些相对通用的配置项。
interval
每个插件的配置中，一开始通常都是 interval 配置，表示采集频率，如果这个配置注释掉了，就会复用 config.toml 中的采集频率，这个配置如果配置成数字，单位就是秒，如果配置成字符串，就要给出单位，比如：
interval = 60
上面三种写法，都表示采集频率是1分钟，如果是使用字符串，可以使用的单位有：
- 秒：s
- 分钟：m
- 小时：h
instances
很多采集插件的配置中，都有 instances 配置段，用 [[]] 包住，说明是数组，即，可以出现多个 [[instances]] 配置段，比如 ping 监控的采集插件，想对4个IP做PING探测，可以按照下面的方式来配置：
[[instances]]
也可以下面这样子配置：
[[instances]]
interval_times
instances 下面如果有 interval_times 配置，表示 interval 的倍数，比如ping监控，有些地址采集频率是15秒，有些可能想采集的别太频繁，比如30秒，那就可以把interval配置成15，把不需要频繁采集的那些instances的interval_times配置成2。
或者：把interval配置成5，需要15秒采集一次的那些instances的interval_times配置成3，需要30秒采集一次的那些instances的interval_times配置成6。
Labels
instances 下面的 labels 和 config.toml 中的 global.labels 的作用类似，只是生效范围不同，都是为时序数据附加标签，instances 下面的 labels 是附到对应的实例上，global.labels 是附到所有时序数据上。
工作计划
categraf 已经完成了一些常用的采集插件，还有很多需要继续开发，欢迎大家共建补充，已经完成的采集插件包括：
部分采集器不但提供了采集能力，还提供了监控大盘的配置和告警规则的配置，将JSON导入夜莺就可以使用，至于有哪些插件提供了JSON配置，可以通过下面的方式找到：
[root@master01 categraf]# find inputs -name "*.json"