当一台 VPS 变成十几台，单靠 top、df -h 和“网站打不开再登录排查”已经不够。你需要提前知道 CPU 是否持续打满、磁盘是否将在三天内耗尽、某个 systemd 服务是否反复重启，并在故障影响用户前收到通知。Zabbix 把指标采集、主机发现、模板、触发器、图表、告警和权限管理集中到一个平台，适合希望长期管理多台 Linux、Windows、网络设备或业务服务的团队。
本文以 Zabbix 7.4、Ubuntu 24.04、Docker Compose、PostgreSQL 和 Zabbix Agent 2 为基准，完成服务端部署、Caddy HTTPS、远程主机接入、主动与被动采集、PSK 加密、邮件/Webhook 告警、数据保留、备份、升级和常见故障排查。文中的版本判断与端口以 2026 年 9 月的 Zabbix 官方 7.4 文档为准；8.0 文档目前属于开发分支，不应当直接当作生产稳定版教程照搬。
Zabbix 不只是“看 CPU 曲线”的仪表盘。它的核心能力包括：
- 使用 Agent 2、SNMP、IPMI、JMX、HTTP、数据库和云 API 等方式采集数据；
- 通过官方模板批量创建监控项、触发器、图表和自动发现规则；
- 在磁盘不足、服务停止、证书即将过期或接口错误率升高时触发告警；
- 通过邮件、Webhook、短信或自定义脚本发送通知；
- 使用主机组、用户组和角色控制不同团队能看到的资源；
- 用代理节点扩展到多机房、内网和高延迟网络。
如果你只监控 2–5 台机器，希望十分钟内完成安装，Beszel 轻量服务器监控教程更省资源；只关心网站是否在线，可以选择 Uptime Kuma。需要 PromQL、日志关联和高度自由的可视化时，可阅读Prometheus + Grafana 监控方案。需要大量现成模板、统一触发器、资产管理和细粒度权限时，Zabbix 的一体化工作流更合适。
| 方案 | 主要优势 | 主要代价 | 推荐场景 |
|---|---|---|---|
| Zabbix | 模板、触发器、发现、告警和权限完整 | 数据库与参数较多，学习成本较高 | 多主机、网络设备、长期运维 |
| Prometheus + Grafana | 云原生生态强，PromQL 灵活 | 告警、资产和长期存储通常要组合多个组件 | Kubernetes、应用指标 |
| Beszel | 部署简单、界面轻量 | 企业级模板与复杂触发器较少 | 小规模 VPS |
| Uptime Kuma | HTTP/TCP 可用性监控直观 | 不适合深度主机指标与容量分析 | 网站与端口探活 |
本文采用四个主要组件：
浏览器 -> Caddy :443 -> Zabbix Web :8080
|
+-> PostgreSQL
受监控主机 Agent 2 -> Zabbix Server :10051（主动检查）
Zabbix Server -> 受监控主机 Agent 2 :10050（被动检查）
Web 前端、Zabbix Server 与 PostgreSQL 在监控 VPS 上以容器运行；被监控主机直接安装 Agent 2。数据库不映射到公网，Web 的容器端口只绑定回环地址，由 Caddy 提供域名和 HTTPS。
Zabbix 官方说明数据库容量主要取决于每秒处理值数量、历史数据保留期、趋势数据保留期和事件数量。不能只按“主机台数”估算。下面是小型 VPS 环境的保守起步值，不是官方容量保证：
| 规模 | 建议起步配置 | 数据保留建议 |
|---|---|---|
| 5–20 台主机，基础 Linux 指标 | 2 vCPU、4GB 内存、60GB NVMe | History 7–14 天，Trends 365 天 |
| 20–100 台主机，含服务与接口监控 | 4 vCPU、8GB 内存、120GB NVMe | 先观察 NVPS 与数据库增长 |
| 100 台以上或大量低间隔监控项 | 8 vCPU、16GB 内存起 | 压测后拆分 Proxy、调优数据库 |
1GB 或 2GB 内存虽然可能启动，但 PostgreSQL、Server、Web 和 Docker 同机后余量很小。监控系统本身一旦因 OOM 停止，最需要告警的时候反而会失声。生产环境还应把备份放到另一台机器或对象存储，而不是只留在监控 VPS 的同一块磁盘。
准备一个域名，例如 zabbix.example.com，添加指向 VPS 公网 IP 的 A 记录。若没有正确可用的 IPv6，就不要添加错误的 AAAA 记录。
所有 Zabbix 组件必须保持准确时间。官方要求页特别强调时间同步，因为时间漂移会造成数据时间戳、触发器判断和图表异常。Ubuntu 24.04 可以检查：
timedatectl status
systemctl status systemd-timesyncd --no-pager
默认端口按实际采集模式开放：
| 端口 | 方向 | 用途 | 建议 |
|---|---|---|---|
80/443 TCP | 浏览器到监控 VPS | HTTP 验证与 HTTPS 管理界面 | 对公网开放，后台可再加 VPN/IP 限制 |
10051/TCP | Agent/Proxy 到 Server | 主动检查、Trapper、Proxy | 只允许受监控网段或通过 VPN |
10050/TCP | Server 到 Agent 2 | 被动检查 | 每台 Agent 只允许 Zabbix Server IP |
5432/TCP | 内部容器网络 | PostgreSQL | 不映射公网 |
8080/8443 TCP | 本机 Caddy 到 Web 容器 | 容器前端 | 只绑定 127.0.0.1 |
主动检查由 Agent 2 主动连接 Server 的 10051/TCP，适合 NAT 后、IP 经常变化或不希望对外开放 10050 的主机。被动检查由 Server 连接 Agent 2 的 10050/TCP，配置直观，但要求 Server 能直接访问 Agent。两种模式可以并存，最终取决于模板内监控项类型。
若端口已经监听但外部仍连不上，可按端口、防火墙和安全组排查指南同时检查云安全组、UFW、Docker 端口映射和监听地址。
先更新系统并安装 Git、Make、OpenSSL 和 Caddy。Docker 建议按照 Docker 官方 Ubuntu 仓库安装；如果机器已经在运行 Docker，不要重复执行会改动仓库配置的脚本。
sudo apt update
sudo apt full-upgrade -y
sudo apt install -y git make openssl ca-certificates curl caddy
docker --version
docker compose version
Zabbix 7.4 官方容器文档要求 Docker Compose 2.24.0 或更高版本：
docker compose version --short
如果输出低于 2.24.0，先升级 Docker Compose 插件。生产部署还应理解健康检查、日志轮转、资源限制和回滚，可先查看Docker Compose 生产配置清单。
官方 zabbix/zabbix-docker 仓库同时包含 MySQL/MariaDB 与 PostgreSQL 组合。本文明确检出 7.4 分支，并使用 compose_pgsql.yaml：
sudo git clone --depth 1 --branch 7.4 \
https://github.com/zabbix/zabbix-docker.git /opt/zabbix-docker
sudo chown -R "$USER":"$USER" /opt/zabbix-docker
cd /opt/zabbix-docker
git branch --show-current
docker compose version
预期分支是 7.4。仓库默认 .env 使用 Alpine 系列 Zabbix 7.4 镜像和 PostgreSQL 17 Alpine；Zabbix 7.4 官方需求页支持 PostgreSQL 15–18。
不要直接使用仓库里的示例数据库密码。官方仓库的 env_vars/.POSTGRES_PASSWORD 是示例值 zabbix，必须在第一次启动前替换：
cd /opt/zabbix-docker
umask 077
openssl rand -base64 36 | tr -d '\n' > env_vars/.POSTGRES_PASSWORD
printf '\n' >> env_vars/.POSTGRES_PASSWORD
chmod 600 env_vars/.POSTGRES_PASSWORD
不要把真实密码复制进教程、工单或 Git 提交。Compose 通过文件型 secret 把 PostgreSQL 用户和密码提供给 Server、Web 与数据库容器。
官方 Compose 默认会发布 Web 端口。为了避免 8080 和 8443 绕过 Caddy 直接暴露，创建本地覆盖文件，把两个端口限制到回环地址：
services:
zabbix-web-nginx-pgsql:
ports:
- name: web-http
target: 8080
published: "8080"
host_ip: 127.0.0.1
protocol: tcp
- name: web-https
target: 8443
published: "8443"
host_ip: 127.0.0.1
protocol: tcp
保存为 /opt/zabbix-docker/compose.local.yaml，先渲染配置检查语法和最终端口：
cd /opt/zabbix-docker
docker compose -f compose_pgsql.yaml -f compose.local.yaml config > /tmp/zabbix-compose-rendered.yaml
grep -nE 'host_ip|published|target' /tmp/zabbix-compose-rendered.yaml
确认 Web 的 host_ip 是 127.0.0.1，再启动最小组件集：
docker compose -f compose_pgsql.yaml -f compose.local.yaml pull
docker compose -f compose_pgsql.yaml -f compose.local.yaml up -d
docker compose -f compose_pgsql.yaml -f compose.local.yaml ps
首次启动需要初始化 PostgreSQL 架构，时间取决于 VPS 磁盘和镜像下载速度。不要看到初始化容器退出就直接判断失败；server-db-init 正常完成后本来就会结束。重点检查 PostgreSQL、Zabbix Server 和 Nginx Web 是否为运行或健康状态：
docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=100 postgres-server
docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=100 zabbix-server
docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=100 zabbix-web-nginx-pgsql
curl -I http://127.0.0.1:8080/
ss -lntp | grep -E ':8080|:8443|:10051'
8080 和 8443 应只出现在 127.0.0.1；10051 是否对外监听取决于你是否需要外部 Agent 主动连接。即使必须发布 10051，也应在云安全组和主机防火墙中限制来源。
创建 /etc/caddy/Caddyfile：
zabbix.example.com {
encode zstd gzip
reverse_proxy 127.0.0.1:8080
header {
Strict-Transport-Security "max-age=31536000; includeSubDomains"
X-Content-Type-Options "nosniff"
Referrer-Policy "strict-origin-when-cross-origin"
}
}
把示例域名替换成真实域名，检查并重载：
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
sudo systemctl status caddy --no-pager
curl -I https://zabbix.example.com/
Caddy 会自动申请和续期证书，但前提是域名已正确解析，公网 80/443 能到达该 VPS，且没有错误 AAAA 记录。更多多域名、反向代理头和证书排障可参考Caddy 自动 HTTPS 教程。
Zabbix 官方快速入门给出的初始账号是：
用户名：Admin
密码：zabbix
第一次登录后立即修改 Admin 密码。不要把 Caddy 的 HTTPS 当成完整后台安全策略，还应完成：
- 为每位管理员创建独立账号，不共享
Admin； - 按职责分配角色、用户组和主机组权限；
- 启用强密码策略，条件允许时配置 MFA；
- 不需要公网管理时，通过 WireGuard/Tailscale 或固定 IP 限制前端；
- 在系统、防火墙和 Zabbix 内分别记录变更；
- 让监控平台自己也被外部探活，避免“监控系统已死但没人知道”。
Zabbix 前端在连续五次登录失败后会暂停 30 秒，但这不是替代反向代理访问限制、MFA 和强密码的理由。
下面在一台被监控 Ubuntu 24.04 VPS 上操作。使用 Zabbix 官方 7.4 软件源，不要从不明脚本安装 Agent：
cd /tmp
wget https://repo.zabbix.com/zabbix/7.4/release/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.4+ubuntu24.04_all.deb
sudo dpkg -i zabbix-release_latest_7.4+ubuntu24.04_all.deb
sudo apt update
sudo apt install -y zabbix-agent2
zabbix_agent2 -V
先决定使用主动检查还是被动检查。
主动模式只需要 Agent 能访问监控 VPS 的 10051/TCP，更适合公网 VPS。编辑 /etc/zabbix/zabbix_agent2.conf 中的关键项：
ServerActive=zabbix.example.com:10051
Hostname=web-01.example.com
Hostname 区分大小写，并且必须与 Zabbix 前端创建主机时填写的 Host name 完全一致。没有 ServerActive 时，主动检查会被禁用。
被动模式由 Server 访问 Agent 的 10050/TCP：
Server=监控VPS的固定公网IP
ListenPort=10050
Hostname=web-01.example.com
Server 决定允许哪些 Server 或 Proxy 发起连接。不要为了省事写 0.0.0.0/0。同时在云安全组和 UFW 只允许监控 VPS：
sudo ufw allow from 监控VPS的固定公网IP to any port 10050 proto tcp
sudo ufw status numbered
检查配置并启动：
sudo zabbix_agent2 -t system.cpu.load
sudo systemctl enable --now zabbix-agent2
sudo systemctl status zabbix-agent2 --no-pager
sudo journalctl -u zabbix-agent2 -n 100 --no-pager
HTTPS 只保护浏览器到 Web 前端的链路，不会自动加密 Agent 与 Server 的通信。Zabbix 组件支持不加密、证书和 PSK 三种连接方式。小规模 VPS 可为每台主机生成独立 PSK：
sudo install -d -m 750 -o root -g zabbix /etc/zabbix/keys
sudo sh -c 'openssl rand -hex 32 > /etc/zabbix/keys/web-01.psk'
sudo chown root:zabbix /etc/zabbix/keys/web-01.psk
sudo chmod 640 /etc/zabbix/keys/web-01.psk
主动检查增加：
TLSConnect=psk
TLSPSKIdentity=web-01-psk
TLSPSKFile=/etc/zabbix/keys/web-01.psk
如果同时使用被动检查，再增加：
TLSAccept=psk
然后重启 Agent：
sudo systemctl restart zabbix-agent2
sudo journalctl -u zabbix-agent2 -n 50 --no-pager
在 Zabbix 前端主机的 Encryption 标签页选择相同连接模式，填写完全一致的 PSK identity 和密钥。密钥不要发送到群聊，也不要让多台主机共用同一份。官方说明 Agent 2 的 TLSConnect 用于主动检查的出站连接，TLSAccept 用于被动检查的入站连接；两端模式不一致时不会自动回退到另一种加密方式。
进入 Data collection → Hosts → Create host：
Host name填web-01.example.com，与 Agent 2 的Hostname完全一致；- 加入例如
Linux servers的主机组； - 主动模式可创建 Agent interface 但不依赖 Server 直连它；被动模式填写主机可达 IP 和
10050； - 链接 Zabbix 7.4 自带的 Linux Agent/Agent active 对应模板；
- 在 Encryption 中录入该主机的 PSK 配置；
- 保存后观察 Availability、Latest data 和 Agent 日志。
不要一开始就把所有模板都挂上。模板越多、采集间隔越短，每秒新值数量和数据库增长越快。先满足 CPU、内存、磁盘、网络、进程和服务状态，再根据业务添加 Nginx、PostgreSQL、Docker 或自定义应用监控。
建议最先验证：
Latest data是否出现 CPU、内存和文件系统指标；- 主机名是否完全匹配；
- 主动检查能否连接
10051； - 被动检查时 Server 能否连接 Agent
10050； Monitoring → Problems是否出现 unsupported item；- Server 和 Agent 2 的系统时间是否一致。
Zabbix 官方当前文档支持 Email、SMS、自定义脚本与 Webhook 媒体类型。要真正收到通知，必须同时具备三个条件：可工作的媒体类型、用户账号上的 Media、以及匹配事件的 Action。
进入 Alerts → Media types，打开 Email 类型并填写 SMTP 服务器、端口、加密方式、发件地址和认证信息。SMTP 密码优先使用宏管理，不要直接把明文秘密留在会被导出的媒体类型配置里。
然后：
- 在接收人的用户资料中打开 Media，添加邮箱地址；
- 选择接收时段和严重级别；
- 在 Alerts → Actions → Trigger actions 创建动作；
- 设置主机组、严重度等条件；
- 在 Operations 中选择用户或用户组；
- 创建一个测试触发器，验证 Problem 与 Recovery 两封通知。
只在媒体类型页面点“测试成功”不代表真实故障会通知，因为 Action、用户 Media 或权限仍可能缺失。
如果使用聊天机器人或工单系统，可复制官方内置 Webhook 媒体类型，再填写目标 URL、Token、频道和消息参数。密钥用 Secret 类型宏保存，并限制 Webhook 只向可信域名发请求。
生产前至少测试：
- Problem 消息是否包含主机、触发器、严重度和事件链接；
- Recovery 是否能关联原事件；
- 重复告警和升级步骤是否符合值班策略；
- 外部服务限流或不可用时 Zabbix 是否记录发送失败；
- 测试告警结束后是否恢复触发器和动作配置。
Zabbix 的 History 保存原始高粒度值，Trends 保存按小时汇总的数据。把所有 History 都保留一年通常没有必要，会明显增加 PostgreSQL 体积、备份时间和升级风险。
小规模环境可从以下策略起步，再根据合规与排障需求调整：
| 数据 | 起步保留期 | 用途 |
|---|---|---|
| 高频 History | 7–14 天 | 近期故障与细粒度分析 |
| 普通 History | 30 天以内 | 常规排障 |
| Trends | 365 天 | 容量趋势和同比 |
| Events/Alerts | 90–180 天 | 故障复盘 |
| Audit log | 按安全与合规要求 | 管理操作追踪 |
进入 Administration → Housekeeping 检查内部 housekeeping。官方说明它会删除过期或已删除的数据，防止数据库无限增长和性能下降。不要突然把保留期从一年缩到一天后期待数据库立刻变小；大量删除会产生数据库负载，空间回收也取决于 PostgreSQL 的维护机制。
每周记录容器、数据库和数据目录体积：
cd /opt/zabbix-docker
docker compose -f compose_pgsql.yaml -f compose.local.yaml ps
docker system df
sudo du -sh /opt/zabbix-docker/zbx_env
df -h /
同时在 Zabbix 内监控“监控 VPS”自身的磁盘空间、队列、进程和内部性能指标。
有效备份至少包含：
- PostgreSQL 数据库逻辑备份；
/opt/zabbix-docker/.env、env_vars、覆盖文件和zbx_env中的自定义脚本/证书；/etc/caddy/Caddyfile；- Agent 端的
/etc/zabbix配置和 PSK； - 一份写清版本、恢复顺序和 DNS/防火墙依赖的恢复文档。
创建数据库备份：
cd /opt/zabbix-docker
sudo install -d -m 700 /var/backups/zabbix
docker compose -f compose_pgsql.yaml -f compose.local.yaml \
exec -T postgres-server pg_dump -U zabbix -d zabbix -Fc \
> /var/backups/zabbix/zabbix-$(date +%F-%H%M).dump
ls -lh /var/backups/zabbix/
配置文件可单独归档，但包含数据库密码与 PSK，备份介质必须加密并限制权限：
sudo tar -C / -czf /var/backups/zabbix/zabbix-config-$(date +%F-%H%M).tar.gz \
opt/zabbix-docker/.env \
opt/zabbix-docker/env_vars \
opt/zabbix-docker/compose.local.yaml \
etc/caddy/Caddyfile
sudo chmod 600 /var/backups/zabbix/*
随后把备份同步到异机或对象存储，并定期在隔离环境恢复。只看到备份文件存在，不等于它能恢复。完整的数据库、Docker Volume、restic 与 rclone 演练流程可参考VPS 备份恢复演练。
恢复测试时，先部署相同主版本的 Zabbix 与空 PostgreSQL，再导入：
cat /path/to/zabbix.dump | docker compose \
-f compose_pgsql.yaml -f compose.local.yaml \
exec -T postgres-server pg_restore -U zabbix -d zabbix --clean --if-exists
这条命令会清理目标数据库中已存在的对象，只能在确认无用的恢复测试库或明确的灾难恢复流程中执行，不能对仍在服务的生产库随手运行。
官方 7.4 Compose 默认使用同分支的 latest 标签，因此 pull 可能拉到新的 7.4 补丁镜像。升级前必须阅读升级说明并备份数据库、配置和文件。Zabbix Server 启动时可能自动执行数据库升级；数据库升级失败时服务不会正常启动。
推荐流程：
- 记录当前镜像 ID、Zabbix 版本和 Git 提交；
- 完成异机数据库与配置备份；
- 在测试环境验证升级；
- 安排维护窗口并停止写入；
- 更新 7.4 分支 Compose 文件，渲染 diff；
- 拉取镜像并重建；
- 持续观察 Server 和 PostgreSQL 日志；
- 验证登录、Latest data、Problems、通知和 Agent 连接。
检查当前状态：
cd /opt/zabbix-docker
git rev-parse --short HEAD
docker compose -f compose_pgsql.yaml -f compose.local.yaml images
docker compose -f compose_pgsql.yaml -f compose.local.yaml exec -T zabbix-server zabbix_server -V
不要跨大版本盲目改分支后直接 up -d，也不要在没有数据库备份时依赖云快照。数据库回滚与容器镜像回滚必须配套；旧 Server 不能保证读取已升级的新数据库架构。
检查 PostgreSQL 健康状态、secret 文件权限和三个组件的日志：
cd /opt/zabbix-docker
docker compose -f compose_pgsql.yaml -f compose.local.yaml ps
docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=200 postgres-server
docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=200 zabbix-server
docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=200 zabbix-web-nginx-pgsql
如果你在首次启动后才修改 PostgreSQL 密码，数据库卷里的旧密码不会自动同步。不要反复删除卷碰运气；先确认是否有生产数据，再按 PostgreSQL 修改密码并同步 secret，或从已验证备份重建。
主动模式重点检查：
getent ahosts zabbix.example.com
nc -vz zabbix.example.com 10051
sudo journalctl -u zabbix-agent2 -n 100 --no-pager
被动模式从 Server 所在网络测试 Agent 的 10050，并核对云安全组、UFW 和 Server= 白名单。两种模式都要核对大小写敏感的 Hostname。
通常是 Agent 2 的 Hostname 与前端 Host name 不一致、主机被禁用、模板没有 active 类型监控项，或 Agent 无法连接 ServerActive。不要只改 Display name，它不是主动检查匹配使用的 Host name。
检查前端与 Agent 的连接方向、PSK identity、密钥内容和权限。主动检查看 TLSConnect，被动检查看 TLSAccept。复制密钥时多出的换行通常可被文件读取处理，但空格、错误路径、不同 identity 或前端选错加密模式都会失败。
先看新增主机、模板、低采集间隔、LLD 自动发现项、History/Trends 保留期和每秒处理值数量。盲目扩容磁盘只会推迟问题。先减少无价值监控项、调整保留策略，再评估 PostgreSQL 参数、分区或 TimescaleDB。
检查 A/AAAA 解析、Caddy 日志、公网 80/443、安全组，以及 Web 端口是否仍只监听 127.0.0.1：
getent ahosts zabbix.example.com
sudo journalctl -u caddy -n 100 --no-pager
curl -I http://127.0.0.1:8080/
curl -I https://zabbix.example.com/
ss -lntp | grep -E ':80|:443|:8080|:8443'
- Zabbix Server、Web、PostgreSQL 均正常运行，初始化容器正常完成；
- Web 的
8080/8443只绑定127.0.0.1； - 域名 HTTPS 有效，HTTP 自动转 HTTPS；
- 默认
Admin/zabbix密码已经修改； - 管理员使用独立账号、最小权限和 MFA；
- Agent 主动/被动模式与防火墙方向一致；
- PSK 已逐主机配置，未复用、未提交到 Git；
- Latest data 持续更新，主机时钟同步；
- 邮件或 Webhook 的 Problem 与 Recovery 均已实测；
- History、Trends、Events 和 Audit 保留期已规划；
- PostgreSQL 与配置已异机备份，并完成过恢复演练；
- 外部探活能够发现 Zabbix 本身离线。
小规模、低频采集时可能运行，但 PostgreSQL、Server、Web 和 Docker 同机会让内存余量很小。新部署更建议 4GB 内存起步，并设置 Swap、监控 OOM 和数据库增长。主机数不是唯一变量，监控项数量与采集间隔更重要。
公网 VPS、NAT 后主机和动态 IP 主机优先主动模式，只需出站访问 Server 的 10051/TCP。网络可控、Server 能直接访问 Agent 时可以使用被动模式。两者可以共存，但模板监控项类型、端口方向和加密配置必须匹配。
不一定。只使用主动检查时，Agent 主动连接 Server 的 10051，可以不对公网开放 10050。使用被动检查时才需要让 Server 访问 Agent 的 10050，并且应只允许 Server 或 Proxy 的固定 IP。
媒体类型可用只是第一步。还要给接收用户添加 Media、启用对应严重度与时段，并创建匹配事件的 Trigger action 和 Operation。分别测试媒体类型、Problem、Recovery 和升级步骤，查看 Alerts 中的发送错误。
可以，Agent 2 有插件和模板生态，但需要谨慎授予 Docker Socket 等权限。读取 Docker Socket 通常等价于较高宿主机权限，不能为了显示容器列表就把 Socket 无限制暴露给任意容器或用户。先监控宿主机和关键服务，再按最小权限增加容器指标。
先备份 PostgreSQL、配置和密钥，在测试环境验证同主版本升级，再于维护窗口拉取镜像并观察数据库升级日志。不要只备份容器，也不要在数据库已经升级后简单切回旧 Server 镜像。跨大版本前必须阅读官方升级说明。
- Zabbix 7.4 当前文档与安装要求
- Zabbix 官方容器安装说明
- Zabbix 官方 Docker Compose 仓库 7.4 分支
- Zabbix Agent 2 配置参数
- Zabbix 组件加密说明
- Zabbix 登录与默认密码说明
- Zabbix 媒体类型与通知
- Zabbix Housekeeping
Zabbix 的价值不在于“能画多少图”，而在于把采集、阈值、通知、权限和恢复验证变成持续可维护的运维流程。先以少量关键指标上线，跑通一次真实告警和恢复，再逐步扩展模板，比第一天导入几万个监控项更可靠。