核心要点
- 采集器通常需要在客户端本地维护配置文件，机器多、权限分散或不方便登录时，批量修改采集规则会很麻烦。
- Categraf 支持本地配置和 HTTP 远端拉取两种采集配置管理方式，这为中心端统一管理采集规则提供了基础。
- 夜莺专业版提供采集规则管理下发能力，可以在中心端维护采集插件模板、规则配置和使用说明。
- 要启用中心端下发，需要把 Categraf 的
providers从["local"]改成["local", "http"]。 - 这个能力适合需要统一管理 MySQL、Redis、Kafka、ElasticSearch、JMX、SNMP 等采集配置的团队。
痛点：采集规则分散在每台机器上
市面上常见的采集器，比如 telegraf、grafana-agent、datadog-agent 等，通常内置多种采集插件。这些插件既可以采集操作系统常规指标，也可以采集 MySQL、Redis、MongoDB、Kafka、ElasticSearch、JMX 等组件指标。
问题在于：具体要采集什么数据，通常需要在客户端采集器上配置。也就是说，要修改采集器的配置文件。
当机器数量很少时，本地改配置还能接受；但在生产环境里，常见困难包括：
- 机器数量多，逐台修改配置效率低。
- 部分机器不容易登录，变更路径很长。
- 不同插件配置格式不同，新人上手成本高。
- 采集规则散落在客户端，不方便审计和复用。
- 采集规则调整后，很难确认哪些机器已经生效。
这类问题的本质不是“采集器不够强”，而是“采集配置缺少中心化管理能力”。
解决方案：中心端管理 Categraf 采集规则
快猫技术团队开源了 Categraf 采集器，并在夜莺社区里广泛使用。Categraf 支持两种采集配置管理方式：
- 修改本地配置文件。
- 通过 HTTP 从远端拉取配置。
第二种方式为中心端采集配置管理提供了可能。因此，夜莺专业版提供了采集规则管理下发能力。
夜莺采集配置内置支持多种采集模板，包括 aliyun、elasticsearch、ipmi、kafka、kubernetes、mongodb、mysql、net_response、nginx、oracle、ping、postgresql、processes、procstat、rabbitmq、redis、smart、snmp、tomcat、zookeeper 等。
除了内置模板，也支持自定义采集规则。采集规则右侧还会展示采集插件的使用说明，方便新人用户上手，降低公司内部答疑和推广成本。
中心化采集规则适合哪些场景
| 场景 | 中心化管理的价值 |
|---|---|
| 数据库和中间件数量多 | 统一维护 MySQL、Redis、Kafka 等采集模板 |
| 机器不方便登录 | 不必逐台 SSH 修改采集配置 |
| 插件使用说明复杂 | 在页面侧边提供说明，减少内部支持成本 |
| 多团队共用监控平台 | 采集规则更容易复用、审计和标准化 |
| 需要快速调整采集范围 | 从中心端修改后由 Categraf 拉取配置 |
如果团队只有少量机器，本地配置文件足够简单，中心化下发不是刚需。但当机器规模、插件种类和团队数量增加后，中心化管理的收益会逐渐明显。
如何体验
1. 下载夜莺专业版软件包
从夜莺下载中心下载专业版软件包：
https://flashcat.cloud/download/nightingale/
写作原文时，最新版本是 v6.0.2。你下载时可能已经有更新，直接下载最新版本即可。带有 plus 字样的是专业版。目前提供了 linux-amd64 版本，如果需要适配其他操作系统版本，可以联系官方获取。
2. 备份并更新夜莺
升级前，先把老的夜莺部署目录备份一下。然后解压 plus 软件包，把 n9e-plus 二进制拷贝到 n9e 二进制所在的同级目录。
操作步骤可以概括为：
- 备份当前夜莺部署目录。
- 解压专业版软件包。
- 拷贝
n9e-plus二进制到原夜莺目录。 - 停掉原
n9e进程。 - 启动
n9e-plus进程。
3. 修改 Categraf 的 providers 配置
修改 Categraf 的 providers 配置。原本配置是：
providers = ["local"]
要能够从中心端拉取配置，需要修改为：
providers = ["local", "http"]
修改后重启 Categraf 进程，就可以从中心端拉取配置。
实施前需要确认的事项
在生产环境启用中心端采集规则下发前，建议先确认几个问题：
| 检查项 | 为什么要确认 |
|---|---|
| Categraf 版本和配置 | 需要支持 HTTP provider，并正确指向中心端 |
| 夜莺专业版部署状态 | 采集规则下发能力依赖专业版 |
| 采集插件模板 | 先确认内置模板是否覆盖你的目标组件 |
| 变更回滚方式 | 如果中心端规则配置错误，需要能快速恢复本地配置 |
| 机器分组和权限 | 多团队共用时，要避免误下发到不相关机器 |
这些检查不复杂，但能避免把“配置中心化”变成“错误中心化”。采集规则一旦统一下发，影响范围会比单机本地修改更大，首次使用时建议从少量机器或测试业务组开始验证。
FAQ
Categraf 是否只能从中心端拉取配置？
不是。Categraf 支持本地配置和 HTTP 远端拉取两种方式。把 providers 配置为 ["local", "http"] 后，可以同时保留本地配置和远端配置能力。
这个能力是否属于夜莺开源版？
原文介绍的是夜莺专业版中的采集规则管理下发能力。开源版和专业版能力边界请以夜莺当前发布说明为准。
哪些采集插件适合中心化管理？
适合统一模板、统一说明、统一下发的插件都适合，比如 MySQL、Redis、Kafka、ElasticSearch、SNMP、JMX、Nginx、PostgreSQL 等。一次性、强个性化的采集配置则可以继续用本地配置管理。
小结
采集器配置中心化的核心价值，是把分散在机器上的采集规则收拢到夜莺中心端，降低批量变更、规则复用、新人上手和内部答疑的成本。
如果你的团队已经使用 Categraf，并且正在为多机器、多插件、多团队的采集配置维护发愁，可以尝试夜莺专业版的采集规则管理下发能力。启用方式的关键点很简单：部署 n9e-plus，并把 Categraf 的 providers 改为 ["local", "http"]。
