Zabbix安装模式详解：二进制包与Docker容器部署实战

前两年我给一批数据库服务器做监控系统选型，组里一位老哥刚把Zabbix的安装包下到一半，扭头问我：这东西到底有几种装法？网上教程有的让编译源码、有的让用yum装、有的直接拉docker镜像，人直接看懵。这个问题确实问到了根子上——Zabbix的安装模式从来不是单选题，源码编译、二进制包、容器化、云镜像这四条路各有各的适用场景，选错了后边维护起来是真遭罪。这篇就把几条路线从头到尾捋一遍，再结合我在CentOS 7.9和Docker环境里的实际部署记录，把关键步骤和坑都摊开讲，适合刚接触Zabbix、正在纠结怎么装的人，也适合装过但没搞明白各模式差异的运维朋友。

1. 安装模式全景透视：先把四个选项摆在桌面上

很多人第一次接触Zabbix，第一个困惑不是监控项怎么写，而是“安装”这件事本身就有好几种玩法。这也是“Zabbix(安装模式)”这个搜索词被反复搜的原因。我见过不少新人拿着一篇源码编译教程折腾了两天，结果连前端页面都起不来，最后换了个rpm包五分钟搞定。所以先别急着敲命令，弄清楚每种模式背后的设计逻辑，再对号入座。

1.1 源码编译安装：什么情况才会选它

源码编译是历史最悠久的方式，流程无非是下载源码包、configure、make、make install。整个过程相当于把关卡全开了，你可以自定义编译选项，比如指定MySQL还是PostgreSQL、启用某些特殊模块、安装到非标准路径，还能针对特定CPU架构做优化。听起来很强大，但代价也很明显：依赖关系完全靠自己解决，光是PHP、zabbix-web、zabbix-server各自的依赖库就能让人调半天，后续升级更是噩梦——新版本编译参数、依赖版本变了，重来一遍，配置文件和数据库迁移还得另算。

另外一个隐藏问题在glibc版本上。一些老系统比如CentOS 7.9，系统自带的库版本偏低，编译Zabbix 7.0时很容易卡在某个依赖上。我用过的实际经验是，如果跑的是主流x86_64服务器，又没什么特殊硬件要求，直接跳过源码编译，除非你在做二次开发或者需要打进特定的嵌入式环境里。我见过一家做国产化适配的公司，底层的CPU是arm架构，官方的rpm包选不到合适的，最后只能自己交叉编译。这种场景下源码编译是绕不过去的，但对绝大多数人来说，它不是第一选择。

1.2 二进制包安装：生产环境最常见的选择

所谓二进制包，就是官方把编译好的程序连同依赖、脚本一起打包成rpm或者deb格式，放到软件仓库里，用户直接用包管理器安装。CentOS和Ubuntu都有对应的官方仓库，配置好后一条命令就能把zabbix-server、zabbix-agent、zabbix-web这些组件装齐。

这种方式最核心的优势在于可维护性。rpm包安装会把文件放到标准位置，启动脚本、配置目录、日志目录全都是约定好的，升级时直接yum update zabbix-server就能完成，数据库脚本也会随包更新。而且rpm包在安装时就会自动处理依赖，比如装zabbix-server-mysql会自动拉上MySQL相关的客户端库，基本不用操心少了哪个包。

代价就是你得接受“官方替你做的决定”，比如文件路径、默认的Web服务器（通常是Apache或者Nginx）、PHP版本之类。对于想快速落地监控系统、后续还要长期维护的团队，这是我推荐的首选方案，也是下文实操部分的主力。Zabbix官方对不同Linux发行版维护了独立的仓库，CentOS 7.9这种已经进入维护尾声的系统，只要处理一下源地址也能正常装到当前最新版。

1.3 容器化安装：快速拉起一套监控系统的捷径

容器模式是近几年个人和中小团队玩得最多的方式。Zabbix官方在Docker Hub上发布了多组镜像，包括基于MySQL的、基于PostgreSQL的、集成了Nginx Web界面的，甚至还有针对ARM架构的版本。用Docker Compose把数据库、Server、Web三容器编排起来，启动时间从“装系统配置一天”压缩到“几分钟出界面”。

容器化最大的价值是环境隔离和可复制性。宿主机上不需要装PHP、Nginx、数据库，每个组件各跑各的容器，升级时只需要换成新tag的镜像，起一个新容器替换旧容器，不回滚也能通过镜像tag快速切换。开发环境里歪了就直接删掉重来，不存在“系统被我装坏了”的问题。

当然也要清醒一点：容器方式对网络、存储和日志的管理比直接用rpm复杂。Zabbix Server容器如果没把数据卷挂出来，整个数据目录随容器销毁而丢失，没备份又是一次“从零开始”。另外容器内的时区、语言环境默认是UTC，如果不显式处理，页面上的时间能让你怀疑人生。这些细节我在第三部分详细展开。

1.4 云镜像与一体机：拿来即用的另一条路

除了上面三种自己动手的模式，Zabbix官方还提供虚拟化一体机（Appliance）和云市场镜像。前者是一个OVA文件，直接导入VMware或者VirtualBox就能跑；后者在AWS、Azure等市场上可以一键拉起。这种方式本质上是官方预先做好的一套封装——系统已经装好、服务已经启动、数据库已经初始化，你只要导入后改一下登录密码就能用。

用这种模式的人通常是两种情况：一种是只想快速看效果，不关心底层细节；另一种是企业内网要求极短时间交付一套可用的监控环境，不想让运维把时间耗在安装上。但要注意，一体机默认的存储和内存配置并不适合大规模监控，前期验证可以，真要上生产还得规划容量。而且基于云镜像的Zabbix，在部分云环境里需要额外配置安全组和存储卷，这一点我在企业项目里踩过一次，后文会提到。

1.5 选型对照：不同团队背景该怎么选

选安装模式的核心逻辑就一条：维护成本和交付速度之间的平衡。几条路的特性我用一张表总结，方便按需对号入座：

如果你是单人维护一个十几个节点的内网环境，直接用二进制包最稳；如果你是想跑一套完整体验一下监控功能，容器化是投入产出比最高的；如果是给客户做POC演示，一体机最省事。下面我把最常用的两条路线，也就是二进制包和容器化，按实际操作流程完整走一遍。

2. 二进制包模式实操：CentOS 7.9 部署 Zabbix 7.0 LTS

先从CentOS 7.9开始讲，因为这个系统版本存量实在太大了，很多企业内部服务器都还跑在上面。Zabbix官方对CentOS 7的仓库维护到Zabbix 7.0 LTS这一代，所以只要源配对了，装最新版是没问题的。但在动手之前，有一件让不少人卡住的事得先解决掉——虚拟机桥接模式获取不到IP。

2.1 准备工作：虚拟机桥接模式无法获取IP的排查思路

热搜词里“笔记本电脑安装虚拟机桥接模式无法获取ip”这个场景，相信很多用VMware或者VirtualBox做实验的人都遇到过。搞明白了这个问题，你的安装环境才算真正搭起来。

我先解释一下虚拟机网络模式的区别。NAT模式下，虚拟机的网络流量经过宿主机转发出去，虚拟网卡使用的是VMnet8这个虚拟子网，由VMware自行分配IP，跟宿主机的局域网没关系。桥接模式则是把虚拟机直接接到物理局域网里，虚拟网卡和宿主机处在同一个网段，需要局域网中的路由器或DHCP服务器给它分配IP。问题就出在这个“需要DHCP分配”上。

笔记本场景下最常见的原因是无线网络环境不允许桥接。很多办公室WiFi启用了AP隔离，也就是接入的各个设备之间不能互相访问，多少虚拟机都会被拒绝。另外有些软路由开启了DHCP过滤，只给已知MAC地址分配IP。你拿一台虚拟机去桥接，结果就是拿到了一个Autoconfiguration Address，169.254开头的地址，上不了网，虚拟机也进不了局域网。排查思路我建议按下面几步来：

先用ip addr确认虚拟网卡状态，看是否出现了169.254地址，是的话说明DHCP确实没拿到IP。然后检查VMware的虚拟网络编辑器，确认桥接模式选的是“自动”还是指定了某块物理网卡，笔记本有无线网卡和有线网卡时选错对象是常事。第三步，试着把WiFi换成手机热点或者有线路由环境，排除AP隔离因素。如果最后实在解决不了，别死磕桥接，直接用NAT模式，然后给虚拟机配一个静态映射（比如VMware的端口转发），实验环境用NAT是完全够的。

Zabbix安装本身对网络模式没有要求，但有个原则要记住：一旦装好，Server的IP尽量固定。后续所有被监控主机都要往这个地址上报数据，IP一旦变了，所有Agent的Active通道会同时失效，那是相当酸爽的排查体验。

2.2 配置官方仓库与安装软件包

CentOS 7.9的系统源因为系统本身EOL的关系，需要做一点特殊处理，否则安装依赖时会有很多404的报错。如果你的系统还能正常从官方源拉包，那直接用官方Zabbix源就行；如果yum源已经废了，先把base和updates源指到Vault镜像，具体操作是用阿里的vault镜像替换CentOS-Base.repo里的链接，这一步不展开太多，网上配套教程很多。

接下来下载并安装Zabbix官方release包：

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

安装完后检查一下仓库是否生效：

yum repolist | grep zabbix

官方仓库里区分了zabbix 7.0的多个组件，前端、Server、Agent都有单独包。我建议一次性装全：

yum install -y zabbix-server-mysql zabbix-web-mysql zabbix-agent zabbix-sql-scripts

注意这里选的是mysql变体，也就是配合MySQL/MariaDB使用的。如果你的环境想用PostgreSQL，安装包名称要换成zabbix-server-pgsql。装完后可以通过rpm -qa | grep zabbix确认安装列表，正常情况下能列出release包、server包、web包、agent包和sql-scripts包。

2.3 初始化数据库与导入表结构

Zabbix的元数据库是整套系统的核心，所有主机、监控项、告警记录都存在这里。CentOS 7.9自带的yum源里默认提供MariaDB 5.5，这个版本是兼容的，但性能一般，如果内存足够，建议直接换成MariaDB 10.x或者MySQL 8.x。这里按常见写法用系统自带的MariaDB来完成。

启动数据库并设置开机自启：

systemctl start mariadb systemctl enable mariadb mysql_secure_installation

安全初始化脚本里设置root密码，然后创建Zabbix专用库和用户。注意字符集一定要用utf8mb4而不是utf8，不然存中文报警信息时容易出乱码：

mysql -uroot -p

进入MySQL命令行：

create database zabbix character set utf8mb4 collate utf8mb4_bin; create user 'zabbix'@'localhost' identified by '你的数据库密码'; grant all privileges on zabbix.* to 'zabbix'@'localhost'; flush privileges;

然后导入官方提供的表结构。Zabbix 7.0的SQL脚本路径在/usr/share/doc/zabbix-sql-scripts/mysql/下，用zcat直接管道导入：

zcat /usr/share/doc/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix

这一步是整个安装过程中最容易出问题的环节。常见报错有ERROR 1064 (42000): You have an error in your SQL syntax，多半是数据库版本太低或者字符集不对；还有Access denied for user 'zabbix'@'localhost'，说明授权没完成。导入过程中如果出现大量输出，基本都是语法警告，可以忽略，只要最后没有以ERROR结尾就行。导入完成后可以用mysql -uzabbix -p zabbix -e "show tables;"验证，能看到几十张表说明导入成功。

2.4 调整服务端配置并完成前端安装

Zabbix Server配置文件在/etc/zabbix/zabbix_server.conf，主要改两项：数据库连接信息和日志相关设置。

vim /etc/zabbix/zabbix_server.conf

找到以下几行并修改：

DBHost=localhost DBName=zabbix DBUser=zabbix DBPassword=你的数据库密码

CentOS 7.9环境下zabbix_server.conf里默认没有写DBHost，连本地库时可以留空，但建议显式写上localhost，避免后续某些版本解析问题。配置保存后启动Server：

systemctl restart zabbix-server systemctl enable zabbix-server

前端配置方面，Zabbix 7.0的Web前端和Apache集成在一起，配置文件在/etc/httpd/conf.d/zabbix.conf。重点修改PHP时区，否则安装向导和后续告警会一直提示PHP timezone未设置：

php_value date.timezone Asia/Shanghai

还需要确认PHP的文件上传大小限制和执行时间参数，如果监控项超过默认值，后面在模板里导入大文件或者批量关联主机时会踩坑。

php_value upload_max_filesize 32M php_value post_max_size 32M

改完后重启Apache：

systemctl restart httpd systemctl enable httpd

接着浏览器访问http://你的服务器IP/zabbix，进入安装向导。中间步骤会检查PHP环境、数据库连接，前端会要求再次填入数据库密码并完成最终配置。整个过程十分钟内能走完，最后一步会把配置写进/etc/zabbix/web/zabbix.conf.php。这里有一个版本差异要注意：Zabbix 6.0以前，安装向导完成后会生成一个schema.inc.php校验文件，而Zabbix 7.0的校验逻辑做了调整，如果看到提示“无法连接数据库”，优先检查Server启动状态而不是前端配置。

2.5 安装完成后必须处理的三个小细节

装完能打开页面只是第一步，还有三个细节我建议立刻处理掉，不然过几天一定会后悔。

第一个是Agent的启动和防火墙放行。被监控主机要连接Server的10051端口，Server要连接Agent的10050端口，如果开了firewalld，需要把这两个端口全部放通：

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

第二个是Zabbix Agent默认配置里的Server地址。装好的Agent默认监听所有地址，但必须让Agent知道允许哪些Server来取数据，修改/etc/zabbix/zabbix_agentd.conf里的Server=和ServerActive=，填上Zabbix Server的IP。这一步漏掉的话，Web界面上主机的可用性会一直显示灰色“未知”。

第三个是时区同步。除了前端的PHP时区，Server本身和Agent的时区也要一致。CentOS 7.9用timedatectl set-timezone Asia/Shanghai同步一下。监控系统时间基准错了，告警时间戳全乱，加班排查问题的时候两眼一黑。

3. 容器化模式实操：Docker Compose 拉起 Zabbix 全栈

如果说二进制包是给“保守派”准备的，那容器化就是给“效率党”准备的。我自己的测试机上常年用容器跑一套Zabbix 7.0，什么事情都先堆里试一圈再往生产上搬。

3.1 为什么推荐用容器做Zabbix的快速验证

容器模式的最大好处不是“装得快”这么简单。它能剥离物理机和系统配置的差异，同一个compose文件，在家里的笔记本能起，在机房一台裸机上也能起，顶多是镜像拉取速度不同。另一个好处是Zabbix Server容器和数据库容器做到本质隔离，升级Server版本时完全不用动数据库宿主机，反之亦然。

我踩过一次印象深刻：给客户做POC演示，现场机器只有8G内存，我原本打算直接装rpm包，结果发现客户的CentOS版本偏旧，PHP版本不够，还得编译升级。后来干脆拉了一组容器镜像，PostgreSQL占了1G左右，Server镜像700M左右，Web镜像500M左右，加起来两分钟跑起来，演示完把容器一停，宿主机干干净净没有任何残留依赖。这种可复现、可销毁的特性，在交付演示环境时价值极高。

还有一个很容易忽略的点：容器版本的Zabbix官方镜像针对Docker环境做了参数优化。你可以通过环境变量直接控制缓存大小、超时时间、并发进程数，而不需要手动去改配置文件。这意味着你可以在不重新构建镜像的情况下，通过调整compose里的环境变量来测试不同配额的运行效果。

3.2 一份可直接落地的 compose 配置

以Zabbix 7.0 LTS加PostgreSQL 16为例，文件名docker-compose.yml，内容如下：

version: "3.8" services: postgres-server: image: postgres:16-alpine container_name: zabbix-postgres environment: POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix POSTGRES_DB: zabbix volumes: - pgdata:/var/lib/postgresql/data restart: unless-stopped zabbix-server: image: zabbix/zabbix-server-pgsql:7.0-alpine-latest container_name: zabbix-server environment: DB_SERVER_HOST: postgres-server POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix ZBX_CACHESIZE: 256M ZBX_STARTPOLLERS: 8 ZBX_STARTPOLLERSUNREACHABLE: 2 ports: - "10051:10051" depends_on: - postgres-server restart: unless-stopped zabbix-web: image: zabbix/zabbix-web-nginx-pgsql:7.0-alpine-latest container_name: zabbix-web environment: ZBX_SERVER_HOST: zabbix-server DB_SERVER_HOST: postgres-server POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix PHP_TZ: Asia/Shanghai ports: - "8080:8080" depends_on: - zabbix-server restart: unless-stopped volumes: pgdata:

启动方式：

docker compose up -d

注意版本tag选取。7.0-alpine-latest表示Zabbix 7.0发行线的最新版，alpine表示基于Alpine Linux的精简镜像，体积小、攻击面小。如果你需要指定某个小版本，就把tag写具体，比如7.0.5-alpine-3.28，生产环境建议固定tag，避免某个清晨突然升级到不兼容的小版本。

3.3 容器模式与物理机部署的行为差异

容器里跑Zabbix和物理机上跑，有几个行为差异必须心里有数。

第一大差异是数据库初始化方式。rpm包模式需要手动创建库、导入schema，而容器镜像里已经内置了初始化逻辑。PostgreSQL容器第一次启动时会自动创建用户和数据库，Zabbix Server容器启动时会检测数据库是否为空，为空就自动初始化表结构。这也是容器模式能“一条命令拉起整套系统”的原因。但如果你手动往PostgreSQL里建了其他表或者改了字符集，初始化可能中断，日志里会报Schema is not up to date之类的错误。

第二大差异是日志访问方式。容器里的日志要透过docker层查看，直接用docker logs -f zabbix-server访问Zabbix Server日志，看不到传统的/var/log/zabbix/zabbix_server.log文件，除非你把日志目录挂在宿主机上。为了方便排查，建议在compose的server服务里额外加一个volume：

volumes: - /data/zabbix/server_log:/var/log/zabbix

这样日志可以落到宿主机磁盘，用tail -f /data/zabbix/server_log/zabbix_server.log盯起来舒服得多。

第三大差异是网络栈。Zabbix Server容器默认使用bridge网络，对外只暴露个别端口。如果同时部署了Zabbix Proxy，还要把Proxy到Server的端口映射出去，或者让它们处于同一个自定义网络内。如果直接用默认网络，容器重启后IP会变化，Agent的Active通道会全部断掉，这一点经常被忽略。

3.4 容器版本的日常维护命令

二进制包模式日常操作是systemctl，容器模式就是docker compose子命令。列举几个最常用的：

# 查看整体状态 docker compose ps # 查看Server日志 docker logs -f zabbix-server # 进入容器内部排查 docker exec -it zabbix-server bash # 升级版本（先把镜像拉下来，再重建容器） docker compose pull docker compose up -d # 停机但不删数据卷 docker compose down # 彻底删除容器和数据卷（慎重） docker compose down -v

升级流程是容器模式最爽的地方：编辑compose文件里的镜像tag，然后docker compose pull加上docker compose up -d，旧容器自动替换，数据库卷保留不丢失，整个升级过程基本在一分钟以内完成。对比rpm模式的数据库脚本升级和PHP兼容检查，这个体验确实是无缝的。

另外，容器模式下ZBX_CACHESIZE这些环境变量对应的就是zabbix_server.conf里的CacheSize。刚开始不用改太多参数，默认值够用，等监控的主机数量上来之后再根据实际内存去调。

4. 部署验收与监控项验证：安装不是终点

不管是哪种安装模式，装完都不算完，总得验证一下整个链路是不是通的。最直接的验证方式不是看页面，而是通过API和监控项测试，这也是为什么“postman zabbix api cpu 内存 磁盘”和“zabbix net.tcp.port”会一起出现在热搜词里的原因——大家在配置到这一步时开始卡壳。

4.1 用 Postman 走一遍 Zabbix API 基本流程

Zabbix从很早的版本就开放了完整的JSON-RPC API，安装完成后可以用Postman或者curl调一下，确认前端和Server的通信正常。Zabbix 6.0之后的API鉴权从旧的auth字段转向了基于token的登录方式，7.0沿用了token方案。

第一步，获取API token：

curl -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": "Admin", "password": "你的密码" }, "id": 1 }'

返回结果类似：

{ "jsonrpc": "2.0", "result": "65d2f6f09a3f9b24c1b7b8ef8f0f7d0f", "id": 1 }

这个result字符串就是token，后边所有API请求都要带着它。注意Zabbix 6.0以后对Admin密码有强度要求，如果你安装过程中设置的密码太简单，这里登录会直接拒绝，需要先去页面上修改密码策略。

第二步，用token获取主机列表：

curl -X POST http://127.0.0.1/zabbix/api_jsonrpc.php \ -H "Content-Type: application/json-rpc" \ -d '{ "jsonrpc": "2.0", "method": "host.get", "params": { "output": ["hostid", "host"] }, "auth": "上面拿到的token", "id": 2 }'

返回的主机列表能看出当前系统里已经纳管了多少台机器。之后不管是要批量出报表，还是通过脚本自动化添加主机，都可以走这套API。Postman用户可以建一个集合专门放这些请求，环境变量里存server地址和token，换环境时只改变量就行。

4.2 加一台主机：CPU、内存、磁盘监控项的选法

完成API验证后，接下来就是配置一台真实的主机。我以一台Linux服务器为例，讲解标准添加流程。

在Web前端导航到“数据采集 -> 主机”，点“创建主机”。主机名填实际机器名（不是IP），可见名称可以随意，Host组建议新建一个和业务相关的组，比如“Product-Linux”。Interfaces里加Agent接口，IP填被监控机的地址，端口默认10050。

然后关联模板。Zabbix 7.0自带大量官方模板，找到“Linux by Zabbix agent active”这一套，关联上去即可。这套模板涵盖了绝大多数基础监控项：

如果你需要更精确的CPU使用率，可以在监控项里额外加一个：

key: system.cpu.util[,idle]

然后通过计算型监控项算100 - 采集到的idle值，就能得到整体CPU使用率。模板里的system.cpu.util本身就带了计算模式，初学阶段直接用模板默认值就够了，不要一开始就精细到每一核的性能指标——监控粒度越细，存储和图表压力越大。

4.3 net.tcp.port 端口监控的正确写法

“zabbix net.tcp.port”是运维人员搜索次数极高的关键词，因为它对应的是最刚需的端口探测场景。比如你要监控MySQL的3306端口是否存活，或者Nginx的80端口是否在监听，这个监控项就能办到。语法是：

net.tcp.port[<ip>,port]

不带IP时默认探测本机：

net.tcp.port[,3306]

这里有个常踩的坑：Zabbix的key里，中括号内第一个参数如果留空，表示用本机IP，但逗号不能省。我第一次写的时候就漏了逗号，排了半天死活说“Not supported”。加了对agent版本有要求，如果Agent版本过旧，部分key的语法会不识别，建议统一升级到7.0。

端口监控有两种形态：被动探测和主动上报。在模板里新增一个监控项时，必须注意“信息类型”要选“数字（无符号）”，因为端口存活状态返回的是0或1。0表示端口未通，1表示通。之后在最新数据页面能看到实时值：比如预期的MySQL端口应该是1，结果成了0，这时候你不管看内存还是CPU都是白查，肯定是数据库进程挂了或防火墙拦截了。

实际项目里我习惯配合Trigger使用，新建一条触发器表达式：

last(/Linux by Zabbix agent active/net.tcp.port[,3306])=0

也就是当端口探测结果为0时触发告警。比直接监控“进程是否存在”靠谱得多，因为进程在但端口没监听的情况很常见（比如MySQL卡死、监听地址变了）。

4.4 NAS 与 Linux 存储设备的监控思路

热搜词里还有“zabbix 监控linux nas存储”，这个场景在小公司特别常见——业务数据放在NAS上，运维被要求把所有存储设备纳入监控。NAS的监控思路取决于设备类型。

如果你的NAS是群晖这种成品设备，最简单的路径是开启SNMP服务，然后在Zabbix里关联“SNMP Generic”模板，通过OID采集CPU、内存、磁盘状态。群晖的MIB库官方有文档，关键OID包括1.3.6.1.4.1.6574.1.2.1.1.2（CPU使用率）、1.3.6.1.4.1.6574.1.2.1.1.3（内存使用率）。配置时注意SNMP community默认是public，生产环境请改成强密码，不然内网其他设备也能轻易读到信息。

如果你用的是TrueNAS、openmediavault这类开源NAS系统，更推荐直接安装Zabbix Agent，然后按照Linux主机的思路添加监控项。存储空间监控用：

vfs.fs.size[/mnt/pool,used]

这里的/mnt/pool是NAS存储池的挂载点，你可以通过df -h确认实际路径。需要注意NFS挂载的远程目录，Zabbix Agent默认不会跨文件系统扫描，如果vfs.fs.size返回0，大概率是挂载方式或权限问题。

如果你需要监控Windows NAS，比如联想、浪潮的存储设备，思路类似，开SNMP或者装Windows版Zabbix Agent，监控项写法略有不同，但整体框架一致。存储监控的精髓是“看容量趋势”而不是只看当前剩余值，Zabbix自带的趋势图表可以直接展示未来容量耗尽的时间点，这一步配合触发器做阈值告警，基本就能覆盖日常需求。

5. 安装踩坑实录：现象、原因、处理办法

走到这里，核心安装和验证流程已经完整走了一遍。最后把我在两种安装模式下实际遇到的高频问题汇总成速查表，再分享几个只有真正动手才会知道的小经验。

5.1 常见问题速查表

5.2 几点只有实际操作过才懂的心得

最后聊几句经验体感。给刚接触Zabbix的同行几个建议，都是我踩过的坑换来的思路谨慎。

第一，第一次部署千万别从源码编译开始。很多教程写源码编译是为了通用性，但你在CentOS 7.9上照着装一个7.0版本，大概率会卡在PHP依赖或者编译环境上，浪费一整天不说，还可能把系统环境搞乱。先用二进制包或者容器模式跑通一套，看到监控数据那一刻，你会对整个系统建立起信心；等以后真有特殊需求，再回头研究编译不迟。

第二，不管选哪种安装模式，数据库字符集务必使用utf8mb4。中文环境下如果用了utf8或者latin1，页面上的中文报警消息和自定义监控项名称会变成问号，排查起来极其痛苦。二进制包模式手动建库时要指定，容器模式镜像内置的初始化脚本默认就是utf8mb4，这一点也是容器模式更省心的体现。

第三，安装完成后建议立刻用zabbix_get命令验证Agent到Server的链路，不要等页面看数据。命令用法示例：

zabbix_get -s 被监控主机IP -k agent.ping

返回1说明Agent在线，之后可以进一步测试zabbix_get -s 目标IP -k net.tcp.port[,3306]这类端口监控key。这一步能直接定位问题是出自网络、Agent还是监控项配置，比在页面上猜省太多时间。

第四，也是我个人一直坚持的做法：生产环境不管用什么模式安装，都先把数据库备份脚本写好。Zabbix的数据库在整个监控体系里是最金贵的资产，主机配置、触发器、模板全在里面，重装Server易，重建整套配置难。每天定时mysqldump或者pg_dump，丢库不慌，这才是安装模式的真正收官动作。