你有没有遇到过这种场景：Zabbix 里监控项堆了一大堆，主机列表密密麻麻，可每次想给老板展示一下业务系统的健康度，或者排查一次跨多台主机的性能问题，都得在原生的图形界面里反复切换、翻页、等加载。我当初搞了大概两周，实在受不了那套图形交互，转头把 Grafana 接了进去，用 Grafana 的插件连上 Zabbix API，把散落在各主机的数据全部做成统一仪表盘，那一瞬间整个监控体验完全不一样了。这篇文章就把我的完整踩坑过程、插件安装方法、数据源配置细节和面板搭建技巧整理出来，希望给对“Grafana 做可视化 + Zabbix 做采集存储”这种组合感兴趣的同行省点时间。
本文适合两类人：一类是已经在用 Zabbix，想把 Grafana 当作统一展示层的运维或 SRE；另一类是刚接触监控体系，想在 Prometheus 之外多掌握一条监控展示链路的初学者。整个方案的技术门槛不高，核心就三步——装插件、配数据源、拉面板，但每一步都有不少容易忽略的细节，我会按实操顺序逐一展开，顺带把我在生产环境里真实遇到过的坑标注出来。
1. 为什么非要用 Grafana 去接 Zabbix
1.1 Zabbix 原生界面到底差在哪
Zabbix 的采集和告警能力其实很强，但它最大的问题是“数据展示”太老派。原生界面的图表虽然能用，但有几个极其明显的痛点：第一，很难在同一张图上对比不同主机甚至不同监控项的指标，遇到一次内存泄漏排查，我得同时开好几个标签页反复横跳；第二，Graph 样式和交互都停留在十年前的水准，缩放、点选、悬停提示这些操作都很生硬；第三，也是我最有感触的一点，当你想做一个“面向业务”的大屏 —— 比如按用户分区展示所有核心服务的可用性时，Zabbix 原生界面几乎没有组合编排的能力，你只能在“主机”和“监控项”的维度里被牵着走。
1.2 Grafana 切入后到底解决了什么问题
Grafana 的强项就在展示层：它不关心数据从哪来，而是把各种数据源（Zabbix、Prometheus、MySQL、Elasticsearch 等）统一抽象为面板、仪表盘、变量的概念。接入 Zabbix 之后，你可以在同一个 Dashboard 里把 Zabbix 的 CPU、内存、网络、磁盘数据，和 Prometheus 里的业务指标放在同一张大屏上展示，甚至还可以在 Grafana 层面做跨数据源的组合计算、阈值标注、告警规则。这种“采集保留在 Zabbix，展示统一到 Grafana”的架构，在很多企业里已经被验证过了。
用 Grafana 接 Zabbix 还有一个非常大的隐性优势：统一用户访问入口。公司里不同的团队可能已经在用 Grafana 看各种数据，如果再给监控单独开一个 Zabbix 地址，大家记地址、记账号、记权限都是一种成本。所有可视化都收敛到 Grafana 之后，登录一个平台就能看到全貌，配合 Grafana 自带的组织和权限管理，按团队分 Dashboard 也很灵活。
1.3 官方插件与第三方插件怎么选
在 Grafana 社区里，Zabbix 数据源插件最被广泛使用的是alexanderzobnin/zabbix-app，也就是 Alexander Zobnin 维护的开源插件。它是一个非官方的社区项目，但质量非常高，支持 Zabbix API 的绝大多数能力，包括分组、主机、监控项、触发器、历史趋势数据，还可以直接在 Grafana 里用 Zabbix 模板和变量。这个插件在 Grafana 插件市场里可以搜到，安装非常方便，我在 8.x、9.x、10.x 版本的 Grafana 上都实测过，兼容性整体很好。
相比之下，Zabbix 官方虽然也提供了一些集成方案，但受限于开发节奏和定位，在 Grafana 社区生态中反而不如这个社区插件知名度高。所以我的建议是：直接用alexanderzobnin-zabbix-app，别自己从零写数据源。这个插件更新频率不低，社区活跃，遇到问题也能在 GitHub 的 issue 区找到类似案例。
2. 动手前的环境准备与版本确认
2.1 环境清单和版本兼容性经验
我在实际操作中遇到过“Grafana 插件装了但启用不了”的情况，最后发现是版本兼容性踩了坑。这里先给出一份我当时使用的环境版本，作为一个安全组合参考：
- Grafana：9.5.x（后来升级到 10.2.x 也没有问题）
- Zabbix：6.0 LTS（API 路径是
http://zabbix-server/api_jsonrpc.php） - 插件：
alexanderzobnin-zabbix-app4.x（4.2 及以上版本对 Grafana 9/10 支持较好）
如果你还在用 Zabbix 5.x，或者 Grafana 还在 8.x，建议先查一下插件对应版本的 release note。核心原则是：Zabbix 端的 API 接口路径和认证方式决定了插件能不能连通；Grafana 端的插件版本决定了面板和查询功能是否完整。如果两端版本都太老，建议先把 Zabbix 升级到 6.x LTS，再考虑 Grafana 侧的接入，这样整体省心很多。
2.2 在 Zabbix 里创建专用 API 用户
这一步很多人会忽略，但我觉得非常关键。接入 Grafana 时，插件本质上是通过 Zabbix API 去拉数据的，也就是说它需要一个能调用 API 的 Zabbix 账号。虽然直接用 Admin 账号也能连通，但生产环境里不建议这么干，原因一是安全，二是权限太粗。我的做法是在 Zabbix 前端里创建一个专用用户，比如叫grafana_svc，角色只给“用户”或自定义的只读权限，要读哪些主机、哪些监控项就开哪些权限。
具体路径是：Zabbix Web 界面 -> Users -> Create user，填写用户名、密码，然后在 Permissions 标签里配置权限。比如我只让这个账号读取 “Service Hosts” 这一个主机组的数据，那在权限配置里就只给这个组分配读权限。这样可以防止 Grafana 侧被攻破后，攻击者能通过 API 看到全部基础设施数据。
2.3 在 Zabbix 6.0 里用 Token 认证替代密码认证
如果你用的是 Zabbix 6.0 或以上版本，我强烈建议在用户里生成一个 API Token 来代替密码认证。原因是：密码认证在每次请求里都要传明文，而 Token 可以单独吊销、更新，安全性高一个档次。在 Zabbix 用户详情页的 “API tokens” 标签页里，点 “Add API token”，选择用户、设置有效期，生成后复制保存好，后面配置 Grafana 数据源时要用到。
我之前在 6.0 上用密码认证时，遇到过 Zabbix 密码策略强制 90 天改密的问题，改完密码之后 Grafana 数据源就挂了。后面换成 Token，彻底免除这种周期性故障。如果你用的是 Zabbix 5.x，没有 Token 功能，那只能密码认证，但建议启用 HTTPS 保护 API 传输链路。
3. 安装 Zabbix 数据源插件：两种方式实操
3.1 方式一：grafana-cli 在线安装（最推荐）
Grafana 提供了grafana-cli命令行工具，在线安装插件是最简单、最不容易出错的方式。你只需要在 Grafana 服务器上执行一条命令：
grafana-cli plugins install alexanderzobnin-zabbix-app执行完成后，会输出类似✔ Installed alexanderzobnin-zabbix-app successfully的信息。然后重启 Grafana 服务：
systemctl restart grafana-server这里有个细节要注意：Grafana 插件的启用，不是装完包就自动出现在界面里的。装好并重启后，你需要进入 Grafana Web 界面，点击左侧菜单的“Plugins”，搜索 Zabbix，找到对应的插件，点进去，在右边点击 “Enable” 按钮。如果这一步不做，后面你在添加数据源的时候根本找不到 Zabbix 类型。
3.2 方式二：离线方式安装（针对内网环境）
很多生产环境的 Grafana 服务器没有外网访问权限，这时grafana-cli在线安装会直接报网络错误。我的做法是：在一台有外网的机器上下载插件包，然后复制到内网服务器。
具体步骤是：到 Grafana 插件市场或者 GitHub release 页面找对应版本的.zip包，比如alexanderzobnin-zabbix-app-4.4.0.zip。下载后上传到 Grafana 服务器的/var/lib/grafana/plugins目录下，解压并把目录名改成alexanderzobnin-zabbix-app。然后设置目录属主为grafana:grafana：
mkdir -p /var/lib/grafana/plugins cd /var/lib/grafana/plugins unzip alexanderzobnin-zabbix-app-4.4.0.zip mv alexanderzobnin-zabbix-app-4.4.0 alexanderzobnin-zabbix-app chown -R grafana:grafana /var/lib/grafana/plugins/alexanderzobnin-zabbix-app systemctl restart grafana-server与在线安装一样，重启后仍需到 Plugins 页面手动 Enable。另外，离线安装还需要注意 Grafana 的配置文件里是否允许加载这个插件目录。默认情况下/var/lib/grafana/plugins就是 Grafana 的插件目录，一般不需要修改，但你可以在/etc/grafana/grafana.ini里检查plugins相关的配置项，确认没有把该目录排除。
3.3 安装之后如何验证插件是否生效
验证插件是否真的被加载，有两个方法。第一个方法很简单：在 Grafana 的 Plugins 页面里搜到 Zabbix 插件，并看到 Enable 按钮变成 Disable，说明已经启用。第二个方法更靠谱：命令行检查 Grafana 启动日志，看看有没有关于 Zabbix 插件的错误。
journalctl -u grafana-server --since today | grep -i zabbix正常情况会看到类似logger=plugins.update.checker的初始化日志，或者不会出现报错。如果日志里出现 “Failed to load plugin” 之类的字样，大概率是插件版本和 Grafana 版本不匹配，或者目录权限有问题。我的排查顺序是先看目录属主、再看插件版本、最后看 Grafana 版本。
提示：如果使用 Docker 方式部署 Grafana，那么插件目录一般在容器内的
/var/lib/grafana/plugins，可以通过挂载宿主机目录到该路径来实现离线安装，安装后需要docker restart重启容器。
4. 配置 Zabbix 数据源：从填参数到调通
4.1 添加数据源时的关键参数说明
插件启用之后，就可以添加数据源了。在 Grafana 左侧菜单选择 Configuration -> Data Sources -> Add data source，搜索 Zabbix，进入配置界面。这里有几个字段要特别留意：
- URL：不能填 Zabbix 前端地址（比如
http://zabbix-server），必须填 Zabbix API 的完整地址，也就是http://zabbix-server/api_jsonrpc.php。填错是新手最容易犯的错误。 - Basic Auth：如果是用户名密码认证，勾选 Basic Auth，填写你在 Zabbix 里创建的专用用户和密码。
- Token Auth：如果你用的是 Zabbix 6.0 的 API Token，可以不勾 Basic Auth，转而把 Token 填到 HTTP Headers 或者插件提供的 Token 字段里。
- Trends：插件有一个 “Use trends data” 的选项，开启后可以拉取 Zabbix 的趋势数据，适合长时间范围的大图。我建议开启，能显著降低 Zabbix API 的查询压力。
- Disable data aggregation：这个选项是处理同一个监控项存在多个值的场景，如果你只是做常规展示，一般不用开启。
以下是我在 6.0 场景下的一个典型配置示例：
| 配置项 | 填写值 | 说明 |
|---|---|---|
| Name | Zabbix-Prod | 数据源名称，后面建面板时要用 |
| URL | http://zabbix-server/api_jsonrpc.php | API 端点，不要加 web 路径 |
| Basic Auth 用户 | grafana_svc | 专用 API 用户 |
| Basic Auth 密码 | ****** | 专用密码或 Token |
| Trends | 开启 | 长时段用趋势数据 |
| Alerting | 不强制 | 告警可选择在 Grafana 侧配置 |
4.2 认证方式对比：密码认证与 Token 认证
我把两种认证方式都实际用过，做个简单的对比：
- 密码认证：配置简单，适合 Zabbix 5.x 或不希望额外维护 Token 的场景。缺点是密码会以明文方式存在于 Grafana 的配置存储里（虽然 Grafana 内部有加密，但总归多一层风险），而且遇到密码定期策略就会自动失效。
- Token 认证：Zabbix 6.0+ 推荐。Token 可以单独撤销，不影响 Zabbix 用户的密码生命周期。配置稍微复杂一点，因为不同插件版本对 Token 的配置位置略有差异。我用 4.2 版本插件时，是在 HTTP Headers 里加
Authorization: Bearer <token>来实现的，也有版本直接在数据源页面提供 Token 输入框。如果发现加了 Token 还是 401，建议查看插件的官方 README。
从长期稳定性角度，我的选择是能 Token 就 Token，毕竟一次配置、长期无忧，不用每三个月折腾一次。
4.3 保存并测试：常见的连接报错汇总
配置完成后，点 “Save & test”，如果一切正常，你会看到绿色的 “Successfully queried the Zabbix API” 提示。但如果报错，多半是以下几类：
- 401 Unauthorized：用户名密码错误，或 Token 无效。检查 Zabbix 用户是否启用、权限是否覆盖目标主机组。
- 404 Not Found：URL 填错了，最常见的是填成了 Zabbix Web 地址，却漏掉了
/api_jsonrpc.php。 - SSL 证书校验失败：如果 Zabbix API 是 HTTPS，且证书是自签的，Grafana 侧可能会拒绝连接。可以在数据源配置里关闭 “Skip TLS Verify”，或者把 CA 证书加载到 Grafana 的信任区。
- Connection refused / timeout：网络不通，检查防火墙、端口，尤其注意 Zabbix 服务器的 API 端口（HTTP 80 或 HTTPS 443）是否对 Grafana 服务器开放。
我第一次配置时把 URL 填成了http://zabbix-server/zabbix/，结果测试一直 404，折腾了十几分钟才意识到要填 API 端点。这类小问题你排查一次记住了，后面就不会再犯。
5. 从模板到自定义面板：真正开始做可视化
5.1 导入现成的 Zabbix Dashboard 模板
插件装好了，数据源也通了，接下来最爽的一步：直接用现成的模板。Grafana 社区有大量 Zabbix 相关的 Dashboard 模板，比如在 Grafana 官方的 Dashboards 页面搜索 “Zabbix”，会出现很多预制面板。进入面板详情页，复制它的 Dashboard ID（例如5364或13395），然后在你的 Grafana 里通过 Import -> 输入 ID -> Load，选择对应的 Zabbix 数据源，就能一键导入。
导入之后你会发现，面板上出现了很多主机、监控项的变量下拉框，这是因为模板默认会读取 Zabbix API 的主机组、主机、监控项信息来做变量填充。如果你的模板显示不了数据，多半是因为数据源名字和模板默认的数据源名字不一致，或者权限账号看不到模板里用到的那些主机。把它当成第一个检查点。
5.2 创建自己的面板：理解 Zabbix 数据源查询逻辑
如果预制模板满足不了你的业务需求，那就得手动创建 Panel。在 Grafana 的 Dashboard 里添加一个 Panel，选择数据源为 Zabbix，你会看到查询编辑器长这样：
- Group：选择要查询的主机组，比如 “Service Hosts”。
- Host：选择具体主机，支持多选。
- Application / Item：选择应用集或具体监控项，比如 CPU load、Memory used、Network bytes 等。
- Functions：可以对监控项做聚合，如 average、max、min 等。
这个查询编辑器的逻辑和 SQL 很像，但本质是帮你生成对 Zabbix API 的调用。这里有一个细节：如果你选到了某个监控项，但面板上没有数据，可能需要检查该项是不是 Zabbix 里属于 “Preprocessing” 的类型，比如日志类型自定义监控项，可能压根没有历史数据。
在手动创建面板时，我建议先从单个监控项开始测通，然后再扩展复杂的面板。我第一次就选了一堆监控项，结果发现图上啥也没有，排查半天才明白是 Group 选错了，权限账号根本看不到该主机组。
5.3 用变量实现主机、监控项的动态切换
Grafana 的杀手锏之一就是变量。你可以为 Dashboard 创建几个下拉模板变量，让使用面板的人不用每次改查询条件。我这里给一个典型的变量示例：
- 变量名：
HostGroup，类型选 Query，查询数据源选 Zabbix，Query 写groups()，这样下拉框会自动列出所有主机组。 - 变量名：
Host，类型选 Query，Query 写hosts(hostgroup=$HostGroup)，也就是根据上一步选中的主机组动态过滤主机。 - 变量名：
Item，类型选 Query，Query 写items(host=$Host, app="CPU")，根据主机动态列出 CPU 相关监控项。
然后在 Panel 查询里，把 Group、Host、Item 分别填成$HostGroup、$Host、$Item，保存之后，你的面板就变成了一个“万能面板”：选组、选主机、选监控项，数据即刻切换。这个思路特别适合做巡检大屏和应急排查页面，一个面板覆盖所有主机。
6. 常见问题与排查技巧实录
6.1 插件启用后找不到数据源类型
这个问题在安装插件后非常常见。如果你确定插件已经在 Plugins 页面里启用了，但还是添加不了 Zabbix 类型的数据源，首先确认 Grafana 是否需要重启以重新扫描插件。我遇到过一次grafana-cli安装完成后忘了重启，导致页面怎么刷新都找不到。重启后如果还不行，查看日志：
journalctl -u grafana-server | grep -i plugin日志里如果有 “Failed to load plugin” 或 “plugin was not registered”，基本就是版本不兼容。以我踩过的为例，旧版插件对 Grafana 10 的某些 API 变更没有适配，会报一个类似于接口不确定的错，升级到插件 4.x 之后问题消失。
6.2 面板显示无数据或 N/A
面板建出来了，但数值永远是 N/A，这是第二个高频问题。我的排查步骤有三个：
- 第一步，确认 Zabbix 账号的权限范围。如果账号只能读某个主机组，但你面板查询的是另一个主机组的监控项，那数据必然为空。打开 Zabbix Web 界面，用同一个账号登录，看能看到哪些主机。
- 第二步，确认监控项确实有数据。如果 Zabbix 里该监控项从来就没有采集到值，Grafana 自然展示不了。
- 第三步，确认时间范围并考虑趋势数据。有时你把时间范围调成“Last 7 days”，但 Zabbix 的 history 数据保留周期只有 7 天，趋势数据如果没开启查询，也可能显示 N/A。这种情况下，把数据源里的 Trends 开关打开即可。
6.3 图表只显示最近几天的数据
这个现象和 Zabbix 的数据保留策略强相关。Zabbix 默认会把监控项的 history 保留一段时间（比如 7 天），把 trends 保留更长时间（比如 365 天）。如果 Grafana 面板查询跨度过大，插件会优先用 trends 数据来画长周期图，如果这一步没配置好，就只会有少量点显示。
解决办法有两个：一是确保数据源配置里的 “Use trends data” 是开启状态；二是在 Zabbix 里针对关键监控项调长 history 保留期或 trends 保留期。注意，如果监控项是自定义且没有建立趋势数据，那即使开启 Trends，长周期也画不出来。所以我的习惯是，对要长期展示的重要指标，在 Zabbix 模板里直接配置一个更长的 trends 保留期。
6.4 数值显示异常（NaN、负数、小数点漂移）
有些监控项是字符型的、或者是带单位转换的（比如字节数、百分比）。Grafana 拉取到之后如果单位不对，显示会很怪。我的建议是：进入面板的 Field 设置里，手动设置 Standard options 的 Unit，比如 bytes、bytes/sec、percent 等。遇到过最惨的一次是磁盘使用量被显示为 8.7e+14 这种科学计数法，就是因为我没有设置 Unit，Grafana 自动用了默认的 short 格式。把 Unit 改成 bytes 后立即正常。
另外，Zabbix 里部分监控项数值是整数还是浮点，也会影响显示。如果发现小数位被截断，检查一下 Zabbix item 的 Value type 是不是 float，不是的话把它改为 float，并设置好 Units 和 precision。
6.5 告警配置：Grafana 侧还是 Zabbix 侧
很多人接完 Grafana 之后，会希望在 Grafana 里直接配告警。这其实是可以的，Grafana 告警引擎支持对 Zabbix 数据源做阈值判断，然后在 Grafana 里发通知。但我的经验建议：告警尽量保留在 Zabbix 侧，因为 Zabbix 的告警引擎、升级策略、依赖关系、历史事件管理都比 Grafana 成熟得多。Grafana 更适合做展示层，它的告警触发和事件管理能力虽然一直在进步，但和 Zabbix 的深度告警能力比，还是有差距。
如果你确实想在 Grafana 里配告警，比如“CPU 使用率连续 5 分钟超过 90%”，原理是：配置 Alert Rule 时选择 Zabbix 数据源，查询语句里选择监控项和聚合函数（比如avg()），然后设定阈值、评估频率（比如每 1 分钟评估一次）、通知渠道（如钉钉、邮件、Webhook）。不过要提醒的是，告警查询会额外增加对 Zabbix API 的请求，如果数据量大，评估频率别设太短，免得拖垮 Zabbix。
7. 补充几个生产环境里的实战经验
7.1 多套 Zabbix 环境如何统一接入
如果你的公司不止一套 Zabbix，比如生产环境和测试环境各一，甚至是多区域多机房，你不需要分别部署多个 Grafana。在一个 Grafana 实例里，可以添加多个 Zabbix 数据源，并在 Dashboard 里使用数据源变量来动态切换。在变量定义里选择 “Datasource” 类型，查询为zabbix，这样面板顶部会自动渲染一个数据源下拉框。我实际用这种方式把三个机房的 Zabbix 统一放进了同一个 Grafana，看板也只需要一份，配合主机组变量就能灵活切换。
7.2 面板加载慢的优化思路
Grafana 面板如果挂了大量监控项，每次切换时间范围都要等好几秒。我的优化手段有三板斧：第一，在数据源里开启 Trends，长跨度查询改用聚合趋势，降低 API 返回的数据量；第二，减少单面板的监控项数量，把几十个监控项拆成多个 Panel，查询并行度更高、渲染更快；第三，配置 Grafana 的dashboards缓存或使用更快的存储后端的方案，但这个要看你的规模值不值。
7.3 插件升级与维护建议
插件不是装完就一劳永逸的，Zabbix API 的变动、Grafana 主版本的升级，都可能影响插件正常工作。我建议每季度检查一次插件是否有新版本，升级前先看 changelog，确认兼容性。特别注意：升级插件后务必重启 Grafana，并重新跑一次数据源测试。另外插件目录的备份也很重要，离线安装场景下，升级前先备份旧版本的插件目录，出问题可以快速回滚。
这个内容后续还可以这样扩展：如果你对监控数据安全有要求，可以研究在 Grafana 和 Zabbix API 之间加一层代理或网关；如果你有多个地区的监控数据，也可以考虑用 Grafana 的 Federation 功能做更高层的聚合展示。但那是另一个话题了，先把这篇里的基础链路搭通，Grafana + Zabbix 这套组合绝对能让你在日常监控的体验上，提升不止一个档位。
