企业官网建设流程全解析

1. 为什么用 Docker 跑 Zabbix，而不是直接装在物理机

聊到 Zabbix 这套监控系统，很多刚接触的人第一反应是："不就是装个服务端、配个数据库、再装个 Agent 吗？"真上手之后才发现，坑全藏在细节里——版本兼容、PHP 扩展缺失、数据库字符集不对、前端连不上服务端……一套搞下来大半天就没了。我在生产环境里踩过一轮之后，现在新环境基本都是走 Docker 部署，尤其是 Zabbix 7.0 以后，官方镜像体系已经非常成熟，用容器编排可以省掉大量环境层面的琐碎问题。

用 Docker 部署 Zabbix，说白了就是把原来需要手动安装、配置、调参的多个组件（Server、Web 前端、数据库、Agent）全部塞进标准化的容器里，通过镜像版本和编排文件统一管理。这套方案最直观的好处有三个：首先是环境隔离，Zabbix Server 依赖的 PHP 扩展、数据库连接库、时区设置等全都固化在镜像里，不会污染宿主机；其次是升级回滚方便，镜像版本一变就能整体切换，出问题也能秒回退；最后是迁移成本低，export 一份 compose 文件和挂载目录，换台机器直接拉起，这在物理机部署时代是想都不敢想的。

还有一个常被忽视的点：Zabbix 是个"组件多、关联复杂"的系统，Server、前端、DB、Agent、Proxy 各有各的生命周期，手动部署时经常出现版本错配。Docker 镜像的 tag 本身就是一套版本对齐的协议，比如用zabbix/zabbix-server-pgsql:7.0-ubuntu和zabbix/zabbix-web-nginx-pgsql:7.0-ubuntu，镜像名里的pgsql后缀说明这个 Server 镜像已经内置了连接 PostgreSQL 的驱动配置，只要用同一版本 tag，基本不会出现组件间握手失败的问题。

当然，Docker 部署也不是银弹。如果你的监控规模到了上万台设备、每秒处理几十万条指标，那容器化的性能损耗和运维复杂度反而会变成瓶颈，那种场景建议直接上物理机 + Zabbix Proxy 分层的架构。但对绝大多数中小团队，几百台服务器、交换机、VMware 虚拟机这种规模，Docker 部署的生产力优势是碾压级的。

所以我这篇就基于 Zabbix 7.0 LTS 版本，带你把整套环境从零拉起来，包括容器编排、数据持久化、Agent 接入、告警通知这几个核心环节，最后再把我在实际部署中碰到的坑一并列出来。适合两类人看：一是刚接触 Zabbix、想快速搭一套环境练手的运维新人；二是已经在用 Zabbix 但还在物理机部署、想平滑迁移到容器方案的团队。

2. 部署前的思路拆解与组件选型

2.1 整套系统的组件构成

Zabbix 的逻辑架构其实不复杂，但组件之间的关系要理清楚。一个最小可用的生产级部署，至少包含四块：

• Zabbix Server：核心调度进程，负责数据收集、触发器计算、告警生成。它自己不存数据，需要连数据库。
• 数据库：存放配置、历史数据、趋势数据。Zabbix 支持 PostgreSQL 和 MySQL，7.0 版本同时对两者提供官方镜像支持。
• Zabbix Web 前端：Nginx + PHP-FPM 的 Web 界面，通过 PHP 的 PDO 扩展连数据库，通过 API 跟 Server 通信。用户日常操作都在这一层。
• Zabbix Agent：部署在被监控主机上的采集进程，主动或被动上报指标。

如果你的监控规模较大，还会加一层 Zabbix Proxy，Proxy 承担边缘采集和缓冲的职责，把压力从中心 Server 卸掉。但这篇先不展开 Proxy，先把最核心的主链路搭通。

2.2 数据库选型：PostgreSQL 还是 MySQL

官方镜像里，Server 和 Web 前端都有两个变体：-pgsql和-mysql。我推荐用 PostgreSQL，理由不复杂：Zabbix 内部有大量依赖 SQL 特性的操作（比如分区表、并行查询、JSONB），PostgreSQL 在高版本上对复杂查询的优化能力更强，历史数据清理（housekeeper）的配合度也更好。另外，Zabbix 官方文档中性能调优章节的示例大多基于 PostgreSQL，遇到问题更容易找到对口的参考资料。

MySQL 也不是不行，如果你团队对 MySQL 更熟、已有高可用的 MySQL 集群想复用，那就直接用-mysql镜像，对外行为完全一致。这里不存在"哪个不能用"的问题，只有"哪个更顺手"的问题。

2.3 网络规划：容器间通信

组件要互相通信，就需要一个共享网络。Docker Compose 会默认创建一个 bridge 网络，容器之间通过服务名互相解析。这个设计很关键：Zabbix Server 连接数据库时，数据库地址直接填 compose 里的服务名（比如postgres），Web 前端连接 Server 时地址填zabbix-server。用服务名而不是写死 IP，容器重建时 IP 变了也不受影响。

另外要给 Web 端口留好宿主机映射。一般习惯用 8080 映射到容器里的 80，或者直接用 10051（Server 的 trapper 端口）映射出去供 Agent 上报。具体端口规划我下面会细说。

2.4 存储规划：持久化什么

容器是无状态的，重启后文件系统重置，所以需要持久化的数据必须挂载到宿主机目录或命名卷。Zabbix 部署里需要持久化的东西有：

• 数据库数据文件：这是最重要的，丢失等于监控历史全部清零。
• Zabbix Server 的配置文件（可选）：如果你手动改过zabbix_server.conf的某些参数，建议挂载出来。
• Web 前端的 PHP 配置（可选）：改了php-fpm参数或时区配置时用。

我在生产环境里的习惯是：所有持久化数据统一放在/opt/zabbix/下，按组件分子目录，数据库数据放./data/pgsql，配置覆盖放./config。这样备份、迁移、定位问题都非常直观。

3. 实操：用 Docker Compose 拉起全套 Zabbix

3.1 环境准备

先确认宿主机条件。Zabbix Server 本身不算吃资源，但数据库和前端进程跑在同一台机器上，建议至少 2 核 4GB 内存起步，磁盘 20GB 以上（历史数据的增长速度取决于监控项数量和 retention 周期）。如果你的监控对象不到 50 台，这个配置足够跑一年。

宿主机需要安装 Docker Engine 和 Docker Compose 插件。我用的是 Ubuntu 22.04，Docker 版本 24+，Compose v2。安装方法这里不展开了，官方文档写得已经非常清楚，装完记得执行docker compose version确认版本。

注意：Docker 镜像仓库在国内访问速度不稳定是个老问题，如果拉镜像超时，可以配置 registry mirror 加速。我在/etc/docker/daemon.json里配置了 Docker Hub 的镜像加速地址，改完重启 docker 服务生效。

3.2 目录结构与 compose 文件

我在/opt/zabbix下创建整个项目：

mkdir -p /opt/zabbix/{data/pgsql,config/server,config/web}

目录结构解释：

• data/pgsql：PostgreSQL 数据文件的挂载目录
• config/server：放自定义的 zabbix_server.conf（可选）
• config/web：放自定义的 PHP 配置（可选）

然后写docker-compose.yml。这是整套环境的核心文件，我要把每个参数为什么这么写解释清楚：

version: "3.8" services: postgres: image: postgres:16-alpine container_name: zabbix-postgres restart: unless-stopped environment: POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix_pass_2024 POSTGRES_DB: zabbix volumes: - ./data/pgsql:/var/lib/postgresql/data networks: - zabbix-net zabbix-server: image: zabbix/zabbix-server-pgsql:7.0-ubuntu container_name: zabbix-server restart: unless-stopped environment: DB_SERVER_HOST: postgres POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix_pass_2024 POSTGRES_DB: zabbix ZBX_STARTPOLLERS: 10 ZBX_STARTPOLLERSUNREACHABLE: 2 ZBX_STARTTRAPPERS: 4 ZBX_CACHESIZE: 64M ZBX_HISTORYCACHESIZE: 64M ZBX_TRENDCACHESIZE: 64M ports: - "10051:10051" volumes: - ./config/server:/etc/zabbix/zabbix_server.conf.d:ro depends_on: - postgres networks: - zabbix-net zabbix-web: image: zabbix/zabbix-web-nginx-pgsql:7.0-ubuntu container_name: zabbix-web restart: unless-stopped environment: ZBX_SERVER_HOST: zabbix-server DB_SERVER_HOST: postgres POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix_pass_2024 POSTGRES_DB: zabbix PHP_TZ: Asia/Shanghai ports: - "8080:8080" depends_on: - zabbix-server networks: - zabbix-net networks: zabbix-net: driver: bridge

逐个解释关键点：

• postgres镜像没有用 Zabbix 官方打包的镜像，而是直接用官方的postgres:16-alpine。为什么？Zabbix 官方也有zabbix/zabbix-server-pgsql依赖的数据库镜像变体，但实际上数据库本身不需要任何 Zabbix 定制，初始化过程就是建库建用户建表。直接用标准 PG 镜像反而更干净，也方便后续单独对数据库做备份和调优。Alpine 版本的镜像体积小，作为数据服务足够用。

• POSTGRES_PASSWORD在 compose 文件里写明文，仅限内网测试环境。生产环境建议通过环境变量替换或 Docker secrets 管理，至少别把密码提交到 Git 仓库。

• ZBX_STARTPOLLERS等变量是 Zabbix Server 的并发进程数配置。POLLER 负责主动轮询被监控设备，TRAPPER 负责接收 Agent 主动上报的数据。默认的 5 个 poller 对于几十台设备够用，我习惯调高到 10 个，给后续扩容留余地。

• Web 端口映射到 8080 是因为宿主机 80 端口可能被其他服务占用。Zabbix Web 容器内默认监听 8080（镜像内 Nginx 配置决定），外部访问http://宿主机IP:8080。

• depends_on只保证服务启动顺序，不保证依赖服务已经"就绪"。PostgreSQL 启动到可以接受连接需要几秒，所以第一次启动时 Server 容器可能会报 "connection refused"，这是正常的，容器重启策略会自动重试。

3.3 首次启动与数据初始化

compose 文件就位后，执行：

cd /opt/zabbix docker compose up -d

第一次启动需要拉镜像并初始化数据库。PostgreSQL 容器创建时会自动执行建库建用户操作，Zabbix Server 第一次启动时会自动创建 schema 并写入初始数据。这个过程耗时取决于机器性能和网络，通常 1~3 分钟。

你可以用下面的命令观察日志，确认初始化是否完成：

docker compose logs -f zabbix-server

当日志出现类似server started的关键字，说明 Server 已经成功连接数据库并启动。再确认 Web 是否就绪：

docker compose ps

所有服务状态为Up且没有持续重启（Restarting状态），基本就没问题了。

3.4 前端初始化

浏览器访问http://宿主机IP:8080，会进入 Zabbix 前端安装向导。首次安装需要填数据库连接信息，注意这里的Database host不要填127.0.0.1或宿主机 IP，因为 Web 容器访问的是 Docker 网络里的数据库服务，要填 compose 里的服务名postgres：

• Database host:postgres
• Database port:5432（默认）
• Database name:zabbix
• User:zabbix
• Password:zabbix_pass_2024

填完后 Zabbix 会校验数据库连接并写入配置文件。安装完成后，默认登录账号是Admin，密码是zabbix。首次登录后强烈建议立刻修改默认密码。

3.5 接入第一台被监控主机

Web 界面能打开，整个系统的主链路就算通了。接下来把你手头的一台 Linux 服务器接入监控，验证端到端的数据流。

在被监控的 Linux 主机上，安装 Zabbix Agent（这里以 Ubuntu/Debian 为例）：

wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-1+ubuntu22.04_all.deb dpkg -i zabbix-release_7.0-1+ubuntu22.04_all.deb apt update apt install -y zabbix-agent

修改 Agent 配置/etc/zabbix/zabbix_agentd.conf，最关键的是 Server 地址和主机名：

Server=宿主机IP ServerActive=宿主机IP:10051 Hostname=server01

• Server是被动检查白名单，Agent 只接受来自这个 IP 的请求。
• ServerActive是主动上报的服务器地址，Agent 会主动连接这里的 10051 端口。
• Hostname必须与 Zabbix Web 前端里配置的主机名完全一致，否则 Agent 数据上报后无法匹配到主机。

重启 Agent：

systemctl restart zabbix-agent

然后回到 Web 前端，在"数据采集 → 主机"里点击"创建主机"，主机名填server01，填写宿主机 IP，端口默认 10050（Agent 被动端口），添加一个模板比如 "Linux by Zabbix agent"，保存后稍等片刻，主机状态应该会变为"已监控"，可用性显示绿色 ZBX。到这里，一条完整的采集链路就走通了。

4. 监控核心原理与告警通知配置

4.1 采集方式怎么选：主动还是被动

Zabbix 的 Agent 采集有两种模式，这也是新手经常会混淆的地方：

被动模式：Zabbix Server 主动连接到 Agent 的 10050 端口请求数据。服务端是发起方，Agent 响应。

主动模式：Agent 周期性地主动连接到 Server 的 10051 端口上报数据。Agent 是发起方。

两种模式在 Web 配置里的区别体现在模板上："Linux by Zabbix agent active" 这个模板里的监控项都是主动模式（key 以agent.ping、system.cpu.load等开头，类型是 "Zabbix agent (active)"），而 "Linux by Zabbix agent" 则混合了两种。

实际部署我的建议是：一台主机只启用一种模式，不要混用。如果被监控主机数量较大（几百台以上），或者网络中有防火墙限制入站连接，优先用主动模式。主动模式下 Server 只需要开放 10051 端口等待上报，Agent 不用开放入站端口，网络层面更安全。小规模内网环境（几十台）用被动模式配置更简单，模板条理也更清晰。

这个选择同时会影响端口规划。如果你只用主动模式，宿主机并不强制要映射 10051 端口（Server 作为接收方仍然监听 10051，但不需要映射到宿主机的公网接口，内网 Docker 网络即可互通）；如果用被动模式，必须保证 Server 能访问到 Agent 的 10050 端口，同时 Agent 能访问到 Server（或 proxy）的 10051 端口。

4.2 触发器：怎么判断"出事了"

光有数据还不够，监控系统的核心价值在于"异常时能发现并通知"。Zabbix 里这个机制叫触发器。

一个触发器本质上是一条表达式，基于监控项的最新值或聚合值做逻辑判断。比如"CPU 负载连续 5 分钟超过 4"：

last(/server01/system.cpu.load[percpu,avg1])>4

或者"磁盘可用空间低于 10GB"：

last(/server01/vfs.fs.size[/,free])<10G

触发器有多个严重级别，从低到高分别是：未分类、信息、警告、一般严重、严重、灾难。你在创建触发器的时候可以设置对应的级别，后续告警通知可以根据级别决定渠道和行为（比如只把"严重"以上的发短信，警告级别的发邮件）。

新手常犯的一个错误是：直接把阈值定死，不看监控项的"历史数据趋势"。正确做法是先让监控项跑几天，观察正常波动范围，再根据真实数据设定报警阈值。否则很容易出现"告警轰炸"——一天几百条邮件，到最后你恨不得把它关掉。

4.3 告警媒介配置：邮件通知

Zabbix 告警链路是三段式：媒介 → 用户 → 动作。任何一个环节没配好，告警都发不出去。

先配置"告警媒介"。管理员登录后，在"报警 → 媒介类型"里选择 Email，配置 SMTP 服务器信息。这里建议用 SMTP 而不是本地 sendmail，因为容器环境里根本没有本地 MTA。

配置要点：

• SMTP 服务器：填你的邮件服务商地址，比如smtp.example.com
• SMTP 服务器端口：一般 465（SSL）或 587（STARTTLS）
• SMTP HELO：填发送方域名
• 连接加密：选 SSL/TLS
• 用户名/密码：发信邮箱的登录凭证

然后创建一个接收告警的用户（或者在 Admin 用户上直接配置），在"报警媒介"标签页添加刚配好的 Email，收件人填你的邮箱地址，并设置"当严重级别为警告及以上时通知"。

最后配置"动作"。在"报警 → 动作"里创建动作，触发条件选"触发器严重级别 ≥ 警告"，操作里配置"发送消息给用户"——这里选择接收告警的用户，并按条件（比如"仅发送通知"）生成标题和内容模板。

Zabbix 的告警消息模板支持宏变量，比如：

标题：{TRIGGER.STATUS}：{TRIGGER.NAME} 内容： 主机：{HOST.NAME} IP：{HOST.IP} 时间：{EVENT.DATE} {EVENT.TIME} 当前值：{ITEM.VALUE}

用宏的好处是消息内容动态化，不会出现每条告警都长一个样、关键时刻没法快速定位是哪台机器出问题的情况。

4.4 企微/钉钉/飞书机器人告警

邮件适合中低优先级的事件流，但真正"分秒必争"的故障（比如机房断电、主库宕机），邮件往往不够即时。现在国内团队普遍用企微、钉钉、飞书的群机器人收告警。

Zabbix 6.0 之后自带 Webhook 媒介类型，可以通过 webhook 把消息推进群机器人。配置思路是：创建 Webhook 媒介类型，配置请求 URL（群机器人的 webhook 地址），把 Zabbix 的消息模板转换为机器人要求的 JSON 格式。

以钉钉为例，机器人的自定义关键词必须出现在消息正文里（比如"zabbix"），把 Zabbix 消息用宏拼成一个带关键词的 JSON body，然后发送 POST 请求。Zabbix 会在触发器和恢复通知时调用这个 webhook，效果就是群里的告警消息卡片。

这套逻辑跟邮件其实是一套链路：媒介配好 → 用户绑定 → 动作里引用。区别只是"媒介类型"选 Webhook，要额外处理一下消息格式。

5. 数据持久化、备份与升级回滚

5.1 数据库备份策略

监控系统的数据一旦丢失，历史趋势、告警记录全部归零，对排障来说是很大的损失。所以数据库备份是必须做的日常操作。

最直接的方式是用pg_dump对 Zabbix 数据库做逻辑备份，保留建表语句和数据，恢复灵活。备份命令：

docker exec zabbix-postgres pg_dump -U zabbix -d zabbix -F c -f /tmp/zabbix_backup.dump

然后将容器内的 dump 文件复制到宿主机：

docker cp zabbix-postgres:/tmp/zabbix_backup.dump /opt/zabbix/backup/

恢复时：

docker exec -i zabbix-postgres pg_restore -U zabbix -d zabbix --clean /tmp/zabbix_backup.dump

生产环境建议做定时备份，用 crontab 每日凌晨执行，保留最近 7 天的备份文件。如果你想更省事，也可以给 PostgreSQL 容器装物理备份工具（如 pgBackRest），但那是另一个话题了。

5.2 升级与回滚：镜像 tag 的管理

Docker 部署的优势在升级时体现得最明显。Zabbix 官方 LTS 版本会持续维护，比如 7.0.x 的补丁版本更新，升级操作其实就是改一下 compose 文件里的镜像 tag：

image: zabbix/zabbix-server-pgsql:7.0.1-ubuntu

改成新版本号，然后docker compose up -d重新拉取并重建容器。

但是有个关键点：Zabbix Server 和 Web 前端的版本必须对齐，否则前端可能因为后端数据结构不一致而报错。我的习惯是 Server、Web、Agent 的 tag 统一用同一个版本号，避免版本错配。

升级前务必先备份数据库。虽然 Zabbix 支持跨小版本升级，但数据库 schema 可能会自动变更，如果升级到一半失败，回滚到旧镜像再去连已经变更的 schema，反而会出问题。有备份在手，心里不慌。

5.3 告警配置的备份与 Git 管理

很多人只备份数据库，忽略了配置文件。实际上 Zabbix 的配置数据（主机、模板、动作、媒介）都存在数据库里，逻辑备份已经把配置一起带上了。这一点跟 Prometheus 那种"配置即代码"的模式不同，Zabbix 的配置都在数据库里，所以数据库备份足够。

但如果你想用 Git 做模板版本管理，可以把 Web 前端导出的模板 YAML 文件放进 Git 仓库。Zabbix 支持模板的导出/导入，跨环境迁移时这套流程非常方便。我的做法是：把常用的模板（Linux、Windows、SNMP 设备、Docker 等）导出为 YAML 存入 Git，新环境搭建完直接导入，省去手动重建模板的重复劳动。

6. 常见问题与排查技巧实录

这部分是我实际部署和帮助别人排查时遇到最多的几个问题，列出来当速查表用。

6.1 Zabbix Server 日志报数据库连接失败

现象：docker compose logs zabbix-server里出现failed to connect to database。

排查思路：

• 先确认 PostgreSQL 容器是否在运行：docker compose ps
• 确认 compose 里的DB_SERVER_HOST是否填的postgres（服务名），不是 IP
• 确认数据库账号密码是否匹配。PostgreSQL 容器默认只有在第一次初始化时才创建用户，如果你中途改过POSTGRES_PASSWORD但数据目录已有旧数据，新密码不会生效。
• 用docker exec进入 postgres 容器手动验证：psql -U zabbix -d zabbix -c "select 1"，能返回结果说明数据库本身正常。

一个隐藏坑：如果./data/pgsql目录已经存在且里面有旧数据，而你在 compose 里换了数据库密码，PostgreSQL 会忽略新密码继续用旧密码。此时要么改密码（ALTER USER zabbix WITH PASSWORD '新密码'），要么清空数据目录重新初始化。

6.2 Web 前端打不开或白屏

现象：访问http://IP:8080页面加载不出来。

排查思路：

• 先看容器状态：docker compose ps，确认 zabbix-web 是Up状态而不是Restarting。
• 看 web 容器日志：docker compose logs zabbix-web。常见报错是 PHP 连接数据库超时或权限问题。
• 确认数据库服务名。Web 容器的DB_SERVER_HOST也必须是postgres服务名，而不是宿主机 IP。

还有一个经常被忽略的点：Zabbix Web 容器默认监听 8080 端口。如果你是按网上老教程写的ports: - "8080:80"，实际上把宿主机的 8080 映射到了容器内的 80，而容器内 Nginx 根本没有监听 80，所以怎么访问都不通。正确写法是- "8080:8080"。

6.3 Agent 显示灰色、不可达

现象：Web 前端主机列表里，Agent 的可用性显示灰色，或者红色 ZBX。

排查思路：

• 检查 Agent 配置里的Server是否指向 Zabbix Server 宿主机 IP（不是被监控主机自己）。
• 检查防火墙：宿主机上测telnet 被监控主机IP 10050，被监控主机上测telnet 宿主机IP 10051。
• 检查 Agent 是否在运行：systemctl status zabbix-agent。
• 检查 Web 前端主机配置里的 IP 地址和端口（默认 10050）是否正确。
• 如果启用的是主动模式，检查主机名：前端的主机名必须和/etc/zabbix/zabbix_agentd.conf里的Hostname完全一致，大小写也区分。

这里有个经验：用zabbix_get命令可以快速定位问题。在 Server 容器或宿主机安装 zabbix-get 后执行：

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

返回1说明 Server 到 Agent 的被动通道正常，问题在别处；返回超时则说明网络不通或 Agent 配置有误。

6.4 SNMP 设备监控不到数据

场景：用 Zabbix 监控交换机、路由器、UPS 等网络设备时，添加了主机、配了 SNMP 模板，但数据一直是空的。

排查思路：

• 先用 snmpwalk 手动验证：snmpwalk -v2c -c public 设备IP .1.3.6.1.2.1.1.1.0，能返回系统描述说明 SNMP 本身可用。连不上就检查设备的 SNMP 开关、community 字符串、ACL 限制。
• 检查 Zabbix 主机配置里的 SNMP 接口：IP/端口/版本/community 是否和实际设备一致。注意 Zabbix 里 SNMP 接口的 IP 是单独配置的，不是默认的主机 IP。
• SNMP 模板里的键值和设备支持的 MIB 要对应。不同厂商（华为、思科、H3C）的部分 OID 有差异，可能需要复制模板并修改 OID 适配。

6.5 磁盘空间被历史数据撑爆

场景：跑了几个月后，发现宿主机磁盘越来越小，最后一看是 PostgreSQL 的数据目录特别大。

这是正常的，Zabbix 默认的 history 数据保留时间是 31 天，趋势数据保留 365 天。大量监控项在高频采集下，数据增长速度远超你想象。

解决办法是在 Web 前端"管理 → 常规 → 历史数据"里调整保留策略，或者给数据库单独挂一个更大的数据盘。另外 Zabbix 自带 housekeeper 进程会定期清理过期数据，但如果数据量太大，housekeeper 清理速度跟不上插入速度，也会造成堆积。可以通过调大ZBX_HOUSEKEEPERFREQUENCY和ZBX_MAXHOUSEKEEPERDELETE参数来加快清理节奏。

7. 一些我的实操心得

整套环境搭完后，我个人的体会是：Docker 部署 Zabbix 这件事，真正的价值不在于"装得快"，而在于让监控系统变成一种可复制的、标准化的交付物。同样的 compose 文件和目录结构，拿到新的服务器上，五分钟就能拉起一套和现有环境完全一致的服务，这种可重复性在物理机部署方式下很难实现。

最后再分享一个小技巧：如果你打算用这套方案覆盖比较大的监控规模（比如 200 台以上），建议从一开始就把 Zabbix Proxy 纳入架构，而不是等 Server 扛不住再临时加。Proxy 的部署方式和 Server 几乎一样，也是一条 compose service，配置好ZBX_HOSTNAME指回 Server 即可。提前把 Proxy 铺到你的各个机房或网络分区，采集压力就地消化，中心 Server 只做汇聚和告警，后面扩容会从容很多。

监控系统的搭建只是第一步，真正考验人的是后续的阈值调优、告警降噪、模板维护。一个健康的监控平台，应该是"告警稀少但每一条都值得处理"，而不是"每天几十条但全都没人看"。带着这个目标去调你的触发器，你会回来感谢我的。