企业官网建设流程全解析

凌晨两点被叫起来处理一起"业务间歇性卡顿"，登上 Zabbix 首页盯着那几张折线图：CPU 冲到 80%、内存缓慢上涨、磁盘 IO 拉满，然后呢？没有然后了。Zabbix 把"哪台机器、哪个指标、什么时候越界"这件事做得非常扎实，但要把三十台机器的同一个指标摆在一张图里做横向对比，或者把一台机器过去三十天的内存曲线和发版记录叠在一起看，自带图形就明显不够用了。

这套 Zabbix 监控结合 Grafana 绘图的方案，解决的就是这个断层：采集和判定交给 Zabbix，观察和对比交给 Grafana。它不是要替换 Zabbix，而是在 Zabbix 之上加一层展示引擎，让原本分散在几十个主机页面里的指标，变成能横向拉通、能按变量筛选、能挂上大屏的一整套视图。适合已经用 Zabbix 跑了一段时间、开始觉得"图不够用"的运维同学，也适合刚接手监控体系、需要快速出一套大盘的人。

下面这份内容是我自己在几套环境里反复折腾之后沉淀下来的，从 Zabbix 侧的前置准备一直讲到面板维护，中间踩过的坑都标出来了。

1. 已经有 Zabbix 图形了，为什么还要挂一层 Grafana

很多人的第一反应是：Zabbix 自带图形不也能看吗，为什么要多装一个组件？我在最开始也是这么想的，直到有一次排查一个跨主机的性能问题，才彻底改了主意。

1.1 Zabbix 自带图形的能力边界在哪

先把话说清楚，Zabbix 在可视化这块并不是"弱"，而是重心不同。它最核心的能力是采集、触发器判定和告警分发，图形更多是"顺带提供"的观察窗口。

具体来说，自带图形有这么几个边界：

• 单主机视角为主。Simple graph 和 Custom graph 基本都是围绕一台主机的若干 item 展开，想同时看二十台机器的同一个指标，得靠聚合图形一块块拼，拼出来的也是二十张独立小图，而不是一条可对比的叠加曲线。
• 时间范围交互有限。前端能选的时间段是固定的几档，想要"从故障时间点往前推三天"这种精确区间，操作路径比较绕。
• 图例和单位不够灵活。多个 item 画在一起时，图例命名、单位换算、小数位的控制空间不大，尤其是字节和比特混在一起的时候，眼睛容易看花。
• 分享成本高。要给不在监控体系里的人看一眼趋势，往往得截图，截出来的图还不能缩放。

这不是吐槽，而是定位问题。Zabbix 的设计目标是"发现问题并可靠地通知你"，在这个目标上它是合格的。

1.2 Grafana 补上的三件事

我把数据接过去之后，真正感受到价值的是三块：

第一块是同图叠加与变量筛选。给面板配一个"主机组"变量和一个"主机"变量，同一张 CPU 使用率图就能在"全部主机 / 单台主机"之间一键切换，曲线要么是一堆细线做横向对比，要么聚焦到某一台上做细节观察。这个能力在排查"是不是某台机器拖了后腿"的时候特别省事。

第二块是多数据源统一视图。Grafana 的面板不认数据源类型，同一个 Dashboard 里可以左边放 Zabbix 的主机指标，右边放 HTTP 探测、日志统计甚至手工录入的容量数据。真正的"一屏看全",在 Zabbix 前端是做不出来的。

第三块是长周期观察和排布自由。大盘的列宽、行高、面板位置、阈值线颜色、单位格式全都可以自己排。把关键指标放上面、细节放下面、告警时间线放最底，这套排版一旦定下来，值班的人接手成本会低很多。

1.3 这套组合不适合谁

我也见过一些团队上了 Grafana 之后反而更累，通常是这几种情况：

• 机器就三五台，只看告警不看图。这种情况 Zabbix 自带图形完全够用，多维护一个组件纯属负担。
• 没有人负责面板。面板是会"腐化"的——主机下线了、指标改名了、模板换了，图会自动变成空白，没人管的话三个月后整套大盘就废了。
• 把 Grafana 当告警主通道。这点后面会专门讲，Zabbix 的触发器体系在依赖关系、恢复条件、告警升级上的能力，不是 Grafana 侧一个阈值判断能替代的。

一句话：Zabbix 负责"有没有问题"，Grafana 负责"问题长什么样"。两者定位清晰，组合才有意义。

2. 动手之前，Zabbix 侧要先把地基铺好

我踩过的最大一个坑，是数据源接上之后发现图全是空的，排查了半天才意识到是权限问题。所以这一节放在最前面，先把 Zabbix 那边的东西理顺。

2.1 单独开一个只读 API 账号

不要拿 Admin 账号去接 Grafana，也不要用超管。原因很实际：Grafana 的数据源配置在团队里往往会被多人看到，密码泄露风险不小；而且超管权限意味着一旦 Grafana 侧被利用，整个 Zabbix 就暴露了。

正确做法是建一个独立用户，角色权限设为只读，只授予需要展示的主机组：

如果你的 Zabbix 版本支持 API Token，强烈建议用 Token。Token 可以在用户界面里单独生成和吊销，不用担心密码过期策略，也不用把明文密码写进 provisioning 配置。

生成之后先用命令行验证一下能不能通，这一步能省掉后面大量的猜测：

# 用 API Token 拉三台主机，确认权限和网络都通 curl -s -H "Content-Type: application/json-rpc" \ -H "Authorization: Bearer <YOUR_TOKEN>" \ -d '{"jsonrpc":"2.0","method":"host.get","params":{"output":["hostid","host"],"limit":3},"id":1}' \ http://zabbix.example.com/api_jsonrpc.php

返回里能看到主机列表，说明 Token 有效、权限正常、网络可达。要是返回空数组，八成是主机组权限没给。

2.2 主机分组和指标命名，决定了后面画图顺不顺手

这一步很多人会跳过，但它直接影响 Grafana 面板的可用性。

Grafana 的变量筛选是依赖 Zabbix 的主机组和 item 名称的。如果主机组是按"Zabbix 服务器""应用服务器"这种技术维度随便分的，那变量里选出来的选项就会很乱。我的建议是按业务 + 环境两层来分，比如prod-payment、prod-order、test-payment，这样面板上先选环境再选业务，逻辑清晰。

指标这边，重点盯三件事：

• item 的可见名称要有意义。Grafana 的 Metrics 查询模式是按名称做模式匹配的，如果名称全是默认的CPU $1、Interface $2，匹配起来会很难受。
• 单位必须填。Zabbix 里 item 的单位设成B、bps、%，Grafana 才能自动做单位换算和 Y 轴标注。不填单位的 item，画出来就是一条没有量纲的线，看着费劲。
• 应用集（Application）要规范。部分查询场景下可以用应用集做过滤，命名统一了能省很多筛选条件。

2.3 面板刷新会变成 Zabbix 的压力，这个账要先算

这是个很容易被忽略的点：Grafana 的每一个面板、每一次刷新，都是一次 API 请求。加一层展示引擎，等于给 Zabbix 增加了一个持续的查询客户端。

我做过一个粗略的估算：一个 Dashboard 有 12 个面板，刷新间隔 30 秒，那么每分钟就是 24 次查询；如果有 20 个人同时开着这个大屏或者面板，就是每分钟 480 次。如果每个查询还要跨 50 台主机做模式匹配，Zabbix Server 的查询压力会明显上升。

几个实用的降载手段：

我自己的习惯是：日常排查用的面板设 1 分钟，值班大屏设 5 分钟。这个组合既保证了及时性，又把压力控制住了。

3. 从零把 Zabbix 数据源接进 Grafana

地基铺好之后，剩下的事情就顺了。这一节按我实际操作过的顺序来写。

3.1 插件安装与版本匹配

Grafana 原生不支持 Zabbix 数据源，需要装社区插件。装法有两种，看你的部署方式：

容器部署的话，用环境变量最省事：

docker run -d --name grafana \ -p 3000:3000 \ -e "GF_INSTALL_PLUGINS=alexanderzobnin-zabbix-app" \ -e "GF_SECURITY_ALLOW_LOADING_UNSIGNED_PLUGINS=alexanderzobnin-zabbix-app,alexanderzobnin-zabbix-datasource" \ grafana/grafana:10.4.5

传统部署的话，用命令行工具装，然后重启服务：

grafana-cli plugins install alexanderzobnin-zabbix-app # 重启 grafana-server 使插件生效

这里有个必须注意的点：插件版本和 Grafana 主版本要匹配。我遇到过 Grafana 主版本比较新、插件版本偏旧，结果插件能装上但加载报错的情况。保险做法是升级 Grafana 之前先看一眼插件发布说明里的兼容范围，把插件版本也一起规划进去。另外就是别在主版本大升级的当天顺手升插件，两件事混在一起出问题，排查起来很难定位是哪边引起的。

3.2 数据源配置项逐个说清楚

插件装好之后，在 Grafana 的插件列表里能找到 Zabbix 应用，启用之后就可以添加数据源了。配置项看着不多，但每一项都有讲究：

URL。填 Zabbix 的 API 地址，通常是你的前端地址加上api_jsonrpc.php。如果你的环境里通过反向代理加了一层路径前缀，这里一定要把前缀带上。我见过最常见的 URL 错误就是漏了这一段，表现为 404。

Access。一定选Server (proxy)模式，让 Grafana 后端的服务去请求 Zabbix。选 Browser 模式意味着请求从前端浏览器发出，除了会把凭据暴露给浏览器之外，还会直接撞上跨域限制，基本是给自己找麻烦。

认证方式。较新版本可以用 API Token，老版本用用户名密码。用密码的话记得后续做轮换，别一用好几年。

Trends（趋势数据）。这个开关我建议打开。Zabbix 的 trends 表按小时做了预聚合，查询长周期数据时走趋势表，速度比扫 history 表快得多。相关的还有"从多久开始用趋势"和"趋势的范围"，一般配成"7 天以内用历史、7 天以上用趋势"这种策略比较平衡。

Cache TTL。默认值通常偏短，我一般会调到 1 小时。同一个面板在 TTL 内重复请求会直接命中缓存，对 Zabbix 后端非常友好。坏处是新采集的数据可能有最长 TTL 的展示延迟，但对运维大盘来说这个延迟完全可以接受。

Direct DB Connection。这个选项是给"不想走 API、直接查数据库"的场景准备的，需要额外配一个只读的 SQL 数据源。我的建议是：除非 API 压力已经明显影响到 Zabbix 本身，否则不要开。多一条数据库直连链路，就多一份权限管理和版本兼容的维护成本，收益和成本不成正比。

3.3 连不上、连上了没数据，按这个顺序排查

连接类问题几乎占了新手阶段的全部时间。我整理了一张对照表，按这个顺序查基本都能定位：

我自己的排查顺序固定是：命令行 curl API → 确认数据存在 → 确认用户权限 → 确认 Grafana 侧配置。这个顺序的好处是每步都能得出明确结论，不会在不同层之间反复跳。

4. 查询面板里那几个特别容易搞混的概念

数据源接上之后，真正的门槛在查询编辑器里。Zabbix 插件提供了好几种查询模式，用错了就是"图能出来但怎么看怎么不对"。

4.1 查询模式怎么选：模式匹配还是 Item ID

插件支持的查询模式大致有这么几类，用途差异很大：

我的经验是：变量化的通用面板用 Metrics 模式，核心固定面板用 Item ID 模式。前者灵活，后者稳定。最怕的是全用 Metrics 模式还写了很宽的正则，主机一多就会匹配到一堆不相关的 item，图上出现一堆莫名其妙的线。

另外提醒一点：item 名称模式匹配时，优先匹配"键值"还是"可见名称"是有区别的，不同插件版本的行为可能不一样。如果画出来的线数量不对，先把查询返回的 item 列表拉出来核对一下，比在图上猜快得多。

4.2 历史和趋势，这两个概念决定了你能看多久以前的数据

这是最容易被忽略、也最容易让人困惑的一块。

Zabbix 的数据分两层存储：history 表存原始采集值，精度高但占用大，保留期通常只有几天到几周；trends 表按小时做聚合，保留期可以拉到一年以上，代价是精度损失。

这带来两个直接影响：

第一，你查不到三个月前的秒级数据。这不是 Grafana 的问题，是 Zabbix 那边 history 保留期到了就把数据清了。很多人第一次遇到这个会以为数据源坏了，其实是正常的存储策略。要长期保留细粒度数据，只能调 Zabbix 的 housekeeper 配置或者外接专门的时序存储。

第二，趋势数据只有数值型 item 才有。字符串型、日志型 item 是没有趋势表的，所以拉长到"过去 30 天"去看这类指标，图会直接断掉。这一点在设计面板的时候就要考虑到，别把字符串指标放到带长时间范围选择器的大盘上。

趋势数据的查询会用到专门的聚合函数，比如取区间平均值、最大值、最小值、计数。想做"过去一天的每小时峰值"这种图，就用最大值的趋势函数，而不是让 Grafana 去对原始数据做聚合。前者走预聚合表，快得多。

4.3 多主机叠加和图例命名

把二十台机器的同一条曲线画在一张图上，如果图例全是默认的名称，图基本没法看。这里的处理办法是：

• 用变量拿到当前选中的主机列表，在查询里对主机做循环。
• 图例模板里带上主机名，比如用类似{{host}} - CPU的写法，这样每条线一眼能对应到机器。
• 开启 Multi-value 和 Include All 两个选项，让变量支持多选和全选。
• 排序上，把变量值的排序方式设成按名称排序，避免每次刷新曲线顺序都在变。

还有个细节：叠加图的主机数量建议控制在 8 到 12 条曲线以内。超过这个数量，颜色区分度会急剧下降，图例也开始堆叠，实际可读性反而变差。真要对比几十台，用统计类的面板或者分组的折线更合适。

5. 把面板做成一块真正能用的值班大屏

图表能出来只是第一步，能不能在出问题的时候帮上忙，取决于面板怎么设计。

5.1 用三级变量把一张面板复用给所有业务

我现在的做法是给资源类面板配三级变量：

1. 业务组变量：数据源查询类型选主机组，把 Zabbix 里的主机组列出来。
2. 主机变量：类型选主机，并且用上一个变量做过滤，只列出该组下的主机。
3. 指标变量：类型选指标名称，用前两个变量过滤。

这样一张 CPU 面板可以覆盖所有业务组，排查时先选业务、再选主机，路径非常自然。变量之间的联动筛选是关键——如果主机变量不过滤，列表里会出来几百台机器，选起来很痛苦。

变量值还可以加正则过滤。比如只想看带prod-前缀的主机，就在变量的正则里限制一下。这个技巧在多环境混用一套 Zabbix 的时候特别有用。

5.2 单位和阈值线，这两个地方最容易画错

单位问题我在好几个环境里都踩过：

• 字节和比特混用。网络设备上报的流量通常是比特每秒，服务器网卡上报的通常是字节每秒，两者差 8 倍。如果 Zabbix 里单位填错了，Grafana 换算出来的数字就会离谱，图上看着"带宽跑满了"，实际才用了八分之一。
• 百分比范围。有些 item 存的是 0 到 100，有些存的是 0 到 1。Grafana 的百分比单位默认按 0 到 1 处理，如果数据是 0 到 100 的，整条线会跑到图表顶端看不见。
• 单位后缀写法。单位写法不规范时，Grafana 可能识别不出来，导致显示成原始数字，比如1073741824而不是1 GiB。

阈值线的配置也有讲究。我一般设三级：绿色是正常区间，黄色是预警线，红色是必须处理的线。颜色的使用要保持全局一致，不要这块面板黄色代表预警、那块黄色代表严重，值班的人会被绕晕。另外，阈值线的位置要和 Zabbix 触发器的阈值对齐，两边不一致是最要命的事情——图上看着正常，告警却响了。

5.3 大盘分层的排布思路

我的大盘固定分四层，从上往下按"从概览到细节"的顺序：

第一层是健康概览。放几个状态类面板，用颜色块展示各业务组当前的整体状态，一眼就能看出"哪个业务红了"。同时放几个最关键的数值，比如核心接口的错误率、订单量。

第二层是资源指标。CPU、内存、磁盘使用率、磁盘 IO、网络流量，每个指标一张图，全部支持变量切换。这一层是排查时用得最多的。

第三层是业务与应用。中间件连接数、队列积压、接口响应时间这类。这里往往是多个数据源混排，Zabbix 的指标和别的来源放在一起看。

第四层是事件时间线。用触发器或问题事件的查询模式，把告警事件按时间轴铺在底部。这一层最大的价值是：当你看曲线突然上扬的时候，能立刻知道同一时刻有没有告警、有没有发版。

用 Row 把这些层折叠起来，配合变量联动，一块大屏就能同时服务"值班扫一眼"和"深入排查"两种场景。

6. 告警到底该由谁发，这件事要提前定

这是我见过最多争议的地方，也是很多团队做完 Grafana 大盘之后反而告警变乱的根源。

6.1 职责划分：Zabbix 判定，Grafana 展示

我的立场很明确：告警的判定和通知继续由 Zabbix 负责，Grafana 只负责看。

理由不是偏好，而是能力差异。Zabbix 的触发器支持依赖关系、多指标组合条件、恢复表达式、告警升级和抑制，还能针对不同主机组走不同的通知渠道。Grafana 侧的告警本质上是对查询结果做阈值判断，缺少触发器之间那种"父触发器不告警时子触发器不通知"的关系管理。真到了大故障的时候，差的就是这些细节。

实践中最省事的做法是：在 Grafana 里用问题事件的查询模式做一个事件面板，把 Zabbix 当前的问题列表和最近的事件流展示出来。这样你在看曲线的时候能同时看到告警状态，但真正发通知的还是 Zabbix，不会出现"同一件事两个渠道各发一遍"的情况。

两套都发同样的告警，后果很实际：值班的人手机上会收到双份通知，时间一长就会对通知麻木，真正的严重告警反而被淹没。

6.2 如果确实要用 Grafana 补一层告警

有些场景下 Grafana 侧告警是有价值的，比如跨主机的聚合判断——"同一业务组里超过一半的主机磁盘使用率都超过阈值"，这种条件在 Zabbix 里写起来很别扭，在 Grafana 里反而直观。

如果要这么做，我的建议是：

• 只作为补充，不作为主通道。主通道永远是 Zabbix。
• 明确命名。Grafana 侧发出来的告警在标题里带上前缀，值班的人一看就知道来源不同。
• 控制数量。Grafana 告警规则数量多了之后，管理成本会快速上升，能不建就不建。

另外提一句，网上经常把另一套监控体系的告警组件和 Grafana 的告警混着讲，那是完全不同的两条链路。别看到别人在配某个告警转发组件，就以为 Zabbix 也要照着配一遍，方向搞错了会白折腾很久。

7. 那些让我熬过夜的问题，以及现在的维护节奏

最后一节讲几个具体的坑，都是实际发生过的，不是从文档里抄的。

7.1 插件升级之后面板集体失效

这个坑我遇到过一次，印象很深。Grafana 主版本升上去、插件也跟着升了一版，结果一批老面板打开就报错，提示和旧查询的升级有关，甚至牵扯到找不到某个旧的数据源。

根因有两层。一层是数据源的身份标识变了——面板的 JSON 里记录的是数据源的名字或者唯一标识，如果你在迁移过程中改了数据源的名字，或者删了重建了一个，旧面板就找不到对应关系了。另一层是插件内部的数据模型发生了变化，老版本的查询对象里缺少新版本的字段，升级逻辑要去做转换，转换失败就报错。

处理办法我总结了几条：

• 数据源名字定下来就别改。换名字的成本远高于一开始想清楚的成本。
• 面板迁移时用唯一标识而不是名字。现在的 Grafana 支持给数据源指定稳定的标识，导入面板之后引用标识，改名字也不会断。
• 面板 JSON 定期备份。Dashboard 的 JSON 就是资产，导出一份放到版本管理里。真出事了，拿着 JSON 改一改就能恢复，比在界面上一个个修快得多。
• 升级前先在测试环境开一套。把插件和数据源配置在测试环境跑通，再动生产。这一步花的时间，通常比事后排查省得多。

7.2 面板的复制和导入导出，有几个细节要注意

在界面上直接复制面板，会带上原面板的数据源引用。如果目标环境里没有同名数据源，面板就是空的。跨环境迁移的时候，我一般用导出的方式，导出时留意"是否导出为外部共享"这个选项的差异：勾了它，导出的是带变量占位的形式，更适合跨环境分享；不勾，导出的是当前环境的完整引用。

如果你们的环境用配置文件管理数据源，那就更省事了。把数据源写成配置文件，敏感信息单独放，面板引用统一的名字或者标识，迁移的时候基本不用改。这类配置长这样：

apiVersion: 1 datasources: - name: Zabbix type: alexanderzobnin-zabbix-datasource access: proxy url: http://zabbix.example.com/api_jsonrpc.php jsonData: username: grafana-readonly trends: true trendsFrom: 7d trendsRange: 4d cacheTTL: 1h secureJsonData: password: <在这里填凭据>

注意字段名和取值在不同插件版本之间可能有差异，以你实际版本的文档为准。别直接照抄我的配置，先对照自己版本的字段说明核一遍。

7.3 长期维护清单

面板这东西，做出来只是开始，能不能活过半年取决于有没有人管。我现在的维护节奏大致是这样：

• 每月扫一遍面板。把三个月没人看、或者数据源已经不存在的面板删掉。留着这些空面板只会让大盘越来越臃肿，新来的人根本找不到重点。
• 每季度核一次权限。确认 Grafana 侧用的那个只读账号还有效，密码或者 Token 没过期，需要展示的主机组没有遗漏。这个检查很有必要，我遇到过因为账号密码轮换导致整个大盘静默失效的情况，最坑的是它不报错，只是所有图都不更新了。
• 给每个面板加标签和责任人。标签用来分类和搜索，责任人写在面板描述里。出问题的时候知道该找谁，这件事的价值在关键时刻才体现出来。
• 控制刷新间隔的总量。定期算一下大屏的刷新总频次，如果 Zabbix 的查询压力上来了，先把大屏的刷新间隔调长，而不是急着优化 Zabbix 数据库。
• 大屏电视机的显示参数要单独调。深色主题在电视上比浅色舒服，字号要比桌面端大一档，分辨率适配也要单独排一版。这个细节不难，但没人做的话，大屏永远是"能用但看不清"的状态。

7.4 我现在对这套组合的理解

折腾了这么久，我对 Zabbix 加 Grafana 这套组合的认识其实一直在变。最开始我以为它是"给 Zabbix 换个好看的皮"，后来发现真正的价值不在好看，而在它逼着你去把监控指标理清楚。

因为一旦要做变量化面板、要做多主机对比、要做图例命名，你就必须回答这些问题：主机组怎么分？指标名字规范吗？单位填对了吗？哪些指标是核心、哪些只是参考？这些问题在只用 Zabbix 自带图形的时候可以糊过去，做大盘的时候糊不过去。

所以我现在一般会在项目开始前先花半天时间把主机组和指标命名理一遍，再动手画图。这半天时间看起来是"没干活"，但它能让后面的面板返工率降一大截。踩过几次坑之后我才明白，画图难的从来不是图本身，而是图背后那套指标到底有没有被整理过。