不追求“最快跑起来”，而是三年不返工、五年不推倒重来
很多 Zabbix 教程，问题不在“写错”，而在 默认你是测试环境。
而现实是：
你一旦在单位、集团、研究院、数据中心里装 Zabbix，它就是基础设施的一部分。
这一讲，我们只解决一件事：
如何搭一套，放进生产环境也不心虚的 Zabbix 安装方案
一、操作系统选型：不是“你会哪个”，而是“谁能活得久”
常见四类 OS，一句话结论
为什么 Rocky / AlmaLinux 是当前主流首选？
RHEL 生态完整
Zabbix 官方支持度最高
MySQL / PostgreSQL / Docker / systemd 行为最“标准”
出了问题，网上一定有人踩过
企业选型的第一原则不是“先进”，而是 “可复制、可救援”
二、Zabbix 6.x vs 7.x：你到底该上哪个？
直接结论（非常重要）
为什么 7.0 是一个分水岭？
Server / Proxy 性能模型重构
Agent2 成为绝对主力
Web UI 更贴近“平台级工具”
为后续 AIOps / 大规模 Proxy 做准备
一句话判断标准：
新环境 → 7.0 LTS
老系统升级 → 6.0 LTS → 再规划 7.0
三、数据库怎么选？别被“性能对比”带偏了
MySQL vs PostgreSQL，本质差异是什么？
企业环境 90% 场景建议 MySQL
原因不是性能，而是：
DBA 人才普遍
国产数据库兼容路径更清晰
问题排查成本低
PostgreSQL 不是不好，而是 “你要为它的好，付出组织成本”
四、安装方式怎么选？别再纠结“源码 vs RPM”
标准结论（请记住）
企业生产环境：只用 官方仓库 RPM / Docker，不碰源码编译
为什么源码编译是“技术债”？
升级路径断裂
参数不可控
运维人员无法继承
安全合规风险高
真正专业的团队，拼的是“可维护性”
五、安装中最容易踩的 8 个坑
坑 1：Server / DB / Web 装一台，还不开 Proxy
👉 后期必拆
坑 2：默认数据库参数
👉 history 表暴涨，IO 直接打满
坑 3：Agent 用老的 zabbix-agent
👉 新模板用不上，性能白白浪费
坑 4：端口全默认
👉 安全审计直接打回
坑 5：数据目录和程序目录混在一起
👉 迁移=重装
坑 6：没规划字符集 / 时区
👉 图表、日志、报表全乱
坑 7：没做 Proxy 编号规划
👉 大规模时直接炸
坑 8：一上来就“全监控”
👉 噪声 > 价值
六、生产环境目录规划
推荐目录结构（示例）
/opt/zabbix/ # 程序目录
/data/zabbix/ # 监控数据
/data/mysql/zabbix/ # 数据库数据
/log/zabbix/ # 日志
/etc/zabbix/ # 配置
/backup/zabbix/ # 备份
核心原则 4 条
程序 ≠ 数据
日志可单独挂盘
数据库必须可独立迁移
任何目录，都要支持“换服务器不换数据”
加分点：麒麟 / 国产环境部署的真实注意事项（稀缺）
这一段，99% 博客不会写。
1️⃣ 软件源问题
官方 Zabbix 仓库 不能直接用
需要：
本地镜像
或 Docker 离线镜像
或内网 RPM 仓库
2️⃣ glibc / systemd 兼容性
Agent2 有版本依赖
必须验证：
Go runtime
systemd 行为
SELinux 策略
3️⃣ 数据库选型现实
MySQL 8.x 是最稳的
国产数据库（人大金仓 / 达梦）
👉 只能 Proxy + 外置适配，别直连 Server
4️⃣ 安全合规要求
端口必须非默认
日志留存周期明确
配置文件权限可审计
在国产环境，Zabbix 不是“装完就算”，
而是 安全体系的一环
本讲小结
这一讲你应该记住 4 句话：
选型优先于安装
版本决定未来 3 年
目录规划 = 是否能升级
国产环境不是“换个 OS”那么简单