Telegraf监控实战:一套配置采集Linux、Docker和MySQL指标

做监控时，很多人都会遇到一个问题：Linux主机、Docker容器、MySQL数据库各用一套采集方式，配置越来越多，维护起来却越来越乱。

如果你正在搭建指标监控，Telegraf值得认真看一看。它通过插件采集系统和中间件指标，并输出到InfluxDB、Prometheus等平台。

一、Telegraf到底适合做什么

Telegraf的核心优势不是“指标多”，而是采集方式统一。它通过插件完成数据输入、处理和输出，运维人员只需要维护一个Agent和一份配置文件。

Inputs：从CPU、磁盘、Docker、MySQL等对象采集指标。

Processors / Aggregators：对指标改名、过滤、计算和聚合。

Outputs：把数据发送到InfluxDB、Prometheus、Kafka等后端。

这套结构适合指标来源多、需要统一采集规范的环境。Telegraf不是完整监控平台，而是监控链路中的“数据入口”。

二、先把采集链路想清楚

一套常见架构是：

Telegraf负责采集和发送，InfluxDB负责时序数据存储，Grafana负责展示。已有Prometheus环境时，也可以启用 `outputs.prometheus_client`，让Prometheus主动拉取Telegraf暴露的指标。

部署前先确认采集周期、数据保留时间和统一标签。主机名、环境、机房等标签如果不规范，后面做大盘和告警会很痛苦。

建议通过全局标签统一增加环境、机房和业务名称，例如 `env=prod`、`idc=shanghai`、`service=order`。这样同一套Grafana面板可以按环境和业务快速筛选，告警路由也更容易匹配负责人。

标签也不是越多越好。请求ID、用户ID、容器临时ID等高基数字段不适合作为长期标签，否则会迅速放大时序数量，增加存储和查询压力。

三、基础配置不要直接用默认值

主配置通常位于 `/etc/telegraf/telegraf.conf`。建议先保留最小配置，再按需增加插件。

[agent]  interval = "10s"  round_interval = true  metric_batch_size = 1000  metric_buffer_limit = 10000  flush_interval = "10s"  omit_hostname = false

`interval`控制采集频率，`flush_interval`控制发送频率。不要为了图表更“丝滑”就盲目改成1秒采集，高频指标会明显增加网络、存储和查询压力。

输出端的Token、数据库密码和证书路径不要直接写进公开模板。生产环境可以通过环境变量、独立权限文件或密钥管理工具注入，并限制配置文件只允许Telegraf运行账户读取。

修改配置后先执行：

telegraf --test --config /etc/telegraf/telegraf.conf

只有测试输出正常，再重启服务。这个动作能提前发现大部分配置语法、权限和连接问题。

四、Linux主机建议采集这些指标

主机监控不需要把所有插件全部打开。第一阶段建议启用CPU、内存、磁盘、磁盘IO、网络、系统负载和进程数量：

[[inputs.cpu]]  percpu = true  totalcpu = true  report_active = true[[inputs.mem]][[inputs.disk]]  ignore_fs = ["tmpfs", "devtmpfs", "overlay"][[inputs.diskio]][[inputs.net]][[inputs.system]][[inputs.processes]]

CPU关注使用率和iowait，内存重点看available，磁盘还要关注IO等待和队列。告警时应组合持续时间和业务状态。

五、Docker和MySQL怎么接入

Docker：启用 `inputs.docker` 后，可以采集容器CPU、内存、网络、磁盘IO和状态。Telegraf运行账户必须具备访问Docker Socket的权限，但不要为了省事直接长期使用root运行。

[[inputs.docker]]  endpoint = "unix:///var/run/docker.sock"  gather_services = false

MySQL：建议创建独立监控账户，只授予采集所需的最小权限，不要把业务高权限账户写进配置文件。

[[inputs.mysql]]  servers = ["telegraf:密码@tcp(127.0.0.1:3306)/"]

数据库侧重点关注连接数、慢查询、Buffer Pool命中、锁等待和复制延迟。插件能采到多少指标，还取决于数据库版本和监控账户权限。

六、告警和排错要盯住这5点

1. 先看Agent：确认Telegraf服务状态和日志里有没有解析、权限或超时错误。

2. 再测插件：使用 `telegraf --test` 判断问题在采集端还是输出端。

3. 检查权限：Docker Socket、证书和配置文件读取权限是高频故障点。

4. 检查时间：主机时间漂移会造成图表断点、数据乱序和告警判断异常。

5. 检查标签：hostname或环境标签变化，会让同一台设备看起来像两台新设备。

接入统一监控平台时，建议同时监控Telegraf自身状态，包括进程存活、采集错误、输出失败和缓冲区积压。采集Agent一旦失联，图表“没有数据”并不代表业务正常，必须单独触发数据中断告警。

Telegraf真正有价值的地方，是用统一方式解决多种指标的采集问题。先从一台测试主机、几个核心插件开始，跑通采集、存储、展示和告警，再逐步复制到生产环境。

团队已有Zabbix时不必二选一。Zabbix负责资产、可用性和告警闭环，Telegraf补充高频时序指标，按场景分工更稳妥。

以上分享基于个人使用经验，如有错误或遗漏，欢迎大家留言补充指正。