刚把Zabbix跑顺没多久，老板就甩过来一句"监控大屏再做好看点"，估计不少人跟我一样卡在这。Zabbix本身采集、告警、自动发现都是一把好手，但图表展示这块着实让人挠头，尤其是想在一个画面里横向对比几十台主机、把监控数据做成汇报大屏的时候，原生的Graph功能就有点力不从心了。后来我试着把Grafana和Zabbix对接起来，用Grafana统一做展示层，Zabbix继续干它最擅长的数据采集，效果立竿见影。这篇文章就把我整理的完整对接方案、查询建模思路和排查经验分享出来，不管是刚装好Zabbix、想学Grafana使用教程的新手，还是已经在生产环境跑着Zabbix、苦于展示效果的老运维，照着做都能少走不少弯路。

1. 为什么非要把Zabbix数据搬进Grafana看

先聊个基本问题：Zabbix监控系统本身不是不能画图，它自带Graph、Screens、Dashboards，中小规模用着也算顺手。可一旦环境复杂起来，几个硬伤就特别明显。

第一是多主机对比困难。Zabbix原生的图形要对比多台服务器的CPU使用率，要么逐个添加监控项，要么靠Screen硬拼，图表之间互相独立，缺乏"拉到同一张图里光滑对比"的体验。我要做的是一个总览页，把核心服务器、数据库实例、网络交换机的关键指标放在同一张图上，Zabbix原生方案实现起来极其别扭。

第二是Dashboard的灵活性差。Zabbix的Dashboard虽然更新到7.0之后进步明显，但跟Grafana比还是差了一截。Grafana的模板变量、联动筛选、图表类型丰富度（时序图、表格、热力图、状态历史、仪表盘）都更成熟，尤其做监控大屏的时候，Grafana的优势是碾压级的。

第三是告警与展示分离的价值。很多团队已经有了一套跑得不错的Zabbix告警体系，媒体类型、通知渠道都配好了，这时候没必要把告警迁走，只需要把数据展示独立出来。Grafana正好提供这个"展示层"，它不碰Zabbix告警逻辑，只通过API读数据。而且如果你想把告警也统一纳管，Grafana Alerting同样能用Zabbix数据源做规则判断，两条路都走得通。

还有一点是我后来才体会到的：Grafana不是把数据搬走，而是"借"数据。它通过Zabbix API实时请求监控项的历史数据和趋势数据，自己并不存一份副本。这意味着Zabbix上已有的历史数据、自动发现结果、自定义监控项，全都能无缝在Grafana里使用，不用做任何ETL，也不用担心数据同步延迟。Zabbix负责采集和执行，Grafana负责把结果翻译成人能一眼看懂的画面，这个分工非常合理。

适用场景也很明确：数据中心机房有一块大屏；运维团队每周要做巡检报告但不想考手动截图；公司有多套监控系统（比如既有Zabbix又有Prometheus Grafana），想统一入口。遇到这些需求，Zabbix原生的展示功能基本都会被淘汰，对接Grafana几乎是绕不开的正解。

2. 环境准备与版本选型：这些坑我替你踩过了

对接方案整体不复杂，但版本匹配这件事上我吃了不少苦头，先说结论。

Grafana侧只要用较新的大版本就行，真正影响兼容性的是那个桥接插件：alexanderzobnin的grafana-zabbix数据源插件。这个插件是社区维护、Grafana官方市场收录的，目前活跃度很高，Zabbix 5.0到7.x都支持。如果你用的是Zabbix 6.0以上版本，建议优先选择支持API Token的插件版本，因为Zabbix 6.0强化了Token认证，比用户名密码方式更可控。

我建议的搭配组合大概是这样（实测过，稳定）：

部署架构上有三种情况，你按现状对号入座。

情况一：Zabbix已经装好，只想加Grafana。这种最省事。只需要把Grafana单独部署起来，装插件、配数据源就能用，Zabbix那边不用动。我给测试环境用的就是这个方案，一台轻量云主机跑Grafana容器，装插件、配好数据源，前后不到半小时。

情况二：全新部署。建议用Docker Compose把Grafana和Zabbix一起编排。需要注意Zabbix的Server、Web、DB、Agent是四个服务，Compose文件里要同时定义。我贴一个最小可跑的简化版结构：

version: '3' services: zabbix-server: image: zabbix/zabbix-server-mysql:alpine-6.4-latest environment: - DB_SERVER_HOST=mysql-server - MYSQL_DATABASE=zabbix - MYSQL_USER=zabbix - MYSQL_PASSWORD=zabbix_pwd - MYSQL_ROOT_PASSWORD=root_pwd ports: - "10051:10051" depends_on: - mysql-server zabbix-web: image: zabbix/zabbix-web-nginx-mysql:alpine-6.4-latest environment: - ZBX_SERVER_HOST=zabbix-server - DB_SERVER_HOST=mysql-server - MYSQL_DATABASE=zabbix - MYSQL_USER=zabbix - MYSQL_PASSWORD=zabbix_pwd - PHP_TZ=Asia/Shanghai ports: - "8080:8080" mysql-server: image: mysql:8.0 environment: - MYSQL_DATABASE=zabbix - MYSQL_USER=zabbix - MYSQL_PASSWORD=zabbix_pwd - MYSQL_ROOT_PASSWORD=root_pwd grafana: image: grafana/grafana:11.0.0 environment: - GF_INSTALL_PLUGINS=alexanderzobnin-zabbix-datasource ports: - "3000:3000"

注意那个GF_INSTALL_PLUGINS环境变量，Grafana容器启动时会自动去官方市场拉取插件，这是我最推荐的安装方式，省去手动敲命令的步骤。

情况三：服务器不能访问外网。内网环境很常见。这种情况需要在一台能联网的机器上先把插件下载成zip包，然后手动拷贝到Grafana的plugins目录：

wget https://github.com/alexanderzobnin/grafana-zabbix/releases/download/v4.9.2/alexanderzobnin-zabbix-datasource-4.9.2.zip unzip alexanderzobnin-zabbix-datasource-4.9.2.zip -d /var/lib/grafana/plugins/ chown -R grafana:grafana /var/lib/grafana/plugins/ systemctl restart grafana-server

如果你用容器方式，也可以把zip文件volume挂载进容器里，然后重启容器。插件安装后务必重启Grafana，不然数据源列表里看不到。

还有个小坑：Zabbix侧如果开了SELinux，Grafana服务器去请求Zabbix API时可能被拦截，请求超时或者Connection Refused。我遇到"zabbix server is not running: the information displayed may not be current"这类提示的时候，一开始以为是Zabbix服务起不来，后来排查发现是SELinux策略拦截了Grafana侧到Zabbix Web端口(8080/443)的访问。遇到类似问题先用curl -s http://zabbix-server/api_jsonrpc.php测连通性，如果连不上再看防火墙和SELinux，别急着怀疑Zabbix本身。

3. 数据源插件安装与认证配置：一条一条说清楚

插件装的姿势五花八门，但核心路径是固定的三步：装插件、重启Grafana、配置数据源。

3.1 安装插件

Grafana镜像里通过GF_INSTALL_PLUGINS自动安装已经提到过。如果是传统安装包方式，直接用命令行：

grafana cli plugins install alexanderzobnin-zabbix-datasource systemctl restart grafana-server

不用管这个插件的名字为什么这么长，记住它是alexanderzobnin维护的就行。搜索的时候别搜错成Zabbix官方插件，Zabbix官方没有为Grafana出数据源插件，这个社区插件就是事实标准。

3.2 创建Zabbix API用户

建议不要用Zabbix的Admin账号去对接Grafana。生产环境里大家都用同一个Admin账号，一旦在Grafana侧泄露，等于把Zabbix控制权交出去。正确做法是在Zabbix里创建一个专用账号，只给读权限。

我的习惯是：

1. 在Zabbix前端进入"Users" → "Create user"。
2. 用户名随意，比如grafana_read，群组选Zabbix administrators或者自定义一个只读群组。
3. 权限方面，如果你只想看某些主机组，在"Permissions"里按主机组分配Read权限；如果图省事，用Zabbix administrators也行，但只读风险自己评估。
4. 在Zabbix 6.0+里，进入"User settings" → "API tokens"，生成一个Token，复制保存。这个Token就是Grafana侧用来认证的凭证。

用Token比用密码的好处是：Token可以在Zabbix端随时吊销重建，不用改密码；而且Token关联的是具体用户，可以精确知道是谁在调API。

3.3 Grafana侧配置数据源

登录Grafana，进入"Connections" → "Data sources" → "Add data source"，搜索"Zabbix"，选Zabbix类型。

关键配置项填这些：

• URL：填Zabbix前端的API地址，格式是http://zabbix-web地址/api_jsonrpc.php。注意api_jsonrpc.php是固定路径，不是/api也不是根路径，填错了测试大概率报404。
• Basic Auth：如果用的用户名密码方式，打开Basic Auth填用户名密码；如果用API Token，我记得新版本插件可以直接在认证选项里选Token，然后把Token填进去。不同版本插件填写位置略有差异，有的版本是"Username and password"，你可以分别填API token为用户名、Token本身为密码，效果都一样。
• Trends from：这个选项决定多长的时间范围查询用趋势数据而非历史数据。我一般填7d，意思是超过7天的图表查询走Zabbix的趋势数据（每小时聚合的分钟级数据），7天以内的走历史数据（原始数据）。这个后面第8节会细说。

填完之后点"Save & test"，能看到"Successfully connected"就通了。如果报错，把重点放在下面几个方向：

• URL是否写对，尾部是否带api_jsonrpc.php。
• 用户名密码/Token是否正确。Zabbix 6.0之后如果连续输错密码，账号会被锁定30秒，测试时别反复狂点。
• 网络连通性：Grafana机器能不能访问到Zabbix Web端口，用curl验证。

这里就是热搜里"zabbix access denied for user 'replace_user'@'localhost'"这类问题的多发区。看过一些生产环境，所谓Access Denied不一定是密码错，更常见是数据库用户不对，比如Zabbix Web连MySQL的用户被写错，导致Zabbix都登录不进去。别在Grafana侧死磕，先确认Zabbix自己的Web界面能正常登录，再回头排查Grafana数据源。

4. 从零创建第一个Zabbix数据面板

配置好数据源，接下来就是最爽的部分——拉数据、出图。我带你走一遍从新建仪表盘到面板出数的完整流程。

4.1 创建仪表盘并选择数据源

Grafana左侧"Dashboards" → "New" → "New dashboard"，然后点"Add visualization"，系统会让你选数据源，选那个Zabbix。

页面会进入面板编辑态。这时候最左边是查询编辑器区域，中间是图表预览，右边是面板设置。Zabbix数据源插件提供的查询编辑器是向导式的下拉框，不像PromQL那样要写表达式，对新手极其友好。

查询编辑器的核心是四层联动选择：

• Group：主机组，比如"Servers"、"Network devices"。如果留空/.*/表示所有组。
• Host：主机，选了主机组之后这里才会出现该组下的主机列表。
• Application：应用集（可选），按需过滤。
• Item：监控项，这是最底层，选中之后右侧会出现该监控项的数值配置。

以显示一台Linux主机的CPU使用率为例子：Group选"Servers"，Host选你的主机名，Item搜索框输入"cpu"或"util"，插件会把匹配的监控项列出来。选中有CPU utilization字样的项，中间预览区应该马上出曲线。

4.2 历史数据和趋势数据的选择

查询模式默认是"History"也就是历史数据，模式里还有一个"Trends"选项，对应第3节说的趋势数据。

这两个模式的区别要说清楚，因为它直接影响出图精度：

• 历史数据：Zabbix按监控项的Update interval收集的原始数据，精度最高，但Zabbix默认只保留7天（你可以改）。
• 趋势数据：Zabbix每小时对过去一小时的数据做一次聚合，存最大值、最小值、平均值、计数，保留时间默认365天，精度只能到小时级。

所以看最近几小时的CPU波动，用History；看一个月、一年的趋势走势，用Trends，否则要么数据被清了，要么查出来的图到处是坑坑洼洼。

4.3 面板设置与单位校正

图表出来之后，右边Panel options里把Title改成"CPU使用率"，然后重点设置Unit。Zabbix返回的CPU利用率数值可能是百分数也可能是小数，我遇到过Zabbix自定义监控项返回值是0到1，而自动发现的是0到100，面板里显示就非常奇怪。在"Standard options" → "Unit"里选Percent (0-100)，如果发现数值是0到1，选Percent (0.0-1.0)这里还是要你们自己去试，我建议养成好习惯，在Zabbix里配监控项时就统一口径，别等出了图再强行改单位。

4.4 快速导入现成模板

自己从零一张一张配面板太累了，Grafana生态里有很多别人分享好的Zabbix仪表盘。

在Grafana市场或者Grafana的"Dashboards"页面搜索"Zabbix"，能看到一大批现成模板，通过Dashboard ID一键导入：

1. "Dashboards" → "New" → "Import"。
2. 输入仪表盘ID（比如8900这种数字），点Load。
3. 选择你的Zabbix数据源，Import。

如果你看到别人分享的是一个JSON文件，也可以直接在Import页面粘贴JSON内容导入。这里回应一下热搜里那个"grafana 拷贝整个面板"的需求——在Grafana任意一个面板右上角菜单里选择"More" → "Copy"，然后在另一个仪表盘里"Paste"就行，非常快，多环境复制面板再也不用手动重新选查询条件了。

5. 查询建模与变量联动：从一个面板到一套多主机全景

单面板看一台主机的CPU没有质的提升，Grafana真正的杀手锏是模板变量和跨主机聚合。

5.1 用模板变量实现主机切换

假设你配了一组CPU、内存、磁盘的面板，希望一台上线所有主机都能用，而不是每台主机复制一遍。做法是在仪表盘层面建模板变量：

1. 进入仪表盘设置"Dashboard settings" → "Variables" → "Add variable"。
2. 变量类型选"Query"，数据源选Zabbix，查询类型选"Host"。
3. 这样你就能在下拉框里动态选择主机，而且可以把主机组也做成变量，实现"先选主机组，再选该组下的主机"的联动。

在面板查询编辑器的Host下拉框里直接引用$host变量，当你在仪表盘顶部切换主机时，所有引用这个变量的面板都会自动刷新数据。这套机制是Grafana模板变量体系的核心，理解之后可以衍生出无数玩法：按业务线筛选、按机房筛选、按标签筛选。

5.2 多监控项合并在同一张图

Zabbix查询编辑器里，添加一个查询组里的多个Item，它们就会自动叠加在同一张图上。我做数据库服务器总览面板时会一次性把CPU、内存使用率、磁盘IO、网络流量全部加到一张时间序列图里，用图例区分不同指标。

如果某个面板想同时看多台主机的同一个监控项，也简单：在Host下拉框里多选。插件会生成多个查询序列，每一台主机一条线。注意这种做法对Zabbix API的压力是线性的，别在同一个面板里放30台主机的20个监控项，那会变成600条查询序列，直接把浏览器画崩。我自己的经验是单个面板控制在300个时间序列以内，超过就拆面板。

5.3 值映射与问题状态面板

Zabbix很多监控项是状态型的，比如某个返回1/0的探活项，还有告警状态、Agent可用性。这些数值直接画折线图完全没有意义，应该用Grafana的Value Mappings把它们翻译成人类语言：

1. 面板类型选"Stat"或"Table"。
2. 在"Standard options" → "Value mappings"里添加映射：0 → "DOWN"（红色），1 → "UP"（绿色）。

这样监控大屏上一排绿色的UP和红色的DOWN一目了然，比看一条01折线舒服一百倍。触发的状态（OK/INFO/WARNING/AVERAGE/HIGH/DISASTER）也建议按这种方式映射，大屏效果会大幅提升。

5.4 问题面板：直接展示Zabbix告警

grafana-zabbix插件内置了一个Problems查询类型，可以直接拉取Zabbix当前的告警/问题列表，并显示主机、严重级别、时间、状态。这个面板放在总览大屏最上方，远处一看就知道有没有待处理的故障，非常实用。

配置方式：新建面板，数据源选Zabbix，查询类型切到"Problems"。可以按主机组、主机、问题标签做过滤；还能在"Options"里设置只显示特定的严重级别。它读的是Zabbix的问题表，不是Grafana的告警，所以Zabbix的触发器和告警配置依然是你唯一的告警源，Grafana只负责展示，架构非常清晰。

6. 监控大屏实战：布局、分组和网络设备展示

从单面板到完整大屏，有几个布局经验值得单独拿出来讲，尤其是网络设备（交换机、路由器）这块，很多新人不知道怎么展示。

6.1 大屏布局的基本方法

监控大屏不是面板的胡乱堆砌。我在生产环境总结出来的一个适用性很广的布局套路：

• 最上层一行：当前告警状态。用Problems面板，红色高亮未处理告警。大屏观众一眼能看到整体健康度。
• 中间区域：核心指标趋势图。CPU、内存、网络流量等时序图，尺寸要大，重点看波动。
• 最底层：明细表格。展示每台主机每个关键指标的最新值，配合健康状态。

实现"固定大屏比例"有一个关键设置：仪表盘设置里把"Docker"或"System"时间范围固定，把Dashboard的"Auto fit"关掉，然后在"Panel options"里手动设定各面板宽高，导出时就不会错位。

6.2 交换机监控数据的处理

热搜里"zabbix监控交换机"这个话题很常见。Zabbix通过SNMP自动发现交换机的端口、流量、光功率，这些监控项同样会在Grafana里出现，不需要额外配置。

但交换机监控有个天然难点：端口太多了。一台48口交换机，光接口加电口可能有六七十个监控项，如果全都拉出来，面板直接变蜘蛛网。我建议按端口类型建变量：

1. 把交换机的"接口流量"这一类Item打上应用集标签，比如Net、Interface。
2. 在Grafana查询编辑器里用Application过滤，先只看流量这个应用集。
3. 用正则或者变量把端口名做成下拉框，比如$port变量可以选GigabitEthernet0/0/1这种。

默认模板（Zabbix自带的Template Net Cisco等）监控项命名格式比较统一，配合Grafana的变量正则过滤，效果好到能拿来当售前demo。

6.3 时间范围统一

监控大屏的大忌是各个面板时间范围不一致，左边看15分钟，右边看6小时，观感非常割裂。记得在仪表盘右上角设置统一时间范围，通常用"Last 6 hours"或者"Last 24 hours"，再开右上角的"Refresh"自动刷新（比如每30秒刷一次）。

大屏模式下Grafana会自动隐藏鼠标悬停的详细信息，默认只展示曲线和数值。如果某个面板希望大屏上也显示图例，可以在面板设置里把Legend模式改成values列表，并固定显示最后几个数据点，这样屏幕下方会有一排实时数值，汇报的时候很加分。

7. 告警联动：Grafana告警和Zabbix告警怎么分工

很多人对接完数据展示之后，下一个需求就是把告警也串起来。这里有个常见的认知误区，我先讲清楚：

Grafana对接Zabbix之后，并没有接管Zabbix的告警能力。Zabbix的触发器、动作、媒介类型依然是独立运行的。Grafana只是读取数据，它不会自动复制Zabbix的告警规则。

所以你的告警架构有两种选项：

7.1 方案A：Grafana Alerting统一告警

如果你希望所有监控数据（包括Zabbix、Prometheus、云监控）都在Grafana里做展示和告警，那就用Grafana的Alerting功能，用Zabbix数据源作为告警规则的数据查询源。

配置要点有这几个：

1. "Alerting" → "Alert rules" → "New alert rule"，条件里选Zabbix数据源。
2. 查询表达式可以直接引用Zabbix监控项，比如查CPU利用率，设置阈值> 85。
3. 通知渠道用"Contact points"，Grafana可以接钉钉、企业微信、飞书、Webhook等。热搜里提到"grafana接入alertmanager告警"也是类似思路，Grafana的告警可以路由到Alertmanager再往下分发。

这个方案的收益是告警规则和展示面板可以共用一套数据源，告警历史也在Grafana里统一查看。隐患是：如果Zabbix本身的采集断了，Grafana可能因为"No data"误报——一定要在告警规则里加"NoData"和"Error"的执行策略，我一般设置成告警而不是保持OK，避免故障时反而静默。

7.2 方案B：Zabbix告警只做通知，Grafana只做展示

如果你的Zabbix告警体系已经跑得很稳，比如Zabbix 7.0联动钉钉这类配置都已经是现成的，那就别把告警逻辑搬到Grafana，让Zabbix继续负责告警，Grafana只负责"看"。这时Grafana里的Problems面板就是你观察告警的窗口，双剑合璧，各司其职。

这套方案最省心：无需迁移告警规则，不会产生两个告警系统规则不一致的问题；告警通知延迟保持在Zabbix原生水平；Grafana挂了也不影响告警下发。很多大型团队实际上都是这么干的。

7.3 我的经验：先展示后告警，别一上来就搞大迁徙

我的建议是第一次对接Grafana和Zabbix时，先只用Grafana做展示和Problems大屏，跑一段时间，确认数据源稳定、查询性能可接受，再考虑要不要把告警逻辑迁到Grafana Alerting。告警是安全生产的红线，不要在迁移初期就把所有鸡蛋放进一个新篮子里。

另外要特别提醒：如果你在Grafana里创建了基于Zabbix数据源的告警规则，它默认也是长期轮询Zabbix API的，压力比普通展示查询大得多。告警规则里的查询间隔不要太短，1分钟一次已经是极限，常见的用2-5分钟。不然Zabbix API被高频打穿，前端页面都打不开，你就知道什么叫"监控系统把自己监控挂了"。

8. 常见问题排查：从连不上到图表空白的完整链路

这一节列几个我在实践中高频踩过的坑，每一条都是一把血泪史。

8.1 数据源测试报错，或者面板显示No data

这是最最常见的。排查链路从外到里：

1. 先确认Zabbix Web本身能登录。如果Zabbix页面都进不去，而且报"zabbix server is not running: the information displayed may not be current"，这是Zabbix服务端到数据库（MySQL/PostgreSQL）连接出问题。先去Zabbix服务器上执行systemctl status zabbix-server，看是不是服务挂了，再看数据库连接和磁盘空间。我遇到过一次是MySQL分区表把磁盘写爆了，Zabbix Server直接起不来。
2. Zabbix正常但Grafana还是连不上：用curl在Grafana服务器上请求Zabbix API，看返回。返回正常的JSON就说明网络通，问题在Grafana数据源填写的URL或者认证信息；返回超时就查防火墙、SELinux。
3. 数据源显示Connected但面板No data：这是权限问题最典型。你配置的API用户如果没有对应主机组的读权限，API返回空列表，Grafana拿不到数据自然No data。这时候去Zabbix里把用户权限加到对应主机组的Read即可。
4. 时间范围问题：你当前时间是2025年，如果把面板时间范围调到"Last 5 minutes"，而Zabbix留的历史数据刚好被清理了，会查不到数据。可以先切到"Last 24 hours"看看有没有。
5. 单位/类型问题：查到的数值明显不对，检查监控项返回类型是浮点还是整型，以及在Grafana里的单位设置。

8.2 grafana failed to upgrade legacy queries datasource was not found

这个报错我在升级Grafana大版本时碰到过，说的是"数据源引用了旧版本的查询格式，但对应数据源找不到了"。

原因通常是：旧Grafana里配置了一个Zabbix数据源，但插件被卸载、重装或目录变化后，数据源ID变了，遗留面板还在引用旧的datasource名称。解决思路很直接：

1. 去"Connections" → "Data sources"里确认Zabbix数据源当前叫什么名字。
2. 打开报错的面板JSON，看datasource字段写的是哪个引用，把旧的"type"和"uid"改成现在的。懒得改JSON的话，直接把面板删除重建更快。
3. 如果所有面板都报这个错，可以考虑在Grafana数据库里删掉旧数据源记录，清理后重新添加，然后逐个打开面板确认。

8.3 图表数据总是有一个时间偏移

Zabbix存储的时间戳和Grafana界面显示差了几个小时。这个基本是时区配置不一致导致的。Zabbix前端配置的PHP时区（php_value[date.timezone]）和我用的国内服务器是East 8，Grafana也需要在配置文件的default_timezone里设定。两边时区统一之后，图上时间戳就正常了。

8.4 聚合后数据变成一条直线

有的监控项，每隔5分钟才更新一次，你用Grafana看Last 15分钟，返回的样本只有3个点，画出来跟折线没区别。另一个情况是，聚合函数选成了avg但监控项本身数值波动极短，平均值会把尖峰平滑掉。遇到曲线异常平滑或特别平直，先在查询编辑器里确认单独的历史数据点数量。监控项采集周期、Grafana时间范围和聚合区间这三者要匹配，我通常看一眼"Query Inspector"确认实际返回多少数据点，再决定调整查询方式。

9. 性能优化与多环境使用经验

最后说说上线之后稳不稳的问题，这部分是我最想写但多数教程不愿细讲的。

9.1 用趋势数据扛长期大屏

生产环境里最怕有人拖个"Last 30 days"的图，又选了History模式，结果Zabbix历史数据只保留7天，图上是空的。正确做法是设置好数据源里的"Trends from"，我设为7d，意思是7天以上的查询自动走趋势数据。趋势数据是一小时的聚合，画30天的日均CPU，精度足够。

9.2 控制API负载

Zabbix API并不擅长被高频大范围轮询。几个具体建议：

• 面板数量不要无节制堆，一个仪表盘里几十个面板对浏览器和API都有压力。
• 每面板查询序列控制在300以下。
• 自动刷新周期别低于30秒。
• Grafana里"Date range"如果很长，插件会按每像素点聚合数据，减少返回的数据量，这一点插件已经优化了，但API层仍然需要查监控项元数据。

如果Zabbix是单机部署、设备量在500台以内，这么用问题不大。设备量更大建议给Zabbix Server加配置好的缓存，别把监控项的数量级和查询频率同时拉满。

9.3 多套Zabbix同时接入

有的公司有多个机房、多套Zabbix，比如内网一套，办公网一套。Grafana支持添加多个数据源实例，你可以分别命名Zabbix-机房A、Zabbix-机房B。在同一条查询里没法跨数据源聚合（不同数据源之间用联合查询不现实），但可以分别做面板，再通过模板变量切换。

多套环境接入还有一个坑：主机名会重复。机房A和机房B可能都有一台叫web-01的主机。建议在Zabbix的主机命名上加前缀，或者在Grafana的仪表盘级别加一个"环境"变量，每个环境对应用户权限和主机组。

9.4 插件升级顺序

grafana-zabbix插件迭代很快，但它升级时不时会改数据源类型ID或面板内部逻辑，升级了插件后旧面板可能会有兼容性问题。我的流程是：

1. 先在测试Grafana上升级插件，用测试面板验证。
2. 确认没问题再在生产环境升级插件。
3. 升级完立即访问几个核心大屏，重点观察查询编辑器是否正常、数据源测试是否通过。
4. 万一出现数据源 not found 或者查询错误，回到上节说的方法处理。

千万别手贱在生产环境直接升级后就不管了。我一个同事就是因为升级后没验证，第二天老板打开大屏发现全是No data，差点上事故通报。

9.5 最后说点题外话

对接这事做完之后，我最大的感受是：监控系统的本质不是"工具越多越好"，而是把数据、告警、展示这三件事分清楚。Zabbix管数据采集和告警逻辑，Grafana管展示和交互，二者通过API轻耦合，各干各擅长的，比在Zabbix里硬憋大屏或者在Grafana里硬造采集，都健康得多。

如果你接下来想继续深挖，可以从模板变量高级用法、Grafana告警路由、Zabbix自动发现与Grafana标签的联动这几个方向入手。等你把整套做顺了，再回头看最初那个"监控大屏做得好看点"的需求，会发现不过是复制两张仪表盘的事。