02-Zabbix Server 安装部署

上一篇 Zabbix简介与架构 建立了 Zabbix 的组件模型：Server 是中心逻辑，Database 是状态与历史仓库，Frontend 是人的入口，Agent/Proxy 是采集边界。本文进入安装部署，但目标不是“把登录页打开”这么简单，而是把一个可以继续接入 Agent、模板、触发器和告警的最小平台稳稳落地。

本文的操作范围明确限定为：Ubuntu 24.04 LTS、Zabbix 7.0 LTS、MySQL、Apache、官方包安装。2026-06-12 复核时，Zabbix 官方下载页支持按版本、系统、数据库和 Web Server 组合生成安装步骤；Zabbix 7.4 是当前稳定分支，Zabbix 7.0 LTS 是长期支持分支。生产环境如果选择 Zabbix 7.4、PostgreSQL、Nginx、容器或其他操作系统，必须回到官方下载页重新生成命令，不要直接复制本文命令。

先确认安装目标

安装前先把目标环境写清楚。Zabbix Server 不是一个独立二进制文件，它依赖数据库、Web 前端、PHP、系统服务、网络端口和后续 Agent/Proxy 接入。安装命令执行成功，只能说明软件包在机器上存在；要进入生产，还需要验证数据库初始化、服务启动、Web 向导、登录、队列、基础监控项和备份恢复路径。

本文采用的最小实验环境如下：

这不是所有生产环境的最终形态。中大型环境通常会把数据库独立出来，Frontend 通过反向代理提供 HTTPS，Server 和 Proxy 分担采集压力，数据库使用分区、备份和监控。本文先完成一个可验证的基线，后续再逐步演进。

安装前至少检查：

lsb_release -a
hostnamectl
ip addr
timedatectl
free -h
df -h
ss -lntup

这些命令不是装饰。Zabbix 依赖正确时间、稳定主机名、可达网络、足够磁盘和可用端口。时间错误会影响事件、趋势和告警；主机名不稳定会影响后续 Agent 自动注册；磁盘不足会让数据库很快进入危险状态；80/443/10051 端口被占用会导致服务冲突。

安装路径的整体链路

这条链路从官方仓库、软件包、数据库、配置文件、服务启动、Web 向导到最终验证。部署时不要跳步骤：每一步都应留下可复查证据。

本文按以下顺序执行：

1. 选择官方版本组合；
2. 安装 Zabbix 官方仓库包；
3. 安装 Server、Frontend、SQL scripts 和 Agent；
4. 创建 MySQL 数据库与账号；
5. 导入 Zabbix 初始 schema；
6. 配置 zabbix_server.conf；
7. 启动并设置自启动；
8. 通过 Web 向导完成前端初始化；
9. 使用服务状态、日志、Web 页面和内部指标验证；
10. 记录回滚与交接信息。

不要把数据库初始化、Web 向导和服务验证混在一起排障。每一步失败时的证据不同。仓库失败看包源和网络，数据库失败看 MySQL 权限和字符集，Server 失败看 zabbix_server.log，Frontend 失败看 Apache/PHP 和 Web 配置，登录后无数据则要看 Server 内部队列和本机 Agent。

使用官方仓库安装

Zabbix 官方下载页会根据版本、系统、数据库和 Web Server 组合生成仓库包和安装命令。本文以 Zabbix 7.0 LTS + Ubuntu 24.04 为例。命令中的版本号和系统版本不要凭记忆修改，应从官方页面确认后再执行。

安装仓库包：

wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu24.04_all.deb
sudo dpkg -i zabbix-release_latest_7.0+ubuntu24.04_all.deb
sudo apt update

安装 Zabbix Server、Frontend、Apache 配置、SQL 脚本和 Agent：

sudo apt install zabbix-server-mysql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts zabbix-agent

这里安装 Agent 是为了监控 Zabbix Server 本机，后续第三篇会单独讲 Agent 批量部署。Server 本机 Agent 不等于生产主机已经纳入监控，只是安装后的自检入口。

安装后先确认包存在：

dpkg -l | grep zabbix
systemctl list-unit-files | grep zabbix

如果仓库包安装失败，不要改用来路不明的第三方源。Zabbix 是版本敏感平台，Server、Frontend、SQL scripts、Agent 和数据库 schema 必须保持兼容。混用不同来源的软件包，后续升级和排障会非常困难。

准备 MySQL 数据库

Zabbix Server 启动前必须有数据库和初始 schema。数据库保存配置、历史、趋势、事件和运行状态。它不是临时缓存，因此创建数据库时要明确字符集、账号、权限和备份策略。

进入 MySQL：

sudo mysql

创建数据库和账号：

create database zabbix character set utf8mb4 collate utf8mb4_bin;
create user zabbix@localhost identified by '请替换为强密码';
grant all privileges on zabbix.* to zabbix@localhost;
set global log_bin_trust_function_creators = 1;
quit;

导入初始 schema：

zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p zabbix

导入完成后回到 MySQL，关闭临时设置：

sudo mysql

set global log_bin_trust_function_creators = 0;
quit;

这里有几个风险点。

第一，数据库密码不要写进普通笔记或聊天记录。后面需要写入 zabbix_server.conf，但交接文档里应只记录密码保管位置，不直接暴露明文。

第二，schema 导入可能需要一段时间。不要中途按 Ctrl+C。如果导入失败，要先确认数据库是否部分写入，再决定清库重来。半导入状态下直接继续安装，Server 启动后会出现难以解释的表缺失或版本不一致。

第三，log_bin_trust_function_creators 的设置只用于初始化过程。导入完成后应恢复，避免留下不必要的数据库全局风险。

第四，生产环境中数据库不一定和 Server 同机。如果数据库独立部署，账号主机范围、网络防火墙、TLS、备份和连接数都要单独设计。本文命令只覆盖 localhost 实验路径。

配置 Zabbix Server

Server 配置文件通常位于：

/etc/zabbix/zabbix_server.conf

至少设置数据库密码：

sudo grep -n '^#*DBPassword' /etc/zabbix/zabbix_server.conf
sudoedit /etc/zabbix/zabbix_server.conf

示例：

DBPassword=请替换为前面创建的数据库密码

如果数据库不在本机，还要设置 DBHost、DBName、DBUser、DBPort 等参数。不要一次改很多参数。先让最小配置启动，再根据容量和安全需要逐步调整。

启动服务：

sudo systemctl restart zabbix-server zabbix-agent apache2
sudo systemctl enable zabbix-server zabbix-agent apache2

查看状态：

systemctl status zabbix-server --no-pager
systemctl status zabbix-agent --no-pager
systemctl status apache2 --no-pager

查看日志：

sudo tail -n 100 /var/log/zabbix/zabbix_server.log
sudo tail -n 100 /var/log/zabbix/zabbix_agentd.log
sudo journalctl -u apache2 -n 100 --no-pager

Zabbix Server 日志是安装排障的第一入口。常见问题包括数据库连接失败、密码错误、schema 版本不匹配、权限不足、端口占用、缓存不足或配置语法错误。不要只看 systemd 显示 active，还要看日志里是否出现数据库连接成功、进程启动、配置加载等信息。

完成 Web 向导

浏览器访问：

http://<server-ip>/zabbix

Web 向导通常会检查 PHP 依赖、数据库连接、Server 信息和前端配置。这里容易出现三类问题。

第一类是 PHP 或 Apache 配置问题。页面打不开、空白页或 500 错误时，先看 Apache 日志和 PHP 模块，不要急着怀疑 Zabbix Server。

第二类是数据库连接问题。Web 向导需要连接数据库验证配置，如果密码、数据库名、账号或主机不对，会在这里失败。注意 Frontend 连接数据库和 Server 连接数据库都依赖同一组数据库信息，但错误表现可能不同。

第三类是时区和 PHP 参数问题。监控系统对时间很敏感。Web 向导通过后，也要确认系统时间、PHP 时区和浏览器展示时间一致。否则后续问题列表和图形时间会让人误判。

初始化完成后，用默认账号登录。默认账号和密码属于公开信息，登录后必须立即修改密码，并创建个人管理员账号。不要长期多人共用默认 Admin，也不要把默认密码写进运维群。

登录后先完成这些基础操作：

1. 修改默认管理员密码；
2. 确认前端语言、时区和页面时间；
3. 查看 Monitoring -> Hosts 中本机状态；
4. 查看 Monitoring -> Problems 是否有本机问题；
5. 查看 Data collection -> Hosts 中 Zabbix server 主机配置；
6. 确认本机 Agent 是否有最新数据。

具体菜单名称会随版本和语言设置变化，操作时以当前界面为准。文章不把 UI 路径写成绝对承诺。

服务验证与最小可用闭环

安装完成后，至少要证明四件事：Server 活着，数据库可写，Frontend 可用，本机 Agent 数据能进入平台。

命令侧检查：

systemctl is-active zabbix-server
systemctl is-active zabbix-agent
systemctl is-active apache2
ss -lntup | grep -E '(:80|:10050|:10051)'

日志侧检查：

sudo grep -i 'error\\|cannot\\|failed' /var/log/zabbix/zabbix_server.log | tail -n 50
sudo grep -i 'error\\|cannot\\|failed' /var/log/zabbix/zabbix_agentd.log | tail -n 50

数据库侧检查：

mysql -uzabbix -p -e "select count(*) from hosts;" zabbix
mysql -uzabbix -p -e "show tables like 'history%';" zabbix

前端侧检查：

如果本机 Agent 没有数据，排查顺序是：Agent 服务、Agent 配置、Server/Agent 端口、主机名匹配、模板关联、Server queue。不要只刷新页面。前端无数据可能是 Agent 没采到，也可能是 Server 没处理，也可能是主机名不匹配。

安全基线

Zabbix 安装完成后的第一天，就应该做最小安全加固。

Web 层：

• 通过反向代理或 Web Server 配置 HTTPS；
• 限制管理入口来源；
• 修改默认管理员密码；
• 创建个人账号而不是多人共用 Admin；
• 按团队划分角色和权限；
• 评估并启用 MFA。

Server 与 Agent：

• 后续 Agent 接入优先规划 TLS PSK 或证书；
• 只开放必要端口；
• 禁止无审批的远程命令；
• 自定义脚本放入受控目录；
• API token 按用途创建并定期轮换。

数据库：

• Zabbix 数据库账号只访问 Zabbix 数据库；
• 密码保存在密码库；
• 限制数据库监听地址；
• 配置备份；
• 监控数据库连接、磁盘和慢查询。

安装教程经常只讲“能登录”，但监控平台有很高的资产可见性。它能看到主机、网络、数据库、接口、触发器、联系人和故障记录。如果账号、API token、SNMP community 或 Agent 密钥泄露，影响范围会很大。

性能与容量的第一轮参数

试点阶段不建议一开始就调大量参数，但要知道后续观察什么。Zabbix Server 关键容量信号包括：

安装后先让平台运行一段时间，记录基线。比如接入本机和少量测试主机后，观察队列是否稳定为 0，Server 日志是否有慢查询或进程繁忙，数据库磁盘是否增长，Frontend 是否响应正常。

不要在没有基线时盲目调 StartPollers、CacheSize、HistoryCacheSize 等参数。参数调大可能掩盖根因，也可能增加内存占用。后续性能优化篇会按内部指标和数据库状态逐项处理。

备份与回滚

安装完成后立刻建立备份意识。Zabbix 的关键数据主要有：

最小备份命令示例：

sudo tar czf /root/zabbix-etc-$(date +%F).tar.gz /etc/zabbix /etc/apache2/conf-enabled/zabbix.conf
mysqldump -uzabbix -p --single-transaction zabbix > /root/zabbix-db-$(date +%F).sql

这些命令只是示例，生产环境要接入正式备份系统，并加密保存。备份是否有效，取决于是否做过恢复演练。至少在测试机上验证一次：恢复数据库、恢复配置、启动服务、登录前端、查看历史数据和主机状态。

回滚边界也要写清楚。如果安装阶段失败，最干净的回滚可能是删除软件包、删除数据库、清理配置并从快照恢复；如果已经接入主机并产生历史数据，回滚就不能简单删库。变更窗口里要明确“当前是否允许保留数据”“是否允许重建环境”“是否已有生产告警依赖”。

常见安装故障的排查顺序

安装故障不要来回跳。按层次排：

1. 软件包层：仓库包是否匹配系统版本，apt update 是否成功；
2. 数据库层：数据库是否创建，账号是否能登录，schema 是否导入完整；
3. Server 层：zabbix_server.log 是否显示数据库连接和进程启动；
4. Web 层：Apache/PHP 是否加载 Zabbix 前端配置；
5. Agent 层：本机 Agent 是否运行，主机名是否匹配；
6. 数据层：Latest data 是否有新值，Queue 是否堆积；
7. 权限层：用户角色是否能看到目标主机和数据。

常见现象和方向：

遇到问题时先保存证据，不要反复重装。记录命令输出、日志片段、配置差异和处理动作。Zabbix 是后续告警平台，如果安装阶段就没有证据习惯，真正生产事故中会更难处理。

生产环境如何从单节点拆分

本文把 Server、Database、Frontend 放在同一台机器上，是为了建立最小可运行基线。生产环境是否拆分，要看规模、可用性和团队能力，而不是盲目追求“标准架构”。

常见拆分方式如下：

拆分数据库时，要先确认 Server 到数据库的网络延迟和可靠性。Zabbix 写入频繁，数据库延迟会直接影响 history syncer、queue 和前端查询体验。数据库不应部署在不稳定链路后面，也不应与大量业务库无隔离地共用同一资源池。

拆分 Frontend 时，要明确 Web 入口、证书、访问控制和会话策略。很多团队把 Zabbix Frontend 放在内网 HTTP 下长期运行，短期方便，长期风险很高。监控平台里有主机、接口、告警、联系人、资产标签和部分脚本配置，这些都属于敏感运维信息。生产环境至少应使用 HTTPS，并限制访问来源。

引入 Proxy 时，不要把 Proxy 当成 Server 性能问题的万能解。Proxy 适合靠近被监控对象采集、跨防火墙连接和本地缓存；如果中心数据库已经写入不过来，增加 Proxy 只会让数据以另一种方式堆积。正确顺序是先看每秒新值数、数据库能力、Server 内部队列，再决定是否引入 Proxy。

安装前的变更窗口设计

Zabbix 安装看似低风险，但一旦用于生产监控，后续每次停机都会影响告警能力。因此第一次安装就应按变更窗口思路处理。

变更单至少包含：

这样写的好处是防止安装任务无限膨胀。很多失败的监控平台建设，是因为第一天同时做安装、批量接入、告警联动、Dashboard 和自动化脚本，结果任何一个环节失败都难以定位。本文只完成平台基线，后续章节逐步扩展。

数据库治理细节

Zabbix 数据库要从第一天开始治理。即使试点只有几台主机，也要避免形成错误习惯。

首先是字符集。官方安装步骤使用 utf8mb4 和 utf8mb4_bin，不要随意改成系统默认字符集。监控对象可能包含中文主机名、标签、业务描述和告警内容，字符集不一致会在后续导入模板、调用 API 或显示前端内容时暴露问题。

其次是账号。zabbix@localhost 只适合同机数据库。如果数据库独立，应明确来源主机，例如只允许 Zabbix Server 地址连接，而不是使用 % 放开所有来源。账号权限也只应覆盖 zabbix.*，不应拥有全局管理权限。

第三是数据保留。刚安装时看不到压力，但 history 和 trends 会持续增长。上线前至少定义：

• 历史数据保留多久；
• 趋势数据保留多久；
• 是否使用 housekeeper；
• 是否采用数据库分区；
• 备份是否包含历史数据；
• 恢复时是否必须恢复全部历史。

第四是平台自身监控。Zabbix 数据库应被 Zabbix 监控，但不能形成盲点。至少监控磁盘空间、连接数、慢查询、备份结果和数据库服务状态。监控平台自身数据库不可用时，告警平台可能同时失去存储和通知能力。

Web 与访问入口

Zabbix Frontend 默认通过 Web Server 访问。实验环境可以先使用 HTTP，但生产环境要规划 HTTPS、域名、反向代理和访问控制。

一个较稳妥的入口设计是：

Web 入口还要考虑浏览器访问路径与 API 调用。很多自动化脚本、Grafana 插件和集成系统会使用 Zabbix API。如果前端地址、证书、反向代理路径或认证方式频繁变化，这些集成都要跟着改。安装阶段就应该确定一个相对稳定的入口。

不要把 Zabbix Frontend 直接暴露到公网。即使启用了强密码和 MFA，监控平台也不适合成为公网服务。它包含过多内部资产信息，暴露面应尽量小。

安装后的最小监控对象

安装成功后，不要立刻接入所有服务器。先用三个对象验证模型：

1. Zabbix server 本机；
2. 一台普通 Linux 测试主机；
3. 一个简单网络设备或 ICMP 目标。

这三个对象能覆盖本机 Agent、远程 Agent、简单网络检查和模板绑定。验证时重点看：

• 主机名是否规范；
• 主机组是否合理；
• 模板是否来自官方或受控自定义模板；
• Latest data 是否按预期刷新；
• Problems 是否产生可解释事件；
• 通知是否暂时关闭或限制在测试人员；
• 删除测试对象后是否留下无用配置。

为什么不建议第一天批量接入？因为模板阈值、主机名、自动注册和通知策略还没有经过验证。一旦批量接入 500 台主机，默认触发器可能产生大量问题事件，值班人员会先对平台失去信任。监控平台最怕第一印象就是噪声。

自动注册与批量接入的准备

虽然本文不展开 Agent 批量配置，但 Server 安装阶段要为它留出空间。

自动注册需要考虑：

如果没有这些规则，自动注册会把大量主机放进默认组，模板绑定随意，后续清理非常痛苦。Server 安装完成后，应先创建主机组、基础模板策略和自动注册草案，再让第三篇 Agent 配置进入批量接入。

验收案例：从空平台到本机数据

一个完整验收案例可以这样执行：

第一步，确认服务：

systemctl is-active zabbix-server zabbix-agent apache2

第二步，确认端口：

ss -lntp | grep -E ':80|:10050|:10051'

第三步，登录 Web 前端，修改默认密码，确认 Zabbix server 主机存在。

第四步，在 Latest data 中搜索本机基础指标，例如 CPU load、available memory、filesystem space。看到数据后，不要只截图，还要记录时间范围和主机名。

第五步，制造一个低风险测试事件。例如临时观察磁盘空间、Agent 可用性或自定义一个测试触发器。测试完成后删除测试触发器，避免长期干扰。

第六步，重启主机或至少重启服务，确认自启动有效：

sudo systemctl restart zabbix-server zabbix-agent apache2
systemctl is-active zabbix-server zabbix-agent apache2

第七步，检查日志是否出现新的严重错误。

这个验收案例要写进交接文档。以后升级、恢复、迁移或修改数据库时，都可以用同一套路径确认平台没有断。

从实验到生产的停止条件

不是所有安装成功的环境都可以继续进入生产接入。出现以下情况时，应暂停扩大范围：

• 数据库没有备份；
• 默认 Admin 密码未修改；
• Zabbix Server 日志仍有数据库或进程错误；
• Web 入口没有访问控制；
• 时间同步异常；
• 本机 Agent 没有稳定数据；
• 没有定义主机组和命名规范；
• 没有确认通知策略；
• 没有回滚或恢复说明；
• 没有负责人接手。

这些停止条件看起来严格，但比后面补救便宜。监控平台一旦被生产依赖，任何调整都会影响告警可信度。安装阶段把门槛立起来，后续 Agent、触发器、告警和 Dashboard 才有稳定基础。

包版本、升级和锁定策略

安装完成后建议记录实际包版本：

dpkg -l | grep -E 'zabbix|mysql|apache|php'
apt-cache policy zabbix-server-mysql zabbix-frontend-php zabbix-agent

这一步经常被忽略。Zabbix Server、Frontend、SQL scripts、Proxy 和 Agent 都有版本关系。Server 与 Frontend 通常应保持同版本；Agent 有一定兼容空间，但批量升级仍要按官方文档确认。不要让无人值守系统升级在夜间自动把 Zabbix 主版本提升，监控平台升级应该进入变更流程。

生产环境可以考虑对 Zabbix 关键包设置 hold，或者至少把 Zabbix 仓库更新纳入补丁评审。锁定版本不是拒绝升级，而是避免升级变成不可追溯事件。Zabbix 数据库 schema 升级尤其敏感：Server 启动后可能执行 schema 升级，一旦数据库结构变更，简单降级软件包未必能回到旧状态。因此升级前必须有数据库备份和测试恢复。

一份合格的升级前检查应包含：

本文是安装篇，不展开升级步骤，但安装当天就要记录版本。没有版本记录的环境，几个月后很难判断某个行为来自 Zabbix 版本差异、配置变更还是系统补丁。

重启验证和持久化检查

很多安装问题不会在第一次启动时出现，而是在重启后暴露。比如服务没有 enable，数据库启动较慢，Apache 配置未持久化，密码只在临时命令里设置，或主机名变化导致本机 Agent 匹配异常。

如果是实验环境，可以直接重启主机：

sudo reboot

重启后检查：

systemctl is-enabled zabbix-server zabbix-agent apache2
systemctl is-active zabbix-server zabbix-agent apache2
sudo tail -n 80 /var/log/zabbix/zabbix_server.log

如果生产环境不方便重启，至少重启相关服务并观察：

sudo systemctl restart mysql
sudo systemctl restart zabbix-server zabbix-agent apache2
systemctl is-active zabbix-server zabbix-agent apache2

重启验证要关注两类结果。第一是服务是否恢复，第二是数据是否继续进入。服务 active 但 Latest data 停止刷新，仍然不合格。安装交付要证明平台在进程重启后仍能继续采集、写入和展示。

安装后的第一批平台配置

登录后不要立刻接入所有服务器。先完成一组平台基础配置，让后续 Agent、模板和告警有承载边界。

这些配置的顺序很重要。先权限，再主机组，再模板，再通知。否则容易出现所有人都是超级管理员、所有主机都在一个组、默认触发器直接通知生产群的情况。

告警通道尤其要谨慎。安装当天可以先把通知限制到测试联系人，不要直接接入正式值班群。等触发器、维护窗口、严重级别和依赖关系验证后，再扩大通知范围。监控平台第一次大规模发噪声，会严重损害团队信任。

日常巡检基线

Zabbix Server 安装交付后，平台管理员至少要周期性检查这些项目：

• Server 内部进程 busy；
• Queue 是否持续堆积；
• 数据库磁盘增长；
• Housekeeper 执行时间；
• 告警发送失败；
• Web 登录失败；
• 本机 Agent 数据是否持续更新；
• 备份是否成功；
• /var/log/zabbix/ 是否出现持续错误。

这些巡检项可以先手工查看，后续再做成 Dashboard 和触发器。关键是形成习惯：监控平台自身也需要被监控。不要等业务团队反馈“没有收到告警”时，才发现 Zabbix Server 已经堆积了一整天。

巡检还要记录趋势。例如 queue 偶尔升高但很快恢复，可能只是短暂网络抖动；queue 长期缓慢增长，则说明采集量已经超过处理能力。数据库磁盘每天增长多少，也应在试点阶段建立基线。没有基线，容量规划只能靠猜。

独立数据库部署的差异

如果正式环境从一开始就要求独立数据库，本文命令要做相应调整。数据库账号不再是 zabbix@localhost，而应绑定 Zabbix Server 来源地址；MySQL 需要监听内网地址；防火墙要允许 Server 到数据库端口；备份策略由数据库团队负责；zabbix_server.conf 要设置 DBHost。

独立数据库还要处理网络和安全：

数据库拆分能提升资源隔离和可维护性，但也增加依赖。数据库网络不稳定、备份不可用或权限配置错误，都会让 Zabbix Server 表现为采集延迟、前端查询慢或服务启动失败。拆分不是目的，稳定可恢复才是目的。

运维接手演练

安装交付前，建议让未参与安装的人按文档完成一次接手演练。演练内容不需要复杂：

1. 找到 Zabbix Web 地址并登录；
2. 查看 Zabbix server 本机 Latest data；
3. 找到 Server 日志；
4. 判断三个服务是否运行；
5. 说明数据库备份在哪里；
6. 解释如何停止扩大接入；
7. 说明下一篇 Agent 接入前还缺什么。

如果接手者卡在“密码在哪里”“日志在哪里”“哪个主机是 Server”“为什么 Latest data 没有数据”这些问题上，说明交付文档还不够。监控平台不是安装者个人工具，而是团队值班和故障处置的基础设施。

信息来源验证与适用边界

本文命令来自 Zabbix 官方下载页在 2026-06-12 生成的组合：Zabbix 7.0 LTS、Ubuntu 24.04、MySQL、Apache、Server/Frontend/Agent。官方页面允许切换 Zabbix 版本、操作系统、数据库和 Web Server，因此本文命令不是所有场景的通用命令。

适用边界如下：

如果你选择 Zabbix 7.4，仓库包路径和包版本会不同；如果选择 PostgreSQL，schema 导入命令和数据库初始化会不同；如果选择 Nginx，前端 Web 配置包和服务名会不同。所有这些变化都必须从官方文档重新确认，不能把本文命令改几个字符串后直接用于生产。

本文没有在当前机器实际执行安装命令，因此命令块应视为“按官方页面复核的操作路径”，不是本机实测输出。正式部署时应把本机执行结果、包版本、日志和截图写入变更记录。

建议部署当天保留一份安装记录：

这份记录不是形式。几个月后升级、迁移或排障时，它能告诉团队这个平台最初是按什么假设部署的，哪些事项当时刻意没有纳入范围。

交付清单

部署完成后，至少留下这些内容：

这份清单会直接交给下一篇使用。Agent 配置和管理依赖 Server 基线稳定；如果安装阶段没有确认端口、主机名、时间、权限和自启动，后续批量接入会把基础问题放大。

进入下一篇前，建议先冻结三个决定：Server 地址是否稳定，主机命名规则是否确定，Agent 接入是否启用 TLS。只要这三项还在变化，就不应该大规模分发 Agent 配置。否则每台主机都可能需要返工，自动注册规则也会被临时例外污染。

安装部署真正完成的标志，是任何接手者都能按文档重启、验证、备份和解释当前平台状态，而不是只有安装者知道哪里改过。

这条标准也适用于后续所有 Zabbix 组件接入和日常巡检复盘工作记录归档管理规范。

本篇结论

Zabbix Server 安装部署不是单纯执行几条 apt install 命令，而是建立监控平台的第一条可运行链路：官方仓库可信，数据库 schema 完整，Server 能连接数据库，Frontend 能完成初始化，本机 Agent 有数据，服务能随系统启动，日志能定位错误，备份和回滚有路径。

本文选择 Ubuntu 24.04 + Zabbix 7.0 LTS + MySQL + Apache，是为了给后续系列提供一个稳定的 LTS 基线。生产环境如果选择不同版本或组件，必须回到官方下载页和文档重新生成安装步骤，并把实际版本写入交接文档。

下一篇 Zabbix Agent配置与管理 会把采集端扩展到被监控主机，重点处理 Agent/Agent 2、主动与被动模式、TLS、批量接入和自定义监控项。

参考资料

• Zabbix Download：Packages
• Zabbix Documentation：Current manual
• Zabbix Documentation：Manuals
• Zabbix：Life Cycle and Release Policy
• Zabbix：Release Notes