凌晨两点被电话叫醒那边是业务线同事的声音“系统慢得不行了你那边能看到怎么回事吗”我打开电脑发现监控平台根本没报警因为那会儿压根就没有成体系的监控平台。那段经历让我下定决心搞一套像样的环境能覆盖服务器、数据库、网络设备出了问题能主动告诉我而不是等业务方来通知我。最后我选定 Zabbix并且用 Docker 完成了整套部署。这个组合到今天已经跑了不短时间整体非常稳。这篇文章就把整个落地过程拆开来讲包括我为什么选择容器化部署 Zabbix、部署前的规划要点、完整的 docker-compose 配置、主机接入、告警配置以及后面真实环境中踩过的一堆坑。无论你是刚接触 Zabbix还是已经在用但部署方式比较传统想换容器化这篇文章都值得你从头到尾看一遍。1. 为什么我最终放弃传统安装改用 Docker 跑 Zabbix1.1 传统部署的痛点清单Zabbix 本身功能确实强但传统方式部署它体验真的谈不上愉快。我不止一次见过同事在新机器上编译安装 Zabbix Server光依赖环境就折腾了大半天。你需要准备 LAMP 或 LNMP 环境PHP 版本要合适数据库要单独初始化前端需要复制到 Web 目录还要配权限、改时区、调 PHP 参数每一步都藏着版本兼容问题。如果只是装一套自己测试用倒还好说浪费时间但总能跑通。可如果要在开发、测试、生产多套环境里都搞一遍每套环境细微差别都会导致安装过程出现不同报错。更麻烦的是升级Zabbix 大版本升级往往需要先升级数据库结构再升级 Server 程序最后处理前端步骤错了或版本跳了轻则告警异常重则配置丢失。当年我自己在一台 CentOS 7 上编译安装 Zabbix Server编译过程 CPU 跑满等了快二十分钟。那一刻我就在想这种基础设施工具为什么不能像拉镜像一样直接拉起来后来 5.0、6.0 时代官方逐步完善了容器镜像到了现在 7.0 LTSDocker 部署方案已经非常成熟。官网本身就提供了完整的 Docker Compose 示例遇到问题在社区里也基本都能搜到答案再让我回到手工编译的老路我是真不愿意了。1.2 Docker 容器化改变了什么用 Docker 部署 Zabbix最大的感受是“标准化”。Zabbix Server、前端 Web、数据库、Agent 各自跑在独立容器里镜像从哪里来、版本是什么、环境变量怎么配都写死在 docker-compose.yml 文件里。换一台新机器把同一个 compose 文件拉过去执行 docker compose up -d几分钟就是一套一模一样的环境。其次隔离性带来了极大的安全感。以前装 Zabbix Server 要在宿主机装 PHP、装数据库对宿主机现有环境是入侵式的改动很容易影响其他业务。用容器之后所有依赖被打包在镜像内部宿主机只暴露必要端口不想要的组件一律不装干净利落。还有一点很实际迁移和灾备。compose 文件、环境变量、数据卷这些都能纳入版本管理。哪台机器崩了新机器上把 compose 拉下来恢复数据库备份整套监控平台就能继续跑。这个优势在做跨机房迁移或环境复制时尤为明显。1.3 这套架构的适用边界当然容器化部署不是银弹我得说清楚它的边界。如果你的监控规模特别大比如上万台设备、海量指标采集或者对采集时延有极高的要求需要针对操作系统内核参数做深度调优那我建议你还是回退到物理机或虚拟机直接部署 Zabbix Server这样性能上限更高排查链路更简单。但如果你是企业内部常规监控场景规模在一两千台设备以内Docker Compose 这套方案完全够用而且维护成本远低于传统方式。我自己目前这套环境稳定运行下来没什么压力资源占用也很可控。提示Docker 部署适合绝大多数企业环境但任何方案都有取舍。别一上来就追求上千台规模先把核心链路跑顺再慢慢验证容器化方案的承载上限。2. 部署前必须想清楚的三件事镜像选型、数据持久化与网络规划2.1 镜像组合怎么选官方镜像 vs 第三方整合包部署之前首先得选镜像。我强烈建议直接使用 Zabbix 官方镜像而不是网上某些“全家桶”第三方整合包。第三方包虽然看起来一条命令全给你搞定但内部结构不透明出了问题很难排查而且升级路径不清晰容易把自己坑进去。官方镜像主要有这几个核心角色镜像名作用关键点zabbix/zabbix-server-mysqlZabbix Server 主程序存储监控数据、处理告警逻辑通过环境变量连接 MySQLzabbix/zabbix-server-pgsql使用 PostgreSQL 的 Server 版本与 MySQL 版二选一后面会专门讨论zabbix/zabbix-web-nginx-mysqlWeb 前端界面内置 Nginx PHP-FPM是用户日常操作入口zabbix/zabbix-web-nginx-pgsql使用 PostgreSQL 的 Web 版本与上面的 MySQL 版对应zabbix/zabbix-agent2Agent 2.0 版本新版本 Agent支持更多插件推荐使用zabbix/zabbix-java-gatewayJava 网关监控 JMX 应用时必须的中间件我自己的选择是 zabbix-server-mysql 加 zabbix-web-nginx-mysql数据库用 MySQL 8.0Agent 统一使用 zabbix-agent2。这套组合是官方支持度最高、社区使用量最大的路径踩坑时最容易搜到答案。2.2 版本组合逻辑7.0 LTS 还是 6.0 LTSZabbix 的版本策略很清晰LTSLong Term Support版本是生产环境首选。目前 7.0 LTS 已经发布官方会提供多年的安全更新和 Bug 修复适合企业常态化使用。6.0 LTS 虽然还在生命周期内但既然 7.0 已经成熟我建议一步到位直接使用 7.0 LTS。版本选择时还要注意一个原则Zabbix Server、Web、Agent 三者尽量保持大版本一致或者遵循官方兼容性矩阵。比如 Server 和 Web 必须是同一版本Agent 可以存在一定版本跨度但最好也不要跨太多版本否则可能出现监控项兼容性问题。我现在生产环境里跑的就是 7.0 LTS 全家桶Agent 端也是统一 7.0这样无论是模板同步、监控项定义还是告警动作语法都不存在版本差异带来的心智负担。2.3 数据持久化不能让容器重启丢监控数据容器是无状态的这一点必须时刻记住。如果你只是 docker run 一把梭没有挂载数据卷容器一删监控数据、历史趋势图、告警记录、用户配置全部归零这种事故我见过不止一次。所以部署前要规划好三类持久化数据数据库数据目录MySQL/MariaDB 的库文件这是最核心的数据存放在一个独立 volume 或宿主机目录里。Zabbix Server 的配置文件与脚本目录以后要放自定义告警脚本、外部检查脚本必须挂载出来。Web 端自定义资源比如字体文件、自定义 Media 类型脚本也需要挂载目录。我习惯把数据卷显式指向宿主机目录而不是用匿名的 docker volume比如 /data/zabbix/mysql、/data/zabbix/server/alertscripts。这样备份时直接打包目录即可出了问题也更容易定位。2.4 网络与端口规划10051、10050、Web 入口Zabbix 监控体系里端口规划很重要。整理一张表让你看明白端口方向用途10051Agent - ServerAgent 主动上报数据到 Server主动模式10050Server - AgentServer 向 Agent 拉取数据被动模式8080 或 80浏览器 - Web访问 Zabbix Web 前端如果你的监控主机数量不多网络环境比较简单可以在服务器上直接放开 10051 和 10050 端口。如果安全要求严格建议让被监控主机主动连 Server 的 10051 端口也就是使用 Agent 主动模式这样被监控主机不需要开启任何入站端口防火墙策略会简单很多。另外容器默认时区往往是 UTC如果你不管后面看到的数据曲线时间会整体慢 8 小时告警判断也会出现偏差。所以从部署一开始就要把时区环境变量设置成 Asia/Shanghai这个坑我在后面还会详细说。3. 从零搭建docker-compose 部署全过程实录3.1 目录结构准备我习惯在部署前先把目录结构建好这样后续挂载数据卷时路径一目了然。下面以 /data/zabbix 为例mkdir -p /data/zabbix/mysql mkdir -p /data/zabbix/server/alertscripts mkdir -p /data/zabbix/server/externalscripts mkdir -p /data/zabbix/web/fonts mkdir -p /data/zabbix/compose这几个目录分别是MySQL 数据目录、Server 的告警脚本目录、外部检查脚本目录、Web 端字体目录、compose 文件存放目录。提示目录路径你可以自定义但必须保持一致性。后续无论是 compose 文件里的挂载路径还是容器内脚本映射都要以这套目录为准。3.2 编写 docker-compose.yml下面是我实际使用的 docker-compose.yml 核心内容你先看着后面我会逐段解释关键变量。services: mysql: image: mysql:8.0 container_name: zabbix-mysql restart: always environment: MYSQL_ROOT_PASSWORD: root_pwd_2024 MYSQL_DATABASE: zabbix MYSQL_USER: zabbix MYSQL_PASSWORD: zabbix_pwd_2024 command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_bin - --default-authentication-pluginmysql_native_password volumes: - /data/zabbix/mysql:/var/lib/mysql networks: - zbx_net zabbix-server: image: zabbix/zabbix-server-mysql:7.0-ubuntu-latest container_name: zabbix-server restart: always environment: DB_SERVER_HOST: mysql MYSQL_DATABASE: zabbix MYSQL_USER: zabbix MYSQL_PASSWORD: zabbix_pwd_2024 ZBX_JAVAGATEWAY: java-gateway ZBX_STARTPOLLERS: 10 ZBX_CACHESIZE: 128M ZBX_HISTORYCACHESIZE: 64M ZBX_TIMEOUT: 4 ports: - 10051:10051 volumes: - /data/zabbix/server/alertscripts:/usr/lib/zabbix/alertscripts:ro - /data/zabbix/server/externalscripts:/usr/lib/zabbix/externalscripts:ro depends_on: - mysql networks: - zbx_net zabbix-web: image: zabbix/zabbix-web-nginx-mysql:7.0-ubuntu-latest container_name: zabbix-web restart: always environment: ZBX_SERVER_HOST: zabbix-server DB_SERVER_HOST: mysql MYSQL_DATABASE: zabbix MYSQL_USER: zabbix MYSQL_PASSWORD: zabbix_pwd_2024 PHP_TZ: Asia/Shanghai ports: - 8080:8080 depends_on: - zabbix-server - mysql networks: - zbx_net java-gateway: image: zabbix/zabbix-java-gateway:7.0-ubuntu-latest container_name: zabbix-java-gateway restart: always networks: - zbx_net networks: zbx_net: driver: bridge这段配置我做了两处关键设计一是增加了 java-gateway 容器虽然当前不一定马上监控 JMX 应用但提前把网关准备好后续接 Java 应用时不用再单独部署二是给 Server 预先调大了缓存参数避免监控项多起来后频繁触发缓存过小告警。3.3 环境变量与数据库连接的关系很多初学者在部署后遇到 “Zabbix server is not running” 或登录页面报数据库连接错误绝大多数都是环境变量没配对。下面整理一张环境变量说明表把最容易出错的几个点单独拎出来。变量名使用位置含义易错点MYSQL_ROOT_PASSWORDmysql 容器MySQL root 密码只在首次创建容器时生效后续修改无效MYSQL_DATABASEmysql 容器自动创建的数据库名必须与 zabbix-server 里 MYSQL_DATABASE 一致MYSQL_USERmysql 容器创建的业务用户必须与 zabbix-server 里 MYSQL_USER 一致MYSQL_PASSWORDmysql 容器业务用户密码必须与 zabbix-server 里 MYSQL_PASSWORD 一致DB_SERVER_HOSTzabbix-server / zabbix-web数据库地址在 compose 网络里写服务名 mysql不能写 localhostZBX_SERVER_HOSTzabbix-webZabbix Server 地址写服务名 zabbix-server不是 IPPHP_TZzabbix-webWeb 端时区必须设置为 Asia/Shanghai否则图形时间差 8 小时你可能会问为什么 zabbix-server 连接数据库时不写 localhost而要写服务名 mysql因为在 Docker 网络模式下mysql 是一个独立的容器它有自己的 IP。服务名 mysql 会自动被 DNS 解析成对应容器 IP这是 compose 自带的网络发现机制。如果你写成 localhostServer 容器会认为数据库就在自己容器内部自然连不上。3.4 启动、等待与初始化验证配置文件准备好后进入 compose 目录执行启动命令cd /data/zabbix/compose docker compose up -d执行后不建议立刻打开浏览器因为 MySQL 首次初始化需要时间Zabbix Server 也要等数据库 ready 之后才能完成初始化建表。我一般等待 1 到 2 分钟然后检查容器状态docker compose ps如果所有容器状态是 Up再看一下日志确认没有报错docker logs zabbix-server --tail 50如果日志里出现类似 “Cannot connect to MySQL database” 或 “Access denied for user” 的报错请回头核对 3.3 小节的变量一致性。确认一切正常后浏览器访问http://你的服务器IP:8080默认账号是 Admin默认密码是 zabbix。进去后第一件事是修改默认密码这一步不要拖生产环境默认密码是极大的安全隐患。3.5 Web 初始化后第一时间做的事登录成功后不要急着添加主机我建议按下面的顺序先做完基础配置修改 Admin 密码在个人信息里或用户设置中强制改密密码复杂度至少要符合企业安全习惯。切换中文界面右上角用户头像 - User settings - Language 选择 Chinese (zh_CN)保存刷新即可。配置告警介质这一步会放到后面讲但需要有告警接收人所以可以先建一个专用的告警用户。有一点要提醒你Zabbix 7.0 的界面和 6.0 相比有一些布局调整但基本操作逻辑没变老用户不用担心。4. 主机接入与模板配置监控的核心操作4.1 添加被监控主机的三种方式Zabbix 核心能力是监控而监控的第一步是把主机接进来。接主机的方式主要有三种方式适用场景特点AgentLinux/Windows 服务器、虚拟机采集指标最丰富支持自定义监控项SNMP交换机、路由器、防火墙、打印机网络设备的标准采集协议IPMI物理服务器的硬件状态采集电压、温度、风扇转速等带外数据JMXJava 应用Tomcat、Kafka 等需要搭配 java-gateway 使用如果你的被监控对象是普通服务器优先用 Agent它的指标覆盖面和自定义能力是最强的。网络设备用 SNMP物理服务器硬件状态用 IPMI。当然实际环境往往是多种方式混合使用一台业务服务器可能既装 Agent还要通过 SNMP 监控带外管理口这些都是常见的组合。4.2 Agent 主动模式与被动模式的选择接入 Agent 时首先要明确你是用主动模式还是被动模式。被动模式默认Zabbix Server 直接连接 Agent 的 10050 端口拉数据要求被监控主机开启入站端口防火墙策略要考虑放行。主动模式Agent 主动连接 Zabbix Server 的 10051 端口上报数据被监控主机不需要开入站端口特别适合跨机房、跨防火墙的场景。我个人的习惯是两个模式都启用配置好 Server 和 ServerActive 两个参数这样既可以从 Server 端即时执行一些远程命令又能保证 Agent 主动上报数据的时效性。Ubuntu 系的 Agent 安装命令wget https://cdn.zabbix.com/zabbix/sources/stable/7.0/zabbix-release_7.0-2ubuntu22.04_all.deb dpkg -i zabbix-release_7.0-2ubuntu22.04_all.deb apt update apt install -y zabbix-agent2CentOS 系的安装命令rpm -Uvh https://cdn.zabbix.com/zabbix/sources/stable/7.0/zabbix-release-7.0-2.el9.noarch.rpm dnf install -y zabbix-agent2安装完成后编辑 /etc/zabbix/zabbix_agent2.conf重点配置三项ServerZabbix服务器IP ServerActiveZabbix服务器IP Hostname当前主机名称重启 Agent 并确认状态systemctl restart zabbix-agent2 systemctl enable zabbix-agent2 ss -lntp | grep 10050看到 10050 端口监听就说明 Agent 已经起来了。4.3 在 Web 界面添加主机和模板Agent 装好后回到 Web 界面添加主机。点击左侧“数据采集”-“主机”-“创建主机”填写关键信息主机名称建议用完整主机名比如 web-01.example.com方便识别。模板选择 “Linux by Zabbix agent” 或 “Windows by Zabbix agent”一个模板就带进来一批常用监控项和触发器。接口IP 地址填被监控主机的实际 IP端口默认 10050如果开启 Agent 主动模式需要额外填写 Agent 主动模式相关配置。模板这一步是 Zabbix 高效的核心。你不需要手工一条一条创建监控项模板里已经预置好了 CPU、内存、磁盘、网络流量、系统负载、进程数量等上百个常用监控项和触发器规则。添加模板后过几十秒刷新“最新数据”就能看到指标自动采集上来了。4.4 交换机、Windows GPU、Oracle 这类热门监控需求怎么延伸网上关于 Zabbix 的搜索里除了基础安装部署问得最多的就是监控交换机、监控 Windows GPU、监控 Oracle 数据库。其实这几类需求本质上是同一类问题选对采集方式 套对模板。监控交换机很简单只要交换机支持 SNMP在 Web 界面添加主机时选择 “SNMP agents” 相关模板然后填上交换机的 IP 和 SNMP community string 即可。采集下来的端口流量、CPU 使用率、端口 up/down 状态都有现成的模板。监控 Windows GPU 会稍微麻烦一点因为 Zabbix 默认不会直接读取 GPU 性能计数器。你需要先在 Windows 上用性能监视器确认 GPU 性能计数器的名称比如 “GPU Engine(*)\Utilization Percentage”再通过 Agent 的自定义监控项或性能计数器支持能力把它采集进来。Windows 自带模板 “Windows by Zabbix agent” 已经覆盖了不少基础指标你要做的是额外加几个自定义监控项补齐 GPU 数据。监控 Oracle 数据库则灵活很多。如果是 Oracle 的 SQL 性能、表空间、会话数这些指标可以用 Zabbix 提供的数据库监控模板配合 Agent 端的 SQL 脚本或 ODBC 方式采集。网上有大量社区模板可以直接导入核心是确认 Agent 到数据库之间的连接链路通不通。提示先掌握“添加主机 - 选择模板 - 查看最新数据”这条链路再根据需要扩展采集方式你就能应对各种监控需求。5. 告警配置实战让平台真正“会喊人”5.1 从触发器到动作一条告警是怎么产生的监控数据采集回来只是第一步没有告警的监控等于白装。Zabbix 告警链路可以拆成三环触发器定义“什么情况算异常”比如 CPU 使用率连续 3 分钟大于 90%。动作触发器被触发后要执行什么操作比如发送邮件、调用脚本、将故障级别升级。告警媒介通过什么渠道把通知发出去比如邮箱、钉钉机器人、企业微信机器人。三者配合才能形成完整的告警闭环。下面分别来说。5.2 配置邮件告警邮件是最正式、使用面最广的告警渠道。Zabbix 7.0 内置了邮件媒介类型配置步骤如下进入“管理”-“告警媒介类型”-找到 Email 类型点击编辑填入 SMTP 服务器地址、端口、SSL 类型、认证用户名和密码。如果是企业邮箱注意 SMTP 服务器地址和端口通常由公司 IT 统一提供认证方式一般是账号密码或授权码不能用邮箱登录密码直接填。配置完媒介类型后还需要为用户分配告警媒介。点击“用户”-“用户”找到告警接收人在“告警媒介”选项卡中添加 Email收件人填该用户的邮箱地址并设置故障级别范围和工作时间段。最后配置动作。点击“告警”-“动作”-“触发器动作”创建动作定义触发条件比如“故障级别警告”、执行的操作发送到指定用户、恢复操作发送恢复通知。这样一条完整的邮件告警链路就通了。5.3 配置钉钉/企业微信机器人告警很多公司内部沟通主力是钉钉或企业微信如果能直接把告警推送到群机器人里那响应效率会高很多。Zabbix 7.0 的 Web 端可以通过 Webhook 方式直接调用钉钉自定义机器人的 URL不需要额外安装脚本。大致的实现逻辑是在钉钉群中添加自定义机器人获得 Webhook 地址然后在 Zabbix 里新建媒介类型选择 Webhook配置请求 URL、请求头和参数模板最后把它接入用户和动作和邮件告警链路类似。如果你用的还是比较老的 Zabbix 版本或者前端不支持 Webhook那就走传统方案写一个 Python 或 Shell 脚本接收 Zabbix 传入的告警参数通过 HTTP 请求发送到钉钉机器人。核心脚本逻辑大致是解析参数 - 拼装 JSON - 发起 HTTP POST 请求。5.4 动作配置的细节通知对象、告警升级、恢复通知动作配置是告警体验的关键处理不好很容易“告警轰炸”。我分享几个细节故障级别与通知对象匹配普通警告通知运维工程师严重问题同时通知运维负责人灾难级别再加一条短信或电话渠道。Zabbix 支持在动作里按故障级别分流。告警升级Zabbix 动作支持配置多个步骤每个步骤可以设置不同通知对象或操作。比如 5 分钟内未处理则发送第二条通知给更高一级负责人。恢复通知必须开没有恢复通知的告警群白天还好深夜同事根本不知道故障是否已恢复。在动作配置里把恢复操作也加上故障处理后群内能看到恢复消息闭环才完整。另外强烈建议关闭默认的“所有问题都被通知”策略不然一个磁盘临时一过性满了的消息可能把所有人炸醒。合理利用触发器的恢复表达式和抑制机制能减少大量无效通知。5.5 常见告警误判与重复告警问题告警平台跑起来后我最常遇到的问题就是误报和重复告警。误报通常来自触发器阈值设置不合理比如 CPU 平均负载在业务高峰期瞬时拉升如果你用单一的 {HOST.HOST}:system.cpu.load.avg1 触发器很容易在业务正常波动时误告。更合理的做法是使用“最近 N 分钟平均值”作为判断依据或者使用基于变化趋势的预测触发器。Zabbix 7.0 在这方面有更多可选的历史预测函数可以大大降低误报率。重复告警则多半是告警事件没有被正确关闭。例如文件系统在阈值边缘来回抖动会连续触发多个动作。此时可以在动作配置里设置“重复操作次数限制”或引入问题抑制逻辑让同一主机同一触发器的告警在指定时间内合并发送。6. 稳定运行后的维护经验与踩坑排查6.1 最经典的告警Zabbix server is not running跑起来之后很多人会突然发现 Web 界面顶部出现黄色横幅Zabbix server is not running: the information displayed may not be current. 这是 Zabbix 里最经典的误报警但绝大多数情况下并不是 Zabbix Server 真的挂了。这个提示的原理是Zabbix Server 有一个内部自监控项 zabbix[host,triggers_find] 或 zabbix[host,available] 等通过检查数据库和内部缓存来判断 Server 是否“健康”。当 Server 负载较高、数据库响应变慢、缓存尺寸不足时内部自检超时就会在界面上显示这段警告。我踩过这个坑后的排查链路如下先看 Server 进程进入容器执行 ps aux | grep zabbix_server 确认进程是否存在。再看 Server 日志docker logs zabbix-server --tail 200重点看有没有 “cannot send list of active checks” 或 “preprocessing failed” 之类的关键报错。然后看数据库负载如果 MySQL 容器 CPU 和 IO 持续飙高就会拖慢 Server 内部自检触发误报。最后看缓存配置如果监控项特别多、历史数据量大而 ZBX_CACHESIZE 配得太小就会出现缓存过小告警间接导致这个提示。解决思路大体对应三步减少不必要的监控项采集频率、调大 ZBX_CACHESIZE 和 ZBX_HISTORYCACHESIZE、确保数据库所在宿主机 IO 性能足够。绝大多数情况下调参后这个提示就自动消失了。6.2 Access denied for user数据库授权问题另一个高频报错是登录或连接时报 Access denied for user replace_userlocalhost (using password: YES)。这个问题几乎都是环境变量不一致或数据库用户权限缺失引起的。最典型的场景是你首次部署时 MYSQL_USER 或 MYSQL_PASSWORD 写错了MySQL 容器首次启动时已经按错误变量初始化了用户之后你再修改 compose 文件里的变量MySQL 不会自动更新已有用户于是 Zabbix Server 和 Web 端都连不上数据库。解决思路有两个要么在 MySQL 容器里手动更新用户密码和授权要么把 MySQL 数据卷清空重新初始化。生产环境如果已有历史数据优先用手动授权方式ALTER USER zabbix% IDENTIFIED BY 新密码; GRANT ALL PRIVILEGES ON zabbix.* TO zabbix%; FLUSH PRIVILEGES;然后再同步修改 compose 里 Zabbix Server 和 Web 端的 MYSQL_PASSWORD重启容器即可。6.3 图形中文乱码问题Zabbix 在图形中展示中文标签时如果容器内没有中文字体就会显示为一堆方框。这个坑几乎每个中文用户都会遇到解决起来也不难。你需要准备一个中文字体文件比如 Windows 自带的 simhei.ttf 或者思源黑体放到宿主机 /data/zabbix/web/fonts 目录下然后在 zabbix-web 容器关闭期间通过 docker cp 命令把字体文件复制进容器docker cp /data/zabbix/web/fonts/simhei.ttf zabbix-web:/usr/share/zabbix/assets/fonts/然后进入容器修改字体配置文件把所用字体指向这个中文字体文件docker exec -it zabbix-web bash cd /usr/share/zabbix/assets/fonts mv graphfont.ttf graphfont.ttf.bak ln -s simhei.ttf graphfont.ttf重启容器后刷新页面图形里的中文就能正常显示了。6.4 数据备份、恢复与升级策略监控平台的备份和数据库备份一样重要。Zabbix 的全部配置和历史数据都存在 MySQL 里所以备份核心是备份数据库。我习惯每天凌晨用 mysqldump 导出全库保留最近 7 天再定期拷到异地存储。docker exec zabbix-mysql mysqldump -uroot -p密码 --single-transaction --databases zabbix /data/zabbix/backup/zabbix_$(date %F).sql恢复的时候先停掉 zabbix-server 和 zabbix-web再通过 mysql 命令导入备份文件最后重新启动容器。整个恢复过程大概几分钟数据不丢。升级方面Zabbix 容器化升级相比传统方式容易很多。流程是备份数据库 - 拉取新版镜像 - 停止并移除旧容器 - 更新 compose 里的镜像版本 - 重新 up -d。首次启动时官方镜像会自动执行数据库结构升级耐心等待完成即可。6.5 性能调优Housekeeper、缓存、监控项数量Zabbix 跑得越久数据量越大性能问题就越明显。我建议从三个方向控制第一魔法级减少监控项数量。模板默认带了很多监控项但你的业务真的每一项都需要吗比如某些文件系统性能计数器如果业务根本用不到建议直接禁用或删除控制数据采集总量。第二合理调整 Housekeeper 清理策略。Zabbix 有历史数据保留周期配置默认趋势数据保留 365 天历史数据保留 30 天。你可以根据实际合规要求和存储成本调整保留时间缩短保留期能显著减轻数据库压力。第三调大缓存参数。监控项多、Agent 多时Server 的配置缓存、历史数据缓存都会成为瓶颈。compose 文件里的 ZBX_CACHESIZE、ZBX_HISTORYCACHESIZE 这些参数要根据实际规模逐步调整改完重启容器生效。提示上线初期把监控项控制在“够用但不过度”的状态。等平台稳定运行你再根据告警和报表需求逐步补充监控项远比一开始贪多求全更可靠。数据库层面也可以做优化比如给 Zabbix 相关表建立合适的索引或者在 MySQL 配置里增大 buffer pool 和连接数。不过这些属于进阶调优暂时不放太多篇幅展开。如果确实遇到性能瓶颈建议先检查是不是监控项数量或采集频率设置不合理这往往是 80% 问题的根源。现在再回头看这套 Docker 部署的 Zabbix 平台它帮我解决了当初“系统出问题时最后一个知道”的根本痛点。整套架构用 docker compose 管起来配置、数据、脚本全部外置可控无论是日常备份、迁移还是升级我都心里有底。最后分享我自己的两个小习惯一是每次修改 compose 配置后先 docker compose config 校验一遍语法再执行 up -d能省下不少低级错误二是把所有自定义的告警脚本和模板备份在一个 Git 仓库里每次改动留痕出现问题时能快速回退。希望你部署 Zabbix 时少踩一些我踩过的坑从第一天开始就拥有一个能让人安心的监控告警平台。