搞运维监控的基本都逃不开Zabbix和Grafana这两个名字。Zabbix负责采集和告警Grafana负责把数据画出来看。我这两年接过两个以“Zabbix大屏”为核心的需求一个是把几十台线上主机的CPU、内存、磁盘、网络全部从Zabbix原生界面搬出来做成一整块投到办公室电视上的运维大屏另一个是业务方非要把Zabbix的监控数据和Prometheus的容器指标放在同一个看板里对比。两个需求最后都落在同一个方案上Grafana对接Zabbix数据展示。这篇文章就是我完整落地一遍的记录。会讲清楚插件版本怎么选、API账号怎么开、查询怎么写、大屏怎么排还有我踩过之后印象最深的几个报错到底是什么意思、怎么处理。如果你正准备把Zabbix的数据展示这块从原生界面挪到Grafana或者已经在Grafana里加了Zabbix数据源但面板总出不来数这篇文章应该能让你少走不少弯路。1. 为什么非要把Zabbix的数据搬到Grafana先说结论Zabbix本身不是不能看数据而是它“能看”和“好看”之间差了十万八千里。我遇到过很多同事一听到“Grafana对接Zabbix”就先反问一句“Zabbix不也能画图吗何必多此一举”。这句话本身没错但真实场景里理由往往比想象中硬得多。1.1 Zabbix原生界面到底差在哪Zabbix的强项从来都是采集、模板、触发器和告警这整套体系而它的前端界面是给“配置管理”服务的不是给“数据展示”服务的。你在Zabbix里看一个监控项的历史图形没问题但想在同一个页面里把几十台主机的CPU、内存、磁盘、网络叠在一起看Zabbix原生界面就会变得很别扭。Zabbix也有Dashboard和Map但做出来的效果始终带一股“系统默认模板”的味道。想调个颜色、排个版、加个百分比阈值线要么操作路径藏得很深要么功能根本没开放。更关键的是Zabbix的图形组件是它自己封装的一套渲染逻辑想要把多个主机的数据叠加对比、做top排序、自定义聚合写起来非常费劲。我最早在Zabbix里试过大屏方案做到一半就放弃了因为一个大屏页面上要放的图太多Zabbix前端勉强拼出来后刷新一次要等好几秒。还有一个现实问题如果你们公司同时用了Zabbix和Prometheus或者还有一套业务系统的数据库指标那运维看板就得开好几个系统来回切换。虽然Zabbix也能接外部数据源但集成成本比Grafana高得多。与其在Zabbix里硬凑不如把展示这层单独拆出来。1.2 Grafana这边能补什么Grafana从一开始就是为“多数据源可视化”设计的。它不会替代Zabbix去采集数据而是通过Zabbix API把监控项、历史数据、触发器告警读出来然后用自己那套成熟的面板体系来展示。具体能补的东西我总结成三点。第一是面板类型丰富时间序列图、Stat卡片、柱状图、表格、仪表盘、日志面板都有做大屏的时候排版自由度很高。第二是模板变量非常灵活选一个主机组下面所有主机的数据就联动变了这在Zabbix原生界面里做起来很费劲。第三是Grafana可以同时加多个数据源把Zabbix的数据和Prometheus、MySQL、Loki的数据放在同一个Dashboard里对比这在跨技术栈排障和复盘时太有用了。另外Grafana的分享能力也很实用。Dashboard可以设置只读链接嵌入到内部工单系统或者门户首页领导要看的“监控大屏”就是浏览器开个页面投屏的事。Zabbix的告警触发、模板管理这些核心能力继续留在Zabbix里跑Grafana只做展示层两者各干各擅长的这本身就是一套很健康的架构。1.3 适合什么场景又不适合什么场景我自己的项目经验下面这几类场景特别适合把Zabbix数据搬到Grafana运维监控大屏。投影仪或者电视墙上长期展示需要美观、色块化、一眼能看出整体健康度这是Grafana最擅长的。多套监控体系统一视图。比如Zabbix管传统服务器和网络设备Prometheus管Kubernetes容器两边指标要放在一起对比排障。周期性汇报和复盘。给管理层展示容量趋势、业务高峰、故障时间线Grafana的时间范围切换和局部放大比Zabbix舒服。跨系统联动。把Zabbix的监控数据和业务库里的订单量、在线人数放一起看基础设施指标和业务指标是否相关。反过来有几类事情我不建议硬塞到Grafana里。主机新增、模板绑定、监控项配置、触发器规则调整这些操作必须在Zabbix前端完成Grafana只是“看数据”的地方不是“配监控”的地方。另外如果需要精细查看单个监控项在某个秒级时间点的原始取值Zabbix原生的“最新数据”和“图形”页面其实更直接因为Grafana的Zabbix插件默认拉的是历史和趋势数据粒度会受保留策略限制。记住一个原则Grafana对接Zabbix数据展示是为了让数据更好看、更好比而不是为了替代Zabbix。明白这一点你后面做架构决策时就不会跑偏。2. 对接前的准备版本匹配、插件安装与API账号很多人在这一步就翻车了原因很简单Grafana、Zabbix插件、Zabbix服务端三者的版本互相不匹配导致插件装上之后要么无法启用要么查询一直报错。这一节把我这边验证过的版本组合和操作步骤完整写出来。2.1 版本匹配别一上来就装最新Grafana的数据源插件和InfluxDB、Prometheus这类直接通过HTTP拉数据的插件不太一样它是通过调用Zabbix的JSON-RPC API来工作的。Zabbix每个大版本的API会有方法增减插件如果不跟进很容易出现“能连上但取不到数据”的诡异问题。我当前项目用的是一套比较保守的组合Grafana 10.x或者11.x搭配Zabbix 6.0 LTS或7.0 LTS插件版本选alexanderzobnin/grafana-zabbix的4.4.x及以上。这个组合我实际跑下来比较稳。如果你还在用Grafana 8甚至更老那就别强求新版插件老老实实用3.9.x左右的旧版否则插件和Grafana自身API对不上启动都启不来。注意Zabbix 7.0发布后API地址和方法整体和6.0兼容性很好插件4.4.x直接支持不用额外适配。但Zabbix 5.x以及更早的版本如果要对接新版插件建议先查插件文档确认支持情况别想当然。2.2 安装grafana-zabbix插件插件的官方名称是alexanderzobnin-zabbix-app在Grafana插件市场里直接搜“Zabbix”也能找到作者是alexanderzobnin。安装有两种方式一种是命令行一种是手动下载zip解压到插件目录。命令行安装最省事grafana-cli plugins install alexanderzobnin-zabbix-app systemctl restart grafana-server装完之后打开Grafana界面在“Connections”或者老版本里的“Configuration”菜单下面找到“Plugins”搜索Zabbix点进去会看到一个“Enable”按钮。这个动作很多人会漏掉结果数据源类型里一直找不到Zabbix的选项。这里还有一个关键点新版Grafana10和11把数据源管理挪到了“Connections”目录下如果你用的还是老的“Configuration Data Sources”路径界面会不一样。加上这个插件本身带一个“App”启用后还会自动生成一套示例Dashboard方便你快速验证数据能不能通。如果你在线安装失败多半是grafana-server无法访问外网插件仓库。这时候去GitHub上插件仓库的release页下载对应版本的zip传到Grafana服务器的/var/lib/grafana/plugins目录下解压然后重启Grafana。自己手动装的插件如果提示未签名还需要在grafana.ini里的[plugins]配置段加一行allow_loading_unsigned_plugins alexanderzobnin-zabbix-app再重启生效。2.3 在Zabbix里创建一个只读API账号这一步是很多人忽略的但直接影响权限边界和安全。直接拿Zabbix的Admin账号填到Grafana数据源里当然能跑但这样Grafana就有了Zabbix的完全控制权万一Dashboard被人误改查询条件或者网页端被盗用风险是很大的。我一般会在Zabbix前端单独开一个用户比如用户名grafana-read密码设一个复杂点的。然后在“用户角色”里给它分配一个合适角色如果你对权限不敏感可以直接挂在默认的“User”角色下但更严谨的做法是在“用户”页面新建一个用户组只给“读”权限然后把这个用户加进去。具体权限配置参考这几个步骤在Zabbix前端进入“Users”或者“Administration Users”新建用户用户名、密码填好。在“Permissions”或者“User roles”里把用户加入一个有读取权限的用户组。如果只监控部分主机组就在用户组的权限设置里选择“Selected host groups”只勾选需要展示的组权限选“Read”。如果是Zabbix 6.0以上版本还可以在用户详情里创建“API token”把token填到Grafana数据源里连密码都不用暴露。我还建议给这个API用户一个独立的用户组而不是复用Admin的组这样以后排查问题能一眼看出是哪边在调用Zabbix API。2.4 用curl先验证API通不通在填Grafana数据源之前先手动调一下Zabbix API确认前端地址、账号、端口都没问题。这一步能把问题隔离得很干净否则你后面排查半天“为什么面板没数据”结果发现是网络都不通。Zabbix的API入口是统一的一个地址默认是http://你的zabbix服务器地址/zabbix/api_jsonrpc.php。如果Zabbix装的是默认包前缀一定要带/zabbix这是最容易漏掉的地方。先用一个无认证的接口测连通性curl -s -X POST http://127.0.0.1/zabbix/api_jsonrpc.php \ -H Content-Type: application/json-rpc \ -d {jsonrpc:2.0,method:apiinfo.version,params:[],id:1}返回类似{jsonrpc:2.0,result:7.0.6,id:1}就说明API地址没错。接下来用API账号登录测试curl -s -X POST http://127.0.0.1/zabbix/api_jsonrpc.php \ -H Content-Type: application/json-rpc \ -d {jsonrpc:2.0,method:user.login,params:{username:grafana-read,password:你的密码},id:2}正常会返回一个session字符串。如果你用的是API token方式那就改成在请求头里加Authorization: Bearer 你的token不需要再走user.login。如果curl这步都通不过先别碰Grafana。检查防火墙、Zabbix前端服务状态、PHP-FPM是否正常运行还有如果是HTTPS证书是否被信任。这些问题在Grafana侧是查不出结果的。3. 数据源配置、查询写法与面板搭建前面的准备工作做完Grafana里能添加Zabbix数据源了接下来就是真正干活的部分配置数据源、写查询、建面板。这一节我按实操顺序写尽量让每一步都直接可复现。3.1 添加Zabbix数据源在Grafana里进入“Connections Data sources”点击“Add data source”搜索Zabbix选中那个带“alexanderzobnin”标识的Zabbix类型数据源。这里只有一个Zabbix别选成Zabbix的其他第三方数据源。填写几项关键配置URL填Zabbix前端的API地址例如http://127.0.0.1/zabbix/api_jsonrpc.php。Username / Password填刚才创建的grafana-read账号和密码如果用API token可以直接不填密码在对应的token字段里填token。Trends建议保持开启数据处理方式选“Use trends”。插件默认在数据跨度超过一定天数时会使用Zabbix的trends表这能显著减少对Zabbix Server的压力。Alerts这里有两个选项“Show events”建议选“Problems only”或者“Any event”看你面板要不要展示已经恢复的告警。填完点“Save test”如果配置正确会返回连接成功。如果提示成功但是查询不出数据多半就是API账号缺少对应主机组的读取权限回Zabbix检查权限。我遇到过很隐蔽的一个情况Grafana服务器和Zabbix之间有反向代理反向代理把/zabbix路径剥离了导致Grafana配置里填的URL少了一层路径测试时却显示成功因为代理兜底返回了一个默认页面。这种问题排查起来特别恶心建议你配置URL时严格以curl验证通过的地址为准。3.2 最常用的几类查询写法插件提供的查询类型有好几个Metrics、Items、Trends、Alerts、Problems我日常用得最多的是Metrics和Problems。下面逐个拆解。Metrics查询是普通时间序列图的核心。打开一个Timeseries面板数据源选Zabbix查询模式选“Metrics”然后按顺序设置Group选主机组可以直接填变量。Host选主机也可以填变量。Application可选比如选“CPU/Memory”这类应用分类能缩小范围。Item填监控项名称支持通配符和正则。比如想看所有CPU相关项填/CPU/想看具体网卡流量填net.if.in[eth0]。Function这里选聚合函数。last()取最近值avg()取平均值max()取最大值min()取最小值。做趋势分析时我会用avg()做告警阈值展示用last()更直观。Group by按时间分组通常选1m或者5m表示每个数据点是这一段时长的聚合值。这里我要特别提醒一点last()这个函数在展示时间范围很长时画出来往往是一条水平线因为它只取了时间范围内最后一个值。如果你要看整段时间的趋势必须用avg()、max()这类函数配合时间分组。这个坑我至少见过三个人踩过面板看着“有数据”但完全不是想要的效果。Items查询适合做表格类的“最新值”面板。比如一个主机健康总览表列出CPU负载、内存使用率、磁盘空间各自的当前值。查询模式选“Items”然后选择主机表格会拉出该主机所有符合条件的监控项及其最后取值。Problems查询用来展示当前未恢复的告警。面板类型可以用Table查询模式选“Problems”设置好严重级别过滤和主机过滤就能列出当前有哪些触发器处于Problem状态。在运维大屏上这个面板我会放在显眼位置配合$host变量做到主机联动。Alerts查询则能拿到历史告警事件包括已恢复的适合做故障复盘和告警统计。3.3 用模板变量把大盘做活Grafana比Zabbix原生界面强很多的一点就是模板变量。在Dashboard设置里新建变量变量类型选“Query”数据源选Zabbix插件会提供一套直接的查询语法。我常用的三个变量是Group变量查询类型groups()返回所有主机组。启用“Multi-value”并勾选“Include All option”这样大屏上就能直接切换所有组。Host变量查询类型hosts()在变量编辑界面里有一个“Group filter”或者“Regex”字段填上[$Group]或者对应的正则就能实现按主机组联动。如果不太会写正则可以先把Group变量设为默认值然后在Host变量里用查询条件关联。Item变量查询类型items()配合Group和Host过滤返回当前主机下的监控项。建好变量后面板查询里的“Group”“Host”“Item”字段直接填$Group、$Host、$Item就能实现下拉框切换全盘联动。在大屏场景下我还会加一个$interval变量用来一键切换1m、5m、15m的统计粒度效果很实用。3.4 大屏布局和面板选择如果你要做的正是“Zabbix监控大屏”这类场景我建议遵循一套简单的排版思路从上到下分三层。第一层是总览层放几个Stat面板拉当前整体健康度比如未恢复告警数、平均CPU使用率、内存使用率峰值。Stat面板颜色阈值设好绿色正常、黄色警戒、红色严重一眼扫过去就知道系统状态。第二层是趋势层放两到三行Timeseries面板覆盖CPU、内存、磁盘、网络流量。每行一个主题变量联动同一个主机。这层用avg()函数分组粒度根据大屏的时间范围来调整一般5m就够了。第三层是明细层放一个Problem告警表格一个Items最新值表格。表格类的面板在大屏上的可读性比时间序列好很多尤其适合值班人员快速定位问题。大屏的刷新时间我会设为30秒到1分钟别太频繁否则每次刷新都会打一次Zabbix API图多的时候Zabbix服务器压力会明显上升。另外大屏显示器一般分辨率高但离得远字号设置要大一点图例尽量精简能用中文别名就用中文别名。4. 常见报错与排查记录对接过程中我遇到的报错不少有些是Zabbix端问题有些是Grafana端问题还有的是版本兼容问题。下面四个是网上被问得最多、我自己也真实踩过的逐个记录排查思路。4.1 页面突然提示 Zabbix server is not running这个提示第一次出现时吓了我一跳因为它出现在Zabbix前端页面顶部看起来像是Grafana数据源的错误。实际上它跟Grafana半毛钱关系没有是Zabbix前端检测不到Zabbix Server进程在正常运行。出现这个提示后如果Grafana这边立刻出现大量面板无数据基本可以断定Zabbix Server后端出了问题。先上Zabbix服务器看进程systemctl status zabbix-server如果进程不在查看/var/log/zabbix/zabbix_server.log常见原因有数据库连接失败、数据库磁盘满了、housekeeper进程卡死、被监控主机过多导致server负载过高。还有一种我在VMware环境里踩过的情况Zabbix Server和Zabbix Agent之间的时间不同步导致Agent数据入库异常前端也显示server not running。处理完根因后记得在Zabbix前端刷新确认提示消失再回Grafana看面板。这个报错本质上是Zabbix健康状态的一个指示灯出现的第一时间应该去查Zabbix Server本身而不是去翻Grafana插件配置。4.2 Grafana报Failed to upgrade legacy queries这个报错听起来像代码级错误实际场景里最常见的诱因是Dashboard是在旧版本插件下创建的里面保存的数据源引用还是老格式Grafana升级或者插件升级后旧Query模型无法自动迁移。我碰到的一次具体报错里带了一个奇怪的ID类似im7_otuvz一看就是Dashboard JSON里写入的datasource UID。这个UID在数据源被删除再重建之后已经不存在了Grafana在加载面板时找不到对应数据源就报了这个错。处理方法有三种最直接打开面板编辑重新选择正确的Zabbix数据源然后保存。Grafana会用新的UID重新写入面板配置。如果面板很多可以用Dashboard的JSON编辑器找到datasource字段把旧的uid值替换成当前Zabbix数据源的真实UID。真实UID在数据源设置页面的浏览器地址栏里能看到。如果以上都不行直接在Dashboard设置里导出JSON备份后用文本编辑器批量替换再导入回来。这个报错不必惊慌它不影响数据源本身只是面板里的引用失效了。关键是养成一个习惯升级Grafana或者插件之前先备份所有Dashboard的JSON这个习惯能让你少掉很多头发。4.3 Zabbix报Access denied for user replace_user这个报错我一看到就认出来是数据库层面的问题。replace_user其实是个占位符真实报错里会替换成Zabbix连接MySQL时配置的数据库用户名后边还跟着(using password: YES)意思很清楚用密码连接数据库被拒绝了。出现这个报错的时候Zabbix Server进程会异常Zabbix前端和Grafana都拿不到数据。先去看/etc/zabbix/zabbix_server.conf里的DBUser和DBPassword配置确认和MySQL里的账号密码是否一致。如果Zabbix是源码编译装的配置文件路径可能不同用zabbix_server --print或者grep DB /etc/zabbix/zabbix_server.conf查。大部分情况是三个原因密码被改过但配置文件没改MySQL用户权限不够MySQL里根本不存在这个用户。对应的处理就是修正配置、执行授权GRANT ALL PRIVILEGES ON zabbix.* TO zabbixlocalhost IDENTIFIED BY 你的密码; FLUSH PRIVILEGES;改完之后重启zabbix-server进程再验证。这个问题跟Grafana插件配置完全无关如果你在Grafana数据源测试时报错提示连接失败先到Zabbix服务器上看日志别在Grafana端瞎折腾。4.4 面板加载慢、图表没数据最后这一类是使用过程中最常见但不涉及具体报错的问题。图表没数据我按经验概率排个序监控项本身处于“不支持”状态。Zabbix前端里该监控项图标是红色的说明Agent那边采集失败Zabbix没有数据Grafana自然画不出来。时间范围太短而history保留期太短。Zabbix默认history保留一周trends保留一年。如果你在Grafana里选了30天但项目配置里trends没有开插件只能返回空。查询条件写错。Host选错、Group选错、Item名称拼写不对或者正则表达式写得不匹配。先在Explore里用同样的条件测试一遍确认能出数再往Dashboard上加。数据源里Trends设置问题。数据跨度大却没用趋势数据导致插件请求历史表但数据已经清理完了。面板加载慢则通常是查询项太多导致的。Zabbix插件查询时会一条条拉取监控项数据如果面板里的Item选择用宽泛正则匹配出几百个监控项每次刷新都会对Zabbix API造成很大压力。解决办法是尽量缩小Item范围用精确的item key或者分组到Application级别再选。还有就是把面板的“Group by time”粒度调大减少返回的数据点数量。Grafana数据源配置里也有一个Timeout设置如果你的Zabbix Server响应本来就慢适当加大超时时间能减少面板报超时错误的概率但这只是治标根本解法还是优化Zabbix Server性能和控制查询量。5. 几个落地后的补充经验主体流程走完、大屏能正常跑了还有几个经验我挺想分享的都是平时文档里不会写、但实际运维中会反复遇到的细节。5.1 数据展示别把Zabbix本身的监控搞乱Grafana只是通过API读取数据按理说不会影响Zabbix的采集和存储但有一种情况很危险如果你给Grafana用的API账号权限过大有人误操作了Zabbix侧的配置比如改了监控项、删了主机整个监控体系就乱了。所以数据源账号一定要限制成只读并且只给它需要的那些主机组的权限。我还在Zabbix侧做了一层保护核心的模板和触发器都加了审计和备份每天凌晨把Zabbix的配置导出到文件这样就算哪天Grafana侧误操作或者Zabbix被误改至少能快速恢复。5.2 多数据源混排与告警边界如果你像我一样Dashboard里同时要放Zabbix和Prometheus的数据Grafana直接支持在同一面板里添加多个查询每个查询指定不同的数据源。但要注意两边的数据粒度和命名风格不一样Zabbix里的CPU使用率是百分比Prometheus里可能是100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100单位对齐之后再放到同一个图里否则很容易误导人。告警这边我也明确一下边界Zabbix的触发器继续留任负责短信、钉钉、企业微信这些传统的告警通知。如果想在Grafana里做告警用Grafana Unified Alerting读取Zabbix数据也能实现但这样一来告警规则就分散在两个系统里了管理成本会上升。我的建议是能用Zabbix触发器的就别重复造轮子Grafana侧只做展示保持职责单一。5.3 面板复制、备份与团队协作最后分享一个很实用的小技巧。Grafana里复制整个面板不需要重新配置一堆查询条件。在面板标题栏的菜单选择“More Copy”然后在目标Dashboard里按CtrlV或者右键粘贴就能把面板连同查询配置一起复制过去。我经常用这个方式把一套验证好的CPU面板复制到不同业务线的Dashboard里再改个主机变量就完事了。Dashboard的备份也用同样的逻辑面板菜单里可以导出整个Dashboard为JSON我习惯每次改动比较大的时候导出一份放到git里管理。这样即使Grafana实例挂了重新部署后导入JSON所有面板和变量配置都能秒级恢复。团队协作时可以用Grafana的文件夹和标签功能做权限隔离让不同业务线只能看到自己的Dashboard避免互相干扰。这个项目后续如果还想扩展可以考虑把Zabbix的告警事件通过Grafana的Alertmanager集成统一收口或者用Grafana新版的文本面板做更丰富的业务展示。不过这些都是锦上添花的事了先把数据展示这层做扎实运维同事和领导看到大屏的第一反应就说明这套对接方案值了。