TICK监控栈实战：Telegraf+InfluxDB+Grafana打造轻量服务器监控

1. 为什么不选别的监控方案偏偏选了TICK这套组合聊服务器监控很多人第一反应是Prometheus或者开箱即用的商业监控产品。我最初也纠结过毕竟Prometheus生态确实热闹但折腾过一轮之后反而觉得TelegrafInfluxDBGrafana这套TICK组合更贴合中小团队的实际场景尤其是当你手上机器数量不多、又不想引入太重的基础设施时这套方案的优势会非常明显。先说个背景。我有几台业务服务器和数据库实例需要盯运行状态CPU、内存、磁盘、网络这些基础指标要随时能看到趋势偶尔还要翻历史数据做性能分析。中间试过直接看云控制台的监控面板指标倒是全但历史数据保留时间有限想查一个月前的负载曲线就得开额外付费功能而且不同厂商的页面风格和使用习惯也各不相同没法统一管理。后来下定决心自建一套监控对比了Prometheus node_exporter Grafana、Zabbix、TICK这三类方案最后留了TICK。TICK这个名字其实是一组工具的缩写Telegraf负责采集服务器指标InfluxDB负责存储时序数据Kapacitor负责流式处理和告警Chronograf负责可视化。不过实际部署中大多数人跟我一样把Chronograf换成了Grafana因为Grafana的图表交互和生态插件明显更成熟。于是最常用的组合变成Telegraf InfluxDB Grafana也就是标题里说的这个三件套。Kapacitor仍然可以作为告警组件保留但Grafana也内置了告警功能小规模场景下可以二选一不一定非得全上。这套组合适合谁我个人的判断是手上有几台到几十台服务器、想快速搭起一套看得见趋势的监控系统、团队里又没有人专职搞运维的开发者或小团队。它不需要你理解复杂的服务发现机制Telegraf装上之后自动会采集本机指标一条命令就能测通。数据写进InfluxDB以后Grafana里填个地址就能出图从安装到看到第一张图表熟练的话半小时之内能搞定这个上手速度在同类型方案里算是很有竞争力的。当然它也有自己的脾气。后面我会讲到InfluxDB的存储策略、Telegraf的配置格式、Grafana的变量联动这些问题每一个都对应了实际使用中的具体场景。如果只是装完看个CPU曲线那确实简单但想要长期稳定地跑下去有几个关键点必须从一开始就意识到。2. 部署前的关键决策版本选型、存储规划和数据模型2.1 版本怎么选InfluxDB 1.x还是2.x这是第一个要拍板的事。InfluxDB目前有1.x和2.x两条大版本线很多人上来就装最新的2.x结果发现API、认证方式、界面逻辑全变了之前搜到的教程一半不能用心态直接崩掉。我自己是先用1.8跑了大半年后来才在另一台测试机上尝试2.7两边都踩过坑在这里给一个比较务实的结论如果目标是搭建稳定的监控系统优先选1.8系列的最后一个版本资料多、兼容性好、Telegraf和Grafana的配置方式也最成熟。2.x更适用于需要token认证、二次开发集成或想要内置UI能力更强的新项目但需要接受它的学习曲线。这个建议背后的原因很简单。监控系统最重要的是可持续运行而不是用最新版本。1.8版本的InfluxDB配置文件清晰端口是8086Grafana里添加数据源时选择InfluxQL查询语言填上数据库名就完事了。2.x版本引入了bucket概念替代了database认证必须带tokenGrafana数据源要切换成Flux查询语言前后写法完全不同。如果你没有预算去啃新的查询语法1.8会让你少掉很多头发。2.2 InfluxDB存储规划别低估时序数据的吃硬盘速度时序数据最容易被忽略的就是存储增长。刚开始监控几台机器时感觉一天也写不了多少数据但用一段时间后查询变慢才发现磁盘空间被大量历史数据占满了。这里有两个参数需要提前规划数据库的保留策略Retention Policy和分片组时长Shard Group Duration。以1.8为例默认的保留策略是autogen数据永久保存。我的做法是为监控数据库单独设置一个30天的保留策略超过30天的数据自动过期删除。对绝大多数需要看趋势的场景30天足够再久的场景就属于冷数据分析不应该放在InfluxDB里。分片组时长我设成了7天这决定了数据索引按什么粒度拆分也会影响写入和查询性能。具体配置命令后面专门讲。2.3 Telegraf、Grafana的安装方式选择Telegraf和Grafana在Linux下的安装很简单用包管理器直接装官方仓库版本就行。这里值得注意的一个细节是版本匹配关系Telegraf的版本号不需要跟InfluxDB完全对齐但最新版Telegraf可能会用到新版本的InfluxDB line protocol特性如果InfluxDB太老写入时可能报格式错误。稳妥做法是先装InfluxDB再装跟它的发布时间相差不太远的Telegraf和Grafana。不用精确匹配别一个大版本差太多就行。我一般先把三个仓库都配好再统一安装比一个个装更省事。安装完成之后先别急着配Grafana先把Telegraf到InfluxDB这条链路打通这是整个监控系统里最基础的一条管子管子通了后面所有事情都是通的。3. Telegraf采集配置把服务器的各种指标变成一条条时序数据3.1 配置Telegraf输出到InfluxDBTelegraf的配置文件默认在/etc/telegraf/telegraf.conf它分成三大部分全局配置、输入插件inputs、输出插件outputs。大多数教程默认你已经填好了一个完整的配置文件但实际手动安装时要自己保证outputs这段指向正确的InfluxDB地址。打开配置文件找到[[outputs.influxdb]]这一段这是告诉Telegraf把数据写到哪去。最核心的几项[[outputs.influxdb]] urls [http://127.0.0.1:8086] database telegraf retention_policy autogen username password urls就是InfluxDB的HTTP地址默认8086端口如果InfluxDB在别的机器上就换成对应的IP。database指定要写入的数据库名建议单独建一个叫telegraf的数据库不要跟其他业务数据混在一起。retention_policy可以先用autogen等后面的数据保留策略设置完再调整。改完配置之后执行sudo systemctl restart telegraf然后马上验证是否写入了数据。一个快速验证方法是执行下面的命令查询InfluxDB里最近的CPU数据curl -G http://127.0.0.1:8086/query?dbtelegraf --data-urlencode qSELECT * FROM cpu LIMIT 5如果返回了带时间戳和多字段的数据行说明Telegraf已经在正常采集并写入InfluxDB了。这一步通了后面Grafana配置数据源和图表就是水到渠成的事。3.2 最常用的一组inputs配置Telegraf的价值在于它自带了几十个输入插件几乎覆盖了所有主流服务的指标采集。对我们监控服务器运行状态这个需求来说下面这几个inputs配置是最基础的[[inputs.cpu]] percpu true totalcpu true collect_cpu_time false report_active false [[inputs.mem]] [[inputs.disk]] ignore_fs [tmpfs, devtmpfs, overlay, aufs, squashfs]inputs.cpu里percpu设为true会采集每个核心的单独使用率totalcpu为true才会把整机CPU使用率作为一条数据输出。有人会漏掉totalcpu这个选项结果发现绘图时找不到cpu usage_user这类指标就是因为没汇总。inputs.mem不需要额外参数默认会把used、available、total等内存相关的指标全采集到。inputs.disk要注意ignore_fs必须把虚拟文件系统过滤掉不然磁盘分区列表里全是tmpfs和overlay这种虚的挂载点把真实磁盘数据挤到后面去。3.3 理解tag和fieldInfluxDB数据模型的核心逻辑在配置Telegraf和编写查询时如果搞不清tag和field的区别一定会被查询结果搞晕。简单说tag是用于过滤的标签比如host、cpu编号、interface名它们是带索引的InfluxDB可以高效地在大量数据里筛选出某个host的数据。field是实际的指标值比如usage_idle98.4这些值是不带索引的你查询再多的历史数据也只能通过它们获得具体的数值。这个区别直接影响你的查询写法。比如想看某个特定主机名的CPU使用率写在WHERE条件里的是host这个tag而查询结果里显示的那个百分比数值来源是usage_idle这个field。初学者经常犯的错是拿field当tag去过滤结果索引用不上查询慢且逻辑不对。Telegraf采集时默认给每条数据加了一个hosttag填的是本机hostname如果你的机器名有变化或者多台机器重名Grafana里的图表数据会混乱所以部署的时候最好提前统一主机命名规范。3.4 让Telegraf采集服务存活状态从ping到exec除了系统指标真正运营中我更关心的是某个服务是否还活着。Telegraf有一个inputs.ping插件可以探测目标主机或IP的连通性很适合拿来监控内网的关键机器。配置也很简单[[inputs.ping]] urls [10.0.0.1, 10.0.0.2] count 3 timeout 1.0把它加到配置里之后Telegraf会周期性发起ping探测然后把丢包率、响应时间这些指标写入InfluxDB。Grafana里可以用丢包率做一个简单的连通性面板红色表示丢包严重黄色表示有轻微抖动直观明了。遇到需要探测TCP端口是否开放的服务比如数据库端口3306、Redis端口6379可以用inputs.netstat或者inputs.socket_listener相关的插件组合。更灵活的做法是用inputs.exec去跑一个自定义脚本把脚本输出的数据整理成InfluxDB的line protocol格式写进来。这种自定义扩展能力是TICK栈的一个亮点后面我会详细展开一个用它做站点健康检查的例子。4. InfluxDB数据治理从建库建表到写查询4.1 建库、建保留策略的完整命令InfluxDB 1.8的使用方式还保留着传统数据库的思路。首先在InfluxDB命令行或直接通过HTTP API创建库和保留策略。我习惯这样做CREATE DATABASE telegraf CREATE RETENTION POLICY 30d ON telegraf DURATION 30d REPLICATION 1 SHARD DURATION 7d DEFAULT第一条命令创建数据库第二条命令创建保留策略。RETENTION POLICY后面的30d是策略名DURATION 30d表示数据保存30天REPLICATION 1在单机部署下固定写1SHARD DURATION 7d表示每7天的数据拆一个分片。设成DEFAULT后后续所有写入这个库的数据都会按这个策略自动过期和分片。设置完这个策略后记得同步修改Telegraf输出配置里的retention_policy把它从autogen改成30d这样新的写入才会落到我们自定义的策略上。如果忘了改会出现数据仍然写入默认的autogen从而不回被自动清理硬盘还是会越来越满。这个细节我最初就漏过等撑爆硬盘才发现很典型。4.2 常用查询语句InfluxQL还是Flux1.8默认的查询语言是InfluxQL语法接近SQL很适合从SQL世界过来的读者。最基础的几类查询-- 查询最近两小时的CPU使用率按时间排序每30秒一点 SELECT mean(usage_idle) FROM cpu WHERE time now() - 2h GROUP BY time(30s) -- 查询最近一天内每台主机的内存可用均值 SELECT mean(available) FROM mem WHERE time now() - 1d GROUP BY time(10m), host -- 查看磁盘根分区的使用率 SELECT last(used_percent) FROM disk WHERE path / AND time now() - 1d GROUP BY time(5m)InfluxQL里最常用的聚合函数是mean()、max()、min()、last()。Grafana绘制曲线时有时候会发现原始点数太多导致图表很糊所以在查询里带上GROUP BY time(...)就能按时间窗口聚合曲线立刻平滑。这里的time窗口大小取决于你要看的时长比如看1小时数据用30秒聚合看1天数据用5分钟聚合。需要提醒的是1.8里也可以开启Flux查询但Grafana连数据源时选择的语言类型不匹配会出现奇怪的报错。我的经验是1.8就老老实实全用InfluxQLGrafana数据源里选择InfluxQL半径最小。4.3 查询性能优化理解时间范围条件的重要性InfluxDB是时序数据库它对时间索引的依赖极强。查询时如果忘记写time范围InfluxDB会去扫描整个保留策略里的所有数据数据量一旦变大一条简单查询也能拖到几十秒才返回。我见过有同事写Grafana面板时把时间范围条件删了结果每次刷新页面都要等很久后来我给每个查询模板都加了$timeFilter变量Grafana会自动把当前选择的时间范围拼进查询里性能立刻正常了。但是如果用户直接用InfluxQL查询千万记住务必带上time now() - 间隔这样的条件。这跟MySQL的索引使用习惯是一个道理索引没走对查询就是慢。5. Grafana可视化从添加数据源到做出一张能看的仪表盘5.1 添加数据源时最容易被忽略的细节Grafana装好以后第一步是登录并添加数据源。默认账号密码是admin/admin第一次登录会强制要求改密码。在Configuration - Data Sources里点Add data source选择InfluxDB然后填三项东西URLInfluxDB的HTTP地址填http://127.0.0.1:8086Database填telegraf查询语言选择InfluxQL填完点Save Test如果提示成功说明Grafana已经能通过InfluxDB的HTTP接口读到数据了。但这个环节有几种常见的坑第一InfluxDB如果启用了认证要在数据源配置里填上用户名和密码第二如果Grafana和InfluxDB不在同一台机器上数据库地址一定要写能被网络访问到的IP不能写localhost第三1.8默认是HTTP接口但如果InfluxDB配置里开了HTTPSGrafana这边的URL也要改成https否则会报本地TLS证书错误。5.2 搭建第一块仪表盘CPU使用率、内存、磁盘、网络数据源配置完毕之后可以直接创建一个新的Dashboard。我建议一开始就按主机概览的思路组织面板把每台机器的核心指标放在同一个页面上这样扫一眼就能知道整体状态。CPU面板的查询可以写成SELECT mean(usage_idle) FROM cpu WHERE host ~ /^$host$/ AND $timeFilter GROUP BY time($__interval)这里的$host是模板变量可以动态切换主机$timeFilter是Grafana自动注入的时间范围$__interval会根据当前面板的宽度和时间跨度自动选择一个合适的聚合窗口。手写查询时把usage_idle换成usage_system或usage_user可以得到不同视角的CPU占用情况。内存面板我习惯用available这个字段它表示可用内存随着缓存回收会动态变化对用户来说直观。磁盘面板按path字段过滤选择/和/data这类重要挂载点画出used_percent变化曲线更有参考价值。网络面板用net插件采集的bytes_recv和bytes_sent通常要除以时间间隔看速率Grafana里可以通过查询语句里的derivative(mean(bytes_recv), 1s)来做出来的曲线就是每秒流量。5.3 模板变量多台机器靠这一个功能管理当你有10台服务器时给每台机器单独建一套仪表盘显然是灾难。Grafana的模板变量就是用来解决这个问题的。在Dashboard的Settings - Variables里新增一个变量类型选择Query查询语句填SHOW TAG VALUES FROM cpu WITH KEY host这样Grafana会自动从InfluxDB的cpu measurement里提取出所有不同的host值变成一个下拉菜单。面板里的查询都通过WHERE host ~ /^$host$/关联到这个变量切一台机器整页图表的数据都会跟着变。这个功能非常实用相当于一套仪表盘管所有机器新增机器时根本不需要改仪表盘Telegraf一装到那台机器上下拉菜单里自然多出那个host。模板变量除了静态拉数据还可以定义成All选项允许用户一次选择所有主机这时候正则表达式匹配要用/^$host$/的格式并把Include All option打开这样就能在一个图里叠加多台机器的曲线做对比了。做压测分析时把几台机器拉到同一张CPU图上谁先逼近瓶颈一目了然。6. 告警机制让异常第一时间通知到人6.1 用Grafana告警还是Kapacitor监控不能只看图表还要在指标越界时发出告警。TICK里做告警的组件是Kapacitor但Grafana从8.0开始也内置了完善的告警引擎。小规模部署我建议直接用Grafana告警少装一个组件就少一个故障点。Kapacitor更适合需要流式处理、对延迟要求极高的场景它基于TICKscript做实时计算能在数据写入的瞬间触发告警但配置门槛高了不少。如果你只是想在CPU超过90%时收到一条通知Grafana告警完全够用也更直观。6.2 Grafana告警规则的配置过程在Grafana面板中选择一个查询然后点击右上角的Alert图标进入告警规则编辑页。这里需要设置的核心参数如下Condition告警触发的阈值条件比如last() OF query (A) IS ABOVE 90Evaluate every每1分钟评估一次For持续5分钟才触发告警避免偶发抖动引起的误报Contact point选择通知渠道例如钉钉/Webhook/Email拿CPU告警举例查询语句里选择usage_system或usage_total字段condition设为IS ABOVE 90For设为5分钟这样CPU超过90%并且持续5分钟后才会收到告警临时飙升一下就略过非常实用。如果不想等5分钟可以调成1分钟但如果告警渠道是电话或短信还是建议留一点时间余量减少骚扰。6.3 把告警通知推到钉钉或飞书Grafana告警支持多种通知方式我这边用得多的是Webhook方式推到协作办公软件的群机器人。具体做法是在Alerting - Contact points里新建一个Webhook类型的联系人填上群机器人的Webhook地址。Grafana会把告警消息以JSON格式POST过去群里就能看到CPU使用率超过90%当前值92.5%这类信息。配置好之后一定记得点击Test按钮发一条测试消息确认机器人地址没填错。这里有个经验细节告警通知里最好带上主机名和当前值不然群里只看到一个IP或一串数字不知道哪台机器出了问题。Grafana的告警消息模板里可以用{{ $labels.host }}引用主机标签也可以引用告警名称、当前值等变量把模板写清楚告警的可用性会大大提高。7. 数据采集的进阶玩法用exec插件做自定义健康检查7.1 为什么需要扩展Telegraf的采集能力Telegraf自带插件虽然多但总会遇到一些它没有覆盖的场景。比如我想监控一个网站首页的HTTP响应码和响应时间Telegraf有inputs.http_response插件可以做到但它的配置和使用逻辑不够灵活比如想要传入自定义的请求头来模拟登录态或者老版本压根没有这个插件。这时inputs.exec就是一个万能解法每隔一段时间执行任意脚本把脚本输出的文本解析成时序数据写入InfluxDB。这个扩展能力让我用很小的成本补齐了很多监控盲区。只要你能写一个脚本把指标打印成标准格式Telegraf就能把数据纳管起来。这是TICK栈里最值得花时间研究的接口之一。7.2 一个站点健康检查脚本的完整落地方案我的做法是写一个Python脚本用requests库请求目标网站取出HTTP状态码和响应耗时然后把结果按InfluxDB line protocol格式输出。脚本部分内容是这样的#!/usr/bin/env python3 import time import requests from datetime import datetime url http://example.com/health r requests.get(url, timeout5) status r.status_code elapsed r.elapsed.total_seconds() ts int(time.time()) print(fhttp_check,url{url} status{status},elapsed{elapsed} {ts})注意line protocol的格式第一部分是measurement名这里叫http_check中间是tagurlxxx后面是fieldstatusxxx,elapsedxxx最后是纳秒级时间戳ts这里其实用了秒级时间戳写入InfluxDB时会自动乘以1e9。Telegraf通过inputs.exec把这个脚本的执行结果解析成InfluxDB能识别的数据。Telegraf配置如下[[inputs.exec]] commands [/usr/local/bin/health_check.py] interval 30s timeout 10s data_format influx然后把脚本加上执行权限Telegraf每30秒执行一次把网站状态写入InfluxDB。Grafana里画status字段的曲线等于实时看到监控网站的可达性。如果再把status字段预警配置上比如status ! 200就发告警就相当于自己实现了站点可用性监控。这个思路可以延伸到检查磁盘某个特定文件大小、备份任务是否按时执行等场景扩展空间很大。7.3 自定义脚本的性能注意点用inputs.exec虽然灵活但要注意脚本执行频率和耗时。如果脚本跑得特别久比如某些接口响应慢到几十秒Telegraf的timeout会杀掉进程并把一次空结果写入InfluxDB导致这个周期没有数据曲线出现断点。建议把interval根据实际情况设置比如站点监控设30秒磁盘清理检查之类的不需要那么频繁设10分钟甚至更久也行。脚本本身要加超时控制别让一个外呼请求卡住整个采集周期。另外多个脚本采集到同一个measurement时注意tag的取值必须有区分度否则图出来会挤在一起没法看。比如给每个脚本设一个固定的tag名像check_nameweb_health这样的查询时按check_name过滤清晰很多。8. 实际运维中的几个坑和最终优化建议8.1 数据源连接到了InfluxDB但看不到数据的排查链路搭建完成后最常见的现象是Grafana数据源测试显示成功但面板上就是没有数据。这时候我一般按这个顺序排查首先在Grafana面板的Query Inspector里看实际发出去的查询语句和返回结果确认查询没有报语法错误。其次确认InfluxDB里确实有数据。在InfluxDB执行SHOW MEASUREMENTS看到CPU、mem等表名就说明Telegraf还在写数据。再看查询里的字段名。Telegraf输出的measurement名和字段名有具体的命名规则比如CPU数据可能在s cpu这个表里字段是usage_idle而不是本来以为的usage_cpu。不要靠猜用SHOW FIELD KEYS FROM cpu这类命令确认字段拼写。最后看时间范围。Grafana右上角默认可能是过去15分钟如果Telegraf采集间隔较长或系统时间不对可能这段时间确实没数据拉长到过去24小时再试。这个排查步骤看起来基础但确实能解决绝大多数明明都装了却看不到图的问题。许多人一上来就怀疑网络和权限反而忽略掉了字段名拼写这种最朴素的问题。8.2 保留策略的坑为什么磁盘还是越来越满前面提到过设置保留策略的事但实际上还有一个容易踩的坑如果InfluxDB不是通过HTTP API创建保留策略而是通过配置文件启动了多个存储策略那么Telegraf写入时如果不指定retention_policy数据会全部落到默认策略里。我用过一段时间后发现磁盘占用一直在涨查了一下发现写入到了autogen策略而autogen是无限保留的于是定期手动删数据才解决问题。后来重新设计了策略名并对Telegraf配置做了同步才根治这个问题。另外删除过期数据在InfluxDB里不是立刻发生的而是后台周期性执行。如果数据写入量巨大且分片组时长设置太长可能出现删除任务追不上新增速度的暂时现象稍等一段时间或手动执行SHOW RETENTION POLICIES验证策略状态即可。8.3 监控系统自身的告警别让监控变成单点最后提一个容易被忽略的点监控系统本身也可能挂掉。InfluxDB宕机、磁盘写满、Telegraf死循环这些都会导致监控数据断档而你正想去看监控的时候偏看不到。我自己的做法是给监控主机单独设置一个简单的存活检测用另一台机器定时ping监控主机配合一个外部脚本检查InfluxDB端口是否响应。这样即使监控系统整体挂了至少还有一个外部通道能告诉你监控掉了。TICK栈这套组合的优点就是灵活、可控、成本低玩熟了之后可以自己随意组合和扩展。按照上面的步骤完整走一遍你手上的服务器运行状态会变得前所未有的清晰排障效率也高很多。最后提醒一句任何监控方案的核心都是运维纪律和配置管理工具只是辅助把数据管明白比换多少监控工具都管用。