简介面向需要快速搭建Zabbix监控系统的运维与开发人员这份资源包提供基于Docker的两种安装方案一种通过Docker Compose编排Zabbix服务器、MySQL数据库与前端服务另一种借助宝塔面板数据库创建容器。两种方式均覆盖环境变量、端口映射等关键配置并附有相应配置文件与命令参考适合有Docker基础或已使用宝塔面板的用户直接对照部署。资源包共5个文件包含YAML编排文件、Markdown说明文档、HTML示例页面及配套的gitignore与inscode配置文件压缩包仅11KB体量轻且结构清晰便于快速查阅。目前已有45人学习使用。此外Zabbix无需在被监控设备安装客户端即可对网络服务、服务器资源进行实时监控与告警资源重点演示如何在容器环境中落地这一能力对希望提升IT运维效率的团队或个人有直接参考价值。1. 为什么我劝你用 Docker 装 Zabbix先跑通再谈调优接手一台要上监控的机器最花时间的往往不是 Zabbix 本身而是它背后那一串依赖数据库版本、PHP 扩展、时区、字体、Web 服务配置。手动编译或者用包管理器装任何一个环节不对装完开机就是黑匣子报错全靠猜。我现在的习惯是用 Docker 装 Zabbix核心理由只有一个把环境问题关进容器里让 Zabbix 的安装从「操作系统适配题」变成「参数填空题」。尤其适合三到五百台设备的小规模监控起步或是在测试环境快速验证模板和告警策略。本文按 Zabbix 7.0 LTS 的容器化部署来讲新手跟完能跑出一套可用的监控老手能直接拿去对照各版本差异和排错思路。这套排查路径我反复用过下面直接落到 compose 文件和参数上。2. 镜像选型与版本锁定两个官方镜像就够了2.1 选型理由为什么用 zabbix-server-mysql 而不是 all-in-oneDocker 安装 Zabbix 的常见做法是拆四个容器数据库、服务端、Web 前端、Agent。官方镜像按数据库分了两类名称zabbix/zabbix-server-mysql和zabbix/zabbix-server-pgsql选型上我一般建议先用 MySQL 8.0 而不是 PostgreSQL不是因为性能差异多大而是 Zabbix 的模板、分区脚本和第三方工具对 MySQL 的兼容资料更全遇到问题搜得到答案。Agent 端单独讲一下zabbix/zabbix-agent是官方维护的主动采集端点需要在每台被监控的机器上起一个。如果你监控的是容器本身还可以用zabbix/zabbix-agent2它支持通过插件采集 Docker 的 CPU、内存和网络指标一个容器解决整台主机加容器的监控不用在宿主机额外装东西。版本锁定上因为latest标签会跨大版本漂移生产环境必须指定具体版本号。我用的是zabbix/zabbix-server-mysql:7.0-ubuntu-1这一串 tag其中 7.0 是 LTS 版本ubuntu 表示基础镜像最后的数字表示该镜像的修订版。这个 tag 在官方 Docker Hub 上能查到锁死之后docker compose pull不会因为「昨天还能用今天直接拉了个新版」导致配置不兼容。2.2 编排文件网络、依赖与持久化一次说清我习惯把整套监控放在一个独立的 compose 项目里用docker compose管理而不是一条条docker run去拼。原因很直接多容器场景下 compose 能把网络别名、启动顺序和存储卷一次性定义清楚重启机器后一条up -d全部恢复。下面的docker-compose.yml是我在生产常用的精简版去掉了与业务无关的注释直接可抄。services: mysql: image: mysql:8.0 container_name: zabbix-mysql environment: MYSQL_DATABASE: zabbix MYSQL_USER: zabbix MYSQL_PASSWORD: zabbix_pwd MYSQL_ROOT_PASSWORD: root_pwd volumes: - ./data/mysql:/var/lib/mysql - ./backup/init:/docker-entrypoint-initdb.d:ro command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_bin - --default-authentication-pluginmysql_native_password healthcheck: test: [CMD, mysqladmin, ping, -h, 127.0.0.1, -proot_pwd] interval: 10s timeout: 5s retries: 10 restart: unless-stopped zabbix-server: image: zabbix/zabbix-server-mysql:7.0-ubuntu-1 container_name: zabbix-server environment: DB_SERVER_HOST: mysql DB_SERVER_PORT: 3306 MYSQL_DATABASE: zabbix MYSQL_USER: zabbix MYSQL_PASSWORD: zabbix_pwd ZBX_JAVAGATEWAY: java-gateway ports: - 10051:10051 depends_on: mysql: condition: service_healthy restart: unless-stopped zabbix-web: image: zabbix/zabbix-web-nginx-mysql:7.0-ubuntu-1 container_name: zabbix-web environment: ZBX_SERVER_HOST: zabbix-server DB_SERVER_HOST: mysql MYSQL_DATABASE: zabbix MYSQL_USER: zabbix MYSQL_PASSWORD: zabbix_pwd PHP_TZ: Asia/Shanghai ZBX_MEMORYLIMIT: 256M ports: - 8080:8080 depends_on: zabbix-server: condition: service_started restart: unless-stopped java-gateway: image: zabbix/zabbix-java-gateway:7.0-ubuntu-1 container_name: zabbix-java-gateway restart: unless-stopped zabbix-agent: image: zabbix/zabbix-agent:7.0-ubuntu-1 container_name: zabbix-agent environment: ZBX_SERVER_HOST: zabbix-server ZBX_HOSTNAME: Zabbix server ports: - 10050:10050 depends_on: - zabbix-server restart: unless-stopped这段编排文件的逻辑分成三层。第一层是数据库MySQL 通过环境变量初始化库和账号utf8mb4_bin排序规则解决中文乱码和告警信息截断问题。第二层是服务端Zabbix Server 只做了三件事连数据库、监听 10051 端口收数据、把 Java 网关地址指过去。第三层是 Web 前端和 AgentWeb 通过ZBX_SERVER_HOST找到服务端Agent 做的是「监控 Zabbix Server 容器自身」的演示场景方便你验证链路通没通。参数上要解释三个关键点。MYSQL_DEFAULT_AUTHENTICATION_PLUGIN设为mysql_native_password是因为 Zabbix 7.0 的 PHP 连接层对 MySQL 8.0 默认的 caching_sha2_password 兼容性不理想换成旧认证插件能省去很多「数据库连接成功但前端报密码错误」的玄学故障。PHP_TZ不设的话Web 界面里的时间和告警时间会偏离北京时间而且这个偏差会直接落进数据库的历史表报警时差最坑。ZBX_MEMORYLIMIT默认 128M 在仪表盘加载大量图形时不够用调到 256M 比较稳。2.3 拉起前的检查端口、时区与目录权限docker compose up -d之前先花两分钟检查宿主机环境能避免八成启动失败问题。先看端口占用情况10051 是 Server 收数据端口10050 是 Agent 端口8080 是 Web 端口任何一个被占用容器都起不来或起了一半。ss -lntp | grep -E 10050|10051|8080然后确认./data/mysql目录存在且有权限。很多新手第一次部署时忘记mkdir -p ./data/mysqlDocker 会自动创建但目录属主是 rootMySQL 容器内的 mysql 用户写不进去表现为容器反复重启。mkdir -p ./data/mysql chown -R 999:999 ./data/mysql这里999:999是 MySQL 容器内 8.0 版本 mysql 用户的 UID:GID不同版本的 MySQL 可能不同如果你用的 MySQL 5.7则用999:999也通用因为官方镜像保持了这一约定。检查完后执行docker compose up -d容器起来后要做的第一件事不是马上开浏览器而是查健康状态。MySQL 容器带 healthcheck 的等docker compose ps里显示 healthy 再继续。若 MySQL 一直处于 starting多半是command里字符集参数写错或者init目录下的 SQL 脚本有语法错误。3. 走通 Web 初始化时区、中文和第一个主机3.1 前端初始化向导的四个字段浏览器访问http://服务器IP:8080Zabbix 7.0 会直接进入初始化向导而不是登录页。这个向导一路 Next 基本不会出错真正要留神的是中间那步数据库连接信息。它会要求你填数据库地址、端口、库名和账号密码这里填的不是宿主机 IP而是 compose 里的服务名mysql端口写 3306库名和密码对应.env里的MYSQL_USER和MYSQL_PASSWORD。为什么强调这一点因为如果你填了127.0.0.1前端容器会去连自己的回环地址等于连空气这个坑在论坛里出现的频率极高。初始化完成后默认账号是Admin密码zabbix。登录后第一件事建议把Administration下的用户密码换掉同时把默认的「Guest access」关闭。这个操作和安全性相关不做的话你能看到这张监控页面的任何人也能看到拓扑和数据。3.2 中文界面与「方框」字体问题中文包在 Zabbix 7.0 镜像里默认不带需要在 Web 界面里下载并启用。路径是Administration - General - Users - Language在里面勾选 Chinese (zh_CN)然后回到用户 Profile 把语言切到中文。但如果你没有提前装字体中文会显示成一个个方框也就是很多人说的「Zabbix 中文方框问题」。这个现象在不同版本里表现一样根因是容器里缺少中文字体浏览器渲染 PDF 或图片图表时找不到字形只能回退成方块。解决方法是进入 Web 容器内部安装字体然后让图表重新生成。docker exec -it zabbix-web bashapt-get update apt-get install -y fonts-noto-cjkdocker restart zabbix-web安装fonts-noto-cjk是 Noto CJK 字体覆盖中文简体、繁体和日文汉字。重启后老图表的缓存还会显示方框此时到仪表盘随便拖动一下时间范围强制重新出图中文就正常了。这个过程中不需要碰 Zabbix 配置只需要容器里多了字体文件。3.3 添加第一台被监控主机Agent 主动模式是最快验证路径Web 界面能打开后先不急着把线上服务接进来而是把 compose 里那个自带 agent 容器加为监控目标。路径是Data collection - Hosts - Create host主机名填Zabbix server它必须和 agent 容器的ZBX_HOSTNAME环境变量一致不然 Agent 会把数据归属到别的名字下Server 端会一直报 Host not found。添加主机时Interfaces里选 AgentIP 写成zabbix-agent。因为在同一个 compose 网络里服务名就是 DNS 名直接写容器名即可不需要写宿主机 IP。否则你在填127.0.0.1或是宿主机 IP 时就会碰到「能 ping 通但 Agent 显示不可达」的怪问题——因为 Server 进程在容器里用网络连接 Agent 的 10050 端口走的是容器网络而非宿主机网络。Templates里选择Linux by Zabbix agent。保存后观察Availability列如果出现绿色 ZBX 图标说明从 Server 到 Agent 的链路已经通了。采集数据在Monitoring - Latest data里能看到主机名选刚建的指标列表往下拉CPU 和内存监控项会以绿色Enabled显示。4. Zabbix 安装避坑五个我反复遇到的故障4.1 数据库迁移失败setup 后页面一直转圈现象初始化向导最后一步「Save configuration」转了很久最终超时返回 500 错误。再刷新页面可能提示「Zabbix Server is not running」。原因这套镜像的 Web 容器在初始化时会执行数据库 schema 导入整个导入过程可能持续几十秒到几分钟。Web 容器的 PHP 脚本执行时间默认较短导入没跑完就被切断了。解决临时调大 PHP 脚本超时时间。编辑 Web 容器的环境变量在docker-compose.yml的 zabbix-web 服务下加一项environment: - ZBX_TIMEOUT300然后docker compose up -d重新创建容器再访问初始化向导跑一遍。如果已经卡在一个坏状态把 Web 容器和数据卷都删了重来docker compose down -v rm -rf ./data/mysql注意down -v会连存储卷一起删执行前确定不需要保留历史监控数据。4.2 Server 日志报错Database is down现象docker compose logs zabbix-server里循环打印Cannot connect to the database或者Database is down但 MySQL 容器明明是 healthy。原因最常见的是DB_SERVER_HOST写成了127.0.0.1或者 compose 里 MySQL 服务名改过但 Server 端没同步。另一个坑是 Server 容器和 MySQL 容器不在同一网络里比如你是不是把两个服务分别up过使它们各自被分到了不同 network。解决我一般直接在docker-compose.yml里用服务名互相引用并强制给所有服务加同一段网络定义networks: default: name: zabbix-net然后在每个服务下面加一行networks: [zabbix-net]。这样不管怎么重启容器都在同一张网卡上DNS 解析不会出幺蛾子。4.3 Agent 的状态是红色点进去提示 Connection refused现象主机列表里 ZBX 图标变红zabbix_get -s IP -p 10050 -k agent.ping也拿不到数据。原因多数情况不是 Zabbix 的问题而是被监控机器的防火墙没放行 10050 端口。Docker 容器里的 Agent 如果是在宿主机上起的还要确认端口有没有映射出来。解决先分三层排查# 第一层容器本身端口是否有监听 docker exec zabbix-agent netstat -lntp # 第二层宿主机端口映射是否生效 ss -lntp | grep 10050 # 第三层从 Server 容器内实测 docker exec zabbix-server bash -c exec 3/dev/tcp/zabbix-agent/10050 echo ok第三层能通而前端红问题一定出在主机名或模板上回到 3.3 核对ZBX_HOSTNAME是否和前端一致。4.4 中文图表里有大量方框现象Web 界面刚切中文时页面文字几乎全正常但图形里的中文、监控项名称里的中文变成方框。原因7.0 镜像和 7.4 镜像都有这个问题根因是基础镜像里只装了英文字体没有中文字体包。图形渲染用的是 GD 库的 imagettftext找不到可用字体时直接输出占位符。解决按 3.2 装fonts-noto-cjk并在docker-compose.yml里固化这一层保证重启不丢zabbix-web: image: zabbix/zabbix-web-nginx-mysql:7.0-ubuntu-1 command: sh -c apt-get update apt-get install -y fonts-noto-cjk /usr/bin/tini -- /usr/bin/docker-entrypoint.sh这个方案比每次手动进容器装字体省事得多但每次镜像更新后需要重新执行。4.5 Java 网关监控不了 JMXServer 日志提示 unknown host现象用Zabbix Java gateway监控 Tomcat 的 JMX 指标主机状态一直为灰色zabbix-server日志中出现Unable to connect to [java-gateway:10052].原因ZBX_JAVAGATEWAY环境变量只定义了主机名没有把 Java 网关的端口告诉 Server。默认端口是 10052但如果你没有显式设置Server 会按默认的 10052 去连而你的网关容器可能没放端口或者容器启动后 IP 变了。解决在三处同步检查。第一处是 Server 的环境变量environment: ZBX_JAVAGATEWAY: java-gateway ZBX_JAVAGATEWAY_PORT: 10052第二处是 Java 网关容器的端口映射java-gateway: ports: - 10052:10052第三处是在被监控主机的 JMX 接口里确认com.sun.management.jmxremote.port设到了正确端口且防火墙允许 Zabbix Server 所在机器访问。5. 从单机到分布式Proxy 节点与数据库外部化路径5.1 什么场景下必须上 Proxy单机 Docker 部署的 Zabbix 适合小规模监控但一旦设备超过二百台或者存在跨机房、弱网环境单 Server 的采集压力会迅速上来。Server 每个监控项按独立周期去连 Agent大量主机网络抖动时Server 的history syncer进程会积压队列前端看到的数据开始延迟。Zabbix 的应对方案是上 Proxy它只负责从 Agent 收数据、缓存、再转发给 Server网络断开时数据先本地存恢复后补送。Proxy 不是可有可无的功能而是 Zabbix 官方推荐的扩展路径。部署 Proxy 的机器不一定要很高配CPU 两核、内存 4G 就够支撑一千台设备的采集任务真正吃资源的是数据库和 Server 端的处理进程。5.2 Proxy 容器编排与注册步骤Proxy 是一个独立容器用 compose 单独管理。它需要自己的数据库用于本地缓存通常用 SQLite 就够不需要再起一个 MySQL 容器这能省不少资源。下面是 Proxy 的最小编排services: zabbix-proxy: image: zabbix/zabbix-proxy-sqlite3:7.0-ubuntu-1 container_name: zabbix-proxy hostname: zabbix-proxy environment: ZBX_SERVER_HOST: 10.0.0.10 ZBX_SERVER_PORT: 10051 ZBX_HOSTNAME: proxy-01 ZBX_CONFIGFREQUENCY: 600 ports: - 10051:10051 volumes: - ./data/proxy:/var/lib/zabbix restart: unless-stopped起 Proxy 容器前先到 Zabbix Server 前端Data collection - Proxies - Create proxy填入 proxy-01 作为 Proxy name类型选 Active。如果类型选成 PassiveServer 会主动连 Proxy 的 10051 端口去拿数据那端口映射就必须对外暴露。而 Active 模式下 Proxy 会主动回连 Server防火墙只需要放行 Proxy 到 Server 的出站方向部署上省事得多。Proxy 起来之后把原本直连 Server 的主机从Hosts的Monitored by proxy下拉改成 proxy-01。之后该主机的采集流量转向 ProxyServer 端依旧能看到完整数据这个过程不需要重启 Server但替代「修改 DNS 或 IP」这类需要通知运维的操作前建议在非业务高峰做。5.3 数据库和 Server 的多节点取向如果监控规模到了上千台MySQL 单库的性能瓶颈就会出现常见表现是历史表太大、housekeeper清理变慢、前端图表加载开始卡顿。此时常见的演进路径是把 MySQL 换成 PostgreSQL或者把 MySQL 数据目录挪到 SSD 独立磁盘阵列。我个人在这里的建议是先不要急着拆服务先把历史数据表按天分区观察 housekeeper 有没有跟上。分区策略没做好的情况下换 PostgreSQL 也只能缓解一时因为瓶颈在服务器的 IO 而不是数据库引擎本身。另一个被问得多的方向是 Zabbix Server 多节点冗余。Zabbix 官方支持多个 Server 共享同一数据库实现前端会话的负载均衡但要注意这套方案不解决历史数据写入冲突。需要真正高可用时通常是把 Server 做成主备模式数据库做同步复制备机冷待命。在没踩过生产事故之前我建议先做监控数据定期备份而不是挣扎于双活架构因为很多团队连监控本身的 SLA 要求都没定义过。6. 安装完成后的验证清单三天后不慌的前提安装完成不等于交付完成。我会在部署后连续观察三天重点看三件事第一是Monitoring - Latest data里每个关键主机的数据是否有缺口第二是Reports - Availability report中可用性百分比第三是数据库连接日志里有没有持续报错。这套习惯帮我抓出过不少「当时一切正常第二天数据断档」的问题具体表现为 Agent 容器因内存不足被 OOM Kill或者某个告警器在深夜重启后没有自动拉起。验证高频告警链路是否通可以在 Server 容器里手动触发一条测试告警。下面是在 SQLite/MySQL 里插入一条模拟事件的行然后检查前端Monitoring - Problems是否出现INSERT INTO zabbix.events (eventid, source, object, objectid, value, clock) VALUES (999999, 0, 1, 10084, 1, UNIX_TIMESTAMP());前端页面里把Problems的筛选时间切到「Last 15 minutes」看这条事件是否出现。出现则说明从 DB 到前端的链路正常。然后再用告警媒介把同一事件发到告警接收端验证整个告警链路不只是在数据库里打了个洞。如果你还没有配通知渠道至少要先把Administration - Media types里的脚本告警通道测通。最后一条习惯是监控的监控给 Zabbix Server 容器本身加一个system.cpu.load和vfs.fs.size[/var/lib/zabbix,free]的告警阈值磁盘满导致历史数据写不进去是 Zabbix 部署后最常见的翻车原因。提前把这条设好至少不会在一个月后发现自己丢了好几天的数据才回头去查 housekeeper。这些参数不是每次部署都需要一模一样但每次都按这套路径过一遍能让我在接手的下一套环境里少踩一半的坑。希望帮到你。本文还有配套的精品资源点击获取
Docker 部署 Zabbix 7.0：compose 编排、避坑与监控扩展
简介面向需要快速搭建Zabbix监控系统的运维与开发人员这份资源包提供基于Docker的两种安装方案一种通过Docker Compose编排Zabbix服务器、MySQL数据库与前端服务另一种借助宝塔面板数据库创建容器。两种方式均覆盖环境变量、端口映射等关键配置并附有相应配置文件与命令参考适合有Docker基础或已使用宝塔面板的用户直接对照部署。资源包共5个文件包含YAML编排文件、Markdown说明文档、HTML示例页面及配套的gitignore与inscode配置文件压缩包仅11KB体量轻且结构清晰便于快速查阅。目前已有45人学习使用。此外Zabbix无需在被监控设备安装客户端即可对网络服务、服务器资源进行实时监控与告警资源重点演示如何在容器环境中落地这一能力对希望提升IT运维效率的团队或个人有直接参考价值。1. 为什么我劝你用 Docker 装 Zabbix先跑通再谈调优接手一台要上监控的机器最花时间的往往不是 Zabbix 本身而是它背后那一串依赖数据库版本、PHP 扩展、时区、字体、Web 服务配置。手动编译或者用包管理器装任何一个环节不对装完开机就是黑匣子报错全靠猜。我现在的习惯是用 Docker 装 Zabbix核心理由只有一个把环境问题关进容器里让 Zabbix 的安装从「操作系统适配题」变成「参数填空题」。尤其适合三到五百台设备的小规模监控起步或是在测试环境快速验证模板和告警策略。本文按 Zabbix 7.0 LTS 的容器化部署来讲新手跟完能跑出一套可用的监控老手能直接拿去对照各版本差异和排错思路。这套排查路径我反复用过下面直接落到 compose 文件和参数上。2. 镜像选型与版本锁定两个官方镜像就够了2.1 选型理由为什么用 zabbix-server-mysql 而不是 all-in-oneDocker 安装 Zabbix 的常见做法是拆四个容器数据库、服务端、Web 前端、Agent。官方镜像按数据库分了两类名称zabbix/zabbix-server-mysql和zabbix/zabbix-server-pgsql选型上我一般建议先用 MySQL 8.0 而不是 PostgreSQL不是因为性能差异多大而是 Zabbix 的模板、分区脚本和第三方工具对 MySQL 的兼容资料更全遇到问题搜得到答案。Agent 端单独讲一下zabbix/zabbix-agent是官方维护的主动采集端点需要在每台被监控的机器上起一个。如果你监控的是容器本身还可以用zabbix/zabbix-agent2它支持通过插件采集 Docker 的 CPU、内存和网络指标一个容器解决整台主机加容器的监控不用在宿主机额外装东西。版本锁定上因为latest标签会跨大版本漂移生产环境必须指定具体版本号。我用的是zabbix/zabbix-server-mysql:7.0-ubuntu-1这一串 tag其中 7.0 是 LTS 版本ubuntu 表示基础镜像最后的数字表示该镜像的修订版。这个 tag 在官方 Docker Hub 上能查到锁死之后docker compose pull不会因为「昨天还能用今天直接拉了个新版」导致配置不兼容。2.2 编排文件网络、依赖与持久化一次说清我习惯把整套监控放在一个独立的 compose 项目里用docker compose管理而不是一条条docker run去拼。原因很直接多容器场景下 compose 能把网络别名、启动顺序和存储卷一次性定义清楚重启机器后一条up -d全部恢复。下面的docker-compose.yml是我在生产常用的精简版去掉了与业务无关的注释直接可抄。services: mysql: image: mysql:8.0 container_name: zabbix-mysql environment: MYSQL_DATABASE: zabbix MYSQL_USER: zabbix MYSQL_PASSWORD: zabbix_pwd MYSQL_ROOT_PASSWORD: root_pwd volumes: - ./data/mysql:/var/lib/mysql - ./backup/init:/docker-entrypoint-initdb.d:ro command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_bin - --default-authentication-pluginmysql_native_password healthcheck: test: [CMD, mysqladmin, ping, -h, 127.0.0.1, -proot_pwd] interval: 10s timeout: 5s retries: 10 restart: unless-stopped zabbix-server: image: zabbix/zabbix-server-mysql:7.0-ubuntu-1 container_name: zabbix-server environment: DB_SERVER_HOST: mysql DB_SERVER_PORT: 3306 MYSQL_DATABASE: zabbix MYSQL_USER: zabbix MYSQL_PASSWORD: zabbix_pwd ZBX_JAVAGATEWAY: java-gateway ports: - 10051:10051 depends_on: mysql: condition: service_healthy restart: unless-stopped zabbix-web: image: zabbix/zabbix-web-nginx-mysql:7.0-ubuntu-1 container_name: zabbix-web environment: ZBX_SERVER_HOST: zabbix-server DB_SERVER_HOST: mysql MYSQL_DATABASE: zabbix MYSQL_USER: zabbix MYSQL_PASSWORD: zabbix_pwd PHP_TZ: Asia/Shanghai ZBX_MEMORYLIMIT: 256M ports: - 8080:8080 depends_on: zabbix-server: condition: service_started restart: unless-stopped java-gateway: image: zabbix/zabbix-java-gateway:7.0-ubuntu-1 container_name: zabbix-java-gateway restart: unless-stopped zabbix-agent: image: zabbix/zabbix-agent:7.0-ubuntu-1 container_name: zabbix-agent environment: ZBX_SERVER_HOST: zabbix-server ZBX_HOSTNAME: Zabbix server ports: - 10050:10050 depends_on: - zabbix-server restart: unless-stopped这段编排文件的逻辑分成三层。第一层是数据库MySQL 通过环境变量初始化库和账号utf8mb4_bin排序规则解决中文乱码和告警信息截断问题。第二层是服务端Zabbix Server 只做了三件事连数据库、监听 10051 端口收数据、把 Java 网关地址指过去。第三层是 Web 前端和 AgentWeb 通过ZBX_SERVER_HOST找到服务端Agent 做的是「监控 Zabbix Server 容器自身」的演示场景方便你验证链路通没通。参数上要解释三个关键点。MYSQL_DEFAULT_AUTHENTICATION_PLUGIN设为mysql_native_password是因为 Zabbix 7.0 的 PHP 连接层对 MySQL 8.0 默认的 caching_sha2_password 兼容性不理想换成旧认证插件能省去很多「数据库连接成功但前端报密码错误」的玄学故障。PHP_TZ不设的话Web 界面里的时间和告警时间会偏离北京时间而且这个偏差会直接落进数据库的历史表报警时差最坑。ZBX_MEMORYLIMIT默认 128M 在仪表盘加载大量图形时不够用调到 256M 比较稳。2.3 拉起前的检查端口、时区与目录权限docker compose up -d之前先花两分钟检查宿主机环境能避免八成启动失败问题。先看端口占用情况10051 是 Server 收数据端口10050 是 Agent 端口8080 是 Web 端口任何一个被占用容器都起不来或起了一半。ss -lntp | grep -E 10050|10051|8080然后确认./data/mysql目录存在且有权限。很多新手第一次部署时忘记mkdir -p ./data/mysqlDocker 会自动创建但目录属主是 rootMySQL 容器内的 mysql 用户写不进去表现为容器反复重启。mkdir -p ./data/mysql chown -R 999:999 ./data/mysql这里999:999是 MySQL 容器内 8.0 版本 mysql 用户的 UID:GID不同版本的 MySQL 可能不同如果你用的 MySQL 5.7则用999:999也通用因为官方镜像保持了这一约定。检查完后执行docker compose up -d容器起来后要做的第一件事不是马上开浏览器而是查健康状态。MySQL 容器带 healthcheck 的等docker compose ps里显示 healthy 再继续。若 MySQL 一直处于 starting多半是command里字符集参数写错或者init目录下的 SQL 脚本有语法错误。3. 走通 Web 初始化时区、中文和第一个主机3.1 前端初始化向导的四个字段浏览器访问http://服务器IP:8080Zabbix 7.0 会直接进入初始化向导而不是登录页。这个向导一路 Next 基本不会出错真正要留神的是中间那步数据库连接信息。它会要求你填数据库地址、端口、库名和账号密码这里填的不是宿主机 IP而是 compose 里的服务名mysql端口写 3306库名和密码对应.env里的MYSQL_USER和MYSQL_PASSWORD。为什么强调这一点因为如果你填了127.0.0.1前端容器会去连自己的回环地址等于连空气这个坑在论坛里出现的频率极高。初始化完成后默认账号是Admin密码zabbix。登录后第一件事建议把Administration下的用户密码换掉同时把默认的「Guest access」关闭。这个操作和安全性相关不做的话你能看到这张监控页面的任何人也能看到拓扑和数据。3.2 中文界面与「方框」字体问题中文包在 Zabbix 7.0 镜像里默认不带需要在 Web 界面里下载并启用。路径是Administration - General - Users - Language在里面勾选 Chinese (zh_CN)然后回到用户 Profile 把语言切到中文。但如果你没有提前装字体中文会显示成一个个方框也就是很多人说的「Zabbix 中文方框问题」。这个现象在不同版本里表现一样根因是容器里缺少中文字体浏览器渲染 PDF 或图片图表时找不到字形只能回退成方块。解决方法是进入 Web 容器内部安装字体然后让图表重新生成。docker exec -it zabbix-web bashapt-get update apt-get install -y fonts-noto-cjkdocker restart zabbix-web安装fonts-noto-cjk是 Noto CJK 字体覆盖中文简体、繁体和日文汉字。重启后老图表的缓存还会显示方框此时到仪表盘随便拖动一下时间范围强制重新出图中文就正常了。这个过程中不需要碰 Zabbix 配置只需要容器里多了字体文件。3.3 添加第一台被监控主机Agent 主动模式是最快验证路径Web 界面能打开后先不急着把线上服务接进来而是把 compose 里那个自带 agent 容器加为监控目标。路径是Data collection - Hosts - Create host主机名填Zabbix server它必须和 agent 容器的ZBX_HOSTNAME环境变量一致不然 Agent 会把数据归属到别的名字下Server 端会一直报 Host not found。添加主机时Interfaces里选 AgentIP 写成zabbix-agent。因为在同一个 compose 网络里服务名就是 DNS 名直接写容器名即可不需要写宿主机 IP。否则你在填127.0.0.1或是宿主机 IP 时就会碰到「能 ping 通但 Agent 显示不可达」的怪问题——因为 Server 进程在容器里用网络连接 Agent 的 10050 端口走的是容器网络而非宿主机网络。Templates里选择Linux by Zabbix agent。保存后观察Availability列如果出现绿色 ZBX 图标说明从 Server 到 Agent 的链路已经通了。采集数据在Monitoring - Latest data里能看到主机名选刚建的指标列表往下拉CPU 和内存监控项会以绿色Enabled显示。4. Zabbix 安装避坑五个我反复遇到的故障4.1 数据库迁移失败setup 后页面一直转圈现象初始化向导最后一步「Save configuration」转了很久最终超时返回 500 错误。再刷新页面可能提示「Zabbix Server is not running」。原因这套镜像的 Web 容器在初始化时会执行数据库 schema 导入整个导入过程可能持续几十秒到几分钟。Web 容器的 PHP 脚本执行时间默认较短导入没跑完就被切断了。解决临时调大 PHP 脚本超时时间。编辑 Web 容器的环境变量在docker-compose.yml的 zabbix-web 服务下加一项environment: - ZBX_TIMEOUT300然后docker compose up -d重新创建容器再访问初始化向导跑一遍。如果已经卡在一个坏状态把 Web 容器和数据卷都删了重来docker compose down -v rm -rf ./data/mysql注意down -v会连存储卷一起删执行前确定不需要保留历史监控数据。4.2 Server 日志报错Database is down现象docker compose logs zabbix-server里循环打印Cannot connect to the database或者Database is down但 MySQL 容器明明是 healthy。原因最常见的是DB_SERVER_HOST写成了127.0.0.1或者 compose 里 MySQL 服务名改过但 Server 端没同步。另一个坑是 Server 容器和 MySQL 容器不在同一网络里比如你是不是把两个服务分别up过使它们各自被分到了不同 network。解决我一般直接在docker-compose.yml里用服务名互相引用并强制给所有服务加同一段网络定义networks: default: name: zabbix-net然后在每个服务下面加一行networks: [zabbix-net]。这样不管怎么重启容器都在同一张网卡上DNS 解析不会出幺蛾子。4.3 Agent 的状态是红色点进去提示 Connection refused现象主机列表里 ZBX 图标变红zabbix_get -s IP -p 10050 -k agent.ping也拿不到数据。原因多数情况不是 Zabbix 的问题而是被监控机器的防火墙没放行 10050 端口。Docker 容器里的 Agent 如果是在宿主机上起的还要确认端口有没有映射出来。解决先分三层排查# 第一层容器本身端口是否有监听 docker exec zabbix-agent netstat -lntp # 第二层宿主机端口映射是否生效 ss -lntp | grep 10050 # 第三层从 Server 容器内实测 docker exec zabbix-server bash -c exec 3/dev/tcp/zabbix-agent/10050 echo ok第三层能通而前端红问题一定出在主机名或模板上回到 3.3 核对ZBX_HOSTNAME是否和前端一致。4.4 中文图表里有大量方框现象Web 界面刚切中文时页面文字几乎全正常但图形里的中文、监控项名称里的中文变成方框。原因7.0 镜像和 7.4 镜像都有这个问题根因是基础镜像里只装了英文字体没有中文字体包。图形渲染用的是 GD 库的 imagettftext找不到可用字体时直接输出占位符。解决按 3.2 装fonts-noto-cjk并在docker-compose.yml里固化这一层保证重启不丢zabbix-web: image: zabbix/zabbix-web-nginx-mysql:7.0-ubuntu-1 command: sh -c apt-get update apt-get install -y fonts-noto-cjk /usr/bin/tini -- /usr/bin/docker-entrypoint.sh这个方案比每次手动进容器装字体省事得多但每次镜像更新后需要重新执行。4.5 Java 网关监控不了 JMXServer 日志提示 unknown host现象用Zabbix Java gateway监控 Tomcat 的 JMX 指标主机状态一直为灰色zabbix-server日志中出现Unable to connect to [java-gateway:10052].原因ZBX_JAVAGATEWAY环境变量只定义了主机名没有把 Java 网关的端口告诉 Server。默认端口是 10052但如果你没有显式设置Server 会按默认的 10052 去连而你的网关容器可能没放端口或者容器启动后 IP 变了。解决在三处同步检查。第一处是 Server 的环境变量environment: ZBX_JAVAGATEWAY: java-gateway ZBX_JAVAGATEWAY_PORT: 10052第二处是 Java 网关容器的端口映射java-gateway: ports: - 10052:10052第三处是在被监控主机的 JMX 接口里确认com.sun.management.jmxremote.port设到了正确端口且防火墙允许 Zabbix Server 所在机器访问。5. 从单机到分布式Proxy 节点与数据库外部化路径5.1 什么场景下必须上 Proxy单机 Docker 部署的 Zabbix 适合小规模监控但一旦设备超过二百台或者存在跨机房、弱网环境单 Server 的采集压力会迅速上来。Server 每个监控项按独立周期去连 Agent大量主机网络抖动时Server 的history syncer进程会积压队列前端看到的数据开始延迟。Zabbix 的应对方案是上 Proxy它只负责从 Agent 收数据、缓存、再转发给 Server网络断开时数据先本地存恢复后补送。Proxy 不是可有可无的功能而是 Zabbix 官方推荐的扩展路径。部署 Proxy 的机器不一定要很高配CPU 两核、内存 4G 就够支撑一千台设备的采集任务真正吃资源的是数据库和 Server 端的处理进程。5.2 Proxy 容器编排与注册步骤Proxy 是一个独立容器用 compose 单独管理。它需要自己的数据库用于本地缓存通常用 SQLite 就够不需要再起一个 MySQL 容器这能省不少资源。下面是 Proxy 的最小编排services: zabbix-proxy: image: zabbix/zabbix-proxy-sqlite3:7.0-ubuntu-1 container_name: zabbix-proxy hostname: zabbix-proxy environment: ZBX_SERVER_HOST: 10.0.0.10 ZBX_SERVER_PORT: 10051 ZBX_HOSTNAME: proxy-01 ZBX_CONFIGFREQUENCY: 600 ports: - 10051:10051 volumes: - ./data/proxy:/var/lib/zabbix restart: unless-stopped起 Proxy 容器前先到 Zabbix Server 前端Data collection - Proxies - Create proxy填入 proxy-01 作为 Proxy name类型选 Active。如果类型选成 PassiveServer 会主动连 Proxy 的 10051 端口去拿数据那端口映射就必须对外暴露。而 Active 模式下 Proxy 会主动回连 Server防火墙只需要放行 Proxy 到 Server 的出站方向部署上省事得多。Proxy 起来之后把原本直连 Server 的主机从Hosts的Monitored by proxy下拉改成 proxy-01。之后该主机的采集流量转向 ProxyServer 端依旧能看到完整数据这个过程不需要重启 Server但替代「修改 DNS 或 IP」这类需要通知运维的操作前建议在非业务高峰做。5.3 数据库和 Server 的多节点取向如果监控规模到了上千台MySQL 单库的性能瓶颈就会出现常见表现是历史表太大、housekeeper清理变慢、前端图表加载开始卡顿。此时常见的演进路径是把 MySQL 换成 PostgreSQL或者把 MySQL 数据目录挪到 SSD 独立磁盘阵列。我个人在这里的建议是先不要急着拆服务先把历史数据表按天分区观察 housekeeper 有没有跟上。分区策略没做好的情况下换 PostgreSQL 也只能缓解一时因为瓶颈在服务器的 IO 而不是数据库引擎本身。另一个被问得多的方向是 Zabbix Server 多节点冗余。Zabbix 官方支持多个 Server 共享同一数据库实现前端会话的负载均衡但要注意这套方案不解决历史数据写入冲突。需要真正高可用时通常是把 Server 做成主备模式数据库做同步复制备机冷待命。在没踩过生产事故之前我建议先做监控数据定期备份而不是挣扎于双活架构因为很多团队连监控本身的 SLA 要求都没定义过。6. 安装完成后的验证清单三天后不慌的前提安装完成不等于交付完成。我会在部署后连续观察三天重点看三件事第一是Monitoring - Latest data里每个关键主机的数据是否有缺口第二是Reports - Availability report中可用性百分比第三是数据库连接日志里有没有持续报错。这套习惯帮我抓出过不少「当时一切正常第二天数据断档」的问题具体表现为 Agent 容器因内存不足被 OOM Kill或者某个告警器在深夜重启后没有自动拉起。验证高频告警链路是否通可以在 Server 容器里手动触发一条测试告警。下面是在 SQLite/MySQL 里插入一条模拟事件的行然后检查前端Monitoring - Problems是否出现INSERT INTO zabbix.events (eventid, source, object, objectid, value, clock) VALUES (999999, 0, 1, 10084, 1, UNIX_TIMESTAMP());前端页面里把Problems的筛选时间切到「Last 15 minutes」看这条事件是否出现。出现则说明从 DB 到前端的链路正常。然后再用告警媒介把同一事件发到告警接收端验证整个告警链路不只是在数据库里打了个洞。如果你还没有配通知渠道至少要先把Administration - Media types里的脚本告警通道测通。最后一条习惯是监控的监控给 Zabbix Server 容器本身加一个system.cpu.load和vfs.fs.size[/var/lib/zabbix,free]的告警阈值磁盘满导致历史数据写不进去是 Zabbix 部署后最常见的翻车原因。提前把这条设好至少不会在一个月后发现自己丢了好几天的数据才回头去查 housekeeper。这些参数不是每次部署都需要一模一样但每次都按这套路径过一遍能让我在接手的下一套环境里少踩一半的坑。希望帮到你。本文还有配套的精品资源点击获取
