在单台 Linux 服务器上使用 Docker 部署了 Halo 博客、MySQL、Nginx Proxy Manager 等多个服务时，仅监控服务器的 CPU、内存和磁盘是远远不够的。一旦某个业务容器崩溃或异常退出，宿主机资源往往毫无波动，导致“服务已挂但告警未响”。

本文记录如何基于 Docker Compose 环境部署 Zabbix 6.0 LTS，配置 Zabbix Agent 2 实现 Docker 容器的自动发现（LLD）与状态免配告警，并记录关键的 Socket 权限避坑方案。

一、 核心架构与监控原理

  • Zabbix Server / Web / MySQL：以容器形式运行，提供数据处理、告警判断与可视化控制台。

  • Zabbix Agent 2：相较于传统 C 语言编写的 Agent 1，Agent 2 使用 Go 语言开发，内置了原生 Docker 采集插件。

  • 自动发现机制（LLD）：Agent 2 通过挂载宿主机的 /var/run/docker.sock 与 Docker 守护进程通信，自动拉取当前运行的所有容器列表，并按模板原型自动生成监控项与触发器。

  • 告警逻辑：当任何容器的状态从 running 变为 exited、dead 或非正常退出时，Zabbix 自动在仪表盘弹出严重级别告警。

二、 部署配置：从 Agent 1 升级到 Agent 2

由于官方模板 Docker by Zabbix agent 2 依赖专属插件，必须运行 zabbix-agent2 镜像，并赋予访问 Docker Socket 的权限。

在 /opt/zabbix/docker-compose.yml 中调整 zabbix-agent 服务定义：

YAML

version: '3.8'

services:
  zabbix-agent:
    image: zabbix/zabbix-agent2:alpine-6.0-latest
    container_name: zabbix-agent
    restart: unless-stopped
    privileged: true
    user: root                     # 关键：指定以 root 权限运行，避免 docker.sock 访问拒绝
    ports:
      - "10050:10050"
    environment:
      - ZBX_HOSTNAME=Zabbix server
      - ZBX_SERVER_HOST=zabbix-server
    volumes:
      - /:/host/root:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro  # 挂载宿主机 Docker 套接字
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
    networks:
      - default

  # zabbix-server、zabbix-web 等服务保持原有配置...

应用并拉起新容器：

Bash

docker compose stop zabbix-agent
docker compose rm -f zabbix-agent
docker compose up -d zabbix-agent

验证方法：执行 docker ps | grep zabbix-agent，确认镜像显示为 zabbix/zabbix-agent2:alpine-6.0-latest 且处于 Up 状态。

三、 关键踩坑：解决 Socket 权限拒绝问题

1. 现象描述

在 Web 控制台关联模板后，进入 Configuration -> Hosts -> Discovery，发现 Docker by Zabbix agent 2: Containers discovery 处于 Not supported 状态，右侧报错提示：

Plaintext

dial unix /var/run/docker.sock: connect: permission denied

2. 原因分析

Alpine 镜像内部默认使用的执行用户可能没有操作宿主机 /var/run/docker.sock 文件的读取权限。

3. 彻底解决方案

双管齐下处理权限限制：

  1. 放行宿主机 Socket 权限：

    Bash

    chmod 666 /var/run/docker.sock

  2. 容器级别提权： 在 docker-compose.yml 中显式指定 user: root 和 privileged: true（如第二节配置所示），避免守护进程重启后权限回滚。

四、 Web 控制台配置：绑定模板与激活发现

1. 确保 Server 与 Agent 网络通信正常

  1. 进入 Configuration（配置） -> Hosts（主机），点击 Zabbix server。

  2. 在 Interfaces（接口） 区域：

    • Connect to：必须勾选 DNS（容器化环境中 IP 模式连 127.0.0.1 会指向 Server 自身）。

    • DNS name：填写容器名 zabbix-agent。

  3. 点击 Update 保存。

2. 关联 Docker 官方模板

  1. 在 Zabbix server 编辑页面中，找到 Templates 输入框。

  2. 搜索并关联：Docker by Zabbix agent 2。

  3. 点击底部 Update 保存。

3. 强制立即执行自动发现（加速纳管）

默认情况下，自动发现扫描周期为 15 分钟或 1 小时。为了无需漫长等待：

  1. 点击 Zabbix server 行的 Discovery 链接。

  2. 勾选 Docker by Zabbix agent 2: Containers discovery 复选框。

  3. 点击页面底部的 Execute now（立即执行）。

  4. 等待 15~30 秒刷新页面，确认该规则状态显示为绿色的 Enabled，红色的 [ i ] 报错图标彻底消除。

五、 端到端故障注入与验证

1. 查看自动纳管的容器项

进入 Monitoring（监测） -> Latest data（最新数据），筛选主机 Zabbix server 并搜索关键词 Docker。 若能看到各业务容器的具体指标（如 Docker: Container halo: State、Docker: Container halo-mysql: State），说明数据抓取成功。

2. 模拟容器宕机

在宿主机终端手动停止任意一个正在运行的容器：

Bash

docker stop halo

3. 观察告警闭环

  1. 等待 30~60 秒，刷新 Zabbix 控制台的 Monitoring -> Dashboard（或 Problems 页面）。

  2. 告警上屏：列表中自动弹出严重级别告警，显示容器已处于停止状态：

    Plaintext

    Container halo: Container has been stopped

  3. 故障恢复（自愈测试）： 重新拉起容器：

    Bash

    docker start halo

    约 15~30 秒后再次刷新 Dashboard，该告警条目自动关闭并移入历史记录，系统面板全绿恢复。

六、 总结与最佳实践

  • 区分 Agent 选型：基础主机监控用普通 Agent 即可，但中间件与 Docker 原生指标采集优先选择 Zabbix Agent 2。

  • 白盒与黑盒双重兜底：

    • 白盒（Docker 模板）：监控容器自身存活、CPU 占用、内存用量。

    • 黑盒（Web 场景监测）：监控实际对外提供访问的 URL（检测是否返回 HTTP 200），防范“容器进程活着但应用假死 502”的场景。

  • 二者配合，即可在不侵入业务代码的前提下，构建出完整的容器基础设施保障体系。