两年前我接手公司运维的时候服务器数量已经涨到三十多台还有几台交换机和一批Windows机器。当时摆在面前最头疼的问题就是用什么做监控。Prometheus生态很强但学起来曲线陡尤其对传统网络设备支持没想象中友好夜莺那一类新平台也在看但团队里并没有人用过试错成本不小。最后选来选去还是定在了Zabbix——理由很朴素它有成熟的企业级监控与告警平台能力模板多、文档全、社区答案一搜一大把而且对服务器、网络设备、Windows主机的覆盖几乎是开箱即用。真正让我下决心的是Docker部署Zabbix这条路能把最折磨人的安装和依赖问题直接绕开把精力留给监控本身。这篇东西就是我当时从零到上线的完整记录包含踩过的坑、排查思路和现在仍在用的日常操作适合刚接触Zabbix、正准备搭建环境或者已经被各种依赖问题折腾得想放弃的朋友参考。1. 为什么我把Zabbix塞进Docker而不是装在裸机上1.1 裸机安装Zabbix的一堆隐形税先说说为什么我一开始犹豫了很久。Zabbix的传统安装方式在官网文档里写得很清楚先装数据库、再装Server、再装Web前端每一步都有版本要求。听起来不难真操作起来就是另一回事了。尤其是老系统比如我手头那台CentOS 7自带的PHP版本是5.4Zabbix 6.4及以上版本要求PHP 8.0以上光这一步就够你折腾半天。你有两个选择用第三方源升级PHP或者用yum装老版本Zabbix。两条路都不轻松前者要处理各种remi源的依赖后者意味着你放弃了新版本的功能和安全更新。MySQL也一样。Zabbix Server对数据库版本有最低要求你不可能让MySQL 5.6去扛6.4的Server跑起来全是warning。加上Web前端需要的php-fpm配置、时区设置、字体支持、中文语言包一套下来只要有一个环节版本不对安装界面就给你弹个红条。我当时在测试机折腾了一个下午卡在PHP缺少扩展上转头就决定不耗了。1.2 容器化之后收益到底在哪换到Docker之后整个环境变得异常清爽。Zabbix Server、MySQL数据库、Nginx Web前端每个服务一个容器镜像启动就是一套完整环境不会再出现我机器上装的PHP版本和你机器不一样这种问题。我用的还是最朴素的docker compose方案没有上Kubernetes对这个规模来说完全够用。容器化最大的好处有三个环境隔离Zabbix Server要求的PHP扩展、依赖库全部打包在镜像里宿主机器上就算装了一堆乱七八糟的环境也不影响。备份与迁移方便监控平台最怕的是装完就忘等到要迁移才发现当时怎么装的已经不记得了。容器化之后整个环境就是一份compose文件加数据卷换机器也就一条命令的事。版本升级可控Zabbix隔段时间就发新版本容器化升级只需要替换镜像Tag数据库备份好起新容器连上老数据就行。不用再走一遍编译安装流程。我见过很多生产环境用了五六年的Zabbix还停留在很老的版本多半就是因为当初是手工装的升级成本太高一直拖着。Docker化之后这个理由基本不存在了。1.3 代价也不是没有当然容器化不是没有成本。最大的问题是数据卷管理。Zabbix的监控数据全在数据库里MySQL容器本身是有状态的一旦容器删了但数据卷没挂好数据就没了。所以compose文件里必须显式声明volume承载路径。另外就是时区问题容器默认时区是UTC日志和告警时间会比北京时间晚8个小时这个问题当时也坑过我一次后面会细说。另一个容易被忽略的是镜像的获取速度。Docker官方的Zabbix镜像在Docker Hub上国内网络环境下拉取很慢一个几百兆的镜像可能要等很久。解决方案就是配置registry mirror或者干脆用国内能访问的镜像源。这个我会在部署小节里专门提。1.4 Docker Desktop和Linux的差别我自己的主力操作机是Windows日常开发在Mac和Linux之间切换所以顺带说一下。如果你打算在Windows上先做实验Docker Desktop装上挺方便但生产部署还是建议用Linux服务器原因有两点一是Docker Desktop在Windows上是虚拟机方案性能相比Linux原生容器有损耗监控平台是7x24小时跑着的东西没必要白白搭这部分性能二是生产环境你大概率不会用Win ServerWindows上验证的compose拿到Linux上跑几乎没有差别提前在Linux上动手能少走弯路。我当时是把一台退役的4核8G服务器翻出来装的Ubuntu 22.04正好拿来当监控机。这台机器到现在还在跑资源占用一直很稳定。2. 部署前必须想清楚的架构三个容器怎么分工2.1 Zabbix Server、Web、DB各自的角色Zabbix官方在Docker Hub上提供了好几种镜像组合最常用的是三个组件分三个容器部署zabbix-server核心监控服务负责拉取数据、执行触发器判断、发送告警通知。它要连数据库要和被监控的客户端通信是整个系统的引擎。zabbix-web-nginx负责提供浏览器访问的Web管理界面。它本身是PHP项目镜像里集成了Nginx和PHP-FPM。它要连Server拿数据也要连数据库做用户验证等操作。mysql或PostgreSQL所有配置、监控历史数据、告警记录的存储层。Zabbix对数据库依赖很重初始化时要导入大量schema。有人会问为什么不直接用官方那个all-in-one的zabbix-appliance镜像那个镜像确实把三个角色打包到一起了启动一个容器就全有了适合快速体验。但生产环境我不推荐理由很实际它把数据库和Server绑在一起扩不了、拆不开做数据备份要进容器里面操作日志也不好分端查看。拆成三个容器之后数据库出问题看MySQL日志、Server出问题看Server日志边界清楚排错效率完全不同。2.2 版本搭配别傻傻用latest版本选择是我特别想提醒的。很多人图省事直接写image: zabbix/zabbix-server-mysql:latest这是个大坑。latest会随时指向最新版本今天启动的是7.0明天重启变成7.2数据库结构可能就不兼容了升级是好事但不可控的升级就是灾难。我当时用的是Zabbix 6.4 LTS版本这个版本在长期支持期内非常稳定配合的数据库用MySQL 8.0。镜像Tag对应关系建议去Docker Hub页面确认一下拿6.4举例子大致是这样的组合组件镜像Tag说明Zabbix Serverzabbix/zabbix-server-mysql:ubuntu-6.4-latest带MySQL支持的Server版本Zabbix Webzabbix/zabbix-web-nginx-mysql:ubuntu-6.4-latestWeb前端Nginx版数据库mysql:8.0官方MySQL选8.0稳定版这种组合的好处是三个镜像版本绑定清晰升级时全部改成7.0-latest之类的Tag即可互相兼容性有官方保障。如果你要用PostgreSQL做存储镜像要换成对应的zabbix-server-pgsql其他逻辑大同小异。2.3 网络规划与数据卷设计三个容器之间要通信最简单可靠的方式是放在同一个桥接网络里通过容器名互相访问。这样Web容器访问Server就不用写IP直接写zabbix-server这个服务名Docker内置DNS会解析到对应容器IP。数据卷方面MySQL容器的数据目录是必须挂载出来的不挂的话容器一删数据就没了。Zabbix Server和Web容器一般是无状态的可以不挂数据卷但如果你改了Web界面的一些文件比如自定义字体、logo就得挂载对应目录。我刚上线那会儿没挂任何数据卷后来升级容器版本时Web里的自定义logo全丢了只能重新换这才老实做了完整的数据卷规划。2.4 资源规划别抠门监控平台的资源消耗主要是两块数据库存储和内存。Zabbix默认的housekeeper会定期清理历史数据但如果你监控的主机数量多、采集频率设得密数据库还是会快速膨胀。我自己的经验是50台主机以内8G内存的服务器足够跑数据库存储按每台主机每天几十MB去估算预留100GB硬盘比较稳妥。内存方面MySQL的buffer pool默认128MB对Zabbix这种大量写入型负载来说偏小我把它调到了512MB。Zabbix Server和PHP-FPM单向启动就吃几百MB加上系统本身8G内存实际用下来峰值在4到5G之间还算舒适。别用2G内存的小机器硬跑卡顿和OOM会让你怀疑人生。3. 完整部署过程编写compose、初始化、验证3.1 编写docker-compose.yml先把我的compose文件贴出来这是经过生产环境验证过的版本国内网络下直接用没问题version: 3.8 networks: zbx_net: driver: bridge volumes: zabbix-db-data: driver: local 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 TZ: Asia/Shanghai command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_bin - --default-time-zone8:00 volumes: - zabbix-db-data:/var/lib/mysql networks: - zbx_net healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -uroot, -proot_pwd] interval: 10s timeout: 5s retries: 5 zabbix-server: image: zabbix/zabbix-server-mysql:ubuntu-6.4-latest container_name: zabbix-server environment: DB_SERVER_HOST: mysql DB_SERVER_PORT: 3306 MYSQL_DATABASE: zabbix MYSQL_USER: zabbix MYSQL_PASSWORD: zabbix_pwd TZ: Asia/Shanghai ports: - 10051:10051 depends_on: - mysql networks: - zbx_net zabbix-web: image: zabbix/zabbix-web-nginx-mysql:ubuntu-6.4-latest 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 ports: - 8080:8080 depends_on: - mysql - zabbix-server networks: - zbx_net简单解释几个关键点。MYSQL_DATABASE、MYSQL_USER、MYSQL_PASSWORD这三个变量是在MySQL首次启动时自动创建数据库和用户的Zabbix Server和Web容器会拿同样的变量去连数据库。三处的密码必须保持一致否则后两个容器起不来。ZBX_SERVER_HOST是Web容器告诉PHPServer服务的地址在哪写成zabbix-server就是走Docker网络里的服务名解析。端口上10051是Zabbix Server接收agent数据的服务端口对外必须暴露否则被监控主机连不进来。Web端口我用8080映射到宿主机避免和Nginx默认80端口冲突。3.2 安装Docker和配置镜像加速如果你还没有Docker环境Ubuntu系统上执行apt update apt install -y docker.io docker-compose-v2 systemctl enable --now dockerCentOS系统类似用yum install docker-ce docker-compose-plugin这里就不展开了。装完之后要立刻做的事是配置registry mirror不然后面拉镜像会急死你。编辑/etc/docker/daemon.json{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.com ] }改完重载Docker服务systemctl daemon-reload systemctl restart docker这里多一句嘴镜像加速地址可能随着网络环境变化失效如果拉镜像还是慢可以搜一下当前可用的公共加速地址或者用代理镜像的方式拉取。另外我习惯提前手动docker pull mysql:8.0这类大镜像慢是慢一点但总好过部署到一半卡住。3.3 启动顺序与数据库初始化启动命令很简单docker compose up -d但启动过程不是一条命令就完了。MySQL容器首次启动要执行初始化脚本、创建数据库耗时比较久Zabbix Server容器启动了会反复尝试连接数据库一旦连不上就报错退出。所以depends_on其实只能保证容器启动顺序不能保证数据库真正就绪。我在compose里加了healthcheck但docker compose的depends_on要配合condition: service_healthy才能生效上面只写了简单的depends_on保险的做法是启动后等一下再看docker compose logs -f mysql看到类似ready for connections的日志再启动Zabbix Server和Web容器docker compose restart zabbix-server zabbix-web正常情况下Server容器首次启动会自动完成数据库表结构的初始化这个过程会持续几分钟。观察Server日志docker compose logs -f zabbix-server看到server started字样基本就成功了。我第一次部署时没等数据库就绪就查看Server状态看到报错就慌结果只是启动时序问题。3.4 浏览器访问Web并处理access denied数据库初始化完成后浏览器访问http://服务器IP:8080会进入安装引导页面。Zabbix会检查PHP环境和数据库连接这里有个常见问题数据库文件里已经写了时区和默认配置向导页面会让你填数据库连接信息如果填的密码跟compose里的不一致就会报Access denied for user zabbixlocalhost (using password: YES)这个报错我在热搜词里看到很多人遇到。原因基本可以锁定在密码填错了、或者数据库用户权限不对、或者Docker网络里MySQL的host识别有问题。按顺序排查先确认compose里的MYSQL_PASSWORD和向导里填的是否一致再确认MySQL容器里用同样的命令手动连一次docker exec -it zabbix-mysql mysql -uzabbix -pzabbix_pwd zabbix能连上数据库层面就没问题回头检查向导填写项。进去之后第一件事把默认管理员账号Admin密码zabbix的密码改掉别拖。3.5 时区问题的修复部署完成后的第一个小惊喜就是告警时间不对。我收到第一条测试告警显示的时间比北京时间慢了8小时查了一圈才找到原因虽然compose里Web容器的环境变量写了PHP_TZ: Asia/Shanghai但如果Zabbix版本对时区变量的支持有差异默认可能还是UTC。正确的排查手段是看Web页面右上角的时间以及告警里的时间戳。如果时间还是UTC几个地方逐一改Web容器环境变量确认是PHP_TZZabbix 6.4里确实认这个变量MySQL容器里执行SELECT NOW();确认数据库时间偏移再不行就在Zabbix的PHP配置文件里手动指定date.timezone。我当时是重新创建了Web容器并在环境变量里加上PHP_TZ才解决的。这一步千万别跳过否则后面看所有告警事件都要在心里加8小时很容易误判。4. Zabbix server is not running的完整排查链路4.1 这个提示到底在说什么部署完成、Web能访问了但页面顶部会出现一行红字提醒Zabbix server is not running: the information displayed may not be current. 这个提示几乎每个用Zabbix的人都会遇到它出现在一个特定的前提条件下Web前端连不上Server或者Server进程没有正常从数据库取到运行时信息。注意这里的s not running不一定是Server容器挂了很多时候容器活得好好的但内部进程因为连不上数据库或者配置异常处于一种半死不活的状态。我当时看到这行字第一反应是看容器状态docker ps显示三个容器全都是Up于是被误导了很久以为问题是Web到Server的网络不通。实际上排查思路应该是从Server进程本身入手。4.2 完整排查顺序我建议按下面的顺序排查这是我踩过几次坑之后总结出的最适合容器环境的一套链路第一步确认Server进程状态docker exec -it zabbix-server ps aux看有没有zabbix_server进程。如果没有说明容器启动后进程崩了或者反复重启看日志docker compose logs zabbix-server | tail -100第二步确认数据库连接。Server日志里最常见的是连不上MySQLcannot connect to database: Cant connect to local MySQL server through socket在容器里手动测一次连接docker exec -it zabbix-server bash mysql -h mysql -uzabbix -pzabbix_pwd zabbix -e select 1能查到数据说明连接正常。如果这里失败优先检查compose里的DB_SERVER_HOST写的是不是mysql而不是localhost或127.0.0.1。这个错误很经典在容器内localhost指容器自己不是MySQL容器。第三步确认Server监听的端口和订阅的IP。如果agent连接不上页面不显示数据看Server日志有没有cannot send list of active checks to xxx: host [xxx] not found这类信息一般指向agent主动模式配置问题。如果是Server is not running这种提示更多时候是Web到Server的通信问题。Web容器里有一个配置文件指向ZBX_SERVER_HOST确认写成zabbix-server。第四步排除资源不足导致的进程被OOM。Docker容器默认没有内存限制但如果宿主机本身内存吃紧内核会杀掉占用高的进程。看dmesg | tail有没有Out of memory记录。我测试环境就遇到过内存4G跑MySQL和Zabbix每跑几天Server就无声无息挂了最后加了交换分区才稳定。4.3 常见根因对照表现象根因快速修复Server日志显示连接MySQL被拒DB_SERVER_HOST写错改为容器服务名mysqlWeb页面提示Server未运行日志无报错Server进程未监听或繁忙ps检查进程必要时docker compose restart zabbix-server告警时间全部是UTC缺少时区设置添加TZAsia/Shanghai环境变量添加主机后无数据agent主动模式连不上Server 10051端口检查防火墙放行10051端口Server反复重启数据库未初始化完成等MySQL就绪后重启Server容器4.4 我遇到的那次有意思的坑有一次我排查了很久都没找到原因日志一切正常进程正常数据库连接正常但页面就是提示Server没运行。后来发现是我手贱改了Web容器里的一个nginx配置把代理超时时间调短了结果前端请求Server接口时频繁超时页面误判成Server不可用。所以这个提示偶尔也是假警报排查时别忽略Web容器自身的配置和网络延迟。如果你改了compose之外的东西比如进容器改了配置文件重启容器后所有修改都会丢失这个特性有时候帮你排错有时候就是坑——改完忘了排查无头绪。修复之后怎么确认回到Web页面刷新红字消失变成绿点然后在报表里生成一份最新数据能看到实时的host监控数据就说明链路全通了。5. 添加被监控对象从Linux主机到Windows显卡再到交换机5.1 Linux主机agent安装的两种模式Zabbix装完只是开始真正让监控平台发挥作用的是把机器纳管进来。对于Linux服务器最常用的是安装Zabbix agent。分两种模式被动模式Server主动拉数据和主动模式Agent主动上报数据。如果主机和Server不在同一内网或者被监控机器在NAT后面建议用主动模式只需要Agent能连上Server的10051端口即可同一内网里两者都可以。Ubuntu上装agentwget https://repo.zabbix.com/zabbix/6.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.4-1ubuntu22.04_all.deb dpkg -i zabbix-release_6.4-1ubuntu22.04_all.deb apt update apt install -y zabbix-agent配置/etc/zabbix/zabbix_agentd.conf里三个核心项Server你的zabbix-server-IP ServerActive你的zabbix-server-IP:10051 Hostname你的主机名建议唯一最后启服务systemctl enable --now zabbix-agent。这里有个容易混淆的点Server这一行是给被动模式用告诉Agent允许谁来连ServerActive是主动模式用告诉Agent主动往哪里上报。两个都要填默认模板里两种模式都会尝试。5.2 在Web界面添加主机Web界面操作不复杂配置Configuration- 主机Hosts- 创建主机。填主机名称、可见名称填Agent接口的IP如果agent主动上报这个IP填本机IP即可然后选模板。模板是Zabbix的灵魂。添加Linux主机选Linux by Zabbix agent模板就够了会自动关联CPU、内存、磁盘、网络等一堆监控项。添加完等一两分钟点主机前面的监控Monitoring- 最新数据就能看到数据在刷新。如果数据一直不来第一反应看Agent日志路径通常是/var/log/zabbix/zabbix_agentd.log里面会明确写是连接失败还是认证失败。5.3 Windows主机的GPU监控Windows主机的agent安装和Linux大同小异下载Windows版agent解压后运行安装脚本配置zabbix_agentd.conf同理。但Windows上有一个特定的需求常被问到监控GPU状态。很多做深度学习或者跑图形渲染的机器需要盯着显卡温度、显存占用和功耗。Zabbix自带的Windows模板里其实没有GPU监控项需要借助NVIDIA官方工具配合。简单可用的方案是在Windows机器上安装NVIDIA的nvidia-smi命令行工具然后通过Zabbix的system.run功能定时执行nvidia-smi --query-gputemperature.gpu,utilization.gpu,memory.used --formatcsv,noheader,nounits去采集数据。用的时候有几个坑要提前讲一是Zabbix Agent默认不允许开启system.run这种远程命令功能必须在zabbix_agentd.conf里把EnableRemoteCommands1打开这有安全风险要确认机器在可信内网里二是执行命令的用户权限建议给Agent服务使用管理员账户启动否则nvidia-smi会读不到显存信息三是在manjaro这类Arch系Linux上监控NVIDIA GPU可以直接装zabbix-agent加nvidia-utils包模板里用proc.num和自定义UserParameter实现。Linux下监控GPU比Windows还简单一些。5.4 交换机监控走SNMP协议网络设备的监控方式和服务器完全不一样服务器装agent交换机一般用SNMP。前提是交换机开启了SNMP服务并设置好团体字community string。比如华为交换机snmp-agent snmp-agent sys-info version v2c snmp-agent community read cipher publicWeb界面添加主机时接口类型选SNMP填交换机的IP和团体字模板选SNMP by Zabbix或厂商专用模板。SNMP的OID你得提前规划好Zabbix模板里已经预置了大量常用OID端口流量、CPU、内存都能直接采。如果模板里没有你要的项可以自己用SNMP walk工具查OID然后在模板里添加键值为snmp.get[OID]的监控项。我负责的三台接入层交换机用SNMP v2c监控端口流量和状态两年了除了风扇报警之外没出过什么大问题。监控交换机的好处是能提前发现端口异常波动比如某个端口流量突然飙高有可能是环路也有可能是有人在一台机器上下大文件这个信息对你的网络管理很有帮助。唯一要提醒的是SNMP v2c是明文传输团体字等于密码不要把团体字设得太简单也不要在不可信网络里直接暴露SNMP端口。6. 告警平台和可视化从通知到大屏的完整落地6.1 告警媒介配置钉钉WebhookZabbix的告警能力是靠媒介Media实现的默认支持邮件现在用得最多的其实是钉钉/企业微信/飞书的Webhook机器人。拿钉钉举例你在钉钉群里添加一个自定义机器人会得到一个Webhook地址类似https://oapi.dingtalk.com/robot/send?access_tokenxxx。然后在Zabbix里配置一个告警媒介管理Administration- 媒介Media types- 创建媒介类型选HTTP类型URL填Webhook地址请求方式POST请求体用JSON{ msgtype: text, text: { content: {ALERT.MESSAGE} } }{ALERT.MESSAGE}是Zabbix里的宏发送时会自动替换成告警内容。这个配置我第一次花了半小时才跑通关键坑在于Zabbix发送HTTP请求时需要勾选内容类型为application/json不勾的话钉钉会返回400错误提示消息格式不正确。6.2 触发器与动作让告警真正闭环告警媒介配好之后如果不创建动作Action告警还是不会发出去。动作的逻辑很简单当某类触发器Trigger触发时执行何种操作、通知什么人、发送什么内容。入口在配置Configuration- 动作Actions默认有一个Report problems to Zabbix administrators的动作把它启用了再把自己挂到管理员用户组的媒介上就能收到告警。我建议每个监控项都单独建触发器别用模板里所有默认的阈值。比如磁盘使用率模板默认80%触发warning但对不同的机器这个阈值该不一样。数据库服务器可能50%就要紧张日志服务器90%也还能撑。触发器表达式的地方可以改掉last(/Linux by Zabbix agent/vfs.fs.size[/,pused])80这个表达式的意思是当前根分区使用率大于80%就触发。你可以改成适合自己业务的阈值。另外触发器一定要配置恢复表达式否则磁盘降下来了告警还在群里的同事会一直收到重复告警。恢复表达式其实不用单独写Zabbix默认反向触发一次但要确认触发器和恢复的严重级别设置合理。6.3 监控大屏 Grafana做数据可视化Zabbix自带的Web界面看单个主机数据还行做一个大屏墙给领导展示就差了点。我这边用的方案是Grafana官方有Zabbix插件配置直观。Docker跑一个Grafana容器一行命令的事docker run -d --name grafana -p 3000:3000 grafana/grafana在Grafana里装Zabbix数据源插件填Zabbix Server的API地址通常是http://zabbix-server:8080/api_jsonrpc.php和管理员账号然后就可以用Zabbix的数据源做仪表盘了。Grafana的仪表盘是真正的可视化生产力拖拽图表、配告警规则、定时截图体验比原生Web友好太多。热搜词里有人问grafana 生成pdf监控报告这个场景挺常见给客户或领导出月度监控报告截图太丑手动整理太累。Grafana本身不直接出PDF但可以用第三方工具grafana-reporter定时抓取仪表盘渲染成图片或PDF文件配合crontab每周一早上自动发送到邮箱整个监控报告就自动化了。这个我还没有完全落地目前用的是Grafana内置的渲染服务访问一个带viewPanel参数的URL就能导出PNG图片再拼到Word里工作量也还能接受。6.4 大屏落地后的维护经验最后聊聊监控平台上线之后怎么维护。首先是告警疲劳问题——告警太多人就会麻木到时候真正出事了反而没人看。我上线第一个月钉钉群里一天能收到几十条告警全是各种小波动。后来我狠下心来花了一个周末把每一条告警都过了一遍能合并的合并能静默的静默阈值不合理的全部调掉。告警量降到每天个位数之后大家才开始真正重视每一条消息。其次是定期检查数据库容量。MySQL的数据卷不会自动瘦身housekeeper默认会清理旧数据但如果历史数据保留时间设得太长或者监控项多、采集间隔短数据库还是会迅速膨胀。我一般是每季度看一次表大小SELECT table_name, round(((data_length index_length) / 1024 / 1024), 2) AS Size(MB) FROM information_schema.tables WHERE table_schema zabbix ORDER BY (data_length index_length) DESC;如果history和trends系列表已经膨胀到占数据库总大小80%以上说明历史保留期设得太长或者采集频率过于激进。把不需要长期保存的监控项改成trends模式只保存趋势值不保存历史原始值能省下大量空间。关于Zabbix的日常维护最后再分享一条实际经验在升级Zabbix容器版本之前一定先把数据库完整备份一次。我自己用的是一个简单粗暴的办法直接把数据卷打包docker run --rm -v zabbix-db-data:/data -v $(pwd):/backup alpine tar czf /backup/zabbix-db-$(date %Y%m%d).tar.gz -C /data .这个备份方案的好处是不依赖mysqldump也不需要停MySQL容器作为升级前的兜底手段足够了。真到要恢复的时候把tar解包回数据卷目录重新启动MySQL容器就完事。我升级过两次版本一次顺利一次因为镜像Tag写错导致Web连不上数据库当时就是靠这个备份秒回滚的。写这篇东西的时候刚好看到网上有人在问zabbix server is not running的解决办法忍不住回忆了一下我当初半夜爬起来看日志的狼狈样。希望看完这篇文章之后你能把步骤、坑位、排查链路都提前摸清楚把Docker部署Zabbix这件事变成一次顺手就能完成的操作而不是又一次通宵排障。