☰
Zabbix离线安装全攻略:内网环境依赖处理与部署实战
2026/10/14 17:57:33 网站建设 项目流程

作为一个干了七八年运维的人,Zabbix 是我无论如何都绕不开的一个名字,而“离线安装”这四个字,几乎是所有内网环境工程师的共同记忆。这个系列第一篇,我就从最让人头疼的离线安装开始写,把我踩过的坑和验证过的路径都摊开来说。

很多人第一次装 Zabbix 是在能上外网的机器上,一路 yum 下去行云流水。但生产环境往往是隔离的内网,没有外部软件源,甚至连基础的编译工具链都不齐全。这时候你才意识到,离线安装考验的不是命令敲得多熟练,而是你对依赖关系、系统环境和安装方案的整体把控。这篇文章适合谁?刚接手内网监控平台建设的运维新人,以及被离线包依赖折腾到怀疑人生的同行。我会把离线安装的思路、依赖处理技巧、实际部署过程和问题排查经验一次说清。

1. 离线安装的整体思路与方案选型

1.1 先搞懂为什么必须走离线这条路

做过内网项目的人都有体会,所谓“内网”不只是网段隔离,更是一整套安全策略的产物。生产服务器往往不直接暴露公网,补丁升级要走审批流程,安装软件更不能随便从外网拉取。有一次我在某项目的内网环境里部署监控系统,连 yum 仓库都是内网自建的,第三方源完全不可达,当时那种“拿着源码却装不上依赖”的心情,至今记忆犹新。

离线安装本质上是解决软件分发的可达性问题。你在能上外网的环境里把该下载的东西准备好,通过移动介质或内网传输手段带到隔离环境,再用本地源或安装包的方式完成部署。听起来简单,但难点在于:Zabbix Server 依赖的软件栈很长,从数据库、Web 服务器、PHP 到各种基础库,缺一个环节都装不上。所以方案选型的第一原则,不是选“看上去简单”的方案,而是选“依赖可控、出错可查”的方案。

1.2 标准在线安装与离线安装的核心差异

维度在线安装离线安装
软件源官方镜像、第三方yum源本地搭建的yum源或rpm包集合
依赖处理yum自动解析手动梳理或提前打包
部署耗时通常几十分钟准备阶段可能花数小时
失败回滚相对容易比较痛苦,需谨慎操作
适用范围有外网开发环境生产隔离网、涉密环境

表格列得很直白,实操中大多数人忽视的是依赖处理这一行的差距。在线时你敲一句 yum install,解析器会自动帮你拉全依赖;离线时你得自己搞清楚 zabbix-server-mysql 到底需要哪些 .so 库、哪些 Perl 模块、哪些 PHP 扩展。通常做法有两种:一种是准备一个洁净的相同版本操作系统环境,把所有 rpm 包一股脑下载下来;另一种是直接用打包工具把整个安装过程固化成镜像或容器。

1.3 方案选型的核心逻辑与个人取舍

离线安装 Zabbix 有三种主流路径,我分别说下适用场景:

  • 本地 yum 源方案:在一台同样系统版本的在线机器上,通过 yumdownloader 或 repotrack 把 Zabbix 及全部依赖 rpm 下载回来,带到内网搭建本地源。适合机器多、版本一致、后续还要部署 agent 的场景。成本是准备时间稍长,但胜在一劳永逸。

  • 全部 rpm 手动安装:少部分机器,快速测试,可以直接 rpm -ivh 逐个安装依赖。看似最直接,但依赖顺序容易踩坑,尤其是 glibc 这类基础库升级不当,会牵连系统其他程序。

  • Docker 镜像离线导入:内网环境若已具备容器化基础,直接拉取相关的 Zabbix 镜像而后 save、load 导入,是最省心的方案。但需要注意,很多内网环境对容器技术本身有限制,而且 Docker 化后的监控网络模式调试也需要经验。

我个人的习惯是,如果内网机器数量超过五台,一律走本地 yum 源;如果只是临时搭一套验证,就手动装 rpm;如果用户环境已经有成熟容器平台,优先 Docker 导入。这篇文章重点展开第一种,因为它的普适性最强,也最能体现离线安装的完整方法论。

2. 前置准备工作:把“弹药”备好再动手

2.1 系统环境确认与版本选择

离线安装失败最隐蔽的原因,是你拿来打包依赖的系统,跟目标部署系统的版本不一致。Zabbix 官方对不同操作系统的支持有差异,某些依赖库的版本编号在不同小版本之间也会变化。拿到部署任务后,我的第一步永远是登进目标机器,确认操作系统版本、架构和内核信息,一个字节都不放过。

环境确认清单:

  1. 操作系统发行版及版本号,执行 cat /etc/os-release
  2. CPU 架构,执行 uname -m
  3. SELinux 与防火墙状态,执行 getenforce 和 systemctl status firewalld
  4. 是否已安装数据库、Web 服务等可能冲突的软件
  5. /etc/hosts 解析是否正常,主机名能否正确解析到本机 IP

版本选择方面,Zabbix 的 LTS 版本是稳妥之选,功能更新和 bug 修复都有保障。数据库方面,MySQL 5.7 或 MariaDB 10.x 都可以跑,但要注意 Zabbix Server 对数据库字符集有明确要求,默认必须是 utf8mb4,否则后面前端图形和数据存储都会出乱子。

2.2 利用在线环境做好依赖的批量化收集

在能访问外网的“跳板机”上,安装与目标机器相同版本的操作系统,然后配置 Zabbix 官方源,不直接安装 Zabbix,而是用 repotrack 一次性把 zabbix-server-mysql、zabbix-web-mysql、zabbix-agent 及其依赖全部拉下来。repotrack 比 yumdownloader 更省心的地方在于,它会递归解析动态依赖,不会漏包。

依赖下载脚本核心写法:

# 安装repotrack工具(基于yum-utils) yum install -y yum-utils # 为zabbix组件及其递归依赖创建一个存放目录 mkdir -p /data/zabbix-rpms cd /data/zabbix-rpms # 拉取zabbix server相关组件及其全部依赖 repotrack -p /data/zabbix-rpms zabbix-server-mysql zabbix-web-mysql zabbix-agent

运行完这条命令,目录里可能躺着一大堆 rpm 文件,别慌,这很正常。Zabbix 的依赖牵扯到 httpd、php、php-bcmath、php-mbstring、php-gd 等一长串,加上 glibc、openssl、libxml2 这类基础库,轻松上百个。下载完成后打包这些文件,同时把 Zabbix 官方源里带的元数据缓存的仓库文件也一并备份,方便内网搭建源时用。

2.3 内网仓库搭建是离线部署的定海神针

把 rpm 包传到内网机器后,下一步是创建本地 yum 源。要注意的是,如果直接把几百个 rpm 放一个目录然后用 createrepo 生成元数据,这个过程可能因为包的依赖关系复杂而出现报错。我看到不少新手在这一步卡住,其实多数是基础软件组缺失,比如 yum-utils、createrepo 包本身没有安装,或 python 版本不对。

标准做法是这样:

# 安装createrepo工具 yum install -y createrepo # 在rpm包存放目录生成仓库元数据 cd /data/zabbix-rpms createrepo . # 新增本地仓库配置文件 cat > /etc/yum.repos.d/zabbix-local.repo <<'EOF' [zabbix-local] name=Zabbix Local Repository baseurl=file:///data/zabbix-rpms enabled=1 gpgcheck=0 EOF # 清理并验证仓库可用 yum clean all yum makecache yum repolist

createrepo 生成 repodata 目录后,yum 就能识别这个本地仓库了。这里有个小细节,gpgcheck 我习惯设为 0,因为离线包的签名验证意义不大,反而可能因为缺少公钥导致安装失败。如果公司安全策略不允许关掉签名检查,就要提前导入对应公钥。

2.4 环境细节:时间同步、主机名与字符集

很多安装问题不是出在安装本身,而是出在环境细节。我见过一次前端页面始终无法完成初始化,折腾半天后发现是数据库服务器的时区与 Zabbix Server 不一致,导致 PHP 会话和图形时间轴数据错乱。部署前一定把时间同步做好,内网没有 NTP 服务器的话,手工同步或找一台基准机器做简单的时间服务。

主机名解析是另一个高频暗坑。Zabbix Server 配置文件中填写的 Server 参数,如果填的是主机名而不是 IP,而后台没有正确的 hosts 解析,Agent 端上报数据会被直接拒绝。最保险的做法是安装前在 /etc/hosts 里写好本机 IP 和主机名映射。字符集方面,数据库初始化前就要明确 utf8mb4,否则装完才发现中文乱码,回头改字符集非常痛苦。

3. 核心安装实操:一步步把 Zabbix 立起来

3.1 先从数据库层开始打好基座

Zabbix 的数据全在数据库里,所以我把数据库部署放在第一步。以 MariaDB 为例,内网源配置好之后,安装命令很直接:

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

接着做安全初始化,设置 root 密码,移除匿名账户,这些不用多讲。关键一步是为 Zabbix 创建独立数据库和账号:

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

密码策略我这里多说一句,Zabbix 本身对数据库密码没有太复杂的要求,但生产环境还是建议用强密码,并且把它保存到安全的地方。后面配置 Zabbix Server 时,数据库密码以明文形式出现在配置文件中,这已经是业内常见做法,注意配置文件权限设置为 640 或更严格即可。

数据库就绪后,导入 Zabbix 初始表结构。这些 SQL 文件由 zabbix-server-mysql 包提供,通常在 /usr/share/doc/zabbix-server-mysql-版本号 目录下。导入顺序不能错,否则外键关系会乱:

cd /usr/share/doc/zabbix-server-mysql-版本号 zcat create.sql.gz | mysql -uzabbix -pyour_password zabbix

导入过程可能需要一点时间,如果报错,先检查数据库账号权限和 SQL 文件完整性。完成后可以用 mysql 客户端验证一下表数量,正常情况下应该是上百张表。

3.2 Zabbix Server 主程序安装,关键参数一次配好

数据库准备完毕,现在安装 Zabbix Server。本地源已经就绪的情况下,安装命令非常简单:

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

安装完成后,编辑 /etc/zabbix/zabbix_server.conf。配置文件里真正核心的参数并不多,但确实每一个都得谨慎填写。主要为以下几项:

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

DBHost 尤其要小心。如果 Zabbix Server 和数据库在同一台机器,我建议直接写 localhost,不要写 127.0.0.1。某些系统配置里,出现 127.0.0.1 导致服务识别不了本地套接字的情况并不少见。另外 ListenPort 默认 10051,除非端口冲突,否则不要随意改动,因为前端页面和 Agent 上报都默认走这个端口。

配置完成之后启动服务:

systemctl restart zabbix-server systemctl enable zabbix-server

验证服务是否起来,最直接的方式是看端口和日志。端口通常不会说谎,而日志会把每个错误细节告诉你。有人习惯看 systemctl status,那个信息量太少,我都是直接 tail -f /var/log/zabbix/zabbix_server.log。

3.3 前端部署:Nginx 与 PHP 的搭配要细心

Zabbix 前端本质是一个 PHP 应用。这里我选择 nginx 与 php-fpm 组合,相比 httpd 更省内存,也更贴近现代部署习惯。安装 php-fpm 后,确认 PHP 版本在 Zabbix 支持范围内,并且 php 的扩展必须齐全。这些扩展的 rpm 包,在依赖收集阶段 repotrack 已经拉取过了,内网本地源里会有,所以安装很顺畅。

PHP 配置需要关注的点:

  • date.timezone 设置为 Asia/Shanghai,不设置前端必然报时区错误
  • max_execution_time 建议 300,Zabbix 某些长时间报表页面需要
  • post_max_size 保持 16M 或更大,图像和报表导入才会顺畅
  • always_populate_raw_post_data 不能随便开,与 PHP 7.2+ 的兼容问题很多

Nginx 站点配置文件示例,核心是正确转发 PHP 请求到 php-fpm:

server { listen 80; server_name zabbix.example.com; root /usr/share/zabbix; location / { index index.php; } location ~ \.php$ { fastcgi_pass unix:/run/php-fpm/www.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }

注意,Zabbix 前端文件默认放在 /usr/share/zabbix,Nginx 的 root 要指到这个路径,同时确保运行 nginx 的用户对这个目录有读权限。这一步如果漏了 chmod 或 chown,前端页面就会出现经典的 403 错误。配置完成后的访问路径是 http://服务器IP/index.php,浏览器会跳到安装引导页。

3.4 Agent 端离线安装与注册的常见坑

Zabbix Server 本身监控不了多少东西,真正的数据来自被监控机器上的 Agent。内网环境下,Agent 的安装包要提前下载好。与 Server 安装一样,用 repotrack 拉取 zabbix-agent 及依赖,打包分发到各内网主机。

Agent 端配置相对简单,但有一个参数非常关键:

Server=zabbix.server.ip ServerActive=zabbix.server.ip Hostname=被监控主机名

第一个 Server 表示允许哪些服务器来被动采集数据,第二个 ServerActive 表示 Agent 主动向哪个服务器上报数据。很多初学者只配置了第一个,结果主动监控项完全无数据。Hostname 必须与前端添加主机时填写的名称保持一致,否则上报会被丢弃。这个一致性问题我踩了不止一次,现在每次写 Agent 配置文件都会反复确认。

启动 Agent 后,回前端页面添加主机时,选择“已由 Agent 监控”的接口类型,填上 IP 或 DNS 名称即可。如果前端显示主机红色“不可达”,不要慌,多半是防火墙没放行 10050 端口,或者 Server 端配置的 Agent 端口和实际不符。

4. 常见问题与排查经验实录

4.1 PHP 版本过新导致的兼容性困惑

不少人在内网装 Zabbix 前端时,发现 PHP 版本比 Zabbix 官方支持的版本高,结果页面要么报 deprecation 警告,要么某些功能按钮失效。我遇到过一次 PHP 8.0 环境下前端登录后白屏的问题,排查到最后是某个 PHP 扩展与官方包不兼容。

经验是,在没有特殊要求时,尽量安装 Zabbix 官方源里锁定的 PHP 版本。如果操作系统自带的软件源版本过新,可以优先考虑使用 Zabbix 官方源对应的软件包,而不是最新版。离线环境里这种兼容性问题更麻烦,因为没有外网可查,所以部署前务必记录下 Zabbix 版本与 PHP 版本的匹配关系。

4.2 依赖仍报缺失,优先排查本地源元数据

有时候你明明把依赖包都拉回来了,执行安装依然提示缺少某个依赖。第一反应不要急着去外网找包,先检查本地仓库的元数据是否过期。createrepo 生成的 repodata 是有时间戳的,如果后来你又往目录里添加了新 rpm 包但没有重新生成元数据,yum 自然识别不到。

这种情况的处理办法是重新执行一遍 createrepo,然后 yum clean all 再 makecache。如果还是提示缺失,就要核实缺失的包名是否真的在目录中,有时候 repotrack 因为源配置问题会漏掉某些可选依赖,少量补下载即可。熟悉的几个包名先记住:php-ldap、php-xml、php-xmlwriter 这些很容易漏。

4.3 前端无法进入安装引导页的多重排查

前端部署完,访问 IP 却一直停留在一个空页面或直接报错,这种问题时序上最容易卡住新手。排查路径按照 OSI 模型逐层往上比较有效率:先确认 Nginx 进程和 PHP-FPM 进程都在运行,再看 Nginx 错误日志,最后检查 PHP 能否正常解析。

有一次我发现 Nginx 正常、PHP 也安装了,但页面始终是空白的,最后定位到是 php-fpm 的监听 socket 路径不对,Nginx 配置里的 unix socket 地址和 php-fpm 实际监听地址不一致。这种事情只看单一配置文件是发现不了的,必须两边对照着看。另外 SELinux 也常是罪魁祸首,内网环境里不少运维直接关掉 SELinux 图省事,这种选择在测试环境可行,生产环境还是要做策略放行而不是直接关闭。

4.4 数据库密码特殊字符导致的连接失败

这是一个非常典型的细节问题。数据库密码里如果包含 ! @ # 等特殊字符,在 Zabbix Server 配置文件中直接填写,某些情况下程序读取配置文件时会对特殊字符做解析,导致密码与实际的字符串不一致,最终服务启动失败或后端持续报数据库连接错误。

解决思路有两个方向。一个是密码加密方式存储,Zabbix 支持在配置中用 DBPassword 指向某个包含真正密码的文件内容,注意配套文件的权限即可。另一个是干脆在创建数据库账号时使用相对简单的强密码,避开特殊符号,这在运维中也是常见取舍。我个人倾向前者,密码复杂性和可维护性都能兼顾。

可能报出的错误信息大概这样,遇到后心里要有个底:

No database connection established: database is down or not available

这时先去手动用账号密码连接数据库,排除网络和账号权限问题,再回过来看 Zabbix Server 的配置文件。别上来就重启服务,盲目重启一百次也解决不了问题。

5. 离线安装效率提升方法与实践总结

个人经验来看,离线安装 Zabbix 最容易掉进去的坑有两个:一是前期方案没选好,装到一半发现依赖缺口;二是细节环境没检查够,装完后启动才发现各种低级错误。与其边踩坑边补,不如提前把准备工作做足,把方案想清楚。

效率提升上,有几个小技巧值得一试。离线安装包用一段时间后,把 rpm 包目录里所有包名和版本生成清单,放到团队内部的知识库,后续再装的时候直接对照,不需要再次拉取。对已经是容器环境的内网,把整个 Zabbix 服务打包成镜像比 rpm 方式更轻量,升级回滚也方便。另外,多利用 ansible 这类自动化工具,把 rpm 包推送到内网各机器后批量执行安装与配置,省去重复劳动。

我个人的体会是,离线安装的最大价值不在于见证 Zabbix 跑起来那一刻的成就感,而是逼着你把整个依赖树和环境关系彻底摸清。这篇文章只是这个系列的第一篇,写到这里,监控服务本身已经能正常启动。下一篇文章,我会继续写 Zabbix 前端的初始化配置、主机分组和监控项的添加,还有那些真正让监控系统发挥价值的数据采集策略。先睡一觉,改天接着聊。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询