之前每次帮人搭监控，我基本都是同一个套路：先问清楚规模，再确认要监控什么，然后直接上一套Zabbix。原因很简单，二三十台服务器加数据库、中间件的企业内网，Zabbix 是最省心的选择，模板齐全、文档多、告警策略成熟。而现在有了 Docker，把这套平台跑起来的成本又低了一大截——一条 docker compose 命令把 Server、数据库、Web 全部拉起，剩下的精力几乎都花在配置监控项和告警上，而不是耗在编译安装和依赖地狱里。
这篇文章就把我从环境准备到告警落地的完整过程拆开讲，重点围绕 Docker 部署 Zabbix 监控告警平台这件事：compose 文件怎么写、每个参数为什么这样配、装完 Agent 之后怎么接第一台主机、告警怎么真正推到人，以及半年来踩过的各种坑。适合两类人看：一是运维或 DevOps 工程师，想在半天内给公司搭一套能用的监控告警体系；二是自己服务器上喜欢折腾的老手，想快速体验 Zabbix 7.0 LTS 的新特性。看完照着操作，一台干净服务器就能变成一个可用的企业级监控平台。
1. 为什么是 Docker + Zabbix：这套组合解决什么问题
1.1 Zabbix 凭什么还是监控主力
Zabbix 从最早发布到现在二十多年了，中间各种监控系统起起伏伏，Prometheus 的生态越来越大，但 Zabbix 在传统企业内网里依然有大量部署。一个重要原因是它“全”：Linux、Windows 系统指标不在话下，网络设备的 SNMP 监控、服务器硬件的 IPMI 带外管理、数据库和中间件的自定义采集，全都有现成模板或成熟方案。比起 Prometheus 更适合做云原生指标，Zabbix 对传统 IT 基础设施的覆盖是它的老本行，尤其上了规模之后，自动发现和模板批量关联这两件事能省下大量重复劳动。
国产开源监控里，夜莺监控这几年口碑也不错，界面现代、上手快，但坦白讲，如果你没有团队做二次开发，Zabbix 的社区资料丰富程度和各类“玄学问题”的解决方案沉淀还是更足一些。尤其是在中小团队里，出了问题能搜到答案比什么都重要。这次我用 Docker 部署 Zabbix，目的就是把它的部署成本压到最低，让团队不用花一整周去搭环境，而是把时间花在真正有用的告警策略上。
1.2 用 Docker 部署的收益和边界
不少人一听到 Docker 部署监控平台，第一反应是“生产环境能行吗？”我的回答是：完全能行，但要把边界想清楚。
Docker 化部署的好处很直接：一是环境隔离，宿主系统是 Ubuntu 还是 openEuler 都不重要，只要 Docker 引擎能跑，镜像起来就是一致的环境，团队里任何一个人都能复制部署过程；二是升级回滚方便，官方镜像发布新版本后，改一下 tag 重新 compose up 即可，出问题也能切回旧版本；三是资源占用可控，一个跑二三十台机器监控的小型 Zabbix 平台，2 核 4G 的机器绰绰有余，容器本身的开销几乎可以忽略。
边界也很明显。第一，不要用 latest 标签，镜像版本必须锁定，比如7.0-ubuntu，否则哪天镜像更新了，容器一重建就是跨版本升级，很容易出兼容性问题。第二，数据卷规划要提前想好，Zabbix 的核心资产是数据库里的历史数据和配置，容器可以随便重建，数据卷丢了就全完了。第三，时区、字符集这类基础设置要在部署时一次配好，后面再改虽然能改，但中间踩坑的成本不值当。最后，如果以后规模大到几千台设备，单机部署就不够了，需要引入 Zabbix Proxy 做分布式采集，这东西同样可以容器化，架构上留好扩展空间就行。
2. 部署前的整体设计：组件拆解与版本选型
2.1 Zabbix 容器化后有哪些组件
Zabbix 本身的架构不算复杂，由几个各司其职的部分组成。核心是 Zabbix Server，它负责接收数据、执行触发器判断、发送告警，是整个平台的“大脑”。数据要存下来，所以要有数据库，Zabbix 官方同时支持 PostgreSQL 和 MySQL。人要看数据、做配置，于是有了 Zabbix Web，它是一套 PHP 和 Nginx（或者 Apache）组成的前端界面。最后是 Agent，装在每台被监控的机器上，负责采集指标并上报给 Server。
用生活类比的话：Server 是公司的运营中枢，数据库是它的笔记本，Web 是前台接待窗口，Agent 则是派驻到各个业务部门的信息员。而 Zabbix Proxy 相当于片区经理，当辖区太大、分公司太多时，由它先在本地收集信息，再统一汇总到总部，减轻 Server 的压力。Docker 化之后，这些组件各自跑在一个容器里，通过 compose 创建的内部网络互相通信。最小可用部署就是三件套：Server、数据库、Web，Agent 单独装在被监控机器上，不需要容器化。
2.2 版本选型：直接上 Zabbix 7.0 LTS
版本选择这里，我建议新部署直接上 7.0 LTS，不要再用 5.0、6.0 了。Zabbix 版本有 LTS 和普通版本之分，LTS 长期支持版本会提供数年的维护更新，适合生产环境。7.0 是 2024 年发布的 LTS 版本，新前端界面明显现代了不少，而且 Agent 2 内置插件更丰富，对 Windows GPU、Oracle 等监控场景的支持比旧版好很多，历史数据存储和查询也有针对性的优化。
| 版本 | 是否 LTS | 建议 |
|---|---|---|
| 5.0 LTS | 是 | 已接近维护末期，新项目不推荐 |
| 6.0 LTS | 是 | 存量升级可选，但没必要新用 |
| 7.0 LTS | 是 | 新部署直接用，维护周期长 |
镜像 tag 有一定规律。以 PostgreSQL 版为例，官方镜像名是zabbix/zabbix-server-pgsql，配合7.0-ubuntu这样的版本 tag 使用。有的教程喜欢用alpine-7.0-latest，也问题不大，但我个人更偏好 ubuntu 版本，排障时能用 apt 装一些排查工具，比如 vim、curl，省事不少。需要留意的是，Agent 老版本连 Server 7.0 是兼容的，但为了用上 Agent 2 的新插件，被监控机器上最好也统一升到 7.x。
2.3 网络与数据卷规划：部署前先把这两件事定下来
部署前花五分钟想清楚网络和数据卷，能避免后续大量返工。网络方面，compose 会自动创建一个 bridge 网络，三个容器之间用服务名互相访问就行，不需要写成 IP。对外只需暴露两个端口：Web 界面端口，一般用宿主机的 8080 映射容器的 8080；Server 的 10051 端口，这是给 Agent 主动上报和 Zabbix Proxy 上报数据用的。
很多新手第一次配端口时会搞混：Agent 被动模式的检查是 Server 主动连接 Agent 的 10050 端口，数据方向是从 Server 指向 Agent；而 Agent 主动模式是 Agent 连 Server 的 10051，方向反过来。如果是公司内网环境，10051 端口需要在防火墙上放行，否则装了 Agent 开了主动模式也上报不了数据。关于 10050，一般只需要在被监控机器的本机防火墙放行即可，不用暴露到外网。
数据卷方面，最重要的就是数据库。PostgreSQL 的数据必须挂到命名卷或宿主机目录，否则docker compose down再up之后历史数据全部丢失。Zabbix Server 容器如果要跑自定义脚本、外部检查，也需要挂载对应目录，比如/usr/lib/zabbix/alertscripts放告警脚本，/usr/lib/zabbix/externalscripts放外部采集脚本。Web 容器如果遇到中文乱码需要补字体，同样要挂载字体文件或者把字体复制进去。
时区问题也要在 compose 里一次配好。容器默认是 UTC 时间，如果不设置，图表时间线会比北京时间差 8 小时，告警时间看起来也会很别扭。Server 容器设置TZ=Asia/Shanghai，Web 容器设置PHP_TZ=Asia/Shanghai，数据库容器也建议把 TZ 带上，这是经验之谈。
3. 手把手部署：Compose 文件编写与启动
3.1 Docker 环境准备：Ubuntu 22.04 为例
我这次部署用的是一台 Ubuntu 22.04 的服务器，系统本身是干净的。安装 Docker 的部分就不啰嗦了，直接给操作步骤。Ubuntu 上最简单的办法是直接用官方源安装 docker-ce 和 compose 插件：
sudo apt update sudo apt install -y ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod a+r /etc/apt/keyrings/docker.gpg echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin安装完后验证一下：
sudo docker compose version然后是镜像加速配置。国内拉 Docker 官方镜像确实慢，这是很多人部署时卡住的第一道坎。做法是编辑/etc/docker/daemon.json，把云厂商提供的镜像加速地址填进去：
{ "registry-mirrors": [ "https://你的加速地址.mirror.aliyuncs.com" ] }加速地址需要在云厂商的控制台申请，这里不展开具体操作。如果公司内网有自建的镜像仓库，直接填内网地址更合适。改完后重启 Docker：
sudo systemctl daemon-reload sudo systemctl restart docker顺便把当前用户加入 docker 组，避免后面每条命令都加 sudo：
sudo usermod -aG docker $USER退出重新登录后生效。
3.2 docker-compose.yml 完整示例和参数解析
Zabbix 官方提供了一套基于 postgres 的 docker compose 参考，但默认配置有几个小地方需要改：时区要设置、密码要换、数据库卷要显式声明。我整理了一份适合企业内网最小化部署的 compose 文件，直接保存成docker-compose.yml：
services: postgres: image: postgres:16-alpine container_name: zabbix-postgres restart: always environment: POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix_pass_2024 POSTGRES_DB: zabbix TZ: Asia/Shanghai volumes: - pgdata:/var/lib/postgresql/data networks: - zbx-net zabbix-server: image: zabbix/zabbix-server-pgsql:7.0-ubuntu container_name: zabbix-server restart: always environment: DB_SERVER_HOST: postgres POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix_pass_2024 POSTGRES_DB: zabbix TZ: Asia/Shanghai ports: - "10051:10051" volumes: - /etc/localtime:/etc/localtime:ro depends_on: - postgres networks: - zbx-net zabbix-web: image: zabbix/zabbix-web-nginx-pgsql:7.0-ubuntu container_name: zabbix-web restart: always environment: DB_SERVER_HOST: postgres POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix_pass_2024 POSTGRES_DB: zabbix ZBX_SERVER_HOST: zabbix-server PHP_TZ: Asia/Shanghai ports: - "8080:8080" depends_on: - zabbix-server - postgres networks: - zbx-net volumes: pgdata: networks: zbx-net: driver: bridge逐个拆解关键参数。POSTGRES_USER、POSTGRES_PASSWORD、POSTGRES_DB是 PostgreSQL 容器初始化时创建用户和数据库的依据，注意这里如果数据库卷已经存在旧数据，改了密码是不会生效的，因为初始化脚本只会在数据目录为空时执行。DB_SERVER_HOST对 Zabbix Server 和 Web 容器来说，填的是 PostgreSQL 容器在 compose 网络里的服务名postgres，这个非常关键，不要填127.0.0.1，因为容器之间通信不是通过 localhost。
ZBX_SERVER_HOST是告诉 Web 容器 Zabbix Server 在哪里，填服务名zabbix-server即可。端口映射方面，8080:8080是把 Web 容器里的 8080 暴露到宿主机 8080，如果你本机 8080 被占了可以改成别的，比如18080:8080。10051:10051是 Server 接收主动上报数据的端口。数据卷pgdata是命名的 volume，由 docker 管理，数据存在宿主机/var/lib/docker/volumes下，这样就算容器重建数据也不丢。
另外再补充一个实用挂载。Zabbix 官方镜像默认没有中文字体，Web 界面切到中文后图表里中文会是方块。我习惯在 compose 里再挂一个目录，或者在容器起来后把字体文件复制进去。更干净的做法是用一个小 Dockerfile：
FROM zabbix/zabbix-web-nginx-pgsql:7.0-ubuntu RUN apt-get update && apt-get install -y fonts-wqy-zenhei这样 build 出来的 web 镜像自带中文字体。如果不想维护自定义镜像，也可以docker cp把本机字体复制到容器/usr/share/fonts下，然后重启容器，实测有效。
3.3 启动、初始化和 Web 界面配置
前面工作准备好后，执行启动命令：
docker compose up -d第一次启动时，Zabbix Server 容器会自动等待 PostgreSQL 就绪，然后初始化表结构。这个过程一般需要两到三分钟，期间可以用日志确认进度：
docker compose logs -f zabbix-server看到类似server started的日志，就说明 Server 已经起来了。这时候再打开浏览器访问http://你的服务器IP:8080，应该能进入 Zabbix Web 界面。首次进入会要你选择语言，这里直接选 Chinese (zh_CN) 会有一部分系统界面变中文，但数据库连接信息一般会因为环境变量正确而自动填好，不用手动改。
用默认账号Admin和密码zabbix登录，登录后会强制要求修改默认密码，这个一定要改掉，默认密码在公网环境相当于裸奔。改完密码后，到用户菜单里把语言设为中文。如果图表里的中文变成方块，就是第 3.2 节说的字体问题，按字体方案处理即可。到这里，核心平台已经跑起来了，接下来是接入被监控主机。
4. 接入第一台被监控主机：Agent 安装、添加主机与告警打通
4.1 安装 Zabbix Agent 2：Linux 和 Windows 都给你示范
Agent 是部署在每台被监控机器上的采集器。7.0 时代推荐直接装 Agent 2，也就是zabbix-agent2，它对插件的支持更好。以 Ubuntu/Debian 系为例，安装过程是先在机器上配置 Zabbix 官方源，再安装 agent 2。这里特意提示一下：如果服务器是 Rocky、CentOS 这类 RHEL 系，需要去 Zabbix 官网下载对应 RPM 包；如果是 openEuler、龙蜥这类国产系统，也可以按照 RHEL 系的套路安装，本质一致。
Ubuntu 上安装的典型命令：
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-1+ubuntu22.04_all.deb sudo dpkg -i zabbix-release_7.0-1+ubuntu22.04_all.deb sudo apt update sudo apt install -y zabbix-agent2装完后需要修改/etc/zabbix/zabbix_agent2.conf，改三个地方：
Server=监控服务器IP ServerActive=监控服务器IP Hostname=这台机器唯一标识Server是允许主动连过来做被动检查的服务器 IP，如果有多个 Server 或 Zabbix Proxy，用逗号分隔。ServerActive是 Agent 主动上报时连接的服务端地址，可以填域名或 IP。Hostname这一项在主动模式下尤其重要，必须和 Web 界面里添加主机时填的主机名完全一致，否则数据会上报失败。改完后启动：
sudo systemctl enable --now zabbix-agent2Windows 上的安装相对简单，去 Zabbix 官网下载 Windows 版本的 MSI 安装包，安装过程中会有界面让你填写 Zabbix Server 地址和 Hostname。如果要做静默安装，也可以命令行指定参数，但图形化装一次就够用了。装完后需要注意 Windows 防火墙默认会拦 10050 端口，要放行入站规则，否则 Server 被动检查连不上。
顺带说一个热词里很多人搜的事情：Zabbix 监控 Windows GPU。Agent 2 在 Windows 上支持通过性能计数器采集数据，常见的 GPU 使用率计数器是\GPU Engine(*engtype_3D)\Utilization Percentage，但不同显卡、不同驱动版本，性能计数器的实例名不完全一样，需要先在 Windows 的性能监视器里确认再配置监控项。Zabbix 社区的 Windows 模板里也有 GPU 相关监控项，可以直接搜模板导入，省得自己一个个建。
4.2 在 Web 控制台添加主机：主动检查 vs 被动检查
Agent 装好了，下一步到 Web 界面把它加进来。路径是采集→主机→创建主机。填写主机名时要注意，这个名字必须是全局唯一的，而且如果 Agent 用了主动模式，它必须和 agent 配置文件里的Hostname完全一致。IP 地址那一栏，填 Agent 机器的实际 IP，接口选Agent。
然后是关键的一步：点击模板选择框，输入关键词搜索，然后选择Linux by Zabbix agent或者Windows by Zabbix agent。模板是一整套预先定义好的监控项、触发器、图形集合，选好之后点添加，系统会自动创建几十上百个监控项。这就是 Zabbix 模板生态的威力，你不需要从零开始定义 CPU、内存、磁盘那些指标。
这里要理解主动检查和被动检查的区别。被动检查是 Zabbix Server 主动连接 Agent 的 10050 端口去取数据，适合 Server 和 Agent 网络互通良好的场景。主动检查是 Agent 定期去找 Server 领取任务列表，再主动把数据推送到 Server 的 10051 端口，适合 Agent 在 NAT 后面、或者 Server 无法直接访问 Agent 的场景。实际操作中，很多模板同时带了两套监控项，比如Linux by Zabbix agent和Linux by Zabbix agent active，前者走被动，后者走主动。如果你方向没理清，最常见的症状是主机显示绿色心跳，但最新数据里什么都没有。
我的建议是：新接入的主机，如果网络允许，优先用被动模式，排查问题更直观；确实有防火墙隔离或跨网段需求的，再改用主动模式。
4.3 配置告警媒介：邮件通知先从 SMTP 开始
告警是监控平台的灵魂。Zabbix 的告警链路是三段式：触发器判断异常、动作匹配条件、媒介把消息发出去。默认安装后，邮件媒介类型是已经存在的，但需要你配置 SMTP 服务器信息。路径是管理→报警媒介类型→Email。
填 SMTP 服务器地址、端口、SSL/TLS 方式、认证的用户名密码，以及发件人地址。用 465 端口一般是 SSL，用 587 端口一般是 STARTTLS，用 25 端口通常没有加密但容易被运营商拦截。配置完可以先点测试，看看能不能成功发送邮件。
然后要给用户分配收件地址。路径是用户→用户→ 选择 Admin →报警媒介→添加，媒介类型选 Email，收件人填自己的邮箱，然后启用它。这里容易漏的一步是：即使你配好了 SMTP 和用户媒介，没有创建动作，告警照样不会发。必须到告警→动作→创建动作，设置名称，配置触发条件，比如主机组等于 Linux servers或者模板等于 Linux by Zabbix agent，然后在操作里选择发送消息给某个用户组或用户。
动作配置里有消息内容模板，默认会带上主机、监控项、当前值，但建议自己调优一下。我常用的消息正文模板大概是这样的：
主机: {HOST.NAME} IP: {HOST.IP} 监控项: {ITEM.NAME} 当前值: {ITEM.LASTVALUE} 告警时间: {EVENT.DATE} {EVENT.TIME}这样告警邮件一眼就能看清是哪台机器、哪个指标、当前是多少。配置完动作之后别急着收工，手动停止一台机器的 agent 服务，等两三分钟，邮箱应该就会收到告警邮件。收到邮件后才算把告警链路真正打通，这一步不验证，后面全是隐患。
5. 告警平台进阶：让报警更准确，不再半夜被轰炸
5.1 触发器表达式：看懂和写几个常用例子
很多团队把监控搭起来后，最头疼的不是收不到告警，而是告警轰炸——白天黑夜响个不停，全是无用告警，最后大家直接把通知关了。想要告警真正有价值，必须学会写触发器表达式。触发器是判断“什么时候算异常”的逻辑，语法格式通常是：
{主机:监控项.函数(参数)} 操作符 阈值先看几个非常常用的写法。CPU 负载过高，比如 5 分钟内平均负载持续超过 4：
last(/Linux by Zabbix agent/system.cpu.load[percpu,avg1])>4这里用last()取最新值，配合比较符判断。如果担心瞬时抖动导致误报，可以改成min(/主机/监控项,5m)>4，意思是 5 分钟内的最小值都大于 4 才触发，灵敏度低一些，但更稳定。
磁盘可用空间不足，比如根分区可用百分比低于 10%：
last(/Linux by Zabbix agent/vfs.fs.size[/,pfree])<10要注意这里监控项键值里的pfree表示“可用空间百分比”，对应的监控项在模板里叫Free disk space on / (percentage)。
进程消失或 Agent 断连，用nodata()函数，比如 5 分钟没有 agent 心跳数据：
nodata(/Linux by Zabbix agent/agent.ping,5m)=1nodata()在“没有数据”时为 1，非常适合监控探活。
写表达式时最实用的技巧是在消息内容里带上宏，比如{ITEM.NAME}显示监控项名称，{ITEM.LASTVALUE}显示当前值。这样告警通知会直观很多。新手上路建议从模板自带触发器开始，看它们是怎么写的，然后照葫芦画瓢改成自己的阈值，不要一上来就自己发明新的表达式。
5.2 告警收敛与升级：维护期、依赖、多步骤通知
告警轰炸的另一个解决手段是利用 Zabbix 的维护期和动作升级机制。维护期相当于给监控“放假”，在业务发布窗口、停机维护前，到告警→维护→创建维护窗口，把要维护的主机或主机组加进去，设置开始时间和时长。这段时间内即使指标异常，也不会触发通知，避免大半夜发布脚本稍微慢一点就一堆告警。
依赖关系是另一个很好用的收敛手段。比如你监控了一个核心交换机，下面挂了二十台业务服务器。交换机一挂，这二十台服务器的agent.ping全都会 nodata，如果每个都发告警，值班同学要被刷屏。解决办法是给监控项或触发器设置依赖：业务服务器的“主机不可达”触发器依赖交换机的“接口 down”触发器，上游已经触发时下游就不重复发。在触发器级别配置依赖关系即可，这个功能很多老手都没用过，其实是 Zabbix 最强悍的告警收敛能力之一。
动作升级则是解决“告警发出去了没人处理”的问题。在动作配置里，点击操作里的步骤，可以设置多步骤：步骤 1-2 发送给第一梯队值班人员，每 10 分钟重复一次；步骤 3-5 发送给小组负责人；超过 30 分钟还没恢复，自动通知部门经理。配好之后，一套告警能形成处理流程，而不是发了就不管。这些功能在 Zabbix Web 界面里都是可视化配置，关键是很多人装完根本没点进去看过。
5.3 用 Grafana 做展现面：一个插件让图表拉满
Zabbix 自带的图形功能这几年进步不少，但整体颜值和交互还是不如 Grafana。很多公司领导汇报、出周报都习惯用 Grafana 来展示监控数据。Grafana 接 Zabbix 很简单：先部署一个 Grafana 容器，然后在 Grafana 里安装 Zabbix 插件，插件名是alexanderzobnin-zabbix-datasource，官方插件市场一键安装即可。
数据源配置时填 Zabbix 的 API 地址，格式是http://监控服务器IP:8080/api_jsonrpc.php，认证方式选 Basic auth 或 Token，用户名密码用你 Zabbix 的账号。连上之后，添加 Dashboard，选择 Zabbix 数据源，就能通过可视化查询界面把监控项拖到面板上。Zabbix 的指标体系在 Grafana 里会被结构化成主机组、主机、应用集、监控项层级，熟悉之后配置面板很快。
如果老板要求提供 PDF 监控报告，Grafana 可以通过内置报告插件或异步渲染服务导出 PDF，现在新版 Grafana 对报告导出支持得也越来越好。不过要提醒一点：Grafana 里如果开了匿名访问，整个监控数据相当于在内网裸奔，一定要设置好权限，最好用 OAuth 或账号密码登录，再限制访问者只能看指定的 Dashboard。
6. 常见问题与排查实录
6.1 看日志：第一排查手段
监控平台本身出问题时，最怕到处乱猜。Zabbix 的排查核心是日志。容器环境下，日志统一走 docker 的标准输出和容器内文件两条路径。先看 compose 服务状态：
docker compose ps docker compose logs --tail=100 zabbix-server如果容器起不来，错误信息大概率会出现在这里。数据库初始化失败、密码不匹配、端口被占用，都能在日志里找到直接线索。Zabbix Server 容器的详细日志在容器内/var/log/zabbix/zabbix_server.log，Agent 的问题则要看被监控机器上的/var/log/zabbix/zabbix_agent2.log。这个日志文件非常重要，Agent 连接不上、Hostname 不匹配、主动上报失败，都会在这里留下记录。
6.2 中文乱码和时区显示不对
中文乱码属于“高发但好解决”的问题。现象是 Web 界面切到中文后，图形标题、图例里的中文全部变成方块。根因是容器里没有中文字体，系统找不到能渲染中文字形的字体文件。解决思路有两条：一条是按第 3.2 节说的，用 Dockerfile 安装fonts-wqy-zenhei重新构建 Web 镜像；另一条是运行时把字体文件复制进容器，然后重启容器。路径是到 Web 容器/usr/share/fonts下放一个中文字体，ttf 或 otf 都行，接着更新字体缓存再重启容器。
时区显示不对，多半是部署时没设置TZ和PHP_TZ。Zabbix Server 和 Web 容器的时间来源分别来自这两个环境变量，有一点要记住：数据库容器的时间也最好设置成 Asia/Shanghai，否则有些写入数据库的时间戳会和前端展示差 8 小时，排查起来相当迷惑。
6.3 Agent 连接不上的典型症状和处理方向
这里直接整理一份问题速查表，都是我在实际部署中遇到过的情况：
| 症状 | 可能原因 | 处理方向 |
|---|---|---|
| 主机心跳是绿色，但最新数据为空 | 主动模式下 Hostname 不一致；模板没关联主动版本 | 检查 agent 配置Hostname，确认和 Web 界面一致 |
报错Get value from agent failed: cannot connect to [IP]:10050 | Server 连不上 Agent 的 10050；防火墙拦截；Agent 未启动 | 在被监控机器上执行 `ss -lntp |
报错Received empty response from daemon | Agent 版本过旧或配置了加密但 Server 没启用加密 | 统一升级 Agent 到 7.x；检查 PSK 配置是否匹配 |
主动模式下unsupported item key | Agent 2 没启用对应插件或模板用了新键值 | 在 agent2 配置里加载插件，或换用兼容的模板 |
| 邮件一直发不出去 | SMTP 端口不通；Zabbix 容器无法访问外网 | 在 Server 容器里用curl测试 SMTP 端口连通性 |
还有一条很容易被忽略的经验：Ubuntu 上安装 agent 后，默认配置文件/etc/zabbix/zabbix_agent2.conf里的Server=127.0.0.1，如果不改成 Zabbix Server 的实际 IP，Web 界面填了 IP 也连不上，因为 agent 根本不允许来自其他地址的被动检查。很多新手栽在这上面，从头到尾检查了一遍防火墙、端口、模板，最后发现是这一个配置项没改。
6.4 镜像拉取慢和数据持久化备份
镜像拉取慢的问题，在第 3.1 节已经讲了通过配置 registry-mirrors 解决。但企业内网环境还有一种更常见的情况：生产服务器不能直接访问外网。这时候建议在能访问外网的机器上先把镜像 pull 下来，然后导成 tar 包，传进内网后再用docker load导入。
docker pull zabbix/zabbix-server-pgsql:7.0-ubuntu docker save zabbix/zabbix-server-pgsql:7.0-ubuntu -o zabbix-server.tar # 内网机器执行 docker load -i zabbix-server.tar数据备份这件事，很多团队到最后都忘了。Zabbix 的配置数据、历史数据全在 PostgreSQL 里，最稳妥的备份方式是用pg_dump定时导出数据库：
docker exec zabbix-postgres pg_dump -U zabbix zabbix | gzip > zbx_backup_$(date +%F).sql.gz恢复时用gunzip解压后psql导入。历史数据量很大时，也可以只备份配置库，但生产环境建议全量备份。数据卷pgdata本身也可以直接停止数据库容器后打包目录，但这种方式在数据库运行中做容易造成数据不一致，所以还是推荐pg_dump。备份频率看告警历史的重要程度，一般公司每天备份一次就够了，保留最近 30 天。
6.5 升级版本前先把这件事做掉
Zabbix 官方在大版本升级上有严格要求，尤其是跨 LTS 大版本，比如从 6.0 升 7.0，需要先确认数据库版本兼容、配置备份完整。容器化部署让升级过程变简单了，但不要因此掉以轻心。我的建议升级流程是：先docker compose down，手动备份数据库，确认备份文件存在且能解析，然后修改 compose 文件里的镜像 tag，再docker compose up -d。如果新版本启动后有任何异常，马上用备份恢复旧版本。
千万别在生产环境用docker compose pull && docker compose up -d这种“一键升级”方式，你根本不知道 new tag 拉下来的是什么版本，万一拉到一个大版本变更，数据迁移逻辑会把你折腾到怀疑人生。凡是涉及数据库结构的应用，升级前备份永远是第一位。
最后再分享一条个人经验：Zabbix 这类监控平台，最忌讳一次性把模板、触发器、告警全铺开，结果没人维护、告警一堆没人看，最后运维团队对监控彻底失去信任。我建议新部署完，先接三到五台核心机器，配置 CPU、内存、磁盘、网络这四类基础告警，跑两周，把误报率调低，再逐步扩大覆盖面。告警不是越多越好，而是每条告警都必须对应一个明确的处理动作。把这条路走顺了，Docker 部署 Zabbix 这套东西才算真正在你公司落地，而不是又多了一套没人看的系统。
