企业官网建设流程全解析

把 Grafana 接进 Zabbix 可视化平台这件事，我在生产环境里做过好几次，但每次换一套环境，最稳定的"见面礼"就是数据源保存时报那个 Could not connect to given url。这个报错看起来很劝退，实际上大部分时候是 URL 写法、网络链路或者认证方式的问题。我见过不少同事在这里卡了一下午，最后发现只是少写了一段/api_jsonrpc.php。这篇文章会把整套搭建流程、报错排查链路、以及我反复踩过的坑全部过一遍，给正准备搭可视化平台的运维同学一条能直接跟着走的路，少耗一点在这种本该五分钟解决的问题上。

1. 为什么非要折腾 Grafana 来看 Zabbix 的数据

先说结论：Zabbix 不是不能画图，但当你需要把几十台主机的状态放在一块大屏上、按业务维度横向对比、甚至把 Zabbix 的监控数据和另外一套系统的指标叠在同一条时间线上时，Zabbix 原生界面会非常吃力。这也是我在多个项目里最终选择 Grafana + Zabbix 组合的根本原因。

1.1 Zabbix 原生界面的三个明显短板

第一个短板是图形样式偏老。Zabbix 自带的 Simple Graph 虽然能出趋势图，但线条样式、调色、坐标轴控制都比较有限，想做一个能让业务部门看得懂、觉得专业的"监控大屏"很吃力。第二个短板是多主机对比效率低。Zabbix 默认的图形系统更偏向"单台主机看单指标"，虽然也能做聚合图形（Aggregate Graph），但配置起来繁琐，且交互方式不友好，在大屏上的展示效果大打折扣。第三个短板是权限与展示的分层不够灵活。你可能会希望给管理层一个只读展示页、给运维组一个可交互的排查页面、给开发组只看自己服务的面板，在 Zabbix 前端里做这种细粒度展示配置虽然可行，但体验远不如 Grafana 来得顺畅。

1.2 Grafana 在监控展示上的优势点

Grafana 本身就是为"统一可视化"而生的。它支持几十种数据源，Zabbix 只是其中之一，后续你想把 Prometheus、InfluxDB、Elasticsearch 的数据也接进来，可以在同一套面板上并排展示，不需要再切系统。Grafana 的 Dashboard 体系也成熟得多：变量联动、模板复用、JSON 导入导出、团队文件夹权限管理，这些都是日常运维里高频用到的能力。对于已经有 Zabbix 做采集和告警、又不想彻底迁移监控体系的团队来说，加一层 Grafana 作为展示层，几乎是性价比最高的方案。它不替代 Zabbix 的采集和告警，只负责把数据变得更好看、更好用。

2. 动手前的环境盘点和 API 自检

在装 Grafana 之前，我建议先花十分钟确认一下 Zabbix 侧的底子。很多人一上来就装 Grafana，装完插件发现连不上，回头才发现 Zabbix API 本身都没通。

2.1 本次搭建的软件环境

我这篇的搭建环境供参考：Zabbix 用的是 7.0 LTS，跑在 Rocky Linux 9 上，Nginx + PHP-FPM 部署，数据库是 MySQL；Grafana 是 11.x，安装在一台独立的 CentOS 7.9 服务器上，通过内网访问 Zabbix 服务器。版本组合很关键，尤其是 Zabbix 7.0 的默认管理员是Admin（不是老版本的admin），登录认证逻辑也有变化，用旧习惯容易在认证环节栽跟头。

Grafana 服务器和 Zabbix 服务器的网络关系比较简单，两台都在同一个网段，没有额外的安全组拦截。如果你用的是云主机，记得提前确认安全组规则放通了对应端口，不然下面所有排查都会绕远路。

2.2 用 curl 验证 Zabbix API 是否已经就绪

Zabbix 数据源插件的连接逻辑，本质上就是向 Zabbix 的 API 地址发请求。只要 API 能通，数据源配置就成功了一大半。所以我会先在任何图形界面操作之前，在 Grafana 服务器上手动调一次 API：

curl -i -X POST \ -H 'Content-Type: application/json' \ -d '{"jsonrpc":"2.0","method":"user.login","params":{"username":"Admin","password":"zabbix"},"id":1}' \ http://192.168.10.10/zabbix/api_jsonrpc.php

正常返回的 JSON 里会有一个result字段，里面是一长串 token，像这样：

{"jsonrpc":"2.0","result":"eyJhbGciOiJIUzI1NiJ9.xxxxxxxx","id":1}

如果看到{"error":{"code":-32602,"message":"Invalid params"}}，说明认证信息不对；如果连接超时或拒绝，那就说明网络层有问题，先不要碰 Grafana。这一步能最大程度把问题范围缩小，避免后面在 Grafana 界面里反复试错。

2.3 给 Grafana 单独建一个监控账号

我不建议在 Grafana 数据源里直接用 Zabbix 的超级管理员账号。一是安全风险，二是权限不好控制。请在 Zabbix 前端单独建一个用户，比如叫grafana，属于一个新建的用户组grafana-group，给这个组只配置对需要展示的主机组授予只读权限。这样做的好处是：即使 Grafana 数据源配置被谁误改、泄露，也只会影响读操作，Zabbix 侧的配置不会被改掉。

Zabbix 7.0 创建用户时要注意，用户类型选择"Zabbix User"即可，不要给超级管理员。密码建议设置复杂一些，并且要和zabbix默认密码区分开。如果以后要换密码，Zabbix 侧改完后 Grafana 数据源同步更新即可。

3. Grafana 安装、Zabbix 插件部署与启用

环境没问题之后，开始在 Grafana 服务器上装本体和插件。这一步相对流程化，但有几个细节容易忽略，我一个个说。

3.1 用 YUM 装 Grafana

Grafana 官方提供了 RPM 源，装起来很简单。先写 repo 文件：

sudo tee /etc/yum.repos.d/grafana.repo <<EOF [grafana] name=grafana baseurl=https://packages.grafana.com/oss/rpm repo_gpgcheck=1 enabled=1 gpgcheck=1 gpgkey=https://packages.grafana.com/gpg.key sslverify=1 sslcacert=/etc/pki/tls/certs/ca-bundle.crt EOF

然后安装并启动：

sudo yum install -y grafana sudo systemctl daemon-reload sudo systemctl enable --now grafana-server

装完先访问一下http://Grafana服务器IP:3000，默认用户名密码是admin/admin，首次登录会强制改密码。这一步别跳过，很多人装完直接装插件，结果连 Grafana 都没起来，插件验证自然无从谈起。Grafana 默认监听 3000 端口，如果前面还有 Nginx 反代，一定要先把端口测通再考虑反代。

3.2 安装 Zabbix 数据源插件

Grafana 社区里最常用的 Zabbix 插件是alexanderzobnin-zabbix-app。安装就一条命令：

sudo grafana-cli plugins install alexanderzobnin-zabbix-app sudo systemctl restart grafana-server

安装完成后，去 Grafana 的 Administration → Plugins 页面搜索 Zabbix，会看到这个插件，点击进入后选择 Enable。这一步很多人漏了，插件装完不启用，后面添加数据源时根本搜不到 Zabbix 类型。如果插件列表里没有，多半是 grafana-server 没重启，或者插件下载到了错误目录。可以用grafana-cli plugins ls确认插件是否被识别。

3.3 数据源配置页面里的三个关键字段

插件启用后，在 Connections → Data Sources → Add data source 里搜索 Zabbix，进入配置页面。有三个关键字段需要留意：

URL 字段是核心，后面报错绝大多数都和它有关。保存前按页面底部的 Save & Test 进行测试，然后就会看到那个熟悉的报错。接下来我们集中精力把它干掉。

4. Could not connect to given url 完整排查链路

这个报错表面上只告诉你"连不上"，但背后的原因可能吵出五六种口味。我按排查顺序整理了六个站点，每站都有验证方法，按照这个顺序走完，基本能定位九成以上的问题。

4.1 第一站：URL 到底该填哪个地址

这是最高频的坑。Grafana 的 Zabbix 插件要连的是 API 入口，不是 Zabbix Web 前端入口。如果 Zabbix 部署在根路径，URL 是http://IP/api_jsonrpc.php；如果 Zabbix 前端放在子路径/zabbix下，URL 是http://IP/zabbix/api_jsonrpc.php。

判断方法很简单：在浏览器里访问 Zabbix 首页，看地址栏。如果是http://IP/zabbix/，那 URL 就带上/zabbix；如果是http://zabbix.example.com/直接打开，那就不用带子路径。我这里填的就是http://192.168.10.10/zabbix/api_jsonrpc.php。常见错误是填成http://192.168.10.10/zabbix或者漏掉api_jsonrpc.php，插件会拿这个地址去请求 API，自然连不上。

还有一点，URL 里的协议不能搞错。Zabbix 内部如果只监听 HTTP，你填 HTTPS 一定会失败。有些环境里 Zabbix 前端用 Nginx 做了 SSL 终结，但 API 监听在本地 HTTP，外部访问通过 HTTPS 才通，那 URL 就要填 HTTPS。这个用 curl 验证时一并确认。

4.2 第二站：Grafana 服务器到 Zabbix 的链路

如果 URL 填对了还是报错，第二步确认网络链路。这里特别强调：不是在你电脑浏览器上测试，而是在 Grafana 服务器上测试。因为这个连接是 Grafana 后端发出的，不是你的浏览器发出的。

curl -v http://192.168.10.10/zabbix/api_jsonrpc.php

如果超时或者Connection refused，检查防火墙和网络：

• Grafana 服务器是否能 ping 通 Zabbix 服务器
• Zabbix 服务器的防火墙是否放行了 80/443 端口（firewall-cmd --list-all）
• 云环境安全组是否放行相应端口

另外，如果你在 Grafana 服务器上配置了全局 HTTP 代理（环境变量HTTP_PROXY/HTTPS_PROXY），curl 和 Grafana 都可能会走代理，这时候内网地址可能被代理拒绝。我之前就遇到过一台服务器上设置了系统代理的坑，Grafana 请求内网 Zabbix 被代理服务器拦截，报错一模一样。排查方法是在 grafana-server 的启动环境里临时清掉代理变量，或者确认代理配置对192.168.x.x这类内网地址不做转发。

4.3 第三站：Zabbix API 本身是不是活着

网络通了，但 API 可能本身有问题。在 Zabbix 服务器本机上执行同样的 curl 命令：

curl -X POST \ -H 'Content-Type: application/json' \ -d '{"jsonrpc":"2.0","method":"apiinfo.version","params":{},"id":1}' \ http://127.0.0.1/zabbix/api_jsonrpc.php

如果返回版本号 JSON，比如{"jsonrpc":"2.0","result":"7.0.0","id":1}，说明 API 进程正常。如果返回 HTML 错误页或者 500，那是 Zabbix 侧的 PHP-FPM、Nginx 或数据库出了问题，跟 Grafana 无关。

需要留意的是：用 Nginx + PHP-FPM 部署 Zabbix 时，API 对 PHP 的post_max_size、max_execution_time等参数有要求。特别是 Zabbix 7.0，PHP 版本要求 8.1 以上，PHP-FPM 进程异常会导致 API 要么 502，要么长时间无响应。Grafana 这边等待超时后，就会表现为 "Could not connect to given url"。如果你发现 curl 请求 API 要好几秒才返回，那就算连上，后续查数据也会很卡，建议先优化 Zabbix 侧。

4.4 第四站：账号权限与认证方式

API 通了却报同样的错误，还有一种可能是插件在调用user.login时被 Zabbix 拒绝了。插件的处理方式是：你填了用户名密码，它先调user.login拿 token，再拿 token 去查数据。如果用户名不对、密码不对、用户被禁用、或者用户类型不允许 API 访问，登录失败，最终也会表现为连接错误。

复制粘贴用户名时特别小心。Zabbix 5.0 之后默认管理员是Admin（大写 A），不是admin。如果你用旧版本的记忆去填admin，会认证失败。另外，如果密码里有特殊字符，比如@、#，注意有没有被输入的浏览器插件或密码管理器干扰。

建议在 Zabbix 前端里用 curl 验证一下专用账号的登录：

curl -X POST \ -H 'Content-Type: application/json' \ -d '{"jsonrpc":"2.0","method":"user.login","params":{"username":"grafana","password":"你的密码"},"id":1}' \ http://192.168.10.10/zabbix/api_jsonrpc.php

如果返回 token，说明账号没问题。另外，如果你的 Zabbix 开了Auth配置里的 IP 限制或登录失败锁定策略，也要注意是否把 Grafana 服务器 IP 误伤了。

4.5 第五站：TLS 证书和反向代理的干扰

如果你配置的 Zabbix 是 HTTPS 访问，而且用的自签名证书，Grafana 在 SSL 校验时会直接拒绝连接。插件在数据源配置的高级设置里提供了跳过 TLS 验证的选项，不同版本位置略有差异，一般在TLS settings或Advanced settings里。如果实在找不到，可以在 Grafana 的grafana.ini中设置skip_tls_verify = true（指 Grafana 自身作为客户端去请求外部时跳过证书校验），但这是在数据源层面做的。

还有一种常见干扰是反向代理。很多人用 Nginx 反代 Grafana 和 Zabbix，如果反代配置里对/api/datasources/proxy/路径做了额外拦截，或者proxy_read_timeout设置太短，数据源测试时也容易报连接失败。排查方法是暂时绕过反向代理，直接用 IP:3000 访问 Grafana 测试，如果直连能通而反代后不通，问题锁定在反代配置上。

4.6 第六站：插件和 Grafana 的版本兼容

最后检查版本矩阵。alexanderzobnin-zabbix-app插件更新很快，不同版本对 Grafana 版本有要求。比如老版本的插件可能在 Grafana 11 上无法正常加载。如果你是从旧环境迁移过来的数据源配置，或者grafana-cli plugins update之后没重启，也可能出现这种问题。

查看 Grafana 日志是最直接的定位手段：

journalctl -u grafana-server -f tail -f /var/log/grafana/grafana.log

日志里通常会给出比界面上更具体的错误，比如超时、404、401、证书错误等。我之前遇到过插件内报错显示Get "http://...": context deadline exceeded，这明显是超时，而 Zabbix 端 PHP-FPM 负载太高，处理不过来。把 Zabbix 侧优化完，Grafana 这边连重试都不用，直接好了。

5. 数据源连通后：第一个 Zabbix 看板怎么搭

连接问题解决后，别急着关页面，先确认数据是不是真的能从 Zabbix 拉出来。在数据源页面点击 Explore，或者随便选一个主机尝试加载图表，能看到数据了，再开始建 Dashboard。

5.1 先套用社区面板还是自己画

Grafana 社区有很多现成的 Zabbix 面板，可以在 Dashboards → Import 页面输入关键词搜索（比如zabbix），找一个 star 数高的导入。导入后可能需要重新选择数据源、刷新变量。选模板时注意看一下模板支持的 Zabbix 版本和 Zabbix 插件版本，老模板在 Zabbix 7.0 上可能拿不到数据，因为 API 返回结构有调整。

如果你不想依赖模板，自己从零建第一个面板也很简单。新增一个 Time series 面板，数据源选 Zabbix，然后在 Query 里选主机、应用集、监控项。Zabbix 数据源的查询方式比较友好，基本是下拉选择，熟悉 Zabbix 里的监控项路径后，五分钟就能出第一张图。

5.2 经典图表的变量联动配置

面板一旦多起来，逐台主机切换就成了痛点。Grafana 的 Dashboard 变量可以解决这个问题。在最上层 Dashboard Settings 里新建一个变量，比如$host，查询类型选 Query，数据源选 Zabbix，Query 用*通配符，它就能列出所有主机。然后在每个面板的查询条件里用$host变量代替固定主机，这样你在 Dashboard 顶部切换主机，所有面板会联动更新，效果非常直观。

变量粒度可以做得更细：用$app变量过滤应用集，用$item变量选择具体监控项。我一般会建三个层级变量：主机组 → 主机 → 监控项，这样即使监控数量很大，面板切换也不会卡。变量查询的底层实现其实是在调 Zabbix API，如果你连数据源都通了，变量基本不会出问题；反而要留意主机数量过多时下拉框会很长，可以按主机组先过滤一层。

5.3 给面板加一层展示细节

做给业务和管理层看的面板，不用塞太多监控项，选几个关键指标就够：CPU、内存、磁盘、网络、服务存活状态。Grafana 的 Stat、Gauge 适合做当前值展示，Time series 看趋势，再加上 threshold 配置，可以在面板上直接看到哪些指标超了阈值。颜色阈值配色建议简单直接，绿、黄、红三档就够用，不要五颜六色，不然大屏上反而看不清楚。还有一个小技巧：给每个面板设置No value时的显示内容，避免某个监控项因为暂时没数据而显示空白，影响观看。

6. 上线之后那些文档里不会写的维护教训

Grafana + Zabbix 组合跑起来之后，真正磨人的不是搭建，而是后续维护。我把几个踩过的坑总结在这里，希望你能直接绕过去。

6.1 升级 Grafana 前先看插件兼容矩阵

Grafana 升级频率不低，而 Zabbix 插件的兼容性更新未必同步跟得上。我有一次把 Grafana 从 10.x 升到 11.x，Zabbix 数据源直接失效，界面打开一片报错。查下来是插件版本太老，不兼容新版 Grafana 的插件协议。升级前一定先去插件 GitHub 页面确认兼容矩阵，再执行grafana-cli plugins update alexanderzobnin-zabbix-app，升级完一定要重启 grafana-server 并重新测试数据源。

为了降低升级风险，我建议把 Grafana 和插件的版本组合固定下来，不要每次弹更新提示就去点。生产环境里，稳定比新鲜重要得多。真要升级，先在一台测试服务器上验证面板加载和数据链路都没问题，再动生产。

6.2 API 专用账号的权限回收与轮换

你给 Grafana 建的专用账号，时间久了很容易被遗忘在 Zabbix 用户列表里。建议在账号备注里写清楚用途和创建时间，比如"Grafana 数据源只读账号，2025年创建"。如果团队换人或密码泄露，及时在 Zabbix 侧改密码，并同步更新 Grafana 数据源。Zabbix 7.0 还支持 API Token，比密码更可控，到期时间可以设置，建议优先使用 Token 而不是密码，即使 Token 泄露也能单独撤销而不影响其他登录方式。

6.3 我最后保留的一套稳定组合

经过几个项目的验证，我这边最终固定下来的组合是：Zabbix 7.0 LTS + Grafana 10.4 + alexanderzobnin-zabbix-app 4.4.x，这套组合在功能、稳定性和插件兼容性上都比较平衡。如果你的团队用的还是 Zabbix 5.0/6.0，也不需要为了接 Grafana 去升级 Zabbix，插件本身兼容老版本 API，反而要更留意 Grafana 端和插件端的版本搭配。

关于连接报错，还有一个小经验：数据源测试失败但日志里没有任何异常时，不妨看看 Grafana 服务器的系统时间是不是和 Zabbix 服务器差太多。时间不同步会导致 Token 校验失败，表现也接近连接错误。这个坑不好排查，但一旦遇到，修正时间同步后问题立刻消失。把chronyc sources和 Zabbix 侧的时间输出对一下，这是我在多次踩坑之后养成的检查习惯。