Docker部署Zabbix监控平台：从环境搭建到告警配置全指南

做运维这行，最怕的不是故障本身，而是故障发生了，却没人第一时间知道。业务方比你先发现系统挂了，那种被动的滋味，体验过一次就再也不想有第二次。Zabbix 作为老牌的企业级监控与告警平台，恰好就是解决这个问题的利器；而用 Docker 部署 Zabbix，则是我在多个环境里折腾过之后，觉得最省心、最可复现的一套做法。这篇文章就从实际落地的角度，把环境准备、容器编排、主机接入、告警通知的完整链路，一条条掰开讲清楚，连参数为什么这么写、报错怎么排查都会说到。想快速拥有一套能监控服务器、数据库、网络设备并自动告警的平台的同行，尤其是刚接触 Zabbix 的运维新手，按这篇的步骤走一遍，基本都能把平台跑起来。

1. 方案选型与整体架构：先弄明白 Zabbix 在 Docker 里跑着什么

1.1 为什么选 Docker 部署 Zabbix

早年装 Zabbix 是个体力活。要配官方仓库、装 PHP、装数据库驱动、改一堆配置文件，稍不注意版本就对不上。我记得第一次在 CentOS 7 上折腾 Zabbix 4.0，光依赖冲突就解了一天，更别说以后升级大版本还得小心翼翼地停服、备份、迁移数据库。后来用上 Docker，这件事的复杂度直接降了一个量级。

用 Docker 部署 Zabbix 的核心收益，是把“环境一致性”这个最折磨人的问题交给镜像去解决。官方镜像zabbix/zabbix-server-pgsql、zabbix/zabbix-web-nginx-pgsql把这些组件的依赖关系都打包好了，你拉下来起容器就能跑。升级的时候换一个 tag，回滚的时候换回旧 tag，整个操作几分钟完成。测试环境验证完，生产环境用同一套 compose 文件，行为基本一致，这比手写一堆安装命令可预测得多。

当然，没有银弹。Docker 化之后也有代价：数据必须靠 volume 持久化，否则容器一删全没了；日志在容器里，排查问题要多一步docker logs；端口映射做得不好还容易跟宿主机现有服务冲突。所以这篇文章里，我会把网络规划、数据卷、端口映射这些细节都讲清楚，踩过的坑不会再让你踩一遍。

1.2 Zabbix 核心组件与数据流向

Zabbix 不是一个单体程序，它是一组组件协作跑起来的。理解这一点，后面排错会轻松很多。我用一个表格梳理一下：

整个数据流可以这样理解：Server 告诉 Agent 去采集哪些指标，Agent 把数据回传，Server 拿到数据后判断是否落在触发器的阈值范围内，如果触发了，就生成告警事件，通过配置好的告警媒介把消息推给指定的人。所有采集到的历史数据和事件都会写入数据库，Web 前端再从数据库里取出来画图、展示。所以数据库一旦出问题，整个平台就瘫了，这也是后面备份要重点照顾数据库的原因。

值得多说一句的是 Agent 的“被动”和“主动”两种模式。被动模式下，Server 定期向 Agent 发起请求拉数据，默认走 10050 端口；主动模式下，Agent 自己定时把数据推到 Server，走 10051 端口。小规模环境用默认的被动模式就够了，主机多了之后可以考虑把某些采集项改成主动模式，减轻 Server 压力。

1.3 版本、数据库与硬件要求怎么定

版本这块，我的建议是直接用当前 LTS 版本。Zabbix 7.0 LTS 是 2024 年发布的长期支持版，支持周期长，功能上比 6.0、6.4 都完善，Web 界面也不一样了。如果公司有历史包袱必须兼容老版本，再考虑 6.0 LTS。选版本就一个原则：能上新就不守旧，但不要盲目追最新非 LTS 版。

数据库我推荐 PostgreSQL。原因不复杂：官方对 pgsql 镜像的维护最积极，社区里踩坑记录也多是围绕 MySQL 的。Zabbix 官方同时提供zabbix-server-mysql和zabbix-server-pgsql两套镜像，只要把 compose 里的镜像和后端数据库对应上就行，混搭会连不上，这是新手最常见的低级错误。

硬件要求真不高。一个 2 核 4G 内存、20G 磁盘的虚拟机，监控几十台主机绰绰有余。Docker Engine 版本建议 20.10 以上，docker-compose 插件用 v2 语法。系统我常用 Ubuntu 22.04/24.04，Debian 也可以，CentOS 7 由于内核和 Docker 兼容性问题，不建议再作为宿主机了。

2. 五步吃透 docker-compose：从空目录到可访问的监控平台

2.1 网络与数据卷规划

动手写 compose 之前，先把两件事规划好：网络和数据卷。

网络方面，我会创建一个自定义 bridge 网络，让三个容器在内部通过服务名互相访问。为什么不用 host 网络？一是端口冲突风险大，Web、数据库都直接暴露在宿主机网络上，安全性和灵活性都差；二是自定义 bridge 网络内置 DNS 解析，容器之间直接用服务名通信，配置里写DB_SERVER_HOST: zabbix-db就能连通，非常省事。

数据卷方面，数据库的目录必须挂在宿主机上。PostgreSQL 官方镜像的数据目录是/var/lib/postgresql/data，把它映射到一个本地 volume 或者宿主机目录，比如/opt/zabbix/zbx-db-data。另外务必备份/etc/localtime到容器里，保持容器时间和宿主机一致，否则告警时间、图表时间全都会偏移，排查问题的时候特别容易误导人。

我习惯把整套部署文件放在/opt/zabbix目录下，结构清晰，备份也好操作：

/opt/zabbix/ ├── docker-compose.yml └── zbx-db-data/ # 数据库数据目录（volume 实际存储）

2.2 编写 docker-compose.yml 并逐个解释关键参数

下面是我实际在用的 compose 文件，Zabbix 7.0 LTS + PostgreSQL 16，你可以直接复制改密码：

version: "3.8" networks: zbx-net: driver: bridge volumes: zbx-db: driver: local services: zabbix-db: image: postgres:16-alpine container_name: zbx-postgres restart: always environment: POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix@2024 POSTGRES_DB: zabbix volumes: - zbx-db:/var/lib/postgresql/data networks: - zbx-net zabbix-server: image: zabbix/zabbix-server-pgsql:alpine-7.0-latest container_name: zbx-server restart: always environment: DB_SERVER_HOST: zabbix-db POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix@2024 POSTGRES_DB: zabbix ports: - "10051:10051" volumes: - /etc/localtime:/etc/localtime:ro depends_on: - zabbix-db networks: - zbx-net zabbix-web: image: zabbix/zabbix-web-nginx-pgsql:alpine-7.0-latest container_name: zbx-web restart: always environment: ZBX_SERVER_HOST: zabbix-server DB_SERVER_HOST: zabbix-db POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix@2024 POSTGRES_DB: zabbix PHP_TZ: Asia/Shanghai ports: - "8080:8080" depends_on: - zabbix-server - zabbix-db networks: - zbx-net zabbix-agent: image: zabbix/zabbix-agent:alpine-7.0-latest container_name: zbx-agent restart: always environment: ZBX_SERVER_HOST: zbx-server ZBX_HOSTNAME: zbx-server ports: - "10050:10050" depends_on: - zabbix-server networks: - zbx-net

这里的关键参数，我逐个说下含义：

端口映射要理解透：10051是 Zabbix Server 的 trapper 端口，外部 Agent 主动上报数据要靠它，必须映射出来；10050是 Agent 被动采集端口，如果只在 Zabbix 本机监控自己的容器，可以不用映射，但要监控外部主机，不建议把 Agent 容器暴露出去，正确做法是直接在目标主机上装系统原生 agent，后面第三章会说。Web 端口我习惯映射到8080，避免跟宿主机上的 80 端口打架。

2.3 启动服务、初始化数据库与 Web 登录验证

文件写好，进入目录执行：

cd /opt/zabbix docker compose up -d

第一次启动会拉镜像，需要一点时间。之后用docker compose ps确认所有容器都是 Up 状态，再用docker compose logs -f zabbix-server观察日志。如果看到类似server #0 started [main process]之类的输出，说明 Server 已经正常起来了。

数据库初始化是自动完成的，Zabbix Server 容器首次启动时会自动建表并导入 schema，不需要手动执行 SQL。等 Web 容器起来之后，浏览器访问http://宿主机IP:8080，看到 Zabbix 登录页就成功了。默认账号是Admin，密码是zabbix，登录后第一件事就是改密码。

登录后强烈建议先去右上角头像 -> User profile -> Language把语言调成 Chinese，再进入Reports -> System information，确认页面上 Zabbix server 状态显示绿色 "Running"。如果这里显示Zabbix server is not running: the information displayed may not be current.，说明 Web 和 Server 之间的健康检查有问题，这个报错太经典了，第五章我会专门展开讲。

3. 把你手头的主机都纳进来：Linux、MySQL、Nginx、交换机

3.1 添加被监控主机：界面操作全流程

Web 界面能打开了，接下来最核心的一件事：把需要监控的机器加进来。在 Zabbix 里“添加主机”不是一个简单的 IP 录入动作，而是要告诉系统三件事：这台机器叫什么、通过什么方式采集数据、套用哪些监控模板。

以一台 Linux 服务器为例，操作路径是Data collection -> Hosts -> Create host，关键配置如下：

• Host name：填一个容易识别的名称，比如web-01，后面所有图表、触发器都会用这个名字。
• Host groups：至少选一个组，方便后续批量管理和配置告警动作。建议提前建好Linux servers、Databases这类分组。
• Interfaces：添加一个 Agent 接口，IP 填被监控主机的实际 IP，端口默认 10050。
• Templates：在Link new templates里搜索并关联Linux by Zabbix agent，模板会自动带进来一整套 CPU、内存、磁盘、网络、系统服务的监控项和触发器，省得自己一条条配。

保存后等 30 到 60 秒，回到列表页看ZBX列是否变成绿色可用状态，再看Latest data里有没有出现数据。第一次做这一步的新人，十有八九会漏了 Host groups 或者忘了点模板，导致主机加进去却没有任何监控项，记住这两点能少走很多弯路。

3.2 Linux 主机安装 zabbix-agent 并完成自监控

Agent 的安装本身不复杂，难在配置和通路上。以 Ubuntu 22.04 为例，我是直接用官方仓库安装：

# 下载并安装官方仓库包 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

装完改配置/etc/zabbix/zabbix_agentd.conf，重点就三个参数：

Server=10.0.0.10 ServerActive=10.0.0.10 Hostname=web-01

Server填 Zabbix Server 的 IP，作用是被动模式下允许谁过来拉数据；ServerActive是主动模式下 Agent 往哪上报；Hostname必须和 Zabbix Web 后台里创建的主机名完全一致，如果对不上，主动模式的数据会跑到一个叫Hostname的未知主机上去，这是特别容易忽略的坑。

然后启动并验证：

systemctl enable --now zabbix-agent # 放行防火墙，视你的网络策略而定 ufw allow 10050/tcp # 在 Zabbix Server 所在机器上实测采集 zabbix_get -s 10.0.0.11 -p 10050 -k system.hostname

如果zabbix_get能返回主机名，说明链路是通的，回到 Web 界面刷新一下，图标很快会变绿。这里我强烈建议养成一个习惯：任何一台主机接入后，先zabbix_get测通链路再保存配置，别一股脑全靠界面去猜。

3.3 数据库与中间件监控：MySQL、Nginx 模板实战

光监控主机指标还远远不够，业务的核心在数据库和中间件上。Zabbix 官方模板覆盖很全，但前提是你得给这些服务开好“监控入口”。

MySQL 监控的入口是一个专用账号。官方模板MySQL by Zabbix agent需要数据库里有zbx_monitor用户，并且授予特定的最小权限：

CREATE USER 'zbx_monitor'@'%' IDENTIFIED BY 'Zabbix@123'; GRANT REPLICATION CLIENT, PROCESS, SHOW DATABASES, SHOW VIEW ON *.* TO 'zbx_monitor'@'%';

然后在 Zabbix 后台给 MySQL 主机链接模板，并配置宏指明连接串，例如{$MYSQL.DSN}设为tcp://10.0.0.20:3306，{$MYSQL.USER}设为zbx_monitor，{$MYSQL.PASSWORD}设为对应用户密码。模板里几十个监控项会自动开始跑，从查询数、连接数到缓存命中率、慢查询，基本覆盖日常巡检需求。

Nginx 更轻量，只需要在服务端配置里暴露一个状态页。在 nginx 配置中加入：

server { listen 80; location = /basic_status { stub_status; allow 127.0.0.1; allow 10.0.0.0/24; # 按需放行 Zabbix Server 网段 deny all; } }

然后在 Zabbix 里给 Nginx 主机关联Nginx by Zabbix agent模板，把{$NGINX.STUB_STATUS.SCHEME}和{$NGINX.STUB_STATUS.PORT}宏按实际情况改一下。验证方式很简单，浏览器直接访问http://IP/basic_status，能看到Active connections: 12这样的输出，说明入口通了。模板关联后稍等片刻，请求数、连接数、流量这些指标就自己进库了。

3.4 网络设备监控：SNMP 与 ICMP 接入

服务器和中间件搞定之后，交换机、路由器这类网络设备在 Zabbix 里同样可以管起来。网络设备一般不支持装 agent，接入靠的是 SNMP 协议，原理和设备本身开放一个只读的 SNMP agent，Zabbix Server 定期去轮询。

添加方式和普通主机差不多：在Interfaces选项卡里新增一个 SNMP 接口，端口默认 161，然后在Templates里关联Network device by SNMP模板。模板默认会把 CPU、内存、接口流量、接口状态这些常用 OID 都采集进来，写入{$SNMP_COMMUNITY}宏对应的团体名即可，默认public，生产环境务必修改设备的 SNMP 只读团体名，这个弱口令太危险了。

另外还有个实用技巧：给设备同时关联Ping by ICMP模板，这样即使设备 SNMP 挂了，只要 ICMP 能通，至少知道设备在线；两个模板一起用，一个管可用性，一个管性能，分工明确。我在实际项目中监控过几十台接入交换机，Zabbix 的自动发现规则能直接把所有接口和 VLAN 识别出来，基本不需要手工干预。

4. 告警闭环：让监控真正替你半夜值班

4.1 配置邮件告警媒介

监控数据有了，如果没有告警，半夜出问题还是没人知道，等于白搭。Zabbix 的告警链路是：触发器产生事件 -> 动作匹配事件 -> 通过告警媒介把消息发出去。所以第一步是先把“告警媒介”配好。

以邮件为例，进入Administration -> Media types -> Email，配置 SMTP 参数。我常用的配置是：SMTP server 填邮箱服务商的地址，比如企业邮箱填smtp.company.com，端口 465 选 SSL，勾选 Authentication，填发件账号和密码。这里有个常见的坑：很多邮箱服务商对第三方 SMTP 有专门的授权码机制，不能用登录密码，得去邮箱设置里生成授权码，否则会一直报认证失败。

配置完一定要点右下角的Test，填一个收件地址发测试邮件。测试通过再保存，这一步能省去后面所有“为什么没收到告警”的排查时间。另外，在字段设置里可以把Subject和Message改成包含主机名、触发器和严重级别的模板，比如[告警] {EVENT.NAME} on {HOST.NAME}，收到邮件一眼就知道是什么状态、哪台机器出了问题。

4.2 创建告警动作与用户通知

媒介配好只是“能用”，真正把邮件发给谁、什么条件下发，靠的是动作。在Configuration -> Actions -> Trigger actions里，系统默认有一条动作，但往往不满足生产需求，建议新建一条。

操作路径是Create action，我一般这样配置：

• Name：生产环境告警通知
• Conditions：设置触发条件，比如Host group = Linux servers，或者按严重级别过滤，避免测试环境的信息刷屏。
• Operations：添加操作，Send message给指定用户组，媒体类型选 Email。

同时要记得在Administration -> Users里给对应账号配置媒体地址。具体做法是编辑用户，进入Media选项卡，添加一条 Email 媒介，填接收邮箱，勾选接收哪些严重级别的告警，以及通知时间段。我习惯把告警级别至少设为Warning及以上，把Information级别的信息留给界面查看，不然邮件真的会变成轰炸。

最后还有个细节：动作里除了Operations第一操作，还有Recovery operations恢复操作和Update operations确认操作，分别对应“故障恢复时通知”和“人工确认告警时通知”。把恢复操作也勾上，这样故障解决了，相关人员能收到一条“已恢复”的通知，整个告警生命周期才完整。

4.3 触发器、维护窗口与告警降噪

告警配置到最后，真正考验水平的是降噪。你不想凌晨三点因为一条误报爬起来，更不想因为告警风暴把手机震没电。

先从触发器说起。模板自带的触发器已经覆盖 90% 的常规场景，但业务定制场景要自己写表达式。比如要监控 Nginx 的并发连接数连续 3 次超过 200，就在Configuration -> Hosts -> Triggers -> Create trigger里写：

last(/web-01/nginx.active.connections) > 200

精确点用min函数配合周期：

min(/web-01/net.if.in[eth0],5m) > 500000

这表示 eth0 网卡 5 分钟内的平均入流量大于 500KB/s 就触发。表达式里的last、min、max、avg这几个聚合函数是高频使用项，配合时间后缀5m、1h能做出非常精准的告警条件。

维护窗口是我最想强调的功能。比如每周日凌晨 2 点跑批任务，期间 CPU 飙高是正常现象，不处理就会误报。在Configuration -> Maintenance里创建维护期，选择主机和周期，点击激活后，维护期内的所有触发器和告警都会被抑制。我接手的每个 Zabbix 项目，第一件降噪的事就是盘点定期任务窗口，把它们全部纳入维护计划。

严重级别的划分也要上心。我见过很多团队把什么都设成High，结果真正的故障被淹没在红色海洋里。合理划分能让人在收到告警时下意识判断优先级：磁盘快要满了是 Warning，nginx 进程挂了是 High，机房断网导致大面积主机不可达才是 Disaster。级别不合理的告警体系，等于没有告警体系。

5. 生产环境避坑：备份、性能与经典报错排查

5.1 数据备份与恢复：定期 pg_dump

监控平台最不能丢的是数据库里的历史数据和配置。容器跑起来之后，备份方案很简单，用 PostgreSQL 官方工具在容器里直接导出：

docker exec zbx-postgres pg_dump -U zabbix -d zabbix | gzip > /backup/zabbix_backup_$(date +%F).sql.gz

这条命令把整个zabbix库导出并压缩到宿主机/backup目录下。配合 crontab 每天凌晨跑一次，保留最近 30 天，基本就能覆盖日常需求。恢复也不难：

gunzip -c zabbix_backup_2025-01-01.sql.gz | docker exec -i zbx-postgres psql -U zabbix -d zabbix

这里有一个重要提醒：恢复后如果版本不一致，比如从 6.0 的备份恢复到 7.0，很可能因为数据库 schema 结构变化导致 Web 报错。跨大版本升级，正确做法是先在新版本环境里跑一遍备份恢复的演练，确认没问题再动生产。

5.2 性能与资源限制调优

监控平台本身也是服务，不能让它把自己所在的宿主机吃垮。compose 文件里可以给每个服务加上资源限制：

deploy: resources: limits: cpus: '2' memory: 1G

这行配置放在服务定义下，配合restart: always，可以把容器对宿主机的影响控制在预设范围内。另外，容器日志默认是用 docker 的 json-file 驱动，长期不清理会越来越大，建议在 compose 的每个服务里加上：

logging: driver: json-file options: max-size: "50m" max-file: "3"

数据量大的场景，还要关注 Zabbix 内部的缓存参数。在 Server 容器的环境变量里可以设置CacheSize、HistoryCacheSize、TrendCacheSize等，比如：

environment: - CacheSize=128M - HistoryCacheSize=64M - TrendCacheSize=64M

我把这组参数理解为 Zabbix 自己的“内存缓冲池”：采集到的数据先攒在内存里，再批量写入数据库。监控主机多、指标密的话，默认值会不够用，日志里会出现cache allocation failed的报错。调参没有标准答案，按主机数量和监控项规模逐步加大即可，改完重启 Server 容器生效。

5.3 经典报错排查实录：server is not running、access denied、不出数

这部分我把这些年遇到的高频问题整理成速查表，每一个都是真实场景：

这里多说一句那个Zabbix server is not running，它不一定是 Server 真的挂了。Zabbix Web 每 5 秒会请求一次 Server 内部的状态页，只要 Web 容器和 Server 容器之间网络不通，哪怕 Server 本身活得好好的，也会提示这个。所以排查第一步永远是看容器网络，而不是重启。

5.4 事后再看：几个值得尽早养成的习惯

平台跑顺之后，有几件事是我每做一个新环境都会提醒自己先做好的。

容器命名和网络规划要统一。compose 里container_name我习惯用zbx-前缀统一命名，配合端口映射表写进项目 README，这样半年后回来维护，光看名字就知道每个容器是干嘛的。监控平台最容易坏的地方往往不是 Zabbix 本身，而是“没人记得它当初是怎么搭的”。

升级前永远先备份、先做小范围验证。我见过太多人直接docker compose pull && docker compose up -d，结果 Zabbix 跨大版本升级后数据库迁移失败，整个平台起不来。正确的做法永远是：备份数据库 -> 在测试环境验证 -> 再升级生产。

最后，记得定期检查监控平台自身的健康状况。Zabbix 有个内置的Zabbix server主机，默认会监控自己，我在上面额外加了一个触发器：如果zabbix[queue]这个 key 的延迟数量超过预期值，说明采集任务堆积，就该扩容或者优化了。连监控平台自己都监控不住，那就谈不上企业级监控了。我个人的经验是，这套 Docker 部署方式跑了两三年都很稳，真正的功夫都花在“接入更多场景”和“让告警更聪明”上，这些内容以后有机会再单独聊聊。