1. 先想清楚Zabbix 监控结合 Grafana 绘图到底解决的是哪一类问题「Zabbix 监控结合 Grafana 绘图」这套组合我在四种完全不同的环境里落地过一次是给一个二十来台服务器的内部业务系统做统一看板一次是给生产车间的几台边缘设备做运行状态展示还有两次是帮朋友把已经在跑的 Zabbix 数据重新画一遍。每次的需求说法都不一样有人说要大屏有人说领导要看图有人说Zabbix 的图太丑了但剥掉这些表层描述底下其实是同一个诉求数据已经在 Zabbix 里了采集、存储、阈值判断都跑得好好的唯独看这一层不满足要求。如果你手上已经有一台在跑的 Zabbix采集项也配得七七八八这篇东西就是写给这个阶段的你的。它不讲怎么从零装 Zabbix —— 那部分官方文档足够清楚它讲的是中间那段最容易被忽略的路Grafana 怎么接上 Zabbix、接上之后查询要怎么组织、面板怎么搭才不会被数据量拖垮、以及那一堆只有真正上线跑过才会遇到的报错。先把一句可能有点反直觉的话放前面Grafana 不存储任何监控数据它只是一层查询和渲染的前端。这意味着你不需要动 Zabbix 的采集体系不需要重新写 Agent 配置历史数据也是现成的。同样也意味着每一次面板刷新都会实实在在地在 Zabbix 那边产生一次 API 请求。这个特性决定了后面所有的架构选择和性能优化方向我会反复绕回这一点。1.1 Zabbix 自带图表到底差在哪值不值得折腾先别急着上 Grafana。我见过不少人吭哧吭哧折腾完最后发现 Zabbix 原生面板其实已经够用只是因为没摸到设置项。所以先把差距说清楚。Zabbix 的图表能力从 5.0 之后其实进步很大Dashboard 支持自定义布局、支持 widget、支持 Simple graph / Custom graph / Graph prototype。日常看一台机器的 CPU 内存它完全够。真正会逼着人往外走的通常是这几种情况。第一种是多主机横向对比。Zabbix 的 Custom graph 确实能加多个主机但前提是它们用的是同一个 item key而且图例挤在一起颜色区分度差。业务方想看五个 Web 节点谁的 CPU 最高在 Zabbix 里做出来的图基本没法一眼看出结论。Grafana 里用一条查询把/Web Servers/组下所有主机的system.cpu.util拉出来图例里用{{host}}模板变量颜色自动分配一眼就能看出异常节点。第二种是跨主机的聚合计算。比如所有数据库节点的连接数总和这个集群的平均响应时间。Zabbix 做这类计算要么建聚合监控项用 Zabbix 自己的 aggregate item要么用计算型 item配置链路长改起来也麻烦。Grafana 里同样是查询语句里加一个聚合函数的事。第三种是大屏和分享。Zabbix 前端是个带完整登录态的应用想把它嵌到别的页面里或者挂在墙上的电视上要么开放匿名访问有权限风险要么维护一个常驻登录的浏览器。Grafana 天生就是为这个场景设计的kiosk 模式、自动轮播 Playlist、只读 Viewer 账号、公开快照链接一套都齐。第四种是图的美观度和信息密度。这个不用解释把两者的截图并排放一下就明白了。但反过来也要说清楚Zabbix 在告警侧的能力Grafana 短期内替代不了。触发器的依赖关系、事件抑制、维护窗口、确认与关闭流程、升级escalation、自动发现生成的触发器原型这套东西是 Zabbix 的核心资产。我在所有落地项目里都没有把告警搬到 Grafana 去Grafana 只负责看。这条分界线划清楚后面能省掉一大堆麻烦。1.2 三条技术路线我为什么最终选了直连把 Zabbix 的数据画进 Grafana业内主要有三条路我做个对照。路线数据流向优点代价A. Grafana 直连 Zabbix 数据源Grafana → Zabbix API → Zabbix DB改动最小历史数据直接复用无需二次存储每次刷新都打 API压力落在 Zabbix Web 前端B. 数据双写时序库Agent/Exporter → Prometheus 或 VictoriaMetrics → Grafana查询快支持 Grafana 统一告警要维护第二套采集与存储Zabbix 的触发器语义丢失C. 只把问题状态导出去Zabbix API → 社区导出器 → 时序库 → Grafana能把 Zabbix 的告警送进 Grafana 告警链路只能拿到问题级别拿不到原始指标我绝大多数场景选的是 A。理由很务实已有的采集配置不用动已有的历史数据不用迁移改造成本几乎为零。对于已经有一台跑了两年的 Zabbix现在想把图做好看这种最常见的情况A 是唯一性价比合理的答案。B 适合从零开始建监控体系、且团队本来就熟悉 Prometheus 生态的团队但你得接受双份存储成本以及Zabbix 里看不到的东西 Grafana 里也看不到这个事实。C 这条路值得单独提一句因为它解决的是一个特定痛点有些团队告警通知链路已经统一到 Grafana 那一侧了但指标还在 Zabbix 里这时候用导出器把 Zabbix 的问题状态转成时序指标是一条成本可控的桥。注意它导出的是问题的状态不是原始监控值别指望用它画 CPU 曲线。选 A 之后压力模型就变成了这样一个面板 一次或多次 API 调用一次 Dashboard 刷新 所有面板的 API 调用总和。这个数字算出来会很吓人我在第 5 章专门展开。2. 动手之前两侧都要做哪些看不见的准备很多人卡在数据源添加那一步回头看其实问题根本不在 Grafana而在 Zabbix 侧的权限、网络或者前端进程。这一章把前置项捋一遍能省掉你至少半天的排查时间。2.1 Zabbix 侧账号、权限和 API 入口第一件事是别用 Admin 账号。我知道图省事的时候大家都这么干但这会带来两个问题一是权限过大Grafana 侧一旦配置泄漏等于把整个 Zabbix 交出去了二是排查问题时你分不清这个主机没数据是采集问题还是权限问题因为 Admin 能看到所有东西。正确做法是建一个专用用户加到一个专用的用户组里然后用角色Zabbix 5.2 之后有角色这个概念把它限制成只读。具体权限上需要这几项对应主机组的读权限、能读监控项和历史数据、能读问题与事件。如果你要在 Grafana 里画 IT services 或者 SLA 面板还得额外开对应的读权限。Zabbix 5.4 之后我强烈建议用API 令牌而不是用户名密码。在用户设置的 API tokens 页面生成一个插件里的认证方式选 Token把这个串填进去。好处有两个一是密码轮换不会把大屏搞挂二是令牌可以单独设定有效期和单独吊销。注意令牌是有过期时间的我踩过一次坑——设了 90 天有效期三个月后某个周一早上所有大屏集体空白排查了四十分钟才想起来。现在我的做法是把过期时间设成一年然后在日历上提前两周提醒自己换。第二件事是确认 API 入口通不通。Zabbix Web 的 API 端点在部署目录下的api_jsonrpc.php源码包部署通常是http://your-zabbix/zabbix/api_jsonrpc.php包管理安装也类似。先用 curl 确认一下这比在 Grafana 界面里反复试要快得多# 只查版本不需要认证用来确认网络和路径都对 curl -s -X POST http://10.0.0.10/zabbix/api_jsonrpc.php \ -H Content-Type: application/json-rpc \ -d {jsonrpc:2.0,method:apiinfo.version,params:{},id:1} # 返回类似 {jsonrpc:2.0,result:6.0.19,id:1} 就说明端点没问题如果这一步返回的是 HTML 页面、404 或者 502那跟 Grafana 一点关系都没有先解决路径、反向代理和 PHP 的问题。我遇到过最典型的一次是 Nginx 反代把/zabbix/路径重写掉了浏览器访问前端正常但 API 路径被 rewrite 规则吃掉返回的是前端首页的 HTML。第三件事也是最容易被忽略的一件Zabbix Web 前端是靠 PHP-FPM 跑的而 Grafana 的所有查询都会消耗 PHP-FPM 的工作进程。这一条我在第 5 章会重点讲但准备阶段就得有意识。提示如果你的 Zabbix 用 Nginx PHP-FPM 部署去看一眼pm.max_children的值。默认值往往只有个位数而这个数字直接决定了同时能处理几个 API 请求。2.2 Grafana 侧插件安装与版本对齐Grafana 本身用什么方式装都行容器和包安装我都用过。关键在那个 Zabbix 数据源插件。插件 ID 是alexanderzobnin-zabbix-app这是社区里维护最久、用得最广的一个。容器方式最省事直接在环境变量里带插件docker run -d \ --name grafana \ --restart always \ -p 3000:3000 \ -v /data/grafana:/var/lib/grafana \ -e GF_INSTALL_PLUGINSalexanderzobnin-zabbix-app \ grafana/grafana-oss:11.1.0这里有个坑要点名容器的插件安装是发生在启动时的如果你的环境访问外网受限容器会卡在installing plugin然后超时启动失败。稳妥做法是在一台能联网的机器上把插件包下下来解压后放到宿主机挂载目录/data/grafana/plugins/下然后启动时不带GF_INSTALL_PLUGINS参数。注意目录属主容器里的 grafana 用户 UID 通常是 472chown -R 472:472一下否则插件会因为权限问题加载失败日志里报的错还很含糊。包安装的机器上用命令行装也行grafana-cli plugins install alexanderzobnin-zabbix-app systemctl restart grafana-server版本对齐这件事一定要做。我整理过一份自己在用的对应关系但请以插件 release notes 为准因为版本迭代很快GrafanaZabbix 插件Zabbix Server备注8.x4.x5.0 / 5.4 LTS老环境功能基本够用9.x / 10.x4.2 及以上5.0 / 6.0 LTS兼容性最好的一段区间10.x / 11.x5.x6.0 / 6.4 / 7.0建议新环境直接用这组实话说这套组合的兼容性出奇地好我试过用比较新的插件去连 5.0 的老 Zabbix绝大部分查询类型都能正常工作只有个别接口层面的差异会报错。但如果你准备上 Zabbix 7.0就老老实实把插件升到 5.x别省这一步。2.3 那些不起眼但会咬人的基础项时间同步。这条我必须单独说。Zabbix 存的是时间戳Grafana 拿时间戳按自己的时区设置渲染。两台机器时间不同步的话你会看到图表上的数据和 Zabbix 前端对不上甚至出现未来时间的数据。排查半天最后发现是某台机器 NTP 挂了这种经历我至少有过两次。上线前chronyc sources或者ntpq -p看一眼两边的偏移量都在毫秒级才放心。时区设置。Grafana 的组织设置里可以指定默认时区也可以跟随浏览器。团队跨时区的话建议在组织级别固定成业务所在地的时区否则每个人看到的大屏时间轴都不一样讨论问题时容易各说各话。反向代理下的路径。如果 Grafana 部署在子路径比如https://ops.example.com/grafana/必须同时配好root_url和serve_from_sub_path否则前端静态资源能加载但插件的数据源请求会 404。这个坑在容器部署里尤其常见因为很多人习惯只改端口不改路径。字符编码。Zabbix 里的主机名、监控项名称如果带中文或空格在 Grafana 的查询里做精确匹配会出问题。我的建议是给需要画图的主机统一用英文短名或者干脆用正则去匹配。这条下面还会再提。3. 实操把 Zabbix 的数据真正画到 Grafana 上准备做完正式开工。这一章是全文最长的部分我会按添加数据源 → 理解查询模型 → 搭建具体面板 → 用变量做复用的顺序走一遍每一步都标出我当时踩的坑。3.1 添加数据源并验证连通性进 Grafana 的 Connections → Data sources → Add data source搜 Zabbix 选上。需要填的核心字段就这么几个。URL 这一项填的是 API 端点。如果你的 Zabbix 前端在根路径下填http://10.0.0.10/api_jsonrpc.php如果在/zabbix子路径下就填http://10.0.0.10/zabbix/api_jsonrpc.php。注意这里是 HTTP 还是 HTTPS 要跟实际部署一致如果前面挂了 HTTPS 的反代填 HTTP 的地址有时候也能通因为反代会转发但一旦反代配了强制跳转就会失败。认证方式选 API token 或者用户名密码前面已经说过选哪个。另外有个选项是是否开启趋势数据Trends这个先保持默认第 5 章再调。填完点 Save test。这一步成功不代表后面就一帆风顺它只是验证了 API 端点和认证没问题。真正的坑在后面查询的时候才暴露比如连接成功但查不到数据往往是权限问题比如能查到主机但查不到某个监控项往往是 item 名称匹配问题。注意如果 Save test 报的是Cannot connect to Zabbix API这类信息八成是网络或路径问题报Invalid params或者认证失败相关的内容八成是账号权限或令牌问题。这两类问题的排查方向完全不同别混在一起查。3.2 搞懂查询模型Group → Host → Item 的三级结构这个数据源的查询逻辑跟 Zabbix 本身的组织方式是映射的理解了映射关系写查询就是顺理成章的事。第一级是主机组Group。填组名或者用/正则/匹配或者*表示全部。这里有个坑Zabbix 的主机组名支持嵌套/父组/子组而 Grafana 这边填的时候要用完整路径只填空组名可能匹配不到。第二级是主机Host。支持精确主机名、*通配、/正则/也支持引用变量$host。多选变量会展开成多个主机这是做横向对比对比图的基础。第三级是监控项Item。这一级最考验功力。你可以填精确的 item key比如system.cpu.util[,idle]也可以填/vfs.fs.size/这样的正则把所有匹配的项一次性拉出来。用正则的时候图例模板变量一定要配上否则几十条曲线叠在一起谁是谁都看不出来。除了这三级的 Metrics 查询插件还提供几类别的查询类型我把常用的列一下查询类型能拿到什么典型用途Metrics监控项的历史数据与趋势数据画 CPU、内存、磁盘、网络曲线Text文本型监控项的最新值展示版本号、运行状态文本Triggers / Problems触发器与当前问题列表值班看板上的告警墙Item value单个监控项的即时值Stat 面板的数字大屏Services / SLAIT 服务与可用性数据业务视角的可用性报表需要先在 Zabbix 里配好服务树写查询的时候有一个心态上的调整不要用我要看什么的思路而是用Zabbix 里存了什么的思路。Grafana 不能凭空造出 Zabbix 里没有的数据。你想画某个指标先确认它在 Zabbix 里有一个对应的监控项而且这个监控项的历史数据保留期覆盖你要看的时间范围。我有一次想看三个月前的磁盘趋势图是空的查了半天才发现那个 item 的历史数据保留期只有 7 天早被清理了。3.3 五个高频面板的具体搭法下面这几个面板是我每个项目都会搭的直接给配置要点和背后的理由。CPU 使用率。最省事的办法是用 Zabbix 内置模板里已经算好的 CPU utilization 项它的 key 一般是system.cpu.util直接返回百分比。如果你想自己算就用/system.cpu.util/正则把 user、system、iowait、idle 都拉出来然后在 Grafana 侧处理。这里有个细节值得说idle 的展示习惯。很多人直接把 idle 画上去看图的人得自己脑补100 减这个值才是使用率。更好的做法是画 user system iowait 的堆叠面积图剩余部分自然就是 idle一眼就能看懂。单位设置成percent。内存使用率。用vm.memory.size[pavailable]这个 item 直接拿可用内存百分比然后用 Transform 里的计算功能做一次100 - x。或者更直接一点用/vm.memory.utilization/或者 Zabbix 内置模板里的内存使用率计算项。内存图我习惯做成已用 缓存 可用的堆叠而不是单条使用率曲线。原因是排查内存问题时单看使用率看不出是应用真占用了还是被页缓存占着堆叠图信息量更大。磁盘使用率。用/vfs.fs.size\[.*,pfree\]/这个正则把所有挂载点的剩余百分比拉出来。图例模板用{{item}}它会带上挂载点信息。这里的关键是别把/dev/shm、/run这类临时挂载点也画进去噪音太大。可以在 Grafana 的 Transform 里用 Filter data by value或者干脆在 Zabbix 侧的自动发现过滤器里就把它们排除掉。网络流量。这个坑最深单独展开。Zabbix 的net.if.in[{#IFNAME}]和net.if.out[{#IFNAME}]返回的是累计字节数是一个单调递增的计数器。你直接把它画出来得到的是一条一直往上走的斜线毫无意义。必须转成速率。有两种转法。一是在 Zabbix 侧加预处理给这个 item 加一个每秒变化量Change per second的预处理步骤生成一个派生 item返回的就是字节/秒。这是我最推荐的因为一次配好所有用这个数据的地方都受益而且 Grafana 侧不用做任何计算。二是在 Grafana 侧做。Transform 里有计算字段的功能但用两个字段做逐点差值比较复杂而且每次刷新都要在浏览器里算一遍面板一多就卡。实测下来方式一比方式二稳定得多。还有一个单位换算的坑运营商和安全团队说的带宽通常是以比特为单位的bps而 Zabbix 存的是字节Bytes。换算要乘以 8。Grafana 的单位里有bits/secSI 单位制和bytes/sec选错了数字会差 8 倍。我就遇到过运维拿着 Grafana 的图跟网络组吵架说带宽跑满了结果发现单位选成了 bytes实际只用了带宽的八分之一。触发器与问题面板。查询类型选 Triggers出来的是一张表。字段包括主机、问题名称、严重级别、开始时间、持续时间。严重级别映射成颜色从信息到灾难做一套配色值班看板的效果就出来了。这个面板有个隐藏好处它跟 Zabbix 前端的问题是同一份数据不会出现两个系统告警不一致的问题。3.4 用变量把面板做成一套顶十套如果每个主机都建一套面板那你迟早会被维护成本压垮。变量Variables是解决这个问题的核心手段。在 Dashboard settings → Variables 里新建一个变量类型选 Query数据源选 Zabbix然后选查询类型。常用的有主机组变量、主机变量、监控项变量三类。主机组变量这样配查询类型选 Group填一个能覆盖你要用到的组比如/.*/或者/生产环境.*/。主机变量依赖组变量在查询里把组设成$group这样选不同的组主机列表会自动跟着变。监控项变量再依赖主机变量查询里 references$host。{ queryType: item, group: $group, host: $host, item: /system.cpu.util/ }然后在面板的查询里主机字段填$host监控项字段填$item。这个面板就变成了一个模板。几个实操要点多选和全选。变量设置里勾上 Multi-value 和 Include All。多选之后插件会把多个值展开成多个查询效果就是横向对比图。但要注意每多一个主机API 请求数量就翻一倍全选一个五十台机器的组一个面板就是五十次 API 调用刷新一下能把 Zabbix 打懵。所以 Include All 这个选项我通常只在小规模组上开。正则过滤。变量里可以用正则做二次过滤比如主机变量里填/web-node-\d/只保留 Web 节点的名字把组里其他主机排除掉。这在组划分不那么严格的环境里特别有用。变量的依赖顺序。变量在列表里的顺序决定了它们的联动关系被依赖的必须排在前面。有一次我调整变量顺序把主机变量拖到了组变量前面结果主机下拉框永远是空的找了好久才发现是顺序问题。一套好用的变量配好之后常见的效果是面板数量从四十个降到八个新增一批主机只需要把它们加进 Zabbix 的主机组Grafana 这边什么都不用改。这个收益值回配置的那一个小时。4. 告警链路Grafana 和 Zabbix 各自该管什么可视化做完下一个问题必然是告警。我见过最多的做法是把两边的告警都打开结果是同一件事收到两条通知时间一长所有人都开始忽略告警 —— 这是监控体系最危险的失效方式。所以这一章的核心结论先给出来告警留在 ZabbixGrafana 只做展示和问题呈现。4.1 为什么不建议把告警搬到 GrafanaGrafana 自己有告警引擎功能也不弱。但用它来取代 Zabbix 的告警有几个绕不过去的问题。第一是依赖和抑制关系丢失。Zabbix 的触发器可以配依赖上游交换机断了下面几十台机器的不可达告警会被自动抑制只发一条根因告警。这套关系在 Grafana 里要重新建一遍而且建不出来 Zabbix 那种基于主机和触发器的层级关系。第二是Zabbix 数据源做告警评估有先天限制。这个数据源的查询很多是在浏览器侧发起的而 Grafana 的告警评估跑在服务端两者对不上。实际表现就是你能在面板上看到曲线但告警规则那边拿不到数据。这不是配置问题是架构问题。第三是维护窗口和确认流程。Zabbix 里一个维护窗口下去相关的告警全部静默。Grafana 侧要做到同样效果得再维护一套静默规则两边不同步就成了新的故障源。所以我的分工原则是Zabbix 负责什么时候该叫人Grafana 负责人来了之后看到什么。4.2 在 Grafana 面板上叠加 Zabbix 的问题信息虽然告警不搬但 Grafana 里能看到的 Zabbix 问题信息非常有用尤其是排查的时候。最直接的做法就是 3.3 里说的那个问题表格面板放在看板的第一屏。值班的同事一眼扫过去就知道现在有几条未恢复的问题严重级别是什么。进阶一点的做法是用标注Annotations。某些版本的插件支持把 Zabbix 的事件作为标注叠加在时间序列图上。这样你看到 CPU 曲线在 14:23 突刺的时候图上就标着14:22 触发 CPU 负载过高因果关系统一在一个画面里不用在两个系统之间来回切。这个功能我强烈建议配上它的价值在于把看到现象和看到事件这一步压缩到零。再进阶就是给图加阈值线。Grafana 的时间序列面板支持设置阈值把 Zabbix 触发器里的阈值同步过来画成虚线。看图的人不需要知道触发器逻辑看到曲线穿过虚线就知道要出事。这里要注意阈值的一致性改 Zabbix 触发器的时候别忘了改 Grafana 的阈值线否则会出现图上是绿的但告警已经响了的尴尬情况。4.3 和办公协作工具联动的正确姿势Zabbix 7.0 之后通知媒介的配置比老版本顺手了很多用 Webhook 类型往常用的办公协作工具推消息是主流做法。这块我的经验是消息内容的结构比消息本身重要。一条好的告警消息应该包含这几段主机名和所属业务、问题名称、当前值、持续时间、以及一个能点回去看图的链接。最后这一条最容易被忽略也最有价值——在消息里直接贴上 Grafana 对应面板的链接最好是带上主机和时间范围的链接收到消息的人点一下就能看到当时的曲线而不是先打开 Zabbix 再翻半天。Grafana 的面板链接可以带参数把时间范围和变量值都固化进去。这个技巧用熟了之后排查效率的提升非常明显因为所有人看的是同一张图、同一个时间窗讨论的时候不会出现我这边看是正常的这种对话。5. 性能、稳定性与故障排查实录这套东西搭起来不难扛住量才是真功夫。这一章是我踩坑最多的地方也是我认为最值得反复读的部分。5.1 先把压力模型算清楚前面反复提到每次刷新都打 API现在把账算具体。假设你有一个 20 个面板的看板每个面板平均 2 条查询比如 CPU 和内存刷新间隔设成 30 秒。那么单次刷新 40 次 API 调用每分钟 80 次如果同时有 5 个人在看值班室的大屏 几个工位每分钟 400 次。这 400 次请求全部落到 Zabbix Web 前端的 PHP-FPM 上。一次 API 请求处理时间按 50 毫秒算400 次就是 20 秒的 CPU 时间平均到每分钟意味着至少需要 1 个 PHP-FPM 进程一直在满负荷跑。如果数据库那侧history表查询慢一点单次涨到 200 毫秒就需要 4 个进程常驻。而默认配置的pm.max_children很可能只有 5 到 10 个。结果就是Grafana 的大屏一开Zabbix 前端就变慢运维打开 Zabbix 页面转圈圈然后就有人来找你。我在一个真实环境里遇到过这个场景最后发现 php-fpm 的子进程全部被 Grafana 的查询占满Zabbix 前端的正常使用完全被挤掉了。解决思路有四条按性价比排序第一条把刷新间隔调大。从 30 秒改成 1 分钟压力直接减半。绝大多数看板根本不需要 30 秒的刷新频率业务指标看 5 分钟粒度完全够。别为了感觉实时付出一倍的资源。第二条开趋势数据。Zabbix 会为数值型监控项维护一份按小时聚合的趋势数据数据量比原始历史数据小一两个数量级。在数据源配置或查询选项里开启使用趋势后查询时间范围超过一定长度时会自动走趋势表速度提升非常明显。代价是精度降到小时级看长期趋势没问题看秒级毛刺就不行了。我的做法是给不同的看板配不同的策略值班看板走历史数据保精度周报月报看板走趋势数据保速度。第三条给 Grafana 单独一套 Web 前端。这是个有点重但很有效的办法再部署一个 Zabbix Web 前端实例连同一个数据库专门给 Grafana 调用 API 用跟人用的那套物理隔离。要注意的是多个 Web 前端连同一个数据库时版本必须完全一致升级的时候要一起升。这个方案适合 Grafana 用量大、又不想让人机互相影响的环境。第四条开数据源缓存。插件本身有缓存相关的选项Grafana 较新版本也支持后端数据源的查询缓存。开启后相同的查询在缓存有效期内直接返回结果不再打 Zabbix。这对多人同时看同一块大屏的场景效果很好。代价是数据会有延迟缓存时间设置要权衡。还有一个从数据库角度看的点Zabbix 的history系列表是按天分区的跨天的查询天然要扫多个分区。你让 Grafana 去查一个跨三个月的时间范围哪怕只有一台主机数据库那边也会很吃力。面板的时间范围默认值设成 6 小时或者 24 小时不要一上来就设成 30 天。5.2 常见问题速查表下面这张表是我这几年攒下来的遇到问题先在这里对一遍。现象大概率原因处理方向Zabbix 页面顶部提示 Zabbix server is not runningZabbix Server 进程未运行或前端连不上 Server这条跟 Grafana 无关检查 Server 进程状态、10051 端口、以及数据库里的服务心跳记录Grafana 报 legacy queries datasource xxx was not found面板 JSON 里引用的数据源 UID 在当前环境不存在给数据源固定 UID或重新在面板里选一次数据源老面板要逐个修数据源保存时报连接失败URL 路径错误、反向代理重写、防火墙用 curl 直接打 api_jsonrpc.php 验证别在界面里猜数据源保存时报认证类错误账号密码错、账号被禁用、认证方式选错、令牌过期确认认证方式与凭据类型匹配令牌要看有效期查询能通但图表全空监控项没有历史数据、时间范围无数据、监控项类型是文本先去 Zabbix 前端确认这个 item 在同一时间段有没有数据图表出现规则的台阶状走了趋势数据精度降到小时级关掉趋势或缩短时间范围看板按用途区分策略时间轴和数据对不上两侧服务器时间不同步检查 NTP 状态两台机器偏移量都要在毫秒级主机下拉框是空的权限不足、组名写错、正则写错用同一个账号去 Zabbix 前端确认能看到哪些主机面板打开极慢查询时间范围过大、面板数过多、开了 Include All缩短默认时间范围、减少面板数、关掉全选大屏打开后 Zabbix 前端变慢PHP-FPM 子进程被占满调大刷新间隔、开缓存、单独部署 API 用的前端某些主机拿不到数据该主机走的是代理上报代理缓冲区还没提交检查代理状态和缓冲区积压情况主机名带中文或空格导致查询失败名称匹配问题改用正则匹配或规范主机命名这张表里我想重点说两个。第一个是Zabbix server is not running。这条提示其实是 Zabbix 自己的前端报出来的跟 Grafana 半毛钱关系没有。但因为很多人是在折腾 Grafana 的过程中第一次注意到它就误以为是 Grafana 搞坏了 Zabbix。实际原因通常是 Zabbix Server 进程挂了、前端连不上 Server 的监听端口、或者数据库里的服务心跳记录过期了。排查顺序是先看 Server 进程在不在再看前端到 Server 的网络最后查数据库。第二个是legacy queries datasource was not found。这个报错的意思是面板 JSON 里记录的数据源标识UID在当前 Grafana 里找不到。典型触发场景是把面板从一个环境导到另一个环境、或者数据源被删了重建。根治办法是给数据源手动指定一个固定的 UID这样不管怎么迁移面板里的引用都能对上。在数据源配置的 JSON 视图里能看到并修改 UID这一步做了之后面板导出导入的痛苦能减少八成。5.3 备份、迁移与升级的操作顺序看板搭到几十个之后它就成了资产得按资产来管理。备份有三层。最基础的是 Grafana 的数据目录里面那个 SQLite 数据库文件如果是默认配置装了所有看板。第二层是把重要的看板导出成 JSON 存到版本控制里这样你能看到改动历史也能做 code review。第三层是用 Grafana 的 provisioning 功能把数据源和看板定义写成 YAML 文件启动时自动加载。# /etc/grafana/provisioning/datasources/zabbix.yaml apiVersion: 1 datasources: - name: Zabbix type: alexanderzobnin-zabbix-datasource uid: zabbix-main access: proxy url: http://10.0.0.10/zabbix/api_jsonrpc.php jsonData: authType: accesstoken secureJsonData: accessToken: ${ZABBIX_API_TOKEN}这份配置的关键是那个uid固定下来所有看板引用它迁移的时候不会出问题。令牌从环境变量读不要明文写进文件。升级的顺序也有讲究。我的做法是先备份 Grafana 数据目录和所有看板 JSON然后升级插件最后验证各个查询类型是否正常。Zabbix 侧升级的话因为涉及数据库 schema 变更要单独安排窗口并且注意多前端版本必须一致这条约束。插件大版本升级后老看板偶尔会出现查询需要迁移的提示这就是前面说的 legacy queries 问题逐个面板重新选一次数据源就能解决。6. 几个只有真跑过才知道的细节写到这里主体内容差不多了。最后分享几个零碎但实用的经验都是文档里不会写、但实际用起来能省事的。图例模板变量一定要用。用正则拉多个监控项的时候如果不配图例模板出来的就是item12345这种没有意义的字符串。配上{{host}} - {{item}}之后图例直接可读。这个配置在时间序列面板的 Legend 设置里选 Custom 模式填模板。单位设置比你想的重要。Grafana 的单位选项极其丰富从bytes到bits/sec到percentunit到自定义后缀。用对了Y 轴自动按 K/M/G 缩放不用自己算用错了看图和别人讨论的时候就得反复确认量级。网络类面板建议统一用bits/sec因为大多数网络设备的口径就是这个。给看板加说明文字。Grafana 面板支持加描述鼠标悬停在标题旁边的小图标上会显示。我习惯把这个指标的正常范围是多少看到异常该找谁写进去。看起来是小事但值班的同事换了一批又一批这些说明能省掉大量重复解释。大屏用 kiosk 模式。在 URL 后面加上?kiosk就能隐藏所有导航栏只留面板内容挂电视上效果干净很多。配合 Playlist 功能做多页轮播再把浏览器设成全屏和自动登录一套看板墙就成了。这里注意给大屏用一个专门的只读账号权限收窄到只能看。别在 Grafana 里做太重的聚合。插件的聚合函数用起来很方便但它是把数据拉到浏览器侧再算的。数据点一多浏览器内存和 CPU 都会吃紧表现就是面板转圈很久然后卡住。重聚合尽量放到 Zabbix 侧用计算型监控项做Grafana 只负责画。定期清理没人看的看板。这条听起来像管理建议但它是实打实的性能优化。每个看板都在消耗 API 配额和数据库查询那些建完就没人打开过的看板删掉之后 Zabbix 侧的压力会明显下降。我每个季度会看一眼看板列表把过去三个月没人访问的清一遍。我个人在实际操作中的体会是Zabbix 加 Grafana 这套组合最大的价值不在于图好看而在于它让发现异常到定位原因之间的路径变短了。以前是收到告警、打开 Zabbix、找到主机、找监控项、看图表、对比其他主机一顿操作下来五分钟过去了现在是一个看板上同时有曲线、有问题列表、有关联主机扫一眼就够。这个效率差距在凌晨三点被叫起来处理故障的时候感受特别明显。所以这套东西值得花时间打磨而且打磨的方向应该是少而精——八个精心设计的、带变量和链接的面板比八十个随手拉出来的面板有用得多。