企业官网建设流程全解析

最近把公司的监控展示层从 Zabbix 原生页面切到了 Grafana，折腾了大半个月，把插件安装、数据源接入、看板制作、告警联动这些环节的坑基本都踩了一遍。写这篇的时候环境是 Zabbix 6.4 + Grafana 10.x，插件用的是 alexanderzobnin-zabbix-app，这套组合是目前比较主流的玩法，适配大多数中小规模公司的监控场景。

先说说这套方案能解决什么问题。Zabbix 本身不是不能看，但它的图形页面在多主机对比、时间范围联动、大屏展示这些场景下确实别扭。Grafana 则刚好补上这块短板，而且它接的不只是 Zabbix，以后你接 Prometheus、Loki、MySQL、ClickHouse 都不用换平台。所以如果你是运维、监控负责人，或者公司正想把监控数据做成可视化大屏给老板看，这篇文章可以帮你少走很多弯路。

下面我按照实际操作的顺序，把从插件安装到最终出图的全流程拆开来讲，每个环节我会把原理、操作、以及我踩过的坑全部写清楚。

1. 为什么折腾：把 Zabbix 接进 Grafana 背后的真实需求

1.1 Zabbix 原生界面到底哪里不够用

很多团队一开始都有这个疑问：Zabbix 自带图表，为什么还要多此一举接 Grafana？我最初也有这个困惑，但真用起来就发现问题了。

Zabbix 自带的图形功能，单看一台主机的 CPU 使用率、内存、磁盘这类基础指标，完全够用。但一旦涉及“把 20 台数据库服务器的 CPU 使用率放在同一张图里对比”，Zabbix 原生界面就会让你怀疑人生。你需要一台台添加图形，调整样式，最后拼出来的页面既不好看，也没法联动筛选。等到领导说“我要一个大屏，把所有核心服务的状态轮播展示”，Zabbix 就会显得力不从心。

另外，Zabbix 的图表在时间范围选择上交互也比较弱。你想对比“最近 7 天”和“最近 30 天”同一指标的趋势，它做不到像 Grafana 那样通过时间选择器快速切换全局范围。所以，当老板和同事对可视化要求提高之后，我决定把展示层拆出来，接到 Grafana。

1.2 Grafana + Zabbix 的工作模式与核心原理

这套方案本质上不是替代，而是“分工”：Zabbix 负责采集、存储、触发告警，Grafana 负责展示和一部分告警通知。

Grafana 本身不存监控数据，它通过数据源插件去后端拉数据。Zabbix 数据源插件的工作原理很简单：插件调用 Zabbix 的 API 接口（api_jsonrpc.php），通过 JSON-RPC 协议查询主机、监控项、历史数据和趋势数据，然后在 Grafana 的图表面板里渲染出来。

这个模式带来的好处是：

• 不需要改动 Zabbix 的采集配置和数据库，原有监控体系零侵入
• Zabbix 的历史数据继续保留，Grafana 只做读取，不产生额外写入压力
• 未来想接其他数据源，直接在 Grafana 里加，不必再单独搭一套可视化

如果打个比方，Zabbix 就是监控系统里的“数据仓库”，Grafana 则是展示分析层的“报表中心”，两者通过 API 这座桥连起来。

1.3 方案选型：为什么选 zabbix 插件而不是其他方式

市面上把 Zabbix 数据接进 Grafana 的方式，主要就两种：一是用官方社区维护的 alexanderzobnin-zabbix-app 插件，二是通过 Zabbix 的数据库直连（比如 MySQL 数据源直接查 history 表）。

我最终选插件，而不是直连数据库，原因有三点：

第一，插件走 API 是官方支持的方式，不破坏数据库结构。直连 MySQL 虽然查询灵活，但 Zabbix 的数据库表结构在不同版本之间变动较大（尤其是 history 和 trends 表的字段），升级 Zabbix 后 SQL 很可能要跟着改。

第二，插件提供了现成的变量类型（比如按主机组、主机、监控项动态联动），这在制作看板时非常方便。直连数据库做变量筛选取数逻辑得自己写 SQL，费时费力。

第三，插件支持自动启用 trends 模式，查询长时间段的趋势数据时性能更好，这一点后面细说。

所以如果你没有特别复杂的取数需求，用 alexanderzobnin-zabbix-app 插件是最成熟、维护成本最低的方案。

2. 插件安装的几种方式，选哪种看你的环境

2.1 在线安装：一条命令搞定

如果你的 Grafana 服务器能访问外网，在线安装是最省事的方式。安装的是社区维护的 Zabbix 数据源插件，插件 ID 是alexanderzobnin-zabbix-app。

安装命令：

grafana-cli plugins install alexanderzobnin-zabbix-app

装完之后需要重启 Grafana 服务：

sudo systemctl restart grafana-server

重启后可以去 Grafana 的 Administration -> Plugins 页面搜索 zabbix，能看到这个插件就说明加载成功了。

这里有个容易被忽略的细节：grafana-cli默认安装的是最新版本，但最新版本的插件不一定兼容你当前的 Grafana 版本。如果你用的是 Grafana 8.x，建议直接指定插件版本安装。比如：

grafana-cli plugins install alexanderzobnin-zabbix-app 4.2.0

至于版本怎么对应，我后面单独讲。

2.2 内网离线安装：手动解压与签名处理

很多公司监控服务器在隔离网络环境里，没法直接执行在线安装。这时候就需要走离线安装。

首先在能联网的机器上，从 GitHub Releases 页面下载对应版本的插件压缩包，文件名一般是alexanderzobnin-zabbix-app-4.4.0.zip这种格式。然后把压缩包传到 Grafana 服务器上，解压到插件目录。

Grafana 的插件默认目录是/var/lib/grafana/plugins。需要注意，解压后目录名必须和插件 ID 完全一致，即alexanderzobnin-zabbix-app，否则 Grafana 识别不到。有些压缩包解压后会多套一层父目录，要把里面的内容挪到正确位置。

接着修改 Grafana 配置文件/etc/grafana/grafana.ini，找到[plugins]段落，添加允许加载未签名插件：

[plugins] allow_loading_unsigned_plugins = alexanderzobnin-zabbix-app

为什么要加这一行？因为离线下载的插件没有经过 Grafana 官方的签名校验，如果不显式放行，Grafana 会拒绝加载。这算是离线安装最容易踩的坑，很多同学解压完、配置完、重启了，结果插件列表里还是看不到，多半就是漏了这一步。

改完配置重启 Grafana：

sudo systemctl restart grafana-server

然后用grafana-cli plugins ls查看插件列表，确认是否已经加载。

2.3 Docker 方式部署 Grafana 时怎么带插件

如果你和我一样习惯用 Docker 跑 Grafana，安装插件的思路又不太一样。因为容器是临时的，重启后所有未持久化的改动都会丢，所以不能只进容器里手动装。

我常用的方式有两种。

第一种是写 Dockerfile，构建一个带插件的自定义镜像：

FROM grafana/grafana:10.4.0 RUN grafana-cli plugins install alexanderzobnin-zabbix-app

然后构建并运行。这个方式的好处是插件版本可控，镜像分发到哪台机器都一样。

第二种是在 docker-compose.yml 里通过环境变量方式放行未签名插件，并把插件目录挂载进去：

services: grafana: image: grafana/grafana:10.4.0 ports: - "3000:3000" environment: - GF_PLUGINS_ALLOW_LOADING_UNSIGNED_PLUGINS=alexanderzobnin-zabbix-app volumes: - ./plugins:/var/lib/grafana/plugins - grafana-data:/var/lib/grafana

这种情况下，插件 zip 解压后要放到宿主机./plugins/alexanderzobnin-zabbix-app目录里，容器启动时会读取这个目录。

2.4 版本匹配：Grafana 和插件版本别乱配

插件装不上、装完不显示、显示但数据源连不上，很大一部分原因是版本不匹配。

Grafana 8.x 是插件 API 更新的一个分水岭。Grafana 9 之后对插件 API 做了不少调整，老版本插件往往没法在新版 Grafana 上正常跑。我整理了一个简单的版本对应关系，供参考：

确认当前 Grafana 版本，可以在 Grafana 左下角用户菜单里的 About 里看，也可以执行：

grafana-server -v

插件选版本我建议别太追新，确认当前 Grafana 版本后，去插件 GitHub 仓库看一下 release 说明里的兼容性声明，再决定装哪个版本。

3. Zabbix 数据源接入：API 认证与配置避坑

3.1 准备一个安全的 Zabbix API 用户

接入 Grafana 前，我强烈建议在 Zabbix 前端创建一个专用用户，而不是直接用 Admin 账户配置数据源。原因很简单：数据源配置页里会有明文的密码或 token，如果其他人能看到这个配置，等于把 Zabbix 的管理员权限暴露了。

我的做法是，在 Zabbix 里新建一个用户，比如叫grafana_readonly，把它加入一个权限受限的用户组，权限设置为只读。如果你用的是 Zabbix 6.4，创建用户时选择“用户组”，然后为该用户组分配权限时，选中需要被 Grafana 读取的主机组，权限类型选“读”即可。如果只想快速跑通，也可以临时给这个用户“读”权限，后面再收紧。

这个用户的作用是让 Grafana 通过 API 查询主机、监控项、历史数据。只需要读权限就够了，不要给写权限，更不要加入超级管理员组。

3.2 在 Grafana 里添加 Zabbix 数据源

插件加载完成后，进入 Grafana 的 Connections -> Data sources，点击 “Add data source”，搜索 Zabbix，进入配置页。

关键配置项如下：

• Name：数据源名称，随意，比如Zabbix-Prod
• URL：Zabbix API 地址，格式是http://<zabbix-server-ip>/api_jsonrpc.php。注意，不是 Zabbix 前端页面地址，而是 API 端点地址。很多同学会填成http://ip/zabbix/，这是不对的。如果找不到，可以去 Zabbix 前端登录页，通常api_jsonrpc.php就在 web 根目录下。
• Basic Auth：通常在 Zabbix 6 及以上版本，我们用 Zabbix 用户的用户名和密码完成认证，需要勾选 “Basic Auth” 并填写前面创建的用户名、密码。
• 不使用告警联动时跳过：如果只是展示，默认即可。

填完后点击 “Save & Test”，如果看到类似Zabbix API: OK的提示，说明数据源已经通了。如果测试失败，看下面的排查步骤。

3.3 用 API Token 代替密码登录

Zabbix 5.4 之后支持配置 API token，比密码更安全，也更方便管理。我实际使用中更推荐这种认证方式，因为 token 可以单独吊销，不用改密码。

获取 token 的步骤：

1. 在 Zabbix 前端，用专用用户登录
2. 进入用户菜单，选择 “API tokens”
3. 点击 “Create API token”，设置过期时间（我一般选永不过期），生成 token 字符串

然后在 Grafana 数据源配置页：

• 认证方式选择 “Token”
• 将 token 粘贴到 “Zabbix API token” 输入框

保存并测试，提示 OK 即可。注意 token 在页面展示后只显示一次，复制后妥善保存，丢了只能重新生成。

3.4 连接失败时的排查顺序

数据源连接失败是大家问得最多的问题。我按自己实际踩坑的经验，整理一个排查顺序：

1. URL 是否正确：确认末尾是否带了api_jsonrpc.php，不要只是根路径。我试过一次填成http://122.xx.xx.xx/zabbix/，保存测试一直报错，改成带api_jsonrpc.php的完整地址就好了。
2. 账号权限：确认你用的用户能在 Zabbix 前端登录，并且至少有一个主机组的读权限。如果权限为空，API 查询也会失败。
3. 认证方式：确认 Grafana 数据源里选的认证方式和 Zabbix 用户实际的认证匹配。如果 Zabbix 开启了 LDAP 或 SAML，直接用本地用户可能不生效。
4. SSL/TLS 问题：如果 Zabbix 是 HTTPS 且证书是自签的，Grafana 默认会校验证书并失败。这时候需要在数据源配置里勾选 “Skip TLS Verify”，或者把 CA 证书配置到 Grafana 的信任库。
5. 网络隔离：确认 Grafana 服务器能访问 Zabbix 的 80/443 端口，排除防火墙、安全组策略拦截。

如果你按这个顺序排查完还是连不上，可以在 Grafana 容器或本机直接测试 API 连通性：

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

能返回 Zabbix 版本号，说明 API 本身是通的，问题基本出在 Grafana 的认证配置上。

4. 实战：搭一个多主机监控大屏

4.1 导入现成模板快速起步

数据源接通之后，最爽的事情就是直接把现成的模板导入 Grafana 秒出一个看板。社区里贡献了不少 Zabbix 相关的模板，最经典的一个 Dashboard ID 是13383（Zabbix Hosts Overview）。

导入方式：

1. 进入 Grafana 的 Dashboards -> Import
2. 在输入框填入模板 ID13383，点击 Load
3. 选择刚才配置好的 Zabbix 数据源
4. 点击 Import，等几秒看板就出来了

导入后你就能看到类似主机组、主机列表、触发告警状态等面板。这个模板是插件作者维护的，对 Zabbix 的数据结构适配得比较好，可以在此基础上改。

但要注意，模板默认的变量设置是针对特定数据源名的，如果你在模板选择数据源时没有指定，部分变量可能为 null。导入后检查一下看板左上角的变量是否能正常下拉，如果为空，按下面一节的方法重新配置。

4.2 模板变量怎么用

Zabbix 插件最大的优势之一就是内置了变量类型，可以动态关联主机组、主机、监控项。理解变量机制，是做出好用看板的关键。

在自定义看板之前，先理解几个常用的变量类型：

• Group（主机组）：查询所有主机组。在变量 Query 里写zabbix.group()
• Host（主机）：根据选中的主机组动态查询主机。Query 写zabbix.host($group)
• Application：根据主机动态查询应用集。Query 写zabbix.application($host)
• Item（监控项）：根据主机和应用查询具体监控项。Query 写zabbix.item($host)

我在实际配置时，最常用的是 group 和 host 这两个变量，分别对应看板左上角的两个下拉框。比如我要建一个“所有数据库服务器的 CPU 监控”看板，就会配置一个 group 变量（默认选数据库主机组），再配置一个 host 变量（默认选 All），这样后续所有面板会自动跟随这两个变量切换。

手动添加变量的路径：Dashboard Settings -> Variables -> Add variable。类型选择 Query，数据源选择 Zabbix，然后在上面的 Query 里填写对应的zabbix.xxx()函数即可。

4.3 自定义指标面板的配置细节

模板导入只能解决基础需求，真正要适合自己业务，还是得自己加面板。这里我分享一个从零创建 CPU 使用率面板的例子。

1. 点击看板右上角的 Edit Panel 进入编辑模式
2. 在 Query 区域，数据源选择 Zabbix
3. 在 Query Type 里选择 “Metrics” 或 “Item”，不同插件版本叫法略有不同
4. 点击 “Item” 输入框旁边的搜索按钮，选择对应主机的 CPU utilization 监控项。如果你配了 host 变量，可以直接用$host来做动态取值

配置完后，重点调整以下细节：

• 面板标题：建议写成像“数据库服务器 CPU 使用率”这种业务可读的描述，别直接用system.cpu.util之类的原始 key
• 单位（Unit）：CPU 使用率选择percent(0-100)，这样 Y 轴自动标 %
• 阈值（Thresholds）：添加阈值 80，颜色调成黄色，这样一眼能看到警戒线
• 图例（Legend）：如果需要同时展示多台主机，图例模式选择 “Table”，显示 Last/min/max 值

如果你想让多台主机显示在同一张图里，方法是把 host 变量的值设置为多选（Multi-value），然后在面板的查询里把 Host 参数绑定到$host。Grafana 会自动为选中的每个主机拉一条曲线。

4.4 用 Playlist 实现大屏轮播

监控大屏核心诉求就是“不用人盯，自动轮播”。Grafana 内置了 Playlist 功能，专门干这个。

创建 Playlist 的路径：Dashboards -> Playlists -> New playlist。添加你要轮播的看板，设置轮播间隔（比如 30 秒）。然后点右上角的 Start playlist，页面就会自动全屏轮播。

我把这个功能和前面做的多主机看板结合起来：大屏 30 秒切到数据库总览，30 秒切到核心服务状态，30 秒切到网络设备流量。全部自动播放，领导看一眼就知道当前系统健康度。这个效果用 Zabbix 原生页面很难实现，Grafana 里几分钟就搞定。

另外在 Grafana 的配置文件里可以设置playlist的默认间隔，但一般用前端设置就够了。

5. 告警联动与常见问题排查实录

5.1 Grafana 告警还是 Zabbix 告警

很多人接完 Grafana 之后会纠结一个问题：告警要不要也搬到 Grafana 来？

我的建议是：告警继续留在 Zabbix，Grafana 主要负责展示。理由很简单，Zabbix 的触发器、动作、升级流程已经非常成熟，你很可能已经有一堆良好的告警规则跑在生产上，没有必要为了“统一平台”去迁移，迁移过程本身就有风险。

当然，如果你想用 Grafana 的 Alerting 做统一告警，它也支持基于 Zabbix 数据源配置阈值告警。我实测过，在 Grafana 9+ 上，编辑面板切换到 Alert 页签就能新增规则，表达式选择查询的指标，配置阈值，然后配置通知策略。通知可以接钉钉 webhook、邮件、企业微信机器人等渠道。

不过要注意，Grafana 告警是“周期性查询你配置的数据源”来判断是否触发阈值，查询频率和 Zabbix 本身的触发器判断频率是两套体系。所以如果对告警实时性要求很高，还是建议继续用 Zabbix 触发器，Grafana 告警更适合做辅助监控或数据质量检查。

5.2 常见问题速查表

在实际使用中，我把大家踩过的坑整理成了一张速查表，方便你快速定位：

5.3 几个值得留意的细节

最后分享几个容易被忽略的细节，都是实操里验证过的。

一个是 Trends 模式。Zabbix 历史数据分两类：history 表存的是原始采样数据（几秒钟一条，量大），trends 表存的是小时级聚合数据（每一小时的 min/avg/max，量小）。插件默认在查询时间范围超过 7 天时会自动使用 trends 表，但如果你想明确控制，可以在数据源配置里设置 “Enable trends” 的阈值。我建议查询跨度超过 24 小时就优先走 trends，不然 Grafana 拉数的时候 Zabbix 数据库压力会很大。

另一个是查询性能。如果你同时在一个看板上放了很多面板，每个面板都对 Zabbix API 发起查询，并发量上去之后 Zabbix 服务器会有点吃不消。我的做法是把“总览型”大屏和“详情型”看板分开，总览大屏只放最核心的 6-8 个面板，详情页面再放具体指标，这样既保证大屏流畅，也不给 Zabbix 造成压力。

还有一个是权限。Grafana 里可以创建多个组织、多个用户，对不同团队开放不同看板。比如开发团队只需要看应用的 CPU 内存，可以只给他们只读权限访问某个 Folder。这个权限隔离在 Grafana 里做起来很顺手，建议不要所有同事共用一个账号。

对比一下 Zabbix 原生前端和 Grafana 的体验，最大的感觉是 Grafana 更像一个“产品”，而 Zabbix 更像一个“工具”。之前同事要看系统状态，我得截图发给他，现在直接给他一个 Grafana 链接，他自己下拉切换主机就能看。尤其是 Playlist 大屏模式，领导视察的时候确实撑得住场面。

如果你也想把 Zabbix 的展示层换掉，我建议按这个顺序走：先在线或离线装好插件，确认数据源连通，再导入模板跑通一条完整链路，接着按自己业务的指标慢慢加面板。最后提醒一句，装完插件记得重启 Grafana，改完配置文件记得验证grafana-cli plugins ls，这两步能避免八成以上的“为什么看不到插件”问题。