企业官网建设流程全解析

两年前我接手公司运维的时候，服务器数量已经涨到三十多台，还有几台交换机和一批Windows机器。当时摆在面前最头疼的问题就是：用什么做监控。Prometheus生态很强，但学起来曲线陡，尤其对传统网络设备支持没想象中友好；夜莺那一类新平台也在看，但团队里并没有人用过，试错成本不小。最后选来选去还是定在了Zabbix——理由很朴素：它有成熟的企业级监控与告警平台能力，模板多、文档全、社区答案一搜一大把，而且对服务器、网络设备、Windows主机的覆盖几乎是开箱即用。真正让我下决心的，是Docker部署Zabbix这条路能把最折磨人的安装和依赖问题直接绕开，把精力留给监控本身。这篇东西就是我当时从零到上线的完整记录，包含踩过的坑、排查思路和现在仍在用的日常操作，适合刚接触Zabbix、正准备搭建环境，或者已经被各种依赖问题折腾得想放弃的朋友参考。

1. 为什么我把Zabbix塞进Docker而不是装在裸机上

1.1 裸机安装Zabbix的一堆"隐形税"

先说说为什么我一开始犹豫了很久。Zabbix的传统安装方式，在官网文档里写得很清楚：先装数据库、再装Server、再装Web前端，每一步都有版本要求。听起来不难，真操作起来就是另一回事了。尤其是老系统，比如我手头那台CentOS 7，自带的PHP版本是5.4，Zabbix 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 Server，Windows上验证的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举例子，大致是这样的组合：

这种组合的好处是三个镜像版本绑定清晰，升级时全部改成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-server=utf8mb4 - --collation-server=utf8mb4_bin - --default-time-zone=+8: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容器告诉PHP：Server服务的地址在哪，写成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 docker

CentOS系统类似，用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 'zabbix'@'localhost' (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_TZ，Zabbix 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日志里最常见的是连不上MySQL：

cannot connect to database: Can't 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 常见根因对照表

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上装agent：

wget https://repo.zabbix.com/zabbix/6.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.4-1+ubuntu22.04_all.deb dpkg -i zabbix-release_6.4-1+ubuntu22.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-gpu=temperature.gpu,utilization.gpu,memory.used --format=csv,noheader,nounits去采集数据。

用的时候有几个坑要提前讲：一是Zabbix Agent默认不允许开启system.run这种远程命令功能，必须在zabbix_agentd.conf里把EnableRemoteCommands=1打开，这有安全风险，要确认机器在可信内网里；二是执行命令的用户权限，建议给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 public

Web界面添加主机时，接口类型选SNMP，填交换机的IP和团体字，模板选SNMP by Zabbix或厂商专用模板。SNMP的OID你得提前规划好，Zabbix模板里已经预置了大量常用OID，端口流量、CPU、内存都能直接采。如果模板里没有你要的项，可以自己用SNMP walk工具查OID，然后在模板里添加键值为snmp.get[OID]的监控项。

我负责的三台接入层交换机，用SNMP v2c监控端口流量和状态，两年了除了风扇报警之外没出过什么大问题。监控交换机的好处是能提前发现端口异常波动，比如某个端口流量突然飙高，有可能是环路，也有可能是有人在一台机器上下大文件，这个信息对你的网络管理很有帮助。唯一要提醒的是，SNMP v2c是明文传输，团体字等于密码，不要把团体字设得太简单，也不要在不可信网络里直接暴露SNMP端口。

6. 告警平台和可视化：从通知到大屏的完整落地

6.1 告警媒介配置：钉钉Webhook

Zabbix的告警能力是靠"媒介（Media）"实现的，默认支持邮件，现在用得最多的其实是钉钉/企业微信/飞书的Webhook机器人。拿钉钉举例，你在钉钉群里添加一个自定义机器人，会得到一个Webhook地址，类似https://oapi.dingtalk.com/robot/send?access_token=xxx。然后在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这件事变成一次顺手就能完成的操作，而不是又一次通宵排障。