时序数据监控实战：基于InfluxDB 2.5、Telegraf与Grafana的TIG栈部署指南

1. 项目概述从零搭建一套现代监控数据栈最近在折腾一个硬件传感器的数据采集项目数据量不大但频率不低传统的关系型数据库写起来有点力不从心查询聚合更是慢。跟圈里的朋友聊了聊大家一致推荐试试 InfluxDB说它是为时序数据“量身定做”的。于是我花了一周时间把 InfluxDB 2.5、Telegraf 和 Grafana 这套组合拳从头到尾打了一遍。说实话初次接触这套“TIG”栈Telegraf, InfluxDB, Grafana时确实有点懵官方文档虽然全但比较分散对新手不够友好。这次我就把自己从安装、配置到可视化的完整踩坑过程记录下来目标很明确让后来者尤其是像我当初一样的“菜鸟”能跟着这篇教程在最短的时间内搭建起一套可用的、能理解其运作原理的现代监控与数据可视化系统。无论你是想监控服务器性能、收集 IoT 传感器数据还是追踪应用指标这套组合都能给你带来“降维打击”般的体验。2. 核心组件选型与架构解析2.1 为什么是 InfluxDB 2.5 Telegraf Grafana在开始动手之前我们得先搞清楚为什么要选这三个家伙以及它们各自扮演什么角色。这就像组乐队得先知道谁是主唱、谁是贝斯手。InfluxDB 2.5是我们的核心“数据仓库”专为时序数据设计。什么叫时序数据简单说就是带时间戳的一系列数据点比如“每分钟的CPU使用率”、“每秒钟的温度读数”。InfluxDB 2.x 版本相比 1.x 是一个巨大的革新它把数据库、Web管理界面、任务调度和告警引擎全都打包在了一起形成了一个开箱即用的平台。对于新手来说这意味着你不用再费心去组合多个工具一个 InfluxDB 2.5 就提供了从数据写入、查询到基础告警的全套服务。它的数据模型基于“指标Measurement”、“标签Tags”、“字段Fields”和“时间戳”这种设计对时序数据极其高效查询速度比用 MySQL 存类似数据快几个数量级。Telegraf是我们的“数据采集器”或者叫“搬运工”。它是一个插件驱动的代理超级轻量用 Go 语言编写。你可以把它想象成一个万能吸盘它能从几百种不同的来源比如操作系统、数据库、API、消息队列甚至硬件传感器收集数据然后统一“吐”给 InfluxDB。它的强大之处在于“插件化”你需要监控什么就启用对应的输入Input插件数据需要简单处理一下就加上处理Processor插件最后通过输出Output插件送到目的地这里就是 InfluxDB。我们用它来采集服务器的系统指标CPU、内存、磁盘、网络省去了自己写采集脚本的麻烦。Grafana则是我们的“数据可视化与告警面板”。InfluxDB 自己也有个简单的看板但 Grafana 才是这方面的王者。它支持多种数据源包括 InfluxDB提供了极其灵活和强大的图表构建能力。你可以把 InfluxDB 里存储的枯燥数据变成直观的曲线图、仪表盘、热力图还能设置复杂的告警规则当数据异常时通过邮件、钉钉、微信等渠道通知你。它让数据“说话”是最终呈现价值的关键一环。这三者形成了一个完美的流水线Telegraf 采集 - InfluxDB 存储与处理 - Grafana 可视化与告警。这个组合生态成熟、文档丰富是当前监控领域事实上的标准方案之一。2.2 部署方式考量Docker 还是原生安装这是实操前第一个要做的选择。我两种方式都试了这里说说我的体会。Docker 部署是目前最推荐的方式尤其对于新手和测试环境。优点太明显了一键启动、环境隔离、升级回滚方便。你不需要关心系统依赖不用担心端口冲突配置文件通过卷Volume挂载数据持久化也容易。对于 InfluxDB 和 Grafana官方都提供了维护良好的 Docker 镜像。Telegraf 虽然也可以跑在容器里但如果你想监控宿主机本身比如收集宿主机的 CPU 信息需要一些额外的权限配置比如挂载/proc、/sys目录稍微复杂一丢丢。原生安装更适合生产环境对性能有极致要求或者你对系统有完全掌控欲的情况。直接安装的包理论上运行时开销比容器稍小排查问题也更直接。但缺点是你需要手动处理依赖、服务管理和版本升级。对于这篇“菜鸟教程”我强烈建议使用Docker Compose方式。它能用一份配置文件docker-compose.yml把三个服务都定义好并且处理好它们之间的网络连接真正做到“一键启动开箱即用”。这能让我们把精力集中在核心概念和配置上而不是和环境搏斗。注意无论用哪种方式请务必规划好数据持久化的目录。InfluxDB 的数据、Grafana 的仪表盘配置如果丢了可就白忙活了。Docker 中一定要用volumes映射到宿主机可靠的位置。3. 实战部署使用 Docker Compose 一键启动理论说再多不如动手做一遍。我们这就用 Docker Compose 把整个环境拉起来。3.1 准备 Docker 与 Compose 环境首先确保你的机器上已经安装了 Docker 和 Docker Compose。如果你用的是 Linux通常可以通过包管理器安装。以 Ubuntu 为例# 安装 Docker sudo apt-get update sudo apt-get install docker.io docker-compose # 启动 Docker 服务并设置开机自启 sudo systemctl start docker sudo systemctl enable docker # 将当前用户加入 docker 组避免每次都要 sudo操作后需退出终端重新登录生效 sudo usermod -aG docker $USER对于 Windows 和 macOS请直接从 Docker 官网下载 Desktop 版本安装它自带 Compose。3.2 编写 docker-compose.yml 配置文件在你的工作目录例如~/monitoring-stack下创建一个名为docker-compose.yml的文件。这个文件定义了我们的三个服务。version: 3.8 services: influxdb: image: influxdb:2.5-alpine # 使用2.5版本alpine镜像更小巧 container_name: influxdb_v2 restart: unless-stopped ports: - 8086:8086 # InfluxDB HTTP API 端口 environment: - DOCKER_INFLUXDB_INIT_MODEsetup - DOCKER_INFLUXDB_INIT_USERNAMEmyadmin # 初始管理员用户名按需修改 - DOCKER_INFLUXDB_INIT_PASSWORDSecurePassw0rd! # 初始管理员密码务必修改 - DOCKER_INFLUXDB_INIT_ORGmyorg # 初始组织名称 - DOCKER_INFLUXDB_INIT_BUCKETmybucket # 初始存储桶类似数据库 - DOCKER_INFLUXDB_INIT_ADMIN_TOKENmy-super-secret-auth-token # 初始API令牌务必修改并保存好 volumes: - ./data/influxdb2:/var/lib/influxdb2 # 持久化数据库数据 - ./config/influxdb2:/etc/influxdb2 # 持久化配置可选 networks: - monitoring-net telegraf: image: telegraf:latest container_name: telegraf_agent restart: unless-stopped # 关键为了采集宿主机系统指标需要挂载宿主机相关目录并提升权限 privileged: true volumes: - ./config/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro # 配置文件 - /var/run/docker.sock:/var/run/docker.sock:ro # 监控Docker容器可选 - /:/hostfs:ro # 挂载根目录用于读取系统文件如/proc, /sys - /sys:/hostfs/sys:ro - /proc:/hostfs/proc:ro - /etc:/hostfs/etc:ro environment: - HOST_ETC/hostfs/etc - HOST_PROC/hostfs/proc - HOST_SYS/hostfs/sys - HOST_MOUNT_PREFIX/hostfs depends_on: - influxdb networks: - monitoring-net grafana: image: grafana/grafana-oss:latest container_name: grafana_dashboard restart: unless-stopped ports: - 3000:3000 # Grafana Web 界面端口 environment: - GF_SECURITY_ADMIN_PASSWORDadmin # 初始管理员密码首次登录后强制修改 - GF_INSTALL_PLUGINSgrafana-clock-panel # 可预安装插件这里以时钟面板为例 volumes: - ./data/grafana:/var/lib/grafana # 持久化Grafana数据仪表盘、用户等 - ./config/grafana/provisioning:/etc/grafana/provisioning # 自动化配置可选 depends_on: - influxdb networks: - monitoring-net networks: monitoring-net: driver: bridge这个配置文件做了几件关键事定义网络创建了一个名为monitoring-net的桥接网络让三个容器在同一个网络内可以直接用服务名如influxdb互相访问。配置 InfluxDB通过环境变量进行初始化设置包括管理员账号、组织、存储桶和最重要的 API Token。这些信息后面连接 Telegraf 和 Grafana 都要用到。数据持久化到了./data/influxdb2。配置 Telegraf以特权模式运行并挂载了宿主机的一系列系统目录。这是因为 Telegraf 的cpu、mem、disk等输入插件需要读取/proc、/sys下的文件来获取系统指标。我们将宿主机根目录挂载到容器内的/hostfs然后在配置文件中告诉 Telegraf 从这个路径去读。配置 Grafana设置了初始密码并持久化了数据目录。3.3 配置 Telegraf 采集宿主机指标光有 Telegraf 容器还不够我们需要告诉它采集什么、以及发到哪里。在~/monitoring-stack/config/telegraf/目录下创建telegraf.conf配置文件。# Telegraf 主配置 [agent] interval 10s # 每10秒采集一次 round_interval true metric_batch_size 1000 metric_buffer_limit 10000 collection_jitter 0s flush_interval 10s flush_jitter 0s precision hostname # 留空Telegraf会自动使用容器主机名或使用hostname命令获取 omit_hostname false # 在指标中包含主机名这对于区分多台主机数据至关重要 # 输出插件将数据发送到 InfluxDB v2 [[outputs.influxdb_v2]] urls [http://influxdb:8086] # 使用Docker Compose服务名 token $INFLUX_TOKEN # 这里使用环境变量更安全。我们将在启动时传入。 organization myorg # 与 InfluxDB 初始化时设置的组织名一致 bucket mybucket # 与 InfluxDB 初始化时设置的存储桶名一致 # 输入插件采集系统CPU指标 [[inputs.cpu]] percpu true # 采集每个核心的指标 totalcpu true # 采集总的CPU指标 collect_cpu_time false # 不采集CPU时间节省空间 report_active false # 关键因为我们将宿主机根目录挂载到了 /hostfs所以需要指定路径 # 如果Telegraf直接运行在宿主机上则不需要这些前缀 [inputs.cpu.tags] # 可以添加自定义标签如 envprod # 输入插件采集系统内存指标 [[inputs.mem]] # 同样指定正确的路径前缀 # 在配置中我们通过环境变量 HOST_PROC 已经指向了 /hostfs/proc插件会自动处理。 # 输入插件采集系统磁盘指标 [[inputs.disk]] mount_points [/, /hostfs] # 监控的挂载点包含根目录和我们的挂载点 ignore_fs [tmpfs, devtmpfs, devfs, overlay, squashfs] # 忽略的文件系统类型 # 输入插件采集系统网络接口指标 [[inputs.net]] interfaces [eth0, en*] # 监控的网卡en*匹配所有以太网卡 # 输入插件采集系统整体负载与进程数 [[inputs.system]] # 采集系统负载、运行进程数等这个配置文件定义了采集频率每10秒一次。输出目标InfluxDB v2使用了我们在docker-compose.yml中定义的organization和bucket。token用了环境变量占位符这是为了安全避免把敏感信息硬编码在配置文件里。采集内容CPU每个核心和总体、内存、磁盘空间和IO、网络流量、系统负载。这些都是服务器监控最基础的指标。实操心得hostname的配置很重要。在容器中默认的主机名是容器ID不利于识别。我建议要么在docker-compose.yml的telegraf服务中通过hostname: your-server-name指定要么在telegraf.conf的[agent]部分手动设置hostname your-server-name。这样在 Grafana 里做数据筛选时会清晰很多。3.4 启动服务并验证现在一切就绪。在docker-compose.yml所在目录执行以下命令# 首先设置 InfluxDB Token 环境变量与 docker-compose.yml 中设置的一致 export INFLUX_TOKENmy-super-secret-auth-token # 使用环境变量启动所有服务 INFLUX_TOKEN${INFLUX_TOKEN} docker-compose up -d-d参数表示在后台运行。启动后用docker-compose ps查看状态确保三个容器的状态都是Up。接下来我们逐一验证服务是否正常验证 InfluxDB打开浏览器访问http://你的服务器IP:8086。你应该能看到 InfluxDB 的登录界面。用docker-compose.yml里设置的用户名myadmin和密码SecurePassw0rd!登录。登录成功后进入主界面在左侧导航栏点击“Data”数据-“Buckets”存储桶应该能看到名为mybucket的存储桶。这说明 InfluxDB 初始化成功。验证 Telegraf 数据写入在 InfluxDB UI 中点击左侧导航栏的“Explore”探索图标。在查询构建器中从下拉列表选择mybucket存储桶。在过滤器Filter部分选择_measurement你应该能看到一系列以cpu、mem、disk等开头的测量名称这就是 Telegraf 写入的数据。选择cpu再点一下“Submit”提交如果能看到带有时间序列的图表数据恭喜你Telegraf 已经在成功采集并写入数据了验证 Grafana打开浏览器访问http://你的服务器IP:3000。使用默认用户名admin和你在docker-compose.yml中设置的密码初始为admin登录。首次登录会要求修改密码。登录后看到 Grafana 的主界面说明服务正常。4. 核心概念详解与数据操作入门服务跑起来了数据也在往里写了。但要想玩得转必须理解 InfluxDB 2.x 的几个核心概念这和 1.x 有很大不同。4.1 InfluxDB 2.x 核心四要素组织Organization这是最高层级的权限容器。你可以把它理解为一个公司或一个团队。所有的用户、存储桶、任务、仪表盘都隶属于一个组织。我们初始化时创建的myorg就是一个组织。对于个人或小项目一个组织就够了。存储桶Bucket这是存放时序数据的地方类似于传统数据库中的“数据库”。数据按存储桶进行隔离。每个存储桶有一个保留策略Retention Policy定义数据保存多久后自动删除。我们创建的mybucket就是默认无限期保留。生产环境一定要根据数据重要性设置合理的保留期限比如30天、1年否则磁盘很快会被撑爆。API 令牌API Token这是访问 InfluxDB API 的密钥相当于密码。每个令牌都有特定的权限如读、写某个存储桶。我们初始化生成的my-super-secret-auth-token是一个“全权限”令牌拥有所有读写权限方便初期使用。在生产环境中务必遵循最小权限原则为 Telegraf、Grafana 等客户端创建只有必要权限的令牌。测量、标签、字段Measurement, Tags, Fields这是数据模型的核心。测量Measurement类似关系型数据库的表名描述数据的来源或类型如cpu、temperature。标签Tags索引属性用于标识和过滤数据。标签是键值对会被索引查询效率高但值只能是字符串。例如hostserver01,cpucpu0。标签适合存储有有限枚举值、用于分组和查询的条件。字段Fields实际存储的数值数据不会被索引。字段也是键值对但值可以是整数、浮点数、字符串或布尔值。例如usage_idle75.4,temperature22.5。时间戳Timestamp每个数据点都必须有。一个数据点示例cpu,hostserver01,cpucpu0 usage_user12.5,usage_system3.2 1625097600000000000测量cpu标签hostserver01,cpucpu0字段usage_user12.5,usage_system3.2时间戳1625097600000000000(纳秒精度)4.2 使用 Flux 语言查询数据InfluxDB 2.x 默认使用Flux作为查询语言也兼容 InfluxQL但官方主推 Flux。Flux 是一种功能强大的脚本语言专为处理时序数据设计。一开始看可能有点怪但用习惯了非常强大。在 InfluxDB UI 的“Explore”页面或者 Grafana 中连接 InfluxDB 数据源后我们都需要写 Flux 查询。来看一个最简单的例子查询最近5分钟mybucket里cpu测量的usage_user字段from(bucket: mybucket) | range(start: -5m) | filter(fn: (r) r._measurement cpu) | filter(fn: (r) r._field usage_user) | aggregateWindow(every: 10s, fn: mean) // 每10秒聚合一次取平均值我们来拆解这个查询from(bucket: mybucket)指定从哪个存储桶读取数据。| range(start: -5m)指定时间范围-5m表示从现在开始往前5分钟。Flux 使用管道符|连接操作数据像水流一样经过每个处理函数。| filter(fn: (r) r._measurement cpu)过滤出测量名为cpu的数据。| filter(fn: (r) r._field usage_user)进一步过滤出字段名为usage_user的数据。| aggregateWindow(every: 10s, fn: mean)这是一个聚合操作。原始数据可能是每秒一个点这个函数将数据按10秒一个窗口进行分组并计算每个窗口内数据的平均值。这在可视化时非常有用可以平滑曲线并减少数据量。注意事项Flux 查询返回的数据是“流”格式每个序列由唯一的“标签集”定义。在 Grafana 中Flux 查询的结果需要正确映射到 Grafana 的“时间序列”格式。通常查询结果中的_time列作为时间轴_value列作为指标值而host、cpu等标签列会自动成为图例的一部分。如果图例显示不正常检查一下你的查询是否返回了预期的列。5. 配置 Grafana 可视化监控仪表盘数据有了查询也会了现在是时候让数据“活”过来了。Grafana 的强大之处在于你可以通过简单的拖拽和配置将复杂的查询变成直观的图表。5.1 添加 InfluxDB 数据源首先我们需要告诉 Grafana 去哪里拉取数据。登录 Grafana (http://IP:3000)。点击左侧齿轮图标 - “Data Sources”数据源。点击 “Add data source”添加数据源。在搜索框输入 “InfluxDB”选择 “InfluxDB” 数据源类型。配置连接参数Name: 起个名字比如My-InfluxDB。Query Language: 选择Flux。URL: 填写http://influxdb:8086。注意因为 Grafana 和 InfluxDB 在同一个 Docker 网络 (monitoring-net) 下所以可以直接用服务名influxdb访问。如果你在宿主机浏览器访问 Grafana 进行配置这里需要填http://宿主机IP:8086。Organization: 填写myorg。Token: 填写我们之前生成的my-super-secret-auth-token。Default Bucket: 填写mybucket。点击最下方的 “Save test”保存并测试。如果看到绿色的 “Data source is working”数据源工作正常提示就说明连接成功了。5.2 创建第一个仪表盘与面板现在我们来创建一个监控服务器 CPU 和内存使用率的仪表盘。点击左侧 “” 号 - “Dashboard”仪表盘。点击 “Add new panel”添加新面板。在面板编辑器的 “Query”查询选项卡下确保数据源选择我们刚添加的My-InfluxDB。在查询编辑器里输入以下 Flux 查询来获取CPU 总使用率from(bucket: mybucket) | range(start: v.timeRangeStart, stop: v.timeRangeStop) | filter(fn: (r) r._measurement cpu and r.cpu cpu-total) | filter(fn: (r) r._field usage_user or r._field usage_system) | aggregateWindow(every: v.windowPeriod, fn: mean) | pivot(rowKey:[_time], columnKey: [_field], valueColumn: _value) | map(fn: (r) ({ r with _value: r.usage_user r.usage_system }))这个查询稍复杂一些v.timeRangeStart/Stop和v.windowPeriod是 Grafana 提供的变量会自动替换成当前仪表盘选择的时间范围和自动计算的时间间隔。我们过滤出cpu-total总CPU的数据并且只关心usage_user用户态和usage_system内核态两个字段。pivot操作是一个关键转换它将_field列包含usage_user和usage_system旋转为新的列这样每一行就同时有了usage_user和usage_system两个值。map操作创建了一个新字段_value其值是usage_user和usage_system的和即总的 CPU 使用率忽略其他如iowait等状态这里简化处理。在右侧 “Panel options”面板选项中设置 “Title”标题为 “CPU Total Usage”。在 “Visualization”可视化下拉菜单中选择 “Time series”时间序列图。点击右上角的 “Apply”应用保存这个面板。回到仪表盘点击顶部的 “Save dashboard”保存仪表盘图标给仪表盘起个名字比如 “Server Overview”然后保存。用同样的方法你可以再添加一个面板查询内存使用率from(bucket: mybucket) | range(start: v.timeRangeStart, stop: v.timeRangeStop) | filter(fn: (r) r._measurement mem) | filter(fn: (r) r._field used_percent) // Telegraf 的 mem 插件提供 used_percent 字段 | aggregateWindow(every: v.windowPeriod, fn: mean)这个查询就简单多了直接获取内存使用百分比。5.3 仪表盘优化与变量使用一个优秀的仪表盘应该清晰、灵活。Grafana 的“变量”功能可以让你动态地过滤数据。假设我们有多台服务器Telegraf 采集数据时都带有host标签。我们想创建一个下拉框可以选择查看哪台服务器的指标。进入你刚创建的 “Server Overview” 仪表盘点击右上角的 “Dashboard settings”仪表盘设置齿轮图标。选择 “Variables”变量 - “Add variable”添加变量。配置变量Name:host(变量名在查询中引用)Type:QueryData source:My-InfluxDBQuery:from(bucket: mybucket) | range(start: -5m) | keyValues(keyColumns: [host])。这个 Flux 查询会返回mybucket中所有不同的host标签值。Refresh:On Dashboard Load(每次加载仪表盘时刷新变量值)点击 “Update”更新保存变量。现在修改你的 CPU 查询加入主机过滤from(bucket: mybucket) | range(start: v.timeRangeStart, stop: v.timeRangeStop) | filter(fn: (r) r._measurement cpu and r.cpu cpu-total) | filter(fn: (r) r._field usage_user or r._field usage_system) | filter(fn: (r) r.host v.host) // 使用变量进行过滤 | aggregateWindow(every: v.windowPeriod, fn: mean) | pivot(rowKey:[_time], columnKey: [_field], valueColumn: _value) | map(fn: (r) ({ r with _value: r.usage_user r.usage_system }))注意| filter(fn: (r) r.host v.host)这一行v.host会引用我们定义的变量。当你在仪表盘顶部的下拉框选择不同的主机时所有使用了v.host变量的面板都会自动刷新只显示该主机的数据。6. 生产环境进阶配置与调优把服务跑起来只是第一步。要用于生产环境还需要考虑安全性、可靠性和性能。6.1 安全加固权限与网络隔离创建最小权限的 API Token不要在所有地方都使用全权限的管理员 Token。登录 InfluxDB UI进入 “Data” - “Tokens”。点击 “Generate” - “Custom Token”。为 Telegraf 创建一个 Token权限只勾选对mybucket存储桶的 “Write”写。为 Grafana 创建一个 Token权限只勾选对mybucket存储桶的 “Read”读。更新docker-compose.yml和telegraf.conf使用这些专用 Token。修改默认密码与 Token初始化时设置的密码和全权限 Token 必须修改。在 InfluxDB UI 的 “Load Data” - “Tokens” 页面可以重新生成管理员 Token。在 “Settings” - “Profile” 可以修改用户密码。网络隔离我们的docker-compose.yml创建了一个独立的网络。在生产中可以考虑更进一步将 InfluxDB 的 8086 端口不直接映射到宿主机只允许内部网络如 Grafana、Telegraf 容器所在网络访问。使用反向代理如 Nginx、Caddy为 Grafana 和 InfluxDB UI 提供 HTTPS 访问并配置身份认证。6.2 InfluxDB 数据保留策略与降采样时序数据会无限增长必须管理。设置存储桶保留期在 InfluxDB UI 中进入 “Data” - “Buckets”。点击mybucket旁边的三个点选择 “Configure Retention Rules”配置保留规则。你可以设置数据在多少小时后自动删除例如 30d 表示30天。创建降采样任务对于监控数据我们可能只需要查看最近几小时的详细数据而对于历史数据可以只保留每小时或每天的聚合值这能极大节省存储空间。在 InfluxDB UI 中进入 “Tasks”任务。点击 “Create Task”创建任务。给任务起名比如 “Downsample CPU hourly”。编写 Flux 脚本例如将 CPU 数据每小时聚合一次存入另一个长期存储桶option task {name: Downsample CPU hourly, every: 1h} from(bucket: mybucket) | range(start: -task.every) | filter(fn: (r) r._measurement cpu) | aggregateWindow(every: 1h, fn: mean) | to(bucket: mybucket_downsampled_1h, org: myorg)这个任务每小时运行一次将mybucket中过去一小时的cpu数据计算每小时均值然后写入到mybucket_downsampled_1h这个新存储桶。你可以为这个新桶设置更长的保留期比如1年。6.3 Telegraf 配置优化与插件扩展调整采集间隔interval设置得越短数据粒度越细但负载和存储压力也越大。对于服务器监控10s或15s通常是合理的。对于业务指标可能需要1m或更长。启用更多输入插件Telegraf 有海量插件。例如[[inputs.docker]]: 监控 Docker 容器资源使用情况需要挂载/var/run/docker.sock。[[inputs.net_response]]: 监控网络服务的端口响应和延迟。[[inputs.ping]]: 监控网络连通性和延迟。[[inputs.mysql]],[[inputs.redis]]: 监控数据库状态。 只需在telegraf.conf中添加对应的插件配置区块并重启 Telegraf 容器即可。使用处理插件例如[[processors.rename]]可以重命名标签或字段[[processors.converter]]可以转换字段类型。这在统一不同来源的数据格式时非常有用。6.4 Grafana 告警配置可视化是为了发现问题告警是为了及时通知你。配置告警渠道在 Grafana 中进入 “Alerting” - “Contact points” - “Add contact point”。选择你需要的通知方式如 Email、Slack、钉钉、Webhook 等。按照指引配置好接收器。在面板上创建告警规则编辑你的 “CPU Total Usage” 面板。切换到 “Alert”告警选项卡。点击 “Create alert rule from this panel”从此面板创建告警规则。设置规则名称如 “High CPU Usage”。在 “Query” 部分确保选择了正确的查询。在 “Condition” 部分设置告警条件例如WHEN last() OF query(A, 1m, now) IS ABOVE 80。这表示当最近1分钟内 CPU 使用率的最后一个值超过 80% 时触发告警。在 “Notifications” 部分选择你刚刚配置的告警渠道。保存面板和告警规则。现在当 CPU 使用率持续超过80%你就会收到通知了。告警功能非常强大可以设置多级阈值、告警抑制、静默规则等满足复杂的运维需求。7. 常见问题排查与调试技巧在实际操作中你肯定会遇到各种问题。这里记录几个我踩过的坑和解决方法。7.1 Telegraf 无法采集宿主机数据症状InfluxDB 的mybucket里看不到cpu、mem等数据。排查步骤检查 Telegraf 容器日志docker-compose logs telegraf。查看是否有明显的错误信息比如连接 InfluxDB 失败、配置文件语法错误。检查挂载路径确保telegraf.conf中配置的路径前缀与容器内的挂载点匹配。我们的配置使用了环境变量HOST_PROC等Telegraf 的system插件会自动识别。你可以进入 Telegraf 容器内部检查docker-compose exec telegraf sh然后ls /hostfs/proc看看是否存在。检查 InfluxDB 连接在 Telegraf 日志中确认outputs.influxdb_v2插件是否成功连接到http://influxdb:8086并且没有认证错误Token 错误。可以临时在配置中增加debug true来输出更详细的日志。手动测试采集在 Telegraf 容器内可以运行telegraf --config /etc/telegraf/telegraf.conf --test。这个命令会执行一次数据采集并打印到标准输出而不发送到 InfluxDB。这是调试输入插件配置的神器。7.2 Grafana 连接 InfluxDB 失败症状在 Grafana 数据源配置页面点击 “Save test” 时提示失败。排查步骤检查网络连通性在 Grafana 容器内尝试ping influxdb或curl http://influxdb:8086/ping。如果失败说明 Docker 网络有问题检查docker-compose.yml中的网络配置确保所有服务都在monitoring-net下。检查 URL 和端口确认 Grafana 中配置的 URL 是正确的。在容器内用服务名在宿主机配置要用宿主机 IP 和映射的端口。检查 Token 和权限确认使用的 Token 是否有对目标存储桶的读权限。最简单的方法是用这个 Token 在 InfluxDB UI 的 “Explore” 页面尝试执行一个查询看是否成功。检查组织名和存储桶名确保大小写完全一致。7.3 Flux 查询结果在 Grafana 中显示异常症状图表不显示数据或者图例显示为value而不是具体的标签。排查步骤在 InfluxDB UI 中测试查询将 Grafana 中的 Flux 查询复制到 InfluxDB UI 的 “Explore” 页面运行看是否能返回预期的数据格式和内容。这是最直接的验证方法。检查数据格式Grafana 的时间序列面板期望查询返回的表格至少包含_time和_value两列。使用pivot()或map()函数时确保最终输出的流格式正确。检查时间范围确认你的查询中range(start: v.timeRangeStart, stop: v.timeRangeStop)能正确获取 Grafana 面板的时间范围。可以在查询末尾加上| yield(name: results)来显式命名输出流。查看查询检查器在 Grafana 面板编辑器的查询选项卡右下角点击 “Query inspector”查询检查器。这里可以查看原始查询请求和返回的原始数据是排查问题的利器。7.4 磁盘空间增长过快症状InfluxDB 数据目录占用空间迅速增加。排查步骤检查数据保留策略确认是否为存储桶设置了合理的保留期限Retention Period。无限期保留0s会一直积累数据。检查数据写入量可能是 Telegraf 采集间隔太短或者启用了太多高频率的输入插件。调整agent.interval或减少不必要的插件。检查是否存在大量小写入频繁的小批量写入会产生很多小文件影响性能和空间。可以适当调大 Telegraf 的metric_batch_size如从1000调到5000和metric_buffer_limit。考虑启用数据压缩InfluxDB 默认启用压缩。确保没有禁用它。实施降采样如前所述创建降采样任务将高精度数据聚合为低精度数据后删除原始高精度数据。这套 TIG 栈的功能远不止于此比如 InfluxDB 的任务和告警、Grafana 的插件生态和仪表盘变量高级用法、Telegraf 的数百个插件等等。但通过以上步骤你已经成功搭建了一个功能完整、可用于生产环境原型的基础监控平台。最关键的是你理解了每个组件的作用、它们如何协作以及出了问题该如何排查。剩下的就是在实践中根据你的具体需求去探索和深化每一个环节了。记住监控的核心不是堆砌工具而是清晰地定义你需要关注什么指标并确保当它异常时你能第一时间知道。