各位做运维和系统架构的朋友应该都有过这种体验公司系统越来越多服务器从几台涨到几十台今天这个磁盘满了明天那个服务挂了全是业务方先发现再通知你。被动救火的日子过够了就该上一套正经的监控平台。Zabbix 作为老牌开源监控工具加上 Docker 的快速部署能力是目前中小团队搭建企业级监控告警体系非常稳妥的路线。这篇文章就从一个实际落地案例出发把整个部署过程、踩坑经历和告警配置细节全部拆开讲清楚。我这套方案用的是 Zabbix 7.0 LTS Docker Compose数据库选了 PostgreSQL 加 TimescaleDB包含 Server、Web、Agent2、Nginx 反代四个容器整套跑下来资源占用很低2 核 4G 的机器带 200 台以内主机问题不大。后续接 Linux、Windows 服务器配置邮件告警全部流程我会一步步带着走每个操作背后的原因也一并说清。1. 方案选型与整体设计思路1.1 为什么是 Zabbix 而不是 Prometheus先回答一个最常被问到的问题现在 Prometheus 热度那么高为什么还要选 Zabbix我之前也纠结过很久实际两套都跑过一段时间后我的结论是选择取决于你监控的对象和团队结构。Prometheus 的优势在云原生场景尤其是 Kubernetes 集群内部服务发现、指标采集这套生态做得非常顺。但从裸机、虚拟机、网络设备到数据库实例的全面监控Zabbix 的成熟度反而更高。Zabbix 原生的发现规则、模板机制、聚合图表、告警升级、报表功能都是开箱即用不用像 Prometheus 那样拼一堆 exporter 和 Alertmanager 配置。Zabbix 内置了大量社区模板一个命令加关联模板就能监控 Linux、Windows、MySQL、Redis、Nginx、Java 应用等常见对象这对运维人员来说非常省心。另外 Zabbix 的 Agent 支持主动和被动两种模式主动模式下由 Agent 主动把数据推给 Server天然适合跨机房、防火墙后面的场景。这一块 Prometheus 的 pushgateway 用起来就绕一些。当然我这里不是说 Prometheus 不好而是对于以物理机、虚拟机为主的传统企业环境Zabbix 的投入产出比更高。1.2 Docker 化部署解决了什么问题Zabbix 的传统安装方式要说也不算复杂无非是装数据库、跑 PHP、编译安装 Server 和 Agent但麻烦就麻烦在版本依赖和升级维护上。PHP 版本、数据库版本、Zabbix Server 版本三者必须匹配一旦系统自带的软件源版本过旧就得手动编译或加第三方源过程容易出错。Docker 化之后整个 Zabbix 平台被拆成几个独立容器每个容器只跑一个进程镜像由官方持续维护版本升级就是改一行环境变量然后 pull 新镜像重启。不同项目的环境差异被隔离掉开发环境、测试环境、生产环境的行为一致性大大提高。此外Docker Compose 用一份 YAML 文件就能完整描述整个部署拓扑配合 Portainer 这类工具还能实现可视化管理对团队协作和知识交接非常友好。当然容器化也有它的边界。Zabbix Server 本身要持续监控大量目标如果你管理的设备超过几千台就需要深入调优 Zabbix Server 或者考虑原生安装在专用物理机上以获得更高的性能上限。一般情况下中小规模场景用 Docker 部署完全够用。1.3 整体服务拓扑这套部署方案里一共包含以下核心组件组件容器镜像作用zabbix-serverzabbix/zabbix-server-pgsql负责数据采集、触发器计算、告警生成zabbix-webzabbix/zabbix-web-nginx-pgsql提供 Web 管理界面PHP Nginxzabbix-dbpostgres timescaledb存储配置、历史数据、趋势数据zabbix-agent2zabbix/zabbix-agent2监控 Zabbix Server 本机nginxnginx反向代理终结 HTTPS提高安全性服务之间的调用关系很简单Agent2 采集到的数据由 Server 接收Server 写入 PostgreSQLWeb 通过 PHP 从数据库读取配置和展示数据管理员通过浏览器访问 Web 进行配置管理。数据库一层我使用 TimescaleDB 扩展这是 Zabbix 官方重点推荐的方向。Zabbix 7.0 针对 TimescaleDB 做了很多优化历史数据按时间自动分区数据清理housekeeping的效率大幅提升监控数据量大后不会出现数据库越跑越慢的问题。2. 部署准备与 Docker Compose 编写2.1 环境准备清单部署前需要准备一台 Linux 服务器。实际操作中我拿 Ubuntu 22.04 和 CentOS 7.9 都跑过这套 Compose 文件没有发现差异。建议大家用 Debian 系系统Docker 官方源的支持更顺滑CentOS 7 内核版本偏低跑高版本 Zabbix 镜像偶尔会遇到一些网络兼容问题。依赖方面只有两项Docker Engine 20.10 以上版本Docker Compose Plugin 2.20 以上版本安装这块不打算花太多篇幅说官方文档有标准流程。提一个实操建议如果你在国内服务器上拉镜像经常遇到超时建议给 Docker 配置一个国内镜像源在/etc/docker/daemon.json中加入registry-mirrors配置项然后重启 Docker。这件事不影响整体方案的正确性但能省下大量等待时间。2.2 docker-compose.yml 完整配置下面直接贴出我实际使用的 Compose 文件。这个文件经过多次生产环境验证注释我也写在其中方便直接套用networks: zbx-net: driver: bridge volumes: zabbix-db-data: driver: local zabbix-server-data: driver: local zabbix-web-data: driver: local services: db: image: postgres:16-alpine container_name: zabbix-db restart: always networks: - zbx-net environment: POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix_pwd_2024 POSTGRES_DB: zabbix volumes: - zabbix-db-data:/var/lib/postgresql/data command: - postgres - -c - max_connections300 - -c - shared_buffers512MB - -c - effective_cache_size1536MB - -c - maintenance_work_mem128MB - -c - checkpoint_completion_target0.9 - -c - wal_buffers16MB - -c - default_statistics_target100 healthcheck: test: [CMD-SHELL, pg_isready -U zabbix -d zabbix] interval: 10s timeout: 5s retries: 5 start_period: 10s timescaledb: image: timescale/timescaledb:2.15.2-pg16 container_name: zabbix-timescaledb restart: always networks: - zbx-net environment: POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix_pwd_2024 POSTGRES_DB: zabbix volumes: - zabbix-db-data:/var/lib/postgresql/data command: - postgres - -c - max_connections300 - -c - shared_buffers512MB - -c - effective_cache_size1536MB - -c - maintenance_work_mem128MB - -c - checkpoint_completion_target0.9 - -c - wal_buffers16MB - -c - default_statistics_target100 healthcheck: test: [CMD-SHELL, pg_isready -U zabbix -d zabbix] interval: 10s timeout: 5s retries: 5 start_period: 10s server: image: zabbix/zabbix-server-pgsql:7.0.0-ubuntu container_name: zabbix-server restart: always networks: - zbx-net ports: - 10051:10051 environment: DB_SERVER_HOST: db DB_SERVER_PORT: 5432 POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix_pwd_2024 POSTGRES_DB: zabbix ZBX_CACHESIZE: 256M ZBX_HISTORYCACHESIZE: 128M ZBX_TRENDCACHESIZE: 64M ZBX_STARTPOLLERS: 10 ZBX_STARTPOLLERSUNREACHABLE: 2 ZBX_STARTTRAPPERS: 4 ZBX_STARTPREPROCESSORS: 3 ZBX_STARTESCALATORS: 3 ZBX_CACHEUPDATEFREQUENCY: 60 ZBX_HOUSEKEEPINGFREQUENCY: 1 depends_on: db: condition: service_healthy volumes: - zabbix-server-data:/var/lib/zabbix web: image: zabbix/zabbix-web-nginx-pgsql:7.0.0-ubuntu container_name: zabbix-web restart: always networks: - zbx-net ports: - 8080:8080 - 8443:8443 environment: ZBX_SERVER_HOST: server DB_SERVER_HOST: db DB_SERVER_PORT: 5432 POSTGRES_USER: zabbix POSTGRES_PASSWORD: zabbix_pwd_2024 POSTGRES_DB: zabbix PHP_TZ: Asia/Shanghai depends_on: - server agent2: image: zabbix/zabbix-agent2:7.0.0-ubuntu container_name: zabbix-agent2 restart: always networks: - zbx-net environment: ZBX_HOSTNAME: zabbix-server ZBX_SERVER_HOST: server ZBX_SERVER_PORT: 10051 ZBX_DEBUGLEVEL: 3 ports: - 10050:10050 depends_on: - server这里有个点需要说清楚db 和 timescaledb 使用了同一份数据卷zabbix-db-data但正常情况下不会同时启动两个数据库服务timescaledb镜像内部同样基于 PostgreSQL 16并且预装了 TimescaleDB 插件。你可以在两种模式中切换不想用插件扩展就用db想用 TimescaleDB 分区表就停掉db再启动timescaledb。因为两份配置共享同一个数据卷所以数据是完整的schema 中的扩展需要初始化一次后就会保留在数据目录里。2.3 参数设计意图拆解上面那一长串环境变量看着唬人实际上每一个都对应 Zabbix Server 的配置参数理解之后你可以按需调整。ZBX_CACHESIZE配置缓存大小存放主机、监控项、触发器配置。配置数量越多这个值要开得越大。256M 对几百台主机完全够如果监控项超过 2 万个建议加到 512M。ZBX_HISTORYCACHESIZE历史数据缓存新采集到的数据先写进内存再批量刷入数据库。设小了容易出现History cache is full的报错建议至少 128M。ZBX_STARTPOLLERS轮询器进程数影响被动监控项的采集并发能力。一般按每 100 台主机配 2 个 Poller 估算10 个 Poller 带 500 台主机压力不大。ZBX_STARTTRAPPERS接收 Agent 主动数据、发送方trapper数据的进程数。Agent 主动模式场景多的话这个值适当加大。ZBX_HOUSEKEEPINGFREQUENCY内部清理任务执行频率默认 1 小时一次。如果历史数据保留周期长、数据量大保持默认即可不要调太快否则清理任务可能影响正常性能。数据库参数我开了max_connections300。Zabbix Server 的连接池会根据进程数产生大量数据库连接默认 100 个连接很容易不够取消这个限制以后报警会少很多。shared_buffers设 512Meffective_cache_size设 1536M这是针对 4G 内存机器的合理值如果你的机器只有 2G记得相应减半。时区设置也别忘了PHP_TZ: Asia/Shanghai否则 Web 界面显示的时间会比北京时间早 8 个小时排查告警时间会很痛苦。2.4 初始化 Zabbix 数据库Compose 文件准备好之后第一次启动前建议用下面的命令先初始化数据库避免后续日志里出现完全看不懂的建表冲突docker compose up -d db sleep 20 docker exec -i zabbix-db psql -U zabbix -d zabbix -c CREATE EXTENSION IF NOT EXISTS timescaledb; docker exec -i zabbix-db psql -U zabbix -d zabbix -c SELECT default_version FROM pg_available_extensions WHERE name timescaledb;这里解释一下为什么先单起数据库。Zabbix 首次启动时如果发现数据库为空会自动导入 schema 和种子数据。如果用普通 PostgreSQL 镜像先建库建表后面切到 TimescaleDB 镜像时仍需手动启用扩展。反过来先手动建好 TimescaleDB 再让 Zabbix Server 初始化一次性就绪后面想用分区表直接执行转换函数即可。我自己在 7.0 版本上实测不启用 TimescaleDB纯 PostgreSQL 也能正常跑但历史数据表慢慢变大以后housekeeping 的执行时间会显著上升。启用了 TimescaleDB按天分区的历史表清理成本会低很多。所以如果你不是特别排斥新东西我建议直接用 TimescaleDB。3. 完整部署实操流程3.1 启动整套服务数据库初始化完成后可以一次性拉起所有服务docker compose up -d docker compose ps正常情况下所有容器都处于Up状态healthy 状态为 running。如果某个容器反复重启先看日志docker logs -f zabbix-serverZabbix Server 日志里的Zabbix server started表示启动成功数据库连接失败时会直接打印类似Cannot connect to database的报错按错误信息调整环境变量即可。3.2 Web 界面初始化安装浏览器访问http://服务器IP:8080会进入 Zabbix Web 安装向导。这里用的是官方 Nginx 镜像第一页会检查 PHP 环境和数据库连接正常都是绿勾直接下一步。数据库连接信息填写数据库类型PostgreSQL数据库主机db注意不是 localhost这是容器网络内的服务名数据库端口5432数据库名称zabbix用户zabbix密码zabbix_pwd_2024填完点下一步安装程序会往数据库写入初始配置。完成后默认登录账号是Admin密码是zabbix登录后第一件事是先修改默认密码。3.3 配置前端时区与中文显示登录后进入 Web 界面如果显示英文可以在右上角用户头像的 Profile 里把 Language 切换为zh_CN。Zabbix 7.0 自带中文语言包不用额外下载。再检查一下时区进入 Administration - General - User groups确认 Default time zone 选择的是(UTC08:00) Beijing之类的中时区。虽然 PHP 容器内已经设置了时区但 Web 界面层还有一层用户偏好时区要同步改过来两处保持一致才不会出现告警时间对不上的问题。3.4 本机监控验证链路Zabbix 自带的 Agent2 容器已经在运行了接下来在 Web 界面里验证数据链路是否正常。进入 Data collection - Hosts你会发现系统自动添加了一个名为zabbix-server的主机这是 Agent2 容器启动时通过环境变量自动注册的。点进主机的 Latest data可以看到 System CPU、Memory、Disk I/O 等监控项已经在采集数据了。这一步如果 Latest data 始终没有数据通常有以下原因Agent2 的ZBX_SERVER_HOST配置成了容器名以外的地址Agent 无法连接 ServerServer 的 10051 端口没有暴露给宿主机或没有在 Compose 网络内双向互通Agent2 没有将主机名注册成 Web 后台已有的主机名最直接的排查方式是在宿主机执行docker exec zabbix-server zabbix_get -s agent2 -k agent.version能返回 Agent 版本号就说明链路通了返回空或报错就继续查网络和主机名配置。4. 接入真实业务主机Linux 与 Windows 实战Zabbix 光监控自己没有任何业务价值真正要做的第一件事是把公司现有的服务器纳入监控。下面分 Linux 和 Windows 两种主流服务器平台来说明。4.1 Linux 主机接入方式Agent2 容器版Linux 服务器上如果已经装了 Docker最简单的方式是再跑一个 Agent2 容器避免污染宿主机的软件环境。假设要监控一台 IP 为192.168.1.101的 CentOS 服务器docker run -d \ --name zabbix-agent2 \ --network host \ --restart unless-stopped \ -e ZBX_HOSTNAMEweb-prod-01 \ -e ZBX_SERVER_HOSTzabbix.example.com \ -e ZBX_ACTIVE_ALLOWtrue \ -v /:/hostfs:ro \ -v /var/run/docker.sock:/var/run/docker.sock \ zabbix/zabbix-agent2:7.0.0-ubuntu这里使用了--network host模式Agent2 直接监听宿主机的 10050 端口避免端口映射带来的额外 NAT 开销。-v /:/hostfs:ro是让 Agent 能读取宿主机根文件系统从而采集磁盘、内存这类宿主机指标注意一定要只读挂载否则等于给容器开了宿主机的写权限风险很大。Agent2 启动后回到 Zabbix Web 后台手动添加主机主机名称web-prod-01可见名称web-prod-01生产 Web 01群组Linux servers接口AgentIP 填192.168.1.101端口 10050模板关联Linux by Zabbix agent active注意选 active 还是 passive 取决于你的 Agent 配置添加后等个十几秒Latest data 里就会出现数据。如果主机状态显示红色UNREACHABLE先在服务器上测试 10050 端口是否通了telnet 192.168.1.101 10050Zabbix 的 Agent 端口默认只监听本机时远程连接会直接拒绝这种情况下需要在 Agent2 容器的防火墙规则中放行 10050或者在宿主机关闭防火墙测试确认问题。4.2 Linux 主机接入的纯 Agent 方式如果你不想在被监控机器上装 Docker也可以直接用二进制包部署 Agent2。以 Ubuntu 22.04 为例wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-1ubuntu22.04_all.deb dpkg -i zabbix-release_7.0-1ubuntu22.04_all.deb apt update apt install -y zabbix-agent2安装完成后编辑/etc/zabbix/zabbix_agent2.confServerzabbix.example.com ServerActivezabbix.example.com Hostnameweb-prod-01启动服务systemctl enable zabbix-agent2 systemctl start zabbix-agent2原理上同样是在 Web 后台加主机关联模板。区别在于二进制方式没有容器隔离开销适合对主机资源占用要求极低的场景。从我个人实践经验看Agent2 二进制本身占用大约 20M 内存比 Docker 方式少一半以上所以如果你管的主机比较多还是建议直接用二进制包。4.3 Windows 主机接入与 GPU 监控Windows 服务器接入 Zabbix 这种方式也很成熟到 Zabbix 官网下载对应的 Windows Agent2 MSI 安装包然后运行msiexec /i zabbix_agent2-7.0.0-windows-amd64.msi /qn SERVERzabbix.example.com SERVERACTIVEzabbix.example.com HOSTNAMEwin-sql-01安装完成后Agent 服务会自动启动Windows 自带的防火墙一般会自动弹窗选择允许。如果被墙了手动放行10050端口。模板选择方面Windows 主机关联Windows by Zabbix agent active。这个模板里已经内置了 CPU、内存、磁盘、网络、服务状态等几百个监控项无需额外配置。近期有不少朋友问 Zabbix 能不能监控 Windows 上的 GPU 温度、显存占用这类指标。Zabbix 7.0 官方原生模板没有覆盖 GPU但可以通过 Agent2 的system.run功能执行 PowerShell 脚本采集 NVIDIA 显卡数据或者直接使用nvidia-smi输出解析后配合自定义监控项实现。这块通常作为定制需求处理有空我会专门写一篇展开讲。4.4 自动注册规则应对大批量主机等你需要一次性接入几十台上百台服务器时手工一台一台加主机显然不现实。Zabbix 的自动发现可以解决这个问题利用 Agent 主动上报时的 Hostname 自动创建主机并关联模板。配置路径Data collection - Auto registration - Create action。条件设置匹配规则例如主机名以prod-开头则自动加入Production servers群组并关联Linux by Zabbix agent active模板。Agent 端只需配置好 ServerActive 和 Hostname启动后就会被自动纳管。实际操作时我习惯把 Hostname 规范成业务-环境-编号例如order-prod-01、mysql-prod-02再用正则表达式自动分组关联不同模板。这样后端扩容时运维只需要在初始化脚本里写好 Hostname装完 Agent 就自动出现在监控平台中效率非常高。5. 告警平台核心配置从触发器到通知Zabbix 的告警链路可以简单归纳为监控项采集值 - 触发器判定异常 - 产生事件 - 动作匹配事件 - 发送通知或执行远程命令。下面这一节我们把它逐一打通。5.1 触发器的作用与配置示例触发器的作用是给某一个或某几个监控项设置阈值逻辑当条件满足时产生告警事件。还是以磁盘空间为例内置模板Linux by Zabbix agent active已经有现成的磁盘空间触发器。找到某个vfs.fs.size[pfree]监控项对应的触发器可以看到默认阈值是剩余空间小于 20% 时触发 Warning剩余空间小于 10% 时触发 High很多人不知道的是Zabbix 的触发器表达式支持复杂的恢复表达式和持续时间。比如我不想磁盘剩余空间一降到 20% 就立刻告警而是持续 5 分钟仍然低于阈值才触发可以在触发器里维护For 5m持续参数。这样能过滤掉临时的瞬时抖动减少大量无用告警。创建自定义触发器的入口是 Data collection - Triggers - Create triggerlast(/web-prod-01/system.cpu.util[,iowait])30这个表达式的意思是 CPU iowait 大于 30% 时触发告警。实际配置时还可以加上时间窗口限制比如只在工作日的 9 点到 18 点告警表达式写成last(/web-prod-01/system.cpu.util[,iowait])30 and dayofweek(now)1 and dayofweek(now)5 and time(now)090000 and time(now)1800005.2 配置邮件告警媒介告警事件产生后Zabbix 要通过媒介把通知发出去。以最常用的邮件告警为例Zabbix 7.0 内置支持 SMTP 方式的邮件媒介不需要额外脚本。配置路径Alerts - Media types - Email。SMTP 设置里填写你实际可用的邮件服务器如果是公司内部有邮件网关就填内网地址如果使用云邮箱服务需要填写认证信息。比如使用 163 邮箱时SMTP serversmtp.163.comSMTP server port465Connection securitySSL/TLSUsername你的 163 邮箱账号Password163 设置的授权码不是邮箱登录密码AuthenticationEnabled配置完之后不要直接关掉页面先点列表右上角的 Test 按钮输入一个收件人地址测试发送。这一步非常关键先确认邮件链路通再往下走动作配置否则告警动作配得再完美邮件根本收不到也无法定位问题。5.3 创建告警动作媒介只是通道真正决定“什么情况下给谁发邮件”的是动作Action。配置路径Alerts - Actions - Trigger actions - Create action。动作的触发条件可以理解为一段逻辑表达式比如{TRIGGER.SEVERITY}4表示当告警级别高于等于 High 时才触发动作。如果希望所有 Warning 以上级别的告警都通知可以把条件改成{TRIGGER.SEVERITY}3操作步骤里要指定“发送给谁”和“用什么媒介”。在 Operation 里添加用户媒介类型选择 Email标题和消息内容可以使用 Zabbix 的宏自动填充告警: {TRIGGER.NAME} 主机: {HOST.NAME} 当前值: {ITEM.LASTVALUE} 触发时间: {EVENT.DATE} {EVENT.TIME} 当前状态: {TRIGGER.STATUS}恢复通知也要单独配置一个 Operation否则故障恢复后你不会收到任何邮件。消息模板和告警通知类似把状态写成恢复即可恢复: {TRIGGER.NAME} 主机: {HOST.NAME} 恢复正常时间: {EVENT.RECOVERY.DATE} {EVENT.RECOVERY.TIME}5.4 告警间隔与升级策略Zabbix 的动作里有一个Escalation配置用于控制告警的重复通知频率和升级机制。默认情况下动作触发后只发一次告警邮件。如果希望故障持续期间每隔 30 分钟重新通知一次可以把 escalation 步长设置为 30 分钟步骤设置为 1-5这样最多重复通知 5 次。还可以配置升级第 1-3 步通知值班初级运维第 4-6 步通知高级运维第 7 步以上通知运维主管。这种机制对故障处理非常有帮助能避免告警邮件发出去之后无人响应、问题被晾着的情况。Zabbix 的告警升级逻辑很简单就是让你在操作步骤里定义不同阶段的接收人和媒介。6. 常见问题、性能优化与排查技巧6.1 高频踩坑汇总问题一历史数据过大造成数据库膨胀如果你一开始图省事用的纯 PostgreSQL 而不是 TimescaleDB跑了几周之后数据库文件可能暴涨到几十 GB。Zabbix 默认把历史数据保留 90 天趋势数据保留 365 天数据量大后不仅占用磁盘数据库查询也会明显变慢。解决思路有两种。一种是给 Zabbix Server 开启 TimescaleDB 扩展在zabbix-server-pgsql:7.0.0-ubuntu启动参数里加入zbx_db_extensiontimescaledb需要数据库侧已安装扩展并且 schema 已迁移。这个过程建议安排在业务低峰期执行因为分区迁移会重建部分大表。另一种更简单的方案是到 Administration - General - Housekeeping 里调整历史数据和趋势数据的保留时间。比如历史数据从 90 天降到 30 天趋势数据从 365 天降到 180 天对常规排障场景基本够用磁盘占用能降至原来的三分之一。问题二容器时间与宿主机不同步Zabbix Server 容器内默认使用 UTC 时区如果宿主机是东八区查看 Zabbix 界面上的时间和实际时间就会差 8 小时。比较简单的处理方案是为每个容器挂载宿主机的/etc/localtimevolumes: - /etc/localtime:/etc/localtime:ro同时保留环境变量PHP_TZAsia/Shanghai。这一步在容器编排中提前加上避免后期排查告警时间差时绕弯路。问题三Web 界面图表中文乱码Zabbix Web 图表中的中文如果显示成方块或乱码一般是容器里缺少中文字体导致的。Zabbix 官方的 Web 镜像不含中文字体因为 Debian 基础镜像比较精简。处理方式是在 Web 容器里安装字体docker exec -it zabbix-web bash apt-get update apt-get install -y fonts-wqy-microhei exit docker restart zabbix-web安装fonts-wqy-microhei后图表标题、图例的中文就能正常渲染。如果你担心容器重建后字体丢失建议在 Compose 文件里把字体文件挂载到容器内的字体目录。问题四无法添加中文主机名或告警内容乱码Zabbix 数据库字符集在 7.0 版本默认是 UTF8基本不会出现中文乱码问题。但如果你的 PostgreSQL 版本比较老或者从 5.x 时代的老库升级上来需要检查数据库编码SHOW SERVER_ENCODING;出现LATIN1或SQL_ASCII之类非 UTF8 的结果就要考虑重建数据库或转码了这个操作比较重建议在维护窗口执行。6.2 性能瓶颈定位思路Zabbix 跑着跑着发现监控图表经常出现断点最新数据迟迟不出来或者 Web 页面打开很卡需要按下面的顺序排查第一看 Server 内部队列是否有积压。Zabbix 的 Reports - System information 页面会直接显示 Queue 情况。如果队列里堆积了几万条数据说明采集速度大于处理速度需要增加 Poller 数量或调整缓存大小。第二看数据库负载。Zabbix 大部分性能问题最终都追溯到数据库。如果 PostgreSQL 的 CPU 长期超过 80%先检查是否缺少索引再考虑启用 TimescaleDB 压缩和分区。PostgreSQL 慢查询日志是一个非常有用的诊断手段log_min_duration_statement可以设置为 1000ms 记录超过 1 秒的 SQL定位是哪类查询拖慢了整体性能。第三看 Web 层 PHP 执行时间。如果图表页面响应慢但数据采集正常问题多半在前端渲染。docker stats查看 Web 容器 CPU 使用率如果明显偏高可能需要给 Web 容器分配更多 CPU 资源。6.3 数据备份策略Zabbix 这套系统真正的核心资产是数据库里的配置和历史数据。容器本身可以随时重建数据库数据丢了就麻烦了。我的备份方案是每天凌晨用pg_dump导出数据库到宿主机再同步到异地存储docker exec zabbix-db pg_dump -U zabbix -d zabbix | gzip /backup/zabbix_$(date %F).sql.gz恢复时先停掉 Server 容器然后执行gunzip -c zabbix_2025-01-01.sql.gz | docker exec -i zabbix-db psql -U zabbix -d zabbix备份保留 7 天即可。注意一点启用 TimescaleDB 后pg_dump是支持备份分区表的不用额外处理。恢复过程中如果报约束冲突多半是数据库里已经有残留数据建议恢复前清空目标库再导入。6.4 日常维护建议最后分享一些这套平台日常维护的经验。首先是定期更新镜像版本。Zabbix 7.0 是这个系列的第一个 LTS 版本后续会有 7.0.x 的小版本修复补丁建议每隔一两个月更新一次。更新前先备份数据库然后按 Web、Server、Agent 的顺序依次替换镜像。其次是合理规划监控粒度。默认模板里很多监控项是秒级采集例如 CPU 和内存而磁盘和网络这类变化较慢的指标完全可以降低到 60 秒采集一次再配合触发器里的持续时间和聚合函数既能保证告警灵敏度又不会给服务器和数据存储带来过多压力。还有一点容易被忽略Zabbix 的自动发现功能默认会比较激进。比如用网络级发现扫描整个 C 段如果不做限制可能一下子发明大量不需要的主机和服务导致 Server 端 CPU 飙升。自动发现规则里一定要设置好 IP 范围、更新间隔和过滤条件。这套 Docker Zabbix 7.0 的部署方案我在生产环境跑了差不多半年从最初的几台服务器扩展到现在的几十台过程相当平稳。Zabbix 这套体系的好处在于它不像很多轻量监控工具那样只解决告警这一层而是把数据采集、历史存储、趋势预测、权限管理、告警升级这些企业化需求都覆盖到了。借助 Docker 部署你可以在半小时内从零跑起来一套完整的监控告警平台后续再按业务需求逐步扩展监控项、自动发现和告警策略。如果大家部署过程中遇到其他特别怪的问题欢迎在评论区留言我看到会尽量回复。