企业官网建设流程全解析

1. 安装模式选型：先搞清楚三种装法再动手

Zabbix 作为开源监控领域的常青树，几乎成了运维监控的代名词。很多人安装 Zabbix 时会在“安装模式”这个环节卡住，原因不是它有多复杂，而是选择太多：源码编译、RPM 包安装、容器化部署，三种方式各有适用的场景，选错了后面配置和运维都会非常难受。

先说我个人的习惯：生产环境优先考虑 RPM 包安装，测试环境用 Docker 一把梭，而源码编译除非有特殊需求（比如要改内核模块或者自定义编译参数），否则不推荐碰。为什么这么选？RPM 包的方式利用了发行版的包管理机制，依赖关系自动处理，安装完就能用，升级也方便，zabbix_server、zabbix_agent 都作为 systemd 服务管理，出了问题还能用systemctl status快速定位。Docker 适合快速验证功能和做 POC，但生产环境如果指标量很大，容器化的数据持久化、网络模式、日志采集都要额外处理，反而是负担。

三种安装模式的差异用一张表看最直观：

这里多说一句，网络上有大量“一键安装脚本”或第三方编译包，很多人在 Zabbix 官网下载源时碰到官方源在国外、下载慢的问题，于是去网上找替代源。我的建议是：官网下载慢就配置国内镜像源，但不要用来路不明的打包版本，监控软件装到生产环境里还带着未知代码，这个风险不值得冒。

还有一个常被忽略的“安装模式”指的是 Zabbix 组件的部署架构模式。最典型的是把 Zabbix Server、Zabbix Agent、Zabbix Proxy 分开装，还是全装在一台机器上。学习环境全装一台没问题，但生产环境建议 Server 单独部署，Proxy 按机房或网段分散，Agent 装在被监控的目标机器上。这个架构上的“模式”选择，比安装方式本身更影响后续的稳定性。

2. CentOS 7.9 安装 Zabbix 最新版的完整实操

2.1 前置准备：关闭 SELinux 与放行防火墙端口

CentOS 7.9 是最常见的 Zabbix 服务器操作系统，网上的教程大多以这个版本为例。开始安装之前，有两件事必须提前做，漏掉任何一个都会让你在后面的步骤里怀疑人生。

第一件是检查 SELinux。Zabbix 官方文档和依赖包在 SELinux enforcing 模式下容易出现权限问题，虽然可以配置 SELinux 策略来适配，但为了快速部署，先把 SELinux 关掉或者设为 permissive 模式。执行getenforce查看当前状态，如果是 Enforcing，执行setenforce 0临时关闭，再修改/etc/selinux/config把SELINUX=enforcing改成SELINUX=disabled让重启后也生效。

第二件是防火墙。Zabbix Server 默认监听 10051 端口，Zabbix Web 前端默认监听 80 或 8080 端口，Agent 默认监听 10050 端口。如果服务器开了 firewalld，需要执行以下命令放行这些端口：

firewall-cmd --permanent --add-port=80/tcp firewall-cmd --permanent --add-port=10050/tcp firewall-cmd --permanent --add-port=10051/tcp firewall-cmd --reload

如果是临时测试环境直接systemctl stop firewalld也行，但生产环境千万不要关防火墙，把端口精确放开即可。

2.2 配置 Zabbix 官方源并安装 Server、Agent

CentOS 7.9 默认的 yum 仓库里没有 Zabbix，直接yum install zabbix-server会提示找不到包。需要先添加 Zabbix 官方源。以 Zabbix 6.x 最新版本为例（我在写这篇文章时 7.0 也已经发布，安装方式大同小异，只是源地址里的版本号不同）：

rpm -Uvh https://repo.zabbix.com/zabbix/6.0/rhel/7/x86_64/zabbix-release-6.0-5.el7.noarch.rpm yum clean all

如果官网源下载很慢，可以把源地址中的 repo.zabbix.com 替换为国内镜像源地址（比如清华、阿里云的 Zabbix 镜像），但要注意镜像目录结构和版本号路径保持一致。替换后执行yum install前先yum repolist确认源生效。

接着安装服务端和 Agent：

yum install zabbix-server-mysql zabbix-agent zabbix-web-mysql zabbix-nginx-conf -y

如果对前端 Web 的部署方式没有特殊要求，默认用 nginx 和 php-fpm 来跑 Zabbix Web 页面。Zabbix 前端需要 PHP 环境，依赖包会一并安装，所以这里不需要手动装 PHP。

装完后先别急着启动服务，因为 6.0 之后的版本要求必须先初始化数据库，否则服务启动会直接报错说找不到数据库表。

2.3 初始化 MySQL 数据库

Zabbix 数据要存储在 MySQL 里，先确保本机安装了 MySQL 或 MariaDB，并启动服务：

yum install mariadb-server -y systemctl start mariadb systemctl enable mariadb mysql_secure_installation

在mysql_secure_installation里设置 root 密码，建议强密码。然后创建 Zabbix 需要的数据库和用户，官方默认用户名是 zabbix，密码也是 zabbix：

mysql -uroot -p CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'zabbix'; GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost'; FLUSH PRIVILEGES;

注意数据库字符集我推荐 utf8mb4，因为默认的 utf8 在 Zabbix 6.0 以后的版本会出现中文乱码或告警信息超长的问题，UTF8MB4 才能完整支持报警消息中的表情或特殊符号。

数据库创建好之后，导入 Zabbix 初始表结构和种子数据。这一步是关键中的关键，导入文件路径如果不对或版本不匹配，后面 Web 前端会白屏：

zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -pzabbix zabbix

执行完这个命令后，可以用mysql -uzabbix -pzabbix zabbix -e "show tables;"验证表是否导入成功，如果能看到一百多张表，说明这一步成功。

2.4 配置 zabbix_server.conf 并启动服务

Zabbix Server 的配置文件在/etc/zabbix/zabbix_server.conf，需要修改数据库连接信息：

DBHost=localhost DBName=zabbix DBUser=zabbix DBPassword=zabbix

这里有个容易被忽略的细节：如果 MySQL 用的 UNIX Socket 连接，DBHost=localhost会走 socket；如果写成服务器 IP，Zabbix 会用 TCP 方式连接 MySQL，此时必须确认 MySQL 监听在相应地址并且有权限。我遇到过把 DBHost 设成 127.0.0.1 导致连接超时的问题，原因是 MySQL 没开 TCP 或防火墙没放行。

修改完配置，把 Nginx 的 Zabbix 配置也检查一遍。Zabbix 6.0 的前端配置路径是/etc/nginx/conf.d/zabbix.conf，里面默认监听的端口是 8080，也可以改成 80。确认listen端口没有被其他服务占用。

最后启动服务并设置开机自启：

systemctl restart zabbix-server zabbix-agent systemctl restart nginx php-fpm systemctl enable zabbix-server zabbix-agent

启动完检查一下zabbix_server.log，路径在/var/log/zabbix/zabbix_server.log。看到 “enabled” 相关字样说明启动成功，如果报数据库相关错误，回到上一节检查。此时浏览器访问http://服务器IP:8080，进入 Zabbix Web 安装向导，按步骤填数据库信息和时区，前端配置完成后就能登录控制台，默认账号是 Admin，密码是 zabbix。

3. 通过 Zabbix API 获取监控数据：CPU、内存和磁盘

3.1 为什么要用 API 而不用 Web 界面

Zabbix 的 Web 界面能完成日常监控配置，但一旦涉及批量操作、数据对接或告警集中管理，Web UI 的操作效率就远远不够了。Zabbix API 提供了完整的 JSON-RPC 接口，通过 HTTP POST 请求就能查询监控数据、创建主机、修改模板、获取告警事件，这些能力在自动化运维场景里非常有用。

举个例子，公司内部有一个监控面板系统，需要展示所有服务器 CPU、内存、磁盘的实时使用率，不可能让人登录 Zabbix 一个个看，更合理的做法是从 Zabbix API 拉取数据，然后在自己的面板里渲染。这个场景对应了热词里的 “postman zabbix api cpu 内存 磁盘”——用 Postman 调试 Zabbix API 就是最快上手的方式。

Zabbix API 的调用地址是http://服务器IP/api_jsonrpc.php，所有请求都要包含jsonrpc、method、params和id这几个字段。请求头和请求体都是 JSON 格式，用 Postman 配置起来很顺手。

3.2 获取 Token 的完整流程

调用 API 的第一步是登录并获取身份令牌（auth token）。Zabbix 的 token 机制是：用用户名密码换取一个临时 token，后续所有请求都带着这个 token 来证明身份。

用 Postman 发起 POST 请求，URL 填http://服务器IP/api_jsonrpc.php，请求体如下：

{ "jsonrpc": "2.0", "method": "user.login", "params": { "username": "Admin", "password": "zabbix" }, "id": 1 }

返回结果中会包含一段字符串，比如"result": "0414d2c2xxxxxxxxxxxxxxxxxxxx"，这个就是 token。注意这个 token 有有效期，默认是 12 小时，过期后需要重新登录获取。

从 API 管理的角度，我建议不要用默认的 Admin 账户在程序里做认证，而是单独创建一个 API 只读账户，只给读取权限，否则权限太大会有安全风险。在 Web 界面创建一个用户组，权限只读，再创建一个用户分配该组，用这个用户调用 API。

3.3 查询 CPU、内存、磁盘监控数据

拿到 token 后，查询监控数据的核心思路是：先找主机（host），再找监控项（item），最后拉取监控项的历史数据（history）。这个链路搞清楚了，API 的使用就通了。

第一步，查询主机列表：

{ "jsonrpc": "2.0", "method": "host.get", "params": { "output": ["hostid", "host"] }, "auth": "你的token", "id": 2 }

返回结果形如：

{ "jsonrpc": "2.0", "result": [ { "hostid": "10084", "host": "web-server-01" } ] }

记住 hostid，后续查监控项都依赖它。

第二步，查询该主机的监控项，筛选 CPU、内存、磁盘相关的 item。Zabbix 的监控项 key 命名很规范，比如 CPU 使用率是system.cpu.util，内存使用率是vm.memory.size，磁盘使用率是vfs.fs.size。但直接记 key 容易漏，更好的方式是按名称模糊搜索：

{ "jsonrpc": "2.0", "method": "item.get", "params": { "hostids": "10084", "search": { "name": "CPU" } }, "auth": "你的token", "id": 3 }

或者直接按 key 精确过滤：

{ "jsonrpc": "2.0", "method": "item.get", "params": { "hostids": "10084", "filter": { "key_": ["system.cpu.util[,idle]"] } }, "auth": "你的token", "id": 3 }

查到了 itemid 之后，第三步就是拉取历史数据。比如想要过去一小时的 CPU 使用率变化：

{ "jsonrpc": "2.0", "method": "history.get", "params": { "itemids": "27152", "history": 0, "time_from": 1710000000, "time_till": 1710003600, "limit": 100 }, "auth": "你的token", "id": 4 }

这里的history字段很重要，0 表示数值型数据（float），1 表示字符型，2 表示日志，3 表示整数型，4 表示文本类型。CPU 使用率、内存使用率都是 float，用 0 即可。time_from和time_till是 Unix 时间戳，单位是秒。

在我实际使用中，用 Postman 调试 API 最常见的问题是 token 忘记替换、params 里少了必填字段、history 值填错导致查不到数据。还有一个隐蔽问题：Zabbix 前端配置的 PHP 时区会影响到 API 返回的时间字段，如果返回的时间戳转换后不是预期时间，先确认服务器的时区设置是否正确。

磁盘监控的查询方式同理，但要先确认磁盘监控项的 key。Zabbix 自带的 Linux 模板里，磁盘使用率对应vfs.fs.size[/,pused]，意思是查看根分区的已用百分比。可以把pused换成total（总大小）、used（已使用）、free（剩余空间）等，灵活度很高。

3.4 通过 API 批量管理监控项

API 不只能查询数据，还能批量创建监控项。比如要监控一批 Linux 服务器的 TCP 端口连通性，100 台机器，一台台在 Web 界面配置会疯掉。用 API 批量创建才是正确姿势。

核心做法是通过template.get找到需要的模板，再通过host.massadd或host.update把模板应用到目标主机。我实际用过一次：需要给 50 台机器添加同一组端口监控，先创建了一个自定义模板，在里面配置好所有 net.tcp.port 监控项，然后用一条脚本循环调用host.massadd，十几秒就全部生效了，如果用 Web 界面手动点，至少得折腾一下午。

4. 实战监控场景：端口探测、Linux 主机与 NAS 存储

4.1 使用 net.tcp.port 监控业务端口连通性

端口连通性是最基础的监控需求，比如一个 Web 服务要确认 80/443 端口可达、MySQL 要确认 3306 可达、Redis 要确认 6379 可达。Zabbix 的net.tcp.port监控项就是做这件事的。

net.tcp.port的 key 格式是net.tcp.port[<ip>,host,port]，几个参数含义分别是被测目标 IP（可留空表示取 host 配置的 IP）、被测域名、端口号。在 Agent 端配置时最常用的是不写 IP，直接用net.tcp.port[,"localhost",80]，其中 IP 参数留空，第二个参数填域名。

这个监控项的原理很简单：Agent 收到指令后会尝试建立 TCP 连接，能连上返回 1，连不上返回 0。在 Zabbix Server 端配合触发器就能实现“端口挂掉自动告警”的效果。触发条件通常写成：

last(/host/net.tcp.port[,"localhost",80])=0

当值为 0 时触发报警，恢复时值为 1 自动关闭报警。

我在实际应用中踩过一个坑：在配置监控项时，如果你填的 IP 是内网地址，而 Zabbix Server 和 Agent 之间跨了网络无法直连，会导致状态一直为 0。这时候建议在 Agent 的配置文件里设置Server=Zabbix服务器IP只允许 Server 拉取数据，同时确认网络路由和防火墙放行 10050 端口。还有一种情况是监控的目标服务本身只监听了特定来源 IP，net.tcp.port探测连接不上，这时候需要检查服务的白名单配置，而不是监控项配错了。

4.2 Linux 主机基础资源监控

监控 Linux 服务器是 Zabbix 最核心的场景之一，Zabbix 自带的 “Linux by Zabbix agent” 模板包含 CPU、内存、磁盘、网络等全套指标，装好 Agent 后直接把模板套上就能用。

关键的监控项包括：系统负载system.load、CPU 利用率system.cpu.util、内存可用率vm.memory.size[available]、内存已用率vm.memory.size[used]、磁盘使用率vfs.fs.size[*,pused]、网络流量net.if.in/net.if.out。这些监控项的分辨率和数据保留时间都可以在模板里调整。

磁盘监控值得单独说一句。Zabbix 默认模板会监控所有挂载点的磁盘使用率，但某些虚拟文件系统比如/proc、/sys、/dev之类的挂载点也应该过滤掉。建议在模板的宏变量{$VFS.FS.PUSED.MAX.WARN}里设置合理的告警阈值，并且通过监控项过滤正则排除伪文件系统。否则你会看到根分区随时都是满的告警，因为这个阈值实际统计的是/而不是数据盘，这个误区我见过很多次。

内存监控的另一个需要关注的东西是 Zabbix 计算内存使用率的方式。Linux 的内存分为 used、buffer/cache、available 等指标，vm.memory.size[used]统计的是 used 部分加 cache，实际可用内存要用 available。在模板中，内存使用率判断是用(used-buffers-cached)/total还是直接used/total，不同版本有差异，建议以 available 为准，以免出现“明明内存还剩很多却报内存高”的误报。

4.3 NAS 存储设备监控

NAS 存储监控是热词里特别提到的场景。NAS 设备一般有两种接入方式：支持 SNMP 的用 SNMP 协议采集，支持 SSH/WMI 的用 Agent 采集。但许多家用和中小型商业 NAS（比如群晖、威联通）默认支持 SNMP，Zabbix 通过 SNMP 模板就能把存储空间、磁盘状态、系统温度等指标拉过来。

如果通过 Agent 方式监控 NAS 的更细粒度指标，需要 NAS 系统支持安装 Agent 软件包，这取决于厂商是否提供了对应架构的安装包。安装好后配置 host 的 IP 与 Agent 端口 10050，使用 “Linux by Zabbix agent” 模板（如果 NAS 基于 Linux 内核）即可。

NAS 监控最需要关注的指标是存储池使用率、RAID 状态、扇区重映射数、坏道与高温警告。Zabbix 本身不直接获取 RAID 卡 SMAR T 信息，需要 NAS 厂商在系统层面把 SMART 数据暴露为可采集的指标，或者在 NAS 上通过自定义脚本把 SMART 输出传给 Zabbix（类型选择文本或字符型）。这些细节在动手之前先想清楚，否则装完发现 NAS 没有任何可用监控项，就只能从零手写。

还有一点要注意：很多 NAS 设备的 Web 管理界面会占用 5000 或 5001 端口，有的 NAS 上如果开启了防火墙策略，Zabbix Agent 或 SNMP 端口需要先在 NAS 的管理界面放行。我调试 NAS 监控时遇到过 SNMP 不通的情况，排查下来是 NAS 上根本没有启用 SNMP 服务，这属于设备配置层面，而不是 Zabbix 配置问题。排查顺序建议从网络连通性、端口开放、服务启动、agent 状态逐层推进，能少走很多弯路。

5. 安装部署中的常见问题与排查技巧

5.1 虚拟机桥接模式获取不到 IP 的问题

热词里有“笔记本电脑安装虚拟机桥接模式无法获取 ip”，这个问题在做 Zabbix 实验时非常常见。很多人想在笔记本上装一台 CentOS 虚拟机跑 Zabbix Server，虚拟机网络选桥接模式后 Linux 却拿不到 IP 地址。

先解释原理：桥接模式相当于虚拟机和宿主机连到了同一个物理交换机上，DHCP 请求要由局域网内现有的路由器或 DHCP 服务器来响应。如果宿主机连的 Wi-Fi 网络开启了 AP 隔离（这是很多路由器为了安全默认开启的功能），虚拟机的 DHCP 请求根本到不了路由器，自然就拿不到 IP。如果公司有线网络有 MAC 绑定或 802.1X 认证，虚拟机桥接模式也会抢不到地址。

对应的解决办法有几种：最简单的方式是不用桥接，改用 NAT 模式，通过宿主机上网，然后手动给虚拟机配一个固定 IP（和宿主机在同一子网或不同子网均可），再用 Zabbix 时直接在浏览器里访问 NAT 映射出来的 IP；也可以打开虚拟机网卡的“混杂模式”或在路由器管理页关闭 AP 隔离；在公司网络里，找网管要一个独立的 IP 段并做端口映射最省心。

从 Zabbix 安装的角度看，自己电脑上做实验的核心目的是把 Zabbix 跑起来，所以不一定要和宿主机网络完全互通。用 NAT 模式固定 IP，把 Zabbix 的 Web 端口在本机用端口转发映射出来，照样可以在浏览器里正常使用。

5.2 Zabbix 中文乱码与 Web 前端白屏

Zabbix Web 前端安装完成后登录，中文界面经常出现文字显示为方块或乱码，这是因为 Zabbix 前端默认使用的字体不支持中文字符。解决方案是上传一个中文字体文件（推荐思源黑体或文泉驿正黑），放到 Zabbix 前端的字体目录下，并且修改字体配置文件。在 Zabbix 6.0 版本下，字体文件路径一般在/usr/share/zabbix/assets/fonts，将这个目录下的默认字体替换成支持中文的 TTF 文件即可。

如果替换完依然乱码，还需要检查数据库连接配置中的字符集是否用了 utf8mb4，以及 PHP 的default_charset是否设定为 UTF-8。我见过一个怪毛病：Web 界面部分中文正常、部分中文乱码，最后发现是数据库表的字符集和连接字符集不一致，在 config 文件里的DBCharset=utf8mb4改好后就恢复了。

Web 前端白屏一般发生在安装向导“检查必要条件”这一步，95% 是因为 PHP 配置项不满足要求，比如PHP max execution time、PHP memory limit、date.timezone这些值过小或未配置。装完 Zabbix 后一定记得编辑/etc/php.ini里的日期时区：

date.timezone = Asia/Shanghai

否则系统时间与前端时间差 8 小时，告警、图表上的时间全部对不上。改完重启 php-fpm 才能生效。

5.3 Agent 主动模式与被动模式的坑

Zabbix Agent 有两种数据上报模式：被动模式（Server 主动来拉数据，10050 端口）和主动模式（Agent 主动向 Server 发送数据，Server 的 10051 端口），两种模式在 Agent 配置里通过Server=和ServerActive=两个参数区分。

新手最常见的误解是Server=和ServerActive=必须配成一样的，其实是有区别的。Server=是配置被动模式下允许哪些 Zabbix Server 来拉数据，ServerActive=是配置主动模式下 Agent 往哪个 Server 的地址去送数据。如果主机启用了主动模式的监控项，而ServerActive=没有配置或填错了端口，这些 item 会一直显示不支持。

另一个坑发生在第一次部署时发现数据全部显示“Not supported”，查看 Agent 日志发现连接被拒绝。此时先运行zabbix_get -s IP -k agent.ping测试 Server 到 Agent 的连通性，如果报错就看 10050 端口是否监听起来、防火墙有没有放行。这个排查顺序屡试不爽。

5.4 安装源版本不匹配导致的服务起不来

用 yum 安装 Zabbix 时，源配错了版本号会导致安装的 server 版本和 agent 版本不一致，甚至前端代码和服务端代码不同步。启动 zabbix-server 时可能报 “Invalid database version” 或者 “Database was not initialized” 的错误，这类问题的根源大多是第一次初始化数据库时导入的 SQL 版本和当前 server 程序版本不匹配。

遇到这种情况最稳妥的办法是备份数据后把数据库整体重来一遍，把 server 版本和 SQL 版本对齐再重导入。操作流程是：先执行rpm -qa | grep zabbix查看已经安装的包，再从官网找到对应版本的 SQL 导入路径。Zabbix 官方对版本一致性要求很严格，小版本之间的数据库表结构有差异，混用版本大概率会出问题。

我个人的经验是：生产环境装 Zabbix，安装前先查一眼官方安装文档当前 LTS 版本的依赖要求，把 MySQL 版本、PHP 版本、Agent 版本统统拉到同一张表里核对，这样能省掉很多返工时间。

5.5 常被忽略的时区问题和告警时间偏移

监控系统如果时间不准，告警记录和趋势图就没有任何意义。Zabbix Server 的时区、PHP 的时区、数据库的时区必须三者一致。在 CentOS 7.9 上，如果服务器本身 UTC、PHP 配了 Asia/Shanghai、数据库用 system 时区，就会出现“看到的历史数据总是慢了 8 小时”的情况。

检查时区三步走：第一步date看系统时间是否正确；第二步看/etc/php.ini的date.timezone是否配置；第三步进 Zabbix Web 界面“管理 - 一般 - 系统”里看时区设置。建议全链路统一使用Asia/Shanghai。

还有一个隐蔽点：Zabbix 6.0 的 PHP 前端对时区校验更严格，如果date.timezone没有配置，安装向导会在必要条件检查里直接标红提示，很多教程里没提这一点，导致这一步卡住的同学不在少数。装完直接改好再进向导，体验会顺很多。

6. 从安装到落地：调试 Zabbix 时我建议养成的四个习惯

装了无数次 Zabbix、踩过各种安装模式的坑之后，我总结出几个对新人帮助最大的习惯，分享出来供你参考。

第一，测试环境尽量用快照。无论是 VMware 虚拟机还是云主机，安装 Zabbix 前打个快照，一旦配置文件改乱了或数据库导错了，回滚只在一瞬间，不需要重装。我实际操作时通常在关好 SELinux、配好 yum 源、初始化数据库成功后各打一次快照，这样每一步都能回退，排查问题非常从容。

第二，日志比报错信息更诚实。Zabbix Server 的日志在/var/log/zabbix/zabbix_server.log，Agent 的日志在/var/log/zabbix/zabbix_agentd.log，前端 PHP 的错误通常在 Nginx 的 error_log 里。遇到“不支持”或者“连接拒绝”这类报错，先翻日志，不要急着改配置。很多新手一报错就重装，其实日志里早就写明了原因，比如数据库密码不对、权限不足、端口被占。

第三，先跑通最小的监控链路再扩展。刚开始学 Zabbix 时，不要一上来就接几十台机器、配一堆模板。我推荐的最小链路是：先在服务器本机装 Agent，确认agent.ping返回 1，然后加一个 CPU 监控项，再配一个告警，通过邮件或钉钉通知自己。这条链路跑通了，后面所有的“批量接入”“模板定制”都是量变，不会遇到原理性的困难。

第四，监控项的 value 类型和单位一定要匹配。这是一个非常容易排查半天才发现的问题：明明监控项采集到了数据，但图表显示的数字单位完全不对。比如net.if.in的返回单位是 bps，Zabbix 默认的 SI 单位换算会把他从 b 转成 B、再从 B 转成 K。所以配置网络监控项时记得把单位设为 bit/s，否则看到的数据差整整 8 倍。这类细节问题通常在数据量上去之前不会暴露，一旦暴露却会误导决策，提前养好习惯就能避免。

我自己最近一次重新部署 Zabbix 时，还是老老实实走了“RPM 安装 + MySQL 初始化 + Agent 主动模式”的路线。Zabbix 这个工具本身的复杂度不算高，真正让新手头疼的往往是那些安装模式之外的、隐藏在配置细节里的坑。如果你读到这里，能少踩一半我当年踩过的坑，这篇内容就算没白写。