凌晨两点被叫起来处理一起业务间歇性卡顿登上 Zabbix 首页盯着那几张折线图CPU 冲到 80%、内存缓慢上涨、磁盘 IO 拉满然后呢没有然后了。Zabbix 把哪台机器、哪个指标、什么时候越界这件事做得非常扎实但要把三十台机器的同一个指标摆在一张图里做横向对比或者把一台机器过去三十天的内存曲线和发版记录叠在一起看自带图形就明显不够用了。这套 Zabbix 监控结合 Grafana 绘图的方案解决的就是这个断层采集和判定交给 Zabbix观察和对比交给 Grafana。它不是要替换 Zabbix而是在 Zabbix 之上加一层展示引擎让原本分散在几十个主机页面里的指标变成能横向拉通、能按变量筛选、能挂上大屏的一整套视图。适合已经用 Zabbix 跑了一段时间、开始觉得图不够用的运维同学也适合刚接手监控体系、需要快速出一套大盘的人。下面这份内容是我自己在几套环境里反复折腾之后沉淀下来的从 Zabbix 侧的前置准备一直讲到面板维护中间踩过的坑都标出来了。1. 已经有 Zabbix 图形了为什么还要挂一层 Grafana很多人的第一反应是Zabbix 自带图形不也能看吗为什么要多装一个组件我在最开始也是这么想的直到有一次排查一个跨主机的性能问题才彻底改了主意。1.1 Zabbix 自带图形的能力边界在哪先把话说清楚Zabbix 在可视化这块并不是弱而是重心不同。它最核心的能力是采集、触发器判定和告警分发图形更多是顺带提供的观察窗口。具体来说自带图形有这么几个边界单主机视角为主。Simple graph 和 Custom graph 基本都是围绕一台主机的若干 item 展开想同时看二十台机器的同一个指标得靠聚合图形一块块拼拼出来的也是二十张独立小图而不是一条可对比的叠加曲线。时间范围交互有限。前端能选的时间段是固定的几档想要从故障时间点往前推三天这种精确区间操作路径比较绕。图例和单位不够灵活。多个 item 画在一起时图例命名、单位换算、小数位的控制空间不大尤其是字节和比特混在一起的时候眼睛容易看花。分享成本高。要给不在监控体系里的人看一眼趋势往往得截图截出来的图还不能缩放。这不是吐槽而是定位问题。Zabbix 的设计目标是发现问题并可靠地通知你在这个目标上它是合格的。1.2 Grafana 补上的三件事我把数据接过去之后真正感受到价值的是三块第一块是同图叠加与变量筛选。给面板配一个主机组变量和一个主机变量同一张 CPU 使用率图就能在全部主机 / 单台主机之间一键切换曲线要么是一堆细线做横向对比要么聚焦到某一台上做细节观察。这个能力在排查是不是某台机器拖了后腿的时候特别省事。第二块是多数据源统一视图。Grafana 的面板不认数据源类型同一个 Dashboard 里可以左边放 Zabbix 的主机指标右边放 HTTP 探测、日志统计甚至手工录入的容量数据。真正的一屏看全,在 Zabbix 前端是做不出来的。第三块是长周期观察和排布自由。大盘的列宽、行高、面板位置、阈值线颜色、单位格式全都可以自己排。把关键指标放上面、细节放下面、告警时间线放最底这套排版一旦定下来值班的人接手成本会低很多。1.3 这套组合不适合谁我也见过一些团队上了 Grafana 之后反而更累通常是这几种情况机器就三五台只看告警不看图。这种情况 Zabbix 自带图形完全够用多维护一个组件纯属负担。没有人负责面板。面板是会腐化的——主机下线了、指标改名了、模板换了图会自动变成空白没人管的话三个月后整套大盘就废了。把 Grafana 当告警主通道。这点后面会专门讲Zabbix 的触发器体系在依赖关系、恢复条件、告警升级上的能力不是 Grafana 侧一个阈值判断能替代的。一句话Zabbix 负责有没有问题Grafana 负责问题长什么样。两者定位清晰组合才有意义。2. 动手之前Zabbix 侧要先把地基铺好我踩过的最大一个坑是数据源接上之后发现图全是空的排查了半天才意识到是权限问题。所以这一节放在最前面先把 Zabbix 那边的东西理顺。2.1 单独开一个只读 API 账号不要拿 Admin 账号去接 Grafana也不要用超管。原因很实际Grafana 的数据源配置在团队里往往会被多人看到密码泄露风险不小而且超管权限意味着一旦 Grafana 侧被利用整个 Zabbix 就暴露了。正确做法是建一个独立用户角色权限设为只读只授予需要展示的主机组配置项建议值说明用户名grafana-readonly语义清晰便于审计用户角色只读角色User role只能读主机、item、历史数据主机组权限只勾选需要展示的组不授权就查不到数据这是最常见的图空白原因认证方式API Token较新版本支持或用户名密码Token 更适合自动化续期管理更简单如果你的 Zabbix 版本支持 API Token强烈建议用 Token。Token 可以在用户界面里单独生成和吊销不用担心密码过期策略也不用把明文密码写进 provisioning 配置。生成之后先用命令行验证一下能不能通这一步能省掉后面大量的猜测# 用 API Token 拉三台主机确认权限和网络都通 curl -s -H Content-Type: application/json-rpc \ -H Authorization: Bearer YOUR_TOKEN \ -d {jsonrpc:2.0,method:host.get,params:{output:[hostid,host],limit:3},id:1} \ http://zabbix.example.com/api_jsonrpc.php返回里能看到主机列表说明 Token 有效、权限正常、网络可达。要是返回空数组八成是主机组权限没给。2.2 主机分组和指标命名决定了后面画图顺不顺手这一步很多人会跳过但它直接影响 Grafana 面板的可用性。Grafana 的变量筛选是依赖 Zabbix 的主机组和 item 名称的。如果主机组是按Zabbix 服务器应用服务器这种技术维度随便分的那变量里选出来的选项就会很乱。我的建议是按业务 环境两层来分比如prod-payment、prod-order、test-payment这样面板上先选环境再选业务逻辑清晰。指标这边重点盯三件事item 的可见名称要有意义。Grafana 的 Metrics 查询模式是按名称做模式匹配的如果名称全是默认的CPU $1、Interface $2匹配起来会很难受。单位必须填。Zabbix 里 item 的单位设成B、bps、%Grafana 才能自动做单位换算和 Y 轴标注。不填单位的 item画出来就是一条没有量纲的线看着费劲。应用集Application要规范。部分查询场景下可以用应用集做过滤命名统一了能省很多筛选条件。2.3 面板刷新会变成 Zabbix 的压力这个账要先算这是个很容易被忽略的点Grafana 的每一个面板、每一次刷新都是一次 API 请求。加一层展示引擎等于给 Zabbix 增加了一个持续的查询客户端。我做过一个粗略的估算一个 Dashboard 有 12 个面板刷新间隔 30 秒那么每分钟就是 24 次查询如果有 20 个人同时开着这个大屏或者面板就是每分钟 480 次。如果每个查询还要跨 50 台主机做模式匹配Zabbix Server 的查询压力会明显上升。几个实用的降载手段手段具体做法效果拉长刷新间隔大屏 5 分钟日常排查 1 分钟别用 5 秒最直接收益最大启用趋势数据数据源里打开 Trends 开关长周期查询走聚合表查询量大幅下降提高缓存时间Cache TTL 设为 1 小时相同查询在 TTL 内不重复打 API减少主机级模式匹配查询里明确指定主机别用大范围正则每次查询扫的 item 数量减少用直接数据库连接走只读 SQL 连接查 history/trends 表绕开 API但要单独配只读数据库账号维护成本更高我自己的习惯是日常排查用的面板设 1 分钟值班大屏设 5 分钟。这个组合既保证了及时性又把压力控制住了。3. 从零把 Zabbix 数据源接进 Grafana地基铺好之后剩下的事情就顺了。这一节按我实际操作过的顺序来写。3.1 插件安装与版本匹配Grafana 原生不支持 Zabbix 数据源需要装社区插件。装法有两种看你的部署方式容器部署的话用环境变量最省事docker run -d --name grafana \ -p 3000:3000 \ -e GF_INSTALL_PLUGINSalexanderzobnin-zabbix-app \ -e GF_SECURITY_ALLOW_LOADING_UNSIGNED_PLUGINSalexanderzobnin-zabbix-app,alexanderzobnin-zabbix-datasource \ grafana/grafana:10.4.5传统部署的话用命令行工具装然后重启服务grafana-cli plugins install alexanderzobnin-zabbix-app # 重启 grafana-server 使插件生效这里有个必须注意的点插件版本和 Grafana 主版本要匹配。我遇到过 Grafana 主版本比较新、插件版本偏旧结果插件能装上但加载报错的情况。保险做法是升级 Grafana 之前先看一眼插件发布说明里的兼容范围把插件版本也一起规划进去。另外就是别在主版本大升级的当天顺手升插件两件事混在一起出问题排查起来很难定位是哪边引起的。3.2 数据源配置项逐个说清楚插件装好之后在 Grafana 的插件列表里能找到 Zabbix 应用启用之后就可以添加数据源了。配置项看着不多但每一项都有讲究URL。填 Zabbix 的 API 地址通常是你的前端地址加上api_jsonrpc.php。如果你的环境里通过反向代理加了一层路径前缀这里一定要把前缀带上。我见过最常见的 URL 错误就是漏了这一段表现为 404。Access。一定选Server (proxy)模式让 Grafana 后端的服务去请求 Zabbix。选 Browser 模式意味着请求从前端浏览器发出除了会把凭据暴露给浏览器之外还会直接撞上跨域限制基本是给自己找麻烦。认证方式。较新版本可以用 API Token老版本用用户名密码。用密码的话记得后续做轮换别一用好几年。Trends趋势数据。这个开关我建议打开。Zabbix 的 trends 表按小时做了预聚合查询长周期数据时走趋势表速度比扫 history 表快得多。相关的还有从多久开始用趋势和趋势的范围一般配成7 天以内用历史、7 天以上用趋势这种策略比较平衡。Cache TTL。默认值通常偏短我一般会调到 1 小时。同一个面板在 TTL 内重复请求会直接命中缓存对 Zabbix 后端非常友好。坏处是新采集的数据可能有最长 TTL 的展示延迟但对运维大盘来说这个延迟完全可以接受。Direct DB Connection。这个选项是给不想走 API、直接查数据库的场景准备的需要额外配一个只读的 SQL 数据源。我的建议是除非 API 压力已经明显影响到 Zabbix 本身否则不要开。多一条数据库直连链路就多一份权限管理和版本兼容的维护成本收益和成本不成正比。3.3 连不上、连上了没数据按这个顺序排查连接类问题几乎占了新手阶段的全部时间。我整理了一张对照表按这个顺序查基本都能定位现象大概率原因处理方式404 错误URL 少了路径或缺少反向代理前缀补齐完整 API 地址401 / 权限错误用户名密码不对、Token 失效或角色权限不足重新验证凭据确认角色是只读但可读跨域报错Access 选了 Browser 模式改成 Server (proxy)请求超时防火墙拦截、反向代理超时配置过短从 Grafana 所在机器手动 curl 验证链路能连上但图表全空主机组权限没给、趋势开关状态和查询时间范围不匹配、历史保留期已过先用命令行 API 确认数据存在再查权限前端提示服务端未运行之类的告警Zabbix 服务端本身异常与 Grafana 无关回到 Zabbix 侧排查服务状态我自己的排查顺序固定是命令行 curl API → 确认数据存在 → 确认用户权限 → 确认 Grafana 侧配置。这个顺序的好处是每步都能得出明确结论不会在不同层之间反复跳。4. 查询面板里那几个特别容易搞混的概念数据源接上之后真正的门槛在查询编辑器里。Zabbix 插件提供了好几种查询模式用错了就是图能出来但怎么看怎么不对。4.1 查询模式怎么选模式匹配还是 Item ID插件支持的查询模式大致有这么几类用途差异很大查询模式匹配方式适合场景风险Metrics指标主机组 主机 item 名称模式支持正则变量化面板、批量主机item 改名后查询会失效Item ID精确 ID固定的核心指标面板迁移环境时 ID 会变需要重新指触发器 / 问题事件触发器状态与事件流画告警时间线、事件标注需要额外考虑权限和事件量文本类字符串型 item展示版本号、运行状态不能做数值聚合我的经验是变量化的通用面板用 Metrics 模式核心固定面板用 Item ID 模式。前者灵活后者稳定。最怕的是全用 Metrics 模式还写了很宽的正则主机一多就会匹配到一堆不相关的 item图上出现一堆莫名其妙的线。另外提醒一点item 名称模式匹配时优先匹配键值还是可见名称是有区别的不同插件版本的行为可能不一样。如果画出来的线数量不对先把查询返回的 item 列表拉出来核对一下比在图上猜快得多。4.2 历史和趋势这两个概念决定了你能看多久以前的数据这是最容易被忽略、也最容易让人困惑的一块。Zabbix 的数据分两层存储history 表存原始采集值精度高但占用大保留期通常只有几天到几周trends 表按小时做聚合保留期可以拉到一年以上代价是精度损失。这带来两个直接影响第一你查不到三个月前的秒级数据。这不是 Grafana 的问题是 Zabbix 那边 history 保留期到了就把数据清了。很多人第一次遇到这个会以为数据源坏了其实是正常的存储策略。要长期保留细粒度数据只能调 Zabbix 的 housekeeper 配置或者外接专门的时序存储。第二趋势数据只有数值型 item 才有。字符串型、日志型 item 是没有趋势表的所以拉长到过去 30 天去看这类指标图会直接断掉。这一点在设计面板的时候就要考虑到别把字符串指标放到带长时间范围选择器的大盘上。趋势数据的查询会用到专门的聚合函数比如取区间平均值、最大值、最小值、计数。想做过去一天的每小时峰值这种图就用最大值的趋势函数而不是让 Grafana 去对原始数据做聚合。前者走预聚合表快得多。4.3 多主机叠加和图例命名把二十台机器的同一条曲线画在一张图上如果图例全是默认的名称图基本没法看。这里的处理办法是用变量拿到当前选中的主机列表在查询里对主机做循环。图例模板里带上主机名比如用类似{{host}} - CPU的写法这样每条线一眼能对应到机器。开启 Multi-value 和 Include All 两个选项让变量支持多选和全选。排序上把变量值的排序方式设成按名称排序避免每次刷新曲线顺序都在变。还有个细节叠加图的主机数量建议控制在 8 到 12 条曲线以内。超过这个数量颜色区分度会急剧下降图例也开始堆叠实际可读性反而变差。真要对比几十台用统计类的面板或者分组的折线更合适。5. 把面板做成一块真正能用的值班大屏图表能出来只是第一步能不能在出问题的时候帮上忙取决于面板怎么设计。5.1 用三级变量把一张面板复用给所有业务我现在的做法是给资源类面板配三级变量业务组变量数据源查询类型选主机组把 Zabbix 里的主机组列出来。主机变量类型选主机并且用上一个变量做过滤只列出该组下的主机。指标变量类型选指标名称用前两个变量过滤。这样一张 CPU 面板可以覆盖所有业务组排查时先选业务、再选主机路径非常自然。变量之间的联动筛选是关键——如果主机变量不过滤列表里会出来几百台机器选起来很痛苦。变量值还可以加正则过滤。比如只想看带prod-前缀的主机就在变量的正则里限制一下。这个技巧在多环境混用一套 Zabbix 的时候特别有用。5.2 单位和阈值线这两个地方最容易画错单位问题我在好几个环境里都踩过字节和比特混用。网络设备上报的流量通常是比特每秒服务器网卡上报的通常是字节每秒两者差 8 倍。如果 Zabbix 里单位填错了Grafana 换算出来的数字就会离谱图上看着带宽跑满了实际才用了八分之一。百分比范围。有些 item 存的是 0 到 100有些存的是 0 到 1。Grafana 的百分比单位默认按 0 到 1 处理如果数据是 0 到 100 的整条线会跑到图表顶端看不见。单位后缀写法。单位写法不规范时Grafana 可能识别不出来导致显示成原始数字比如1073741824而不是1 GiB。阈值线的配置也有讲究。我一般设三级绿色是正常区间黄色是预警线红色是必须处理的线。颜色的使用要保持全局一致不要这块面板黄色代表预警、那块黄色代表严重值班的人会被绕晕。另外阈值线的位置要和 Zabbix 触发器的阈值对齐两边不一致是最要命的事情——图上看着正常告警却响了。5.3 大盘分层的排布思路我的大盘固定分四层从上往下按从概览到细节的顺序第一层是健康概览。放几个状态类面板用颜色块展示各业务组当前的整体状态一眼就能看出哪个业务红了。同时放几个最关键的数值比如核心接口的错误率、订单量。第二层是资源指标。CPU、内存、磁盘使用率、磁盘 IO、网络流量每个指标一张图全部支持变量切换。这一层是排查时用得最多的。第三层是业务与应用。中间件连接数、队列积压、接口响应时间这类。这里往往是多个数据源混排Zabbix 的指标和别的来源放在一起看。第四层是事件时间线。用触发器或问题事件的查询模式把告警事件按时间轴铺在底部。这一层最大的价值是当你看曲线突然上扬的时候能立刻知道同一时刻有没有告警、有没有发版。用 Row 把这些层折叠起来配合变量联动一块大屏就能同时服务值班扫一眼和深入排查两种场景。6. 告警到底该由谁发这件事要提前定这是我见过最多争议的地方也是很多团队做完 Grafana 大盘之后反而告警变乱的根源。6.1 职责划分Zabbix 判定Grafana 展示我的立场很明确告警的判定和通知继续由 Zabbix 负责Grafana 只负责看。理由不是偏好而是能力差异。Zabbix 的触发器支持依赖关系、多指标组合条件、恢复表达式、告警升级和抑制还能针对不同主机组走不同的通知渠道。Grafana 侧的告警本质上是对查询结果做阈值判断缺少触发器之间那种父触发器不告警时子触发器不通知的关系管理。真到了大故障的时候差的就是这些细节。实践中最省事的做法是在 Grafana 里用问题事件的查询模式做一个事件面板把 Zabbix 当前的问题列表和最近的事件流展示出来。这样你在看曲线的时候能同时看到告警状态但真正发通知的还是 Zabbix不会出现同一件事两个渠道各发一遍的情况。两套都发同样的告警后果很实际值班的人手机上会收到双份通知时间一长就会对通知麻木真正的严重告警反而被淹没。6.2 如果确实要用 Grafana 补一层告警有些场景下 Grafana 侧告警是有价值的比如跨主机的聚合判断——同一业务组里超过一半的主机磁盘使用率都超过阈值这种条件在 Zabbix 里写起来很别扭在 Grafana 里反而直观。如果要这么做我的建议是只作为补充不作为主通道。主通道永远是 Zabbix。明确命名。Grafana 侧发出来的告警在标题里带上前缀值班的人一看就知道来源不同。控制数量。Grafana 告警规则数量多了之后管理成本会快速上升能不建就不建。另外提一句网上经常把另一套监控体系的告警组件和 Grafana 的告警混着讲那是完全不同的两条链路。别看到别人在配某个告警转发组件就以为 Zabbix 也要照着配一遍方向搞错了会白折腾很久。7. 那些让我熬过夜的问题以及现在的维护节奏最后一节讲几个具体的坑都是实际发生过的不是从文档里抄的。7.1 插件升级之后面板集体失效这个坑我遇到过一次印象很深。Grafana 主版本升上去、插件也跟着升了一版结果一批老面板打开就报错提示和旧查询的升级有关甚至牵扯到找不到某个旧的数据源。根因有两层。一层是数据源的身份标识变了——面板的 JSON 里记录的是数据源的名字或者唯一标识如果你在迁移过程中改了数据源的名字或者删了重建了一个旧面板就找不到对应关系了。另一层是插件内部的数据模型发生了变化老版本的查询对象里缺少新版本的字段升级逻辑要去做转换转换失败就报错。处理办法我总结了几条数据源名字定下来就别改。换名字的成本远高于一开始想清楚的成本。面板迁移时用唯一标识而不是名字。现在的 Grafana 支持给数据源指定稳定的标识导入面板之后引用标识改名字也不会断。面板 JSON 定期备份。Dashboard 的 JSON 就是资产导出一份放到版本管理里。真出事了拿着 JSON 改一改就能恢复比在界面上一个个修快得多。升级前先在测试环境开一套。把插件和数据源配置在测试环境跑通再动生产。这一步花的时间通常比事后排查省得多。7.2 面板的复制和导入导出有几个细节要注意在界面上直接复制面板会带上原面板的数据源引用。如果目标环境里没有同名数据源面板就是空的。跨环境迁移的时候我一般用导出的方式导出时留意是否导出为外部共享这个选项的差异勾了它导出的是带变量占位的形式更适合跨环境分享不勾导出的是当前环境的完整引用。如果你们的环境用配置文件管理数据源那就更省事了。把数据源写成配置文件敏感信息单独放面板引用统一的名字或者标识迁移的时候基本不用改。这类配置长这样apiVersion: 1 datasources: - name: Zabbix type: alexanderzobnin-zabbix-datasource access: proxy url: http://zabbix.example.com/api_jsonrpc.php jsonData: username: grafana-readonly trends: true trendsFrom: 7d trendsRange: 4d cacheTTL: 1h secureJsonData: password: 在这里填凭据注意字段名和取值在不同插件版本之间可能有差异以你实际版本的文档为准。别直接照抄我的配置先对照自己版本的字段说明核一遍。7.3 长期维护清单面板这东西做出来只是开始能不能活过半年取决于有没有人管。我现在的维护节奏大致是这样每月扫一遍面板。把三个月没人看、或者数据源已经不存在的面板删掉。留着这些空面板只会让大盘越来越臃肿新来的人根本找不到重点。每季度核一次权限。确认 Grafana 侧用的那个只读账号还有效密码或者 Token 没过期需要展示的主机组没有遗漏。这个检查很有必要我遇到过因为账号密码轮换导致整个大盘静默失效的情况最坑的是它不报错只是所有图都不更新了。给每个面板加标签和责任人。标签用来分类和搜索责任人写在面板描述里。出问题的时候知道该找谁这件事的价值在关键时刻才体现出来。控制刷新间隔的总量。定期算一下大屏的刷新总频次如果 Zabbix 的查询压力上来了先把大屏的刷新间隔调长而不是急着优化 Zabbix 数据库。大屏电视机的显示参数要单独调。深色主题在电视上比浅色舒服字号要比桌面端大一档分辨率适配也要单独排一版。这个细节不难但没人做的话大屏永远是能用但看不清的状态。7.4 我现在对这套组合的理解折腾了这么久我对 Zabbix 加 Grafana 这套组合的认识其实一直在变。最开始我以为它是给 Zabbix 换个好看的皮后来发现真正的价值不在好看而在它逼着你去把监控指标理清楚。因为一旦要做变量化面板、要做多主机对比、要做图例命名你就必须回答这些问题主机组怎么分指标名字规范吗单位填对了吗哪些指标是核心、哪些只是参考这些问题在只用 Zabbix 自带图形的时候可以糊过去做大盘的时候糊不过去。所以我现在一般会在项目开始前先花半天时间把主机组和指标命名理一遍再动手画图。这半天时间看起来是没干活但它能让后面的面板返工率降一大截。踩过几次坑之后我才明白画图难的从来不是图本身而是图背后那套指标到底有没有被整理过。
Zabbix+Grafana监控可视化：从数据源配置到运维值班大屏
凌晨两点被叫起来处理一起业务间歇性卡顿登上 Zabbix 首页盯着那几张折线图CPU 冲到 80%、内存缓慢上涨、磁盘 IO 拉满然后呢没有然后了。Zabbix 把哪台机器、哪个指标、什么时候越界这件事做得非常扎实但要把三十台机器的同一个指标摆在一张图里做横向对比或者把一台机器过去三十天的内存曲线和发版记录叠在一起看自带图形就明显不够用了。这套 Zabbix 监控结合 Grafana 绘图的方案解决的就是这个断层采集和判定交给 Zabbix观察和对比交给 Grafana。它不是要替换 Zabbix而是在 Zabbix 之上加一层展示引擎让原本分散在几十个主机页面里的指标变成能横向拉通、能按变量筛选、能挂上大屏的一整套视图。适合已经用 Zabbix 跑了一段时间、开始觉得图不够用的运维同学也适合刚接手监控体系、需要快速出一套大盘的人。下面这份内容是我自己在几套环境里反复折腾之后沉淀下来的从 Zabbix 侧的前置准备一直讲到面板维护中间踩过的坑都标出来了。1. 已经有 Zabbix 图形了为什么还要挂一层 Grafana很多人的第一反应是Zabbix 自带图形不也能看吗为什么要多装一个组件我在最开始也是这么想的直到有一次排查一个跨主机的性能问题才彻底改了主意。1.1 Zabbix 自带图形的能力边界在哪先把话说清楚Zabbix 在可视化这块并不是弱而是重心不同。它最核心的能力是采集、触发器判定和告警分发图形更多是顺带提供的观察窗口。具体来说自带图形有这么几个边界单主机视角为主。Simple graph 和 Custom graph 基本都是围绕一台主机的若干 item 展开想同时看二十台机器的同一个指标得靠聚合图形一块块拼拼出来的也是二十张独立小图而不是一条可对比的叠加曲线。时间范围交互有限。前端能选的时间段是固定的几档想要从故障时间点往前推三天这种精确区间操作路径比较绕。图例和单位不够灵活。多个 item 画在一起时图例命名、单位换算、小数位的控制空间不大尤其是字节和比特混在一起的时候眼睛容易看花。分享成本高。要给不在监控体系里的人看一眼趋势往往得截图截出来的图还不能缩放。这不是吐槽而是定位问题。Zabbix 的设计目标是发现问题并可靠地通知你在这个目标上它是合格的。1.2 Grafana 补上的三件事我把数据接过去之后真正感受到价值的是三块第一块是同图叠加与变量筛选。给面板配一个主机组变量和一个主机变量同一张 CPU 使用率图就能在全部主机 / 单台主机之间一键切换曲线要么是一堆细线做横向对比要么聚焦到某一台上做细节观察。这个能力在排查是不是某台机器拖了后腿的时候特别省事。第二块是多数据源统一视图。Grafana 的面板不认数据源类型同一个 Dashboard 里可以左边放 Zabbix 的主机指标右边放 HTTP 探测、日志统计甚至手工录入的容量数据。真正的一屏看全,在 Zabbix 前端是做不出来的。第三块是长周期观察和排布自由。大盘的列宽、行高、面板位置、阈值线颜色、单位格式全都可以自己排。把关键指标放上面、细节放下面、告警时间线放最底这套排版一旦定下来值班的人接手成本会低很多。1.3 这套组合不适合谁我也见过一些团队上了 Grafana 之后反而更累通常是这几种情况机器就三五台只看告警不看图。这种情况 Zabbix 自带图形完全够用多维护一个组件纯属负担。没有人负责面板。面板是会腐化的——主机下线了、指标改名了、模板换了图会自动变成空白没人管的话三个月后整套大盘就废了。把 Grafana 当告警主通道。这点后面会专门讲Zabbix 的触发器体系在依赖关系、恢复条件、告警升级上的能力不是 Grafana 侧一个阈值判断能替代的。一句话Zabbix 负责有没有问题Grafana 负责问题长什么样。两者定位清晰组合才有意义。2. 动手之前Zabbix 侧要先把地基铺好我踩过的最大一个坑是数据源接上之后发现图全是空的排查了半天才意识到是权限问题。所以这一节放在最前面先把 Zabbix 那边的东西理顺。2.1 单独开一个只读 API 账号不要拿 Admin 账号去接 Grafana也不要用超管。原因很实际Grafana 的数据源配置在团队里往往会被多人看到密码泄露风险不小而且超管权限意味着一旦 Grafana 侧被利用整个 Zabbix 就暴露了。正确做法是建一个独立用户角色权限设为只读只授予需要展示的主机组配置项建议值说明用户名grafana-readonly语义清晰便于审计用户角色只读角色User role只能读主机、item、历史数据主机组权限只勾选需要展示的组不授权就查不到数据这是最常见的图空白原因认证方式API Token较新版本支持或用户名密码Token 更适合自动化续期管理更简单如果你的 Zabbix 版本支持 API Token强烈建议用 Token。Token 可以在用户界面里单独生成和吊销不用担心密码过期策略也不用把明文密码写进 provisioning 配置。生成之后先用命令行验证一下能不能通这一步能省掉后面大量的猜测# 用 API Token 拉三台主机确认权限和网络都通 curl -s -H Content-Type: application/json-rpc \ -H Authorization: Bearer YOUR_TOKEN \ -d {jsonrpc:2.0,method:host.get,params:{output:[hostid,host],limit:3},id:1} \ http://zabbix.example.com/api_jsonrpc.php返回里能看到主机列表说明 Token 有效、权限正常、网络可达。要是返回空数组八成是主机组权限没给。2.2 主机分组和指标命名决定了后面画图顺不顺手这一步很多人会跳过但它直接影响 Grafana 面板的可用性。Grafana 的变量筛选是依赖 Zabbix 的主机组和 item 名称的。如果主机组是按Zabbix 服务器应用服务器这种技术维度随便分的那变量里选出来的选项就会很乱。我的建议是按业务 环境两层来分比如prod-payment、prod-order、test-payment这样面板上先选环境再选业务逻辑清晰。指标这边重点盯三件事item 的可见名称要有意义。Grafana 的 Metrics 查询模式是按名称做模式匹配的如果名称全是默认的CPU $1、Interface $2匹配起来会很难受。单位必须填。Zabbix 里 item 的单位设成B、bps、%Grafana 才能自动做单位换算和 Y 轴标注。不填单位的 item画出来就是一条没有量纲的线看着费劲。应用集Application要规范。部分查询场景下可以用应用集做过滤命名统一了能省很多筛选条件。2.3 面板刷新会变成 Zabbix 的压力这个账要先算这是个很容易被忽略的点Grafana 的每一个面板、每一次刷新都是一次 API 请求。加一层展示引擎等于给 Zabbix 增加了一个持续的查询客户端。我做过一个粗略的估算一个 Dashboard 有 12 个面板刷新间隔 30 秒那么每分钟就是 24 次查询如果有 20 个人同时开着这个大屏或者面板就是每分钟 480 次。如果每个查询还要跨 50 台主机做模式匹配Zabbix Server 的查询压力会明显上升。几个实用的降载手段手段具体做法效果拉长刷新间隔大屏 5 分钟日常排查 1 分钟别用 5 秒最直接收益最大启用趋势数据数据源里打开 Trends 开关长周期查询走聚合表查询量大幅下降提高缓存时间Cache TTL 设为 1 小时相同查询在 TTL 内不重复打 API减少主机级模式匹配查询里明确指定主机别用大范围正则每次查询扫的 item 数量减少用直接数据库连接走只读 SQL 连接查 history/trends 表绕开 API但要单独配只读数据库账号维护成本更高我自己的习惯是日常排查用的面板设 1 分钟值班大屏设 5 分钟。这个组合既保证了及时性又把压力控制住了。3. 从零把 Zabbix 数据源接进 Grafana地基铺好之后剩下的事情就顺了。这一节按我实际操作过的顺序来写。3.1 插件安装与版本匹配Grafana 原生不支持 Zabbix 数据源需要装社区插件。装法有两种看你的部署方式容器部署的话用环境变量最省事docker run -d --name grafana \ -p 3000:3000 \ -e GF_INSTALL_PLUGINSalexanderzobnin-zabbix-app \ -e GF_SECURITY_ALLOW_LOADING_UNSIGNED_PLUGINSalexanderzobnin-zabbix-app,alexanderzobnin-zabbix-datasource \ grafana/grafana:10.4.5传统部署的话用命令行工具装然后重启服务grafana-cli plugins install alexanderzobnin-zabbix-app # 重启 grafana-server 使插件生效这里有个必须注意的点插件版本和 Grafana 主版本要匹配。我遇到过 Grafana 主版本比较新、插件版本偏旧结果插件能装上但加载报错的情况。保险做法是升级 Grafana 之前先看一眼插件发布说明里的兼容范围把插件版本也一起规划进去。另外就是别在主版本大升级的当天顺手升插件两件事混在一起出问题排查起来很难定位是哪边引起的。3.2 数据源配置项逐个说清楚插件装好之后在 Grafana 的插件列表里能找到 Zabbix 应用启用之后就可以添加数据源了。配置项看着不多但每一项都有讲究URL。填 Zabbix 的 API 地址通常是你的前端地址加上api_jsonrpc.php。如果你的环境里通过反向代理加了一层路径前缀这里一定要把前缀带上。我见过最常见的 URL 错误就是漏了这一段表现为 404。Access。一定选Server (proxy)模式让 Grafana 后端的服务去请求 Zabbix。选 Browser 模式意味着请求从前端浏览器发出除了会把凭据暴露给浏览器之外还会直接撞上跨域限制基本是给自己找麻烦。认证方式。较新版本可以用 API Token老版本用用户名密码。用密码的话记得后续做轮换别一用好几年。Trends趋势数据。这个开关我建议打开。Zabbix 的 trends 表按小时做了预聚合查询长周期数据时走趋势表速度比扫 history 表快得多。相关的还有从多久开始用趋势和趋势的范围一般配成7 天以内用历史、7 天以上用趋势这种策略比较平衡。Cache TTL。默认值通常偏短我一般会调到 1 小时。同一个面板在 TTL 内重复请求会直接命中缓存对 Zabbix 后端非常友好。坏处是新采集的数据可能有最长 TTL 的展示延迟但对运维大盘来说这个延迟完全可以接受。Direct DB Connection。这个选项是给不想走 API、直接查数据库的场景准备的需要额外配一个只读的 SQL 数据源。我的建议是除非 API 压力已经明显影响到 Zabbix 本身否则不要开。多一条数据库直连链路就多一份权限管理和版本兼容的维护成本收益和成本不成正比。3.3 连不上、连上了没数据按这个顺序排查连接类问题几乎占了新手阶段的全部时间。我整理了一张对照表按这个顺序查基本都能定位现象大概率原因处理方式404 错误URL 少了路径或缺少反向代理前缀补齐完整 API 地址401 / 权限错误用户名密码不对、Token 失效或角色权限不足重新验证凭据确认角色是只读但可读跨域报错Access 选了 Browser 模式改成 Server (proxy)请求超时防火墙拦截、反向代理超时配置过短从 Grafana 所在机器手动 curl 验证链路能连上但图表全空主机组权限没给、趋势开关状态和查询时间范围不匹配、历史保留期已过先用命令行 API 确认数据存在再查权限前端提示服务端未运行之类的告警Zabbix 服务端本身异常与 Grafana 无关回到 Zabbix 侧排查服务状态我自己的排查顺序固定是命令行 curl API → 确认数据存在 → 确认用户权限 → 确认 Grafana 侧配置。这个顺序的好处是每步都能得出明确结论不会在不同层之间反复跳。4. 查询面板里那几个特别容易搞混的概念数据源接上之后真正的门槛在查询编辑器里。Zabbix 插件提供了好几种查询模式用错了就是图能出来但怎么看怎么不对。4.1 查询模式怎么选模式匹配还是 Item ID插件支持的查询模式大致有这么几类用途差异很大查询模式匹配方式适合场景风险Metrics指标主机组 主机 item 名称模式支持正则变量化面板、批量主机item 改名后查询会失效Item ID精确 ID固定的核心指标面板迁移环境时 ID 会变需要重新指触发器 / 问题事件触发器状态与事件流画告警时间线、事件标注需要额外考虑权限和事件量文本类字符串型 item展示版本号、运行状态不能做数值聚合我的经验是变量化的通用面板用 Metrics 模式核心固定面板用 Item ID 模式。前者灵活后者稳定。最怕的是全用 Metrics 模式还写了很宽的正则主机一多就会匹配到一堆不相关的 item图上出现一堆莫名其妙的线。另外提醒一点item 名称模式匹配时优先匹配键值还是可见名称是有区别的不同插件版本的行为可能不一样。如果画出来的线数量不对先把查询返回的 item 列表拉出来核对一下比在图上猜快得多。4.2 历史和趋势这两个概念决定了你能看多久以前的数据这是最容易被忽略、也最容易让人困惑的一块。Zabbix 的数据分两层存储history 表存原始采集值精度高但占用大保留期通常只有几天到几周trends 表按小时做聚合保留期可以拉到一年以上代价是精度损失。这带来两个直接影响第一你查不到三个月前的秒级数据。这不是 Grafana 的问题是 Zabbix 那边 history 保留期到了就把数据清了。很多人第一次遇到这个会以为数据源坏了其实是正常的存储策略。要长期保留细粒度数据只能调 Zabbix 的 housekeeper 配置或者外接专门的时序存储。第二趋势数据只有数值型 item 才有。字符串型、日志型 item 是没有趋势表的所以拉长到过去 30 天去看这类指标图会直接断掉。这一点在设计面板的时候就要考虑到别把字符串指标放到带长时间范围选择器的大盘上。趋势数据的查询会用到专门的聚合函数比如取区间平均值、最大值、最小值、计数。想做过去一天的每小时峰值这种图就用最大值的趋势函数而不是让 Grafana 去对原始数据做聚合。前者走预聚合表快得多。4.3 多主机叠加和图例命名把二十台机器的同一条曲线画在一张图上如果图例全是默认的名称图基本没法看。这里的处理办法是用变量拿到当前选中的主机列表在查询里对主机做循环。图例模板里带上主机名比如用类似{{host}} - CPU的写法这样每条线一眼能对应到机器。开启 Multi-value 和 Include All 两个选项让变量支持多选和全选。排序上把变量值的排序方式设成按名称排序避免每次刷新曲线顺序都在变。还有个细节叠加图的主机数量建议控制在 8 到 12 条曲线以内。超过这个数量颜色区分度会急剧下降图例也开始堆叠实际可读性反而变差。真要对比几十台用统计类的面板或者分组的折线更合适。5. 把面板做成一块真正能用的值班大屏图表能出来只是第一步能不能在出问题的时候帮上忙取决于面板怎么设计。5.1 用三级变量把一张面板复用给所有业务我现在的做法是给资源类面板配三级变量业务组变量数据源查询类型选主机组把 Zabbix 里的主机组列出来。主机变量类型选主机并且用上一个变量做过滤只列出该组下的主机。指标变量类型选指标名称用前两个变量过滤。这样一张 CPU 面板可以覆盖所有业务组排查时先选业务、再选主机路径非常自然。变量之间的联动筛选是关键——如果主机变量不过滤列表里会出来几百台机器选起来很痛苦。变量值还可以加正则过滤。比如只想看带prod-前缀的主机就在变量的正则里限制一下。这个技巧在多环境混用一套 Zabbix 的时候特别有用。5.2 单位和阈值线这两个地方最容易画错单位问题我在好几个环境里都踩过字节和比特混用。网络设备上报的流量通常是比特每秒服务器网卡上报的通常是字节每秒两者差 8 倍。如果 Zabbix 里单位填错了Grafana 换算出来的数字就会离谱图上看着带宽跑满了实际才用了八分之一。百分比范围。有些 item 存的是 0 到 100有些存的是 0 到 1。Grafana 的百分比单位默认按 0 到 1 处理如果数据是 0 到 100 的整条线会跑到图表顶端看不见。单位后缀写法。单位写法不规范时Grafana 可能识别不出来导致显示成原始数字比如1073741824而不是1 GiB。阈值线的配置也有讲究。我一般设三级绿色是正常区间黄色是预警线红色是必须处理的线。颜色的使用要保持全局一致不要这块面板黄色代表预警、那块黄色代表严重值班的人会被绕晕。另外阈值线的位置要和 Zabbix 触发器的阈值对齐两边不一致是最要命的事情——图上看着正常告警却响了。5.3 大盘分层的排布思路我的大盘固定分四层从上往下按从概览到细节的顺序第一层是健康概览。放几个状态类面板用颜色块展示各业务组当前的整体状态一眼就能看出哪个业务红了。同时放几个最关键的数值比如核心接口的错误率、订单量。第二层是资源指标。CPU、内存、磁盘使用率、磁盘 IO、网络流量每个指标一张图全部支持变量切换。这一层是排查时用得最多的。第三层是业务与应用。中间件连接数、队列积压、接口响应时间这类。这里往往是多个数据源混排Zabbix 的指标和别的来源放在一起看。第四层是事件时间线。用触发器或问题事件的查询模式把告警事件按时间轴铺在底部。这一层最大的价值是当你看曲线突然上扬的时候能立刻知道同一时刻有没有告警、有没有发版。用 Row 把这些层折叠起来配合变量联动一块大屏就能同时服务值班扫一眼和深入排查两种场景。6. 告警到底该由谁发这件事要提前定这是我见过最多争议的地方也是很多团队做完 Grafana 大盘之后反而告警变乱的根源。6.1 职责划分Zabbix 判定Grafana 展示我的立场很明确告警的判定和通知继续由 Zabbix 负责Grafana 只负责看。理由不是偏好而是能力差异。Zabbix 的触发器支持依赖关系、多指标组合条件、恢复表达式、告警升级和抑制还能针对不同主机组走不同的通知渠道。Grafana 侧的告警本质上是对查询结果做阈值判断缺少触发器之间那种父触发器不告警时子触发器不通知的关系管理。真到了大故障的时候差的就是这些细节。实践中最省事的做法是在 Grafana 里用问题事件的查询模式做一个事件面板把 Zabbix 当前的问题列表和最近的事件流展示出来。这样你在看曲线的时候能同时看到告警状态但真正发通知的还是 Zabbix不会出现同一件事两个渠道各发一遍的情况。两套都发同样的告警后果很实际值班的人手机上会收到双份通知时间一长就会对通知麻木真正的严重告警反而被淹没。6.2 如果确实要用 Grafana 补一层告警有些场景下 Grafana 侧告警是有价值的比如跨主机的聚合判断——同一业务组里超过一半的主机磁盘使用率都超过阈值这种条件在 Zabbix 里写起来很别扭在 Grafana 里反而直观。如果要这么做我的建议是只作为补充不作为主通道。主通道永远是 Zabbix。明确命名。Grafana 侧发出来的告警在标题里带上前缀值班的人一看就知道来源不同。控制数量。Grafana 告警规则数量多了之后管理成本会快速上升能不建就不建。另外提一句网上经常把另一套监控体系的告警组件和 Grafana 的告警混着讲那是完全不同的两条链路。别看到别人在配某个告警转发组件就以为 Zabbix 也要照着配一遍方向搞错了会白折腾很久。7. 那些让我熬过夜的问题以及现在的维护节奏最后一节讲几个具体的坑都是实际发生过的不是从文档里抄的。7.1 插件升级之后面板集体失效这个坑我遇到过一次印象很深。Grafana 主版本升上去、插件也跟着升了一版结果一批老面板打开就报错提示和旧查询的升级有关甚至牵扯到找不到某个旧的数据源。根因有两层。一层是数据源的身份标识变了——面板的 JSON 里记录的是数据源的名字或者唯一标识如果你在迁移过程中改了数据源的名字或者删了重建了一个旧面板就找不到对应关系了。另一层是插件内部的数据模型发生了变化老版本的查询对象里缺少新版本的字段升级逻辑要去做转换转换失败就报错。处理办法我总结了几条数据源名字定下来就别改。换名字的成本远高于一开始想清楚的成本。面板迁移时用唯一标识而不是名字。现在的 Grafana 支持给数据源指定稳定的标识导入面板之后引用标识改名字也不会断。面板 JSON 定期备份。Dashboard 的 JSON 就是资产导出一份放到版本管理里。真出事了拿着 JSON 改一改就能恢复比在界面上一个个修快得多。升级前先在测试环境开一套。把插件和数据源配置在测试环境跑通再动生产。这一步花的时间通常比事后排查省得多。7.2 面板的复制和导入导出有几个细节要注意在界面上直接复制面板会带上原面板的数据源引用。如果目标环境里没有同名数据源面板就是空的。跨环境迁移的时候我一般用导出的方式导出时留意是否导出为外部共享这个选项的差异勾了它导出的是带变量占位的形式更适合跨环境分享不勾导出的是当前环境的完整引用。如果你们的环境用配置文件管理数据源那就更省事了。把数据源写成配置文件敏感信息单独放面板引用统一的名字或者标识迁移的时候基本不用改。这类配置长这样apiVersion: 1 datasources: - name: Zabbix type: alexanderzobnin-zabbix-datasource access: proxy url: http://zabbix.example.com/api_jsonrpc.php jsonData: username: grafana-readonly trends: true trendsFrom: 7d trendsRange: 4d cacheTTL: 1h secureJsonData: password: 在这里填凭据注意字段名和取值在不同插件版本之间可能有差异以你实际版本的文档为准。别直接照抄我的配置先对照自己版本的字段说明核一遍。7.3 长期维护清单面板这东西做出来只是开始能不能活过半年取决于有没有人管。我现在的维护节奏大致是这样每月扫一遍面板。把三个月没人看、或者数据源已经不存在的面板删掉。留着这些空面板只会让大盘越来越臃肿新来的人根本找不到重点。每季度核一次权限。确认 Grafana 侧用的那个只读账号还有效密码或者 Token 没过期需要展示的主机组没有遗漏。这个检查很有必要我遇到过因为账号密码轮换导致整个大盘静默失效的情况最坑的是它不报错只是所有图都不更新了。给每个面板加标签和责任人。标签用来分类和搜索责任人写在面板描述里。出问题的时候知道该找谁这件事的价值在关键时刻才体现出来。控制刷新间隔的总量。定期算一下大屏的刷新总频次如果 Zabbix 的查询压力上来了先把大屏的刷新间隔调长而不是急着优化 Zabbix 数据库。大屏电视机的显示参数要单独调。深色主题在电视上比浅色舒服字号要比桌面端大一档分辨率适配也要单独排一版。这个细节不难但没人做的话大屏永远是能用但看不清的状态。7.4 我现在对这套组合的理解折腾了这么久我对 Zabbix 加 Grafana 这套组合的认识其实一直在变。最开始我以为它是给 Zabbix 换个好看的皮后来发现真正的价值不在好看而在它逼着你去把监控指标理清楚。因为一旦要做变量化面板、要做多主机对比、要做图例命名你就必须回答这些问题主机组怎么分指标名字规范吗单位填对了吗哪些指标是核心、哪些只是参考这些问题在只用 Zabbix 自带图形的时候可以糊过去做大盘的时候糊不过去。所以我现在一般会在项目开始前先花半天时间把主机组和指标命名理一遍再动手画图。这半天时间看起来是没干活但它能让后面的面板返工率降一大截。踩过几次坑之后我才明白画图难的从来不是图本身而是图背后那套指标到底有没有被整理过。
