Zabbix 数据通信解析：Agent、Proxy、主动被动模式

数据采集是 Zabbix 监控体系的核心入口，包含 Agent ↔ Server 和 Proxy ↔ Server 两个独立的通信层级，两层均存在主动、被动两种工作模式。多数新手容易混淆两层模式的概念与适用场景。理解这两种模式的原理、配置、性能差异与适用场景，是合理设计监控架构、优化性能、排查故障的关键。

一、Zabbix 数据采集整体架构

1.1 核心组件定位

Zabbix 数据采集由多层组件协同完成，各组件职责严格边界：

  • Zabbix Server：中心调度与数据处理节点，负责配置管理、数据接收、触发器评估、告警发送等全链路逻辑。
  • Zabbix Proxy：可选分布式采集代理，仅承担区域采集执行、本地数据暂存、批量上报功能，不执行触发器计算与告警生成，用于分担 Server 压力、跨网络采集。
  • Zabbix Agent：部署在被监控主机上的轻量级代理，是主机指标采集的核心载体，支持主动与被动两种工作模式。
  • 其他采集入口：SNMP、IPMI、JMX、HTTP 检查、简单检查等协议采集，适配不同类型的监控对象。

1.2 标准数据处理全链路

数据从采集到告警遵循固定的流水线逻辑，触发器计算为内存实时运算，发生在数据库写入之前。

1. 无 Proxy 直连架构（小规模场景）

被监控对象 → 采集端（Agent / SNMP / IPMI / HTTP / 简单检查等）
    ↓
Server 采集进程（agent poller / trapper / snmp poller 等）
    ↓
数据预处理（合法性校验、格式转换、正则提取、依赖项解析等）
    ↓
共享内存缓存（历史缓存 + 值缓存）
    ↓
触发器实时计算（全内存运算，状态变更则生成事件）
    ↓
history syncer 批量写入数据库
    ↓
告警动作匹配 → 通知发送 / 远程命令 / 告警升级

2. 有 Proxy 分布式架构（中大规模场景）

被监控对象 → 边缘采集端（Agent / SNMP / IPMI / 各类协议采集）
    ↓
Zabbix Proxy（区域采集执行 + 本地数据暂存 + 批量上报）
    ↓
Server 接收进程（trapper / proxy poller）
    ↓
数据预处理
    ↓
共享内存缓存
    ↓
触发器实时计算
    ↓
批量写入数据库
    ↓
告警通知与动作执行

二、Zabbix Agent 架构体系

Zabbix 官方提供两代 Agent 实现，对外协议完全兼容，但底层进程架构与并发模型存在本质差异。

2.1 Agent 1（传统 C 语言版）：多进程架构

传统 Zabbix Agent（zabbix_agentd）采用 C 语言开发，基于预派生多进程模型运行，启动后 fork 出多个功能独立的子进程，可通过启动日志直接验证：

agent #0 started [main process]
agent #1 started [collector]
agent #2 started [listener #1]
agent #3 started [listener #2]
agent #4 started [listener #3]
agent #5 started [active checks #1]

各进程职责：

  • 主进程（main process）：负责管理其他子进程的生命周期，监控子进程状态，异常时自动重启。

  • collector 进程：固定 1 个，不可配置数量。后台常驻周期性预采集 CPU、磁盘等系统基础指标并缓存，主、被动模式均可复用缓存数据，降低系统调用开销。

  • listener 进程：被动模式专属进程，数量由 StartAgents 参数控制（默认 3 个）。监听 10050/TCP 端口，每个进程独立处理 Server 发起的被动检查请求。

  • active checks 进程：主动模式专属进程，固定 1 个，不可配置数量。全链路负责从 Server 拉取配置、调度采集、管理本地缓冲区、批量上报数据。

    重要澄清：Agent 1 中不存在独立的「Sender 发送进程」，主动模式的采集、缓冲、上报逻辑均由 active checks 进程串行完成。

2.2 Agent 2（Go 语言版）：单进程协程架构

Zabbix Agent 2（zabbix_agent2）基于 Go 语言重写，采用 单进程 + 多协程（Goroutine） 架构，ps 命令仅能看到一个主进程，内部功能模块均以协程方式并发运行。

核心特性：

  • 不再 fork 独立子进程，被动监听、主动检查、数据采集均由内部协程实现，上下文切换开销更低。
  • 原生支持插件化扩展，不同采集插件独立运行，并发能力由插件级 Capacity 参数控制。
  • 支持持久化磁盘缓冲区（EnablePersistentBuffer），网络长时间中断时数据写入磁盘，避免数据丢失。
  • 支持增量配置同步，配置变更时仅传输差异数据，网络开销更低。

2.3 两代 Agent 核心对比表

对比维度 Agent 1（zabbix_agentd） Agent 2（zabbix_agent2）
开发语言 C 语言 Go 语言
进程模型 预派生多进程（fork） 单进程 + 多协程（Goroutine）
进程可见性 可通过 ps 查看各独立子进程 仅可见单一主进程，内部并发不可见
被动并发控制 全局 StartAgents 参数控制进程数 插件级 Capacity 参数控制并发数
插件机制 仅支持 UserParameter 外部脚本 原生支持插件体系，内置丰富采集插件
配置同步 全量拉取 支持增量同步
持久化缓存 不支持 支持（EnablePersistentBuffer）
适用场景 轻量基础采集，资源占用低 复杂场景、插件化扩展、高可靠要求

2.4 两类监控项的实现机制

  • 内建 key：由 Agent 原生代码直接实现，通过系统调用读取 /proc、/sys 等内核接口获取数据，性能极高，如 system.cpu.load、vfs.fs.size 等。
  • UserParameter 自定义参数：用户自定义的外部命令或脚本。执行时 Agent 会 fork 子进程（Agent 1）或启动协程（Agent 2）调用外部程序，执行超时由 Timeout 参数控制（默认 3 秒）。大量执行缓慢的自定义参数会长时间占用资源，导致采集排队，需合理控制超时与数量。

三、Agent ↔ Server 采集层：主动模式与被动模式

这是日常运维最核心的采集层，两种模式的本质区别是通信发起方不同：Server 主动发起请求为被动模式，Agent 主动发起连接为主动模式。

3.1 被动模式（Passive Checks）

被动模式是 Zabbix Agent 的默认工作模式，采集调度权完全在 Server 侧。

工作原理

Server（或 Proxy）侧的 agent poller 进程（Zabbix 5.0 新增的异步 IO 专属进程）根据调度队列，主动向目标 Agent 的 10050/TCP 端口发起连接，发送监控项 key 请求；Agent 被动接收请求后执行本地采集，将结果返回给 Server（或 Proxy）。

nextcheck 时间轮调度机制

被动模式的采集调度基于下一次执行时间队列实现，而非简单的定时轮询：

  • 每个被动监控项在 Server 共享内存的配置缓存中维护一个 nextcheck 时间戳，记录下一次计划采集的时间。

    版本说明：Zabbix 6.4 及更早版本中，该字段同时持久化存储在 items 数据库表中；7.0 版本起已从数据库表移除，改为纯内存运行时维护。

  • 所有被动监控项按 nextcheck 时间升序排列，形成全局有序的任务队列。

  • 采集进程空闲时，从队列头部取出已到期的任务执行采集。

  • 采集完成后，根据监控项的更新间隔计算新的 nextcheck 时间，重新放回队列对应位置。

从 Zabbix 5.0 开始，Agent 被动检查采用异步 IO 模型，单进程可同时处理上千个并发请求，无需等待前一个请求响应即可发起下一个，并发上限由 MaxConcurrentChecksPerPoller 控制。

标准通信流程

Server agent poller → 建立 TCP 连接至 Agent:10050 → 发送监控项 key → Agent 执行采集 → 返回结果 → 连接关闭

关键配置参数

Agent 1 端（zabbix_agentd.conf）

参数 说明 默认值
Server 允许发起被动检查的 Server/Proxy IP 列表，多地址用逗号分隔，未列入的 IP 会被拒绝连接 -
ListenPort 被动模式监听端口 10050
StartAgents 被动检查预派生进程数，控制被动模式并发处理能力；设为 0 则完全禁用被动检查 3

Agent 2 端（zabbix_agent2.conf）

参数 说明 默认值
Server 允许发起被动检查的 Server/Proxy IP 列表 -
ListenPort 被动模式监听端口 10050
无 StartAgents 被动并发由各采集插件的 Capacity 参数分别控制，无全局配置项 -

Server 端

  • 监控项类型选择「Zabbix 客户端」

  • 主机接口配置 Agent 的 IP 地址与 10050 端口

  • Agent 被动采集并发数由 StartAgentPollers 参数控制，单进程最大并发由 MaxConcurrentChecksPerPoller 控制

    注意：StartPollers 是通用同步轮询进程参数，仅负责 IPMI、ODBC、简单检查等非 Agent 类被动采集，不承载 Agent 被动检查主力流量，二者不可混淆。

优缺点

  • 优点：逻辑简单直观，排障容易；采集节奏完全由 Server 控制，配置变更立即生效，无同步延迟；支持多进程并行处理，适合大量慢采集项场景。
  • 缺点：Server 需直达 Agent 的 10050 端口，无法穿透 NAT/防火墙；大规模环境下连接数随监控项线性增长，Server 侧压力大；单条请求响应模式网络开销高。
  • 适用场景：主机数量较少（建议 < 300 台）、网络环境简单、Server 可直接访问 Agent、配置变更频繁需即时生效的场景。

3.2 主动模式（Active Checks）

主动模式下采集调度权下沉至 Agent 侧，Agent 自主完成配置拉取、本地采集与批量上报。

工作原理

Agent 根据 ServerActive 配置，主动连接 Server（或 Proxy）的 10051/TCP 端口（trapper 端口），先拉取自身对应的主动监控项列表，再按配置的间隔在本地独立执行采集，结果达到阈值后批量上报给 Server。

配置同步机制演进

  • Zabbix 6.4 之前：Agent 每 RefreshActiveChecks 周期（默认 120 秒）拉取完整的监控项配置副本，网络开销大。
  • Zabbix 6.4 及以后：采用增量配置同步机制，默认每 5 秒同步一次增量变更，仅配置变化时传输完整数据，显著降低网络与数据库开销。

标准通信流程

Agent → 建立 TCP 连接至 Server:10051 → 发送 active checks 配置请求 → Server 返回监控项列表 → Agent 本地定时采集 → 批量上报 agent data → 连接复用/关闭

关键配置参数

Agent 端（两代 Agent 通用）

参数 说明 默认值
ServerActive Agent 主动连接的 Server/Proxy 地址，支持指定端口，多地址用逗号分隔 -
Hostname Agent 身份标识，必须与 Server 端主机名称完全一致（大小写敏感），是数据关联的核心依据 自动获取主机名
RefreshActiveChecks 主动检查配置刷新间隔 120秒
BufferSize 内存缓冲区最大容纳数据条数，满则立即发送 100
BufferSend 缓冲区数据最长保留时间，达到时间即使未满也发送 5秒

Server 端

  • 监控项类型选择「Zabbix 客户端（主动式）」
  • 主机名称必须与 Agent 配置的 Hostname 完全匹配
  • 数据接收由 trapper 进程处理，并发数由 StartTrappers 参数控制

优缺点

  • 优点：仅需 Agent 出站访问 Server，可穿透 NAT/防火墙；批量上报减少连接开销，Server 侧压力小，扩展性强；支持本地数据缓存，网络中断时数据不丢失；天然支持客户端自动注册，适配弹性扩缩容场景。
  • 缺点：配置相对复杂，Hostname 不匹配会导致采集失败；配置变更存在同步延迟；主动检查单进程串行执行，大量慢采集项易产生排队延迟。
  • 适用场景：大规模部署、主机位于 NAT/防火墙后、云环境弹性扩缩容、网络不稳定需数据保活、日志监控为主的场景。

3.3 核心特性对比表

对比维度 被动模式 主动模式
通信发起方 Server → Agent Agent → Server
监听端口 Agent 侧 10050/TCP Server 侧 10051/TCP
核心进程 Server 侧 agent poller Server 侧 trapper、Agent 侧 active checks
防火墙要求 Server 需能访问 Agent 入站端口 Agent 需能访问 Server 出站端口
NAT/穿透能力 不支持 支持
数据传输方式 单 key 请求响应 批量上报
配置生效时效 立即生效 需等待配置同步周期
自动注册 不支持 支持
数据缓存 无，断网数据丢失 有本地缓冲区，断网可补传
Server 压力 较高（poller 随监控项线性增长） 较低（仅接收批量数据）
适用规模 中小规模、简单网络 大规模、复杂网络环境

3.4 混合模式部署策略

实际生产中，两种模式可在同一 Agent 上共存，配置文件同时设置 Server（被动）与 ServerActive（主动），前端监控项分别选择对应类型即可。 通用最佳实践：

  • 关键核心指标（CPU、内存、核心服务状态）使用被动模式，保证实时性与可控性。
  • 非核心指标、日志监控、大批量采集项使用主动模式，降低 Server 负载与网络开销。

四、Proxy ↔ Server 代理层：主动模式与被动模式

Zabbix Proxy 作为分布式采集代理，与 Server 之间的数据同步同样分为主动、被动两种模式，与 Agent 层模式概念独立，不可混淆。

4.1 Proxy 核心定位

Proxy 是纯采集代理组件，仅承担区域采集执行、本地数据暂存、批量上报功能，不执行触发器计算、不生成告警、不发送通知，所有逻辑判断均在 Server 端统一完成。

4.2 Proxy 主动模式（默认推荐）

工作原理

Proxy 主动连接 Server 的 10051 端口，主动拉取自身负责区域的配置信息，同时将采集到的批量数据主动上报给 Server；Server 无需为 Proxy 维护专门的拉取进程。

配置（zabbix_proxy.conf）

ProxyMode=0    # 0 代表主动模式，官方默认值
Server=10.0.0.1  # Server 地址

优点

  • 无需 Server 主动连接 Proxy，支持 Proxy 位于 NAT/防火墙后。
  • Server 无需额外配置 StartProxyPollers 进程，资源开销小。
  • 配置灵活，管理简单，是绝大多数生产场景的标准方案。

4.3 Proxy 被动模式（特定安全场景）

工作原理

Server 主动连接 Proxy 的 10051 端口，主动向 Proxy 下发配置、拉取采集数据；Proxy 被动响应 Server 的请求。

重要说明：该模式未被官方废弃。在安全策略极其严格的 DMZ 隔离区环境中，若禁止内部设备主动向外网发起连接，被动 Proxy 是唯一合规方案。

配置

ProxyMode=1    # 1 代表被动模式

Server 端需配套配置 StartProxyPollers 进程数，用于主动拉取 Proxy 数据。

缺点

  • 增加 Server 侧进程负担。
  • 要求 Server 能直接访问 Proxy 的 10051 端口，网络限制多。

4.4 两种 Proxy 模式对比表

对比维度 Proxy 主动模式 Proxy 被动模式
连接发起方 Proxy → Server Server → Proxy
默认状态 官方默认模式 非默认，特殊场景启用
Server 侧进程 无需额外进程 需配置 StartProxyPollers
网络要求 Proxy 能访问 Server 即可 Server 能访问 Proxy 即可
适用场景 绝大多数生产环境 DMZ 等严格禁止出站的安全场景

五、底层通信协议规范

Zabbix 两种模式采用不同的通信协议，被动模式为简单文本协议，主动模式为 JSON 结构协议。

5.1 被动模式：简单文本协议

请求格式

Server 向 Agent 发送一行纯文本，内容为监控项 key，例如：

system.cpu.load[all,avg1]

带参数的 key 按官方语法拼接在方括号内。

响应格式

Agent 返回数据采用「长度 + 内容」的格式：

<数据长度>
<数据内容>

例如返回值为 0.45，实际字节流为：

4
0.45

若 key 不支持或执行错误，Agent 返回以 ZBX_NOTSUPPORTED 开头的错误信息。

连接管理

默认采用短连接，单次请求完成后关闭连接；高版本支持 KeepAlive 复用连接，减少握手开销；请求超时由 Timeout 参数控制（默认 3 秒）。

5.2 主动模式：JSON 结构协议

主动模式所有交互均采用 JSON 格式，核心分为两类请求。

1. 配置拉取请求

Agent 发送请求获取主动监控项列表：

{
    "request": "active checks",
    "host": "web-server-01"
}

Server 成功响应：

{
    "response": "success",
    "data": [
        {
            "key": "system.cpu.load[all,avg1]",
            "delay": 30,
            "lastlogsize": 0,
            "mtime": 0
        }
    ]
}

2. 数据上报请求

Agent 批量上报采集数据：

{
    "request": "agent data",
    "data": [
        {
            "host": "web-server-01",
            "key": "system.cpu.load[all,avg1]",
            "value": "0.45",
            "clock": 1690000000
        }
    ]
}

Server 的 trapper 进程接收后，根据 host 和 key 匹配对应监控项，进入数据处理流水线。

3. 缓冲区机制

若网络中断或 Server 不可达，Agent 会将数据保存在本地内存缓冲区，达到 BufferSize 或 BufferSend 阈值时重试；Agent 2 支持开启持久化缓冲区，数据写入磁盘，避免长时间断网导致数据丢失。

六、配置实战与最佳实践

6.1 典型配置示例

Agent 1 被动模式配置（zabbix_agentd.conf）

# 允许发起被动检查的 Server IP
Server=192.168.1.100
# 监听端口
ListenPort=10050
# 被动处理进程数
StartAgents=3

Agent 1 主动模式配置（zabbix_agentd.conf）

# 主动模式 Server 地址
ServerActive=192.168.1.100:10051
# 主机名，必须与 Server 端完全一致
Hostname=web-server-01
# 配置刷新间隔
RefreshActiveChecks=120
# 缓冲区配置
BufferSize=200
BufferSend=5
# 可选：关闭被动模式
# StartAgents=0

混合模式配置（生产最常用）

# 被动模式
Server=192.168.1.100
StartAgents=2

# 主动模式
ServerActive=192.168.1.100
Hostname=web-server-01
BufferSize=200

6.2 场景选型指南

Agent 模式选型

主机规模 推荐模式 补充说明
< 50 台 被动模式 配置简单，维护成本低
50 - 500 台 混合模式 核心指标被动，非核心与日志主动
> 500 台 主动模式 + Proxy 主动模式为主，结合 Proxy 分层采集
NAT/防火墙后 主动模式 仅需出站连接，可穿透网络
云环境弹性扩缩容 主动模式 + 自动注册 实现节点自动纳管

Proxy 模式选型

  • 绝大多数场景：使用默认主动模式（ProxyMode=0），无需修改。
  • DMZ 严格安全区域：使用被动模式，满足等保合规要求。

6.3 性能优化要点

  1. 采集侧精准调优
    • Agent 被动采集延迟：优先调整 StartAgentPollers 与 MaxConcurrentChecksPerPoller，而非通用 StartPollers；后者仅负责 IPMI、ODBC 等非 Agent 采集。
    • 主动模式上报积压：调整 StartTrappers 进程数。
    • SNMP 设备采集延迟（7.0+）：调整 StartSNMPPollers 独立异步进程。
  2. 主动模式缓冲区优化
    • 监控项较多时，BufferSize 建议调至 200-500，减少网络请求次数。
    • 网络不稳定场景，Agent 2 开启 EnablePersistentBuffer，数据持久化到磁盘。
  3. 配置同步频率控制
    • RefreshActiveChecks 不宜设置过小，频繁拉取会增加 Server 数据库压力，建议 60-120 秒。
    • 大规模环境优先使用 6.4+ 版本的增量同步机制。
  4. 大规模部署建议
    • 超过 500 台主机时，引入 Zabbix Proxy 进行分层采集，Proxy 与 Server 之间采用主动模式。
    • 统一使用官方模板，避免混用导致维护混乱。
    • 部署自监控覆盖，监控 Agent 连接状态、缓冲区使用率、配置同步状态。
    • 从被动向主动迁移时，先非核心业务、后核心业务，渐进式验证。

七、常见故障排查思路

7.1 被动模式采集失败排查

  1. 网络连通性验证：Server 端执行 zabbix_get -s <AgentIP> -k system.hostname，测试是否能正常获取数据。
  2. 端口与防火墙：检查 Agent 端 10050 端口是否放行，安全策略是否允许 Server IP 访问。
  3. 配置校验：确认 Agent 配置文件中 Server 参数包含 Server IP，无拼写错误。
  4. 主机接口配置：确认 Web 界面主机的 Agent 接口 IP、端口与实际一致。

7.2 主动模式数据不更新排查

  1. Hostname 一致性检查：Agent 配置的 Hostname 与 Server 端主机名称是否完全一致（大小写、空格），这是最常见故障原因。
  2. 网络连通性验证：Agent 端执行 telnet <ServerIP> 10051，确认端口可达。
  3. 监控项类型校验：确认 Server 端监控项类型为「Zabbix 客户端（主动式）」，而非被动类型。
  4. 配置同步等待：新增监控项后需等待 RefreshActiveChecks 周期，或重启 Agent 立即同步。
  5. 日志排查：查看 Agent 日志，是否有 active check configuration update 成功记录。

7.3 Proxy 通信故障排查

  • 主动模式：检查 Proxy 是否能连通 Server 的 10051 端口，Proxy 配置中的 Server 地址是否正确。
  • 被动模式：检查 Server 是否能连通 Proxy 的 10051 端口，StartProxyPollers 是否已配置且大于 0。

7.4 常用排障命令

# Server 端测试被动模式采集
zabbix_get -s 192.168.1.200 -k system.hostname

# Agent 端查看运行日志
tail -f /var/log/zabbix/zabbix_agentd.log

# 测试端口连通性
telnet 192.168.1.100 10051

八、总结

Zabbix 数据采集体系的核心是「两层架构、两种模式」：

  1. Agent ↔ Server 采集层：被动模式为 Server 拉取，简单可控，适合小规模、简单网络场景；主动模式为 Agent 推送，扩展性强，适合大规模、复杂网络与弹性部署场景。
  2. Proxy ↔ Server 代理层：主动模式为官方默认通用方案，适配绝大多数生产环境；被动模式仅用于特定安全合规场景。

生产环境不必强求统一模式，采用「核心指标被动 + 非核心指标主动 + 边缘区域 Proxy 分层」的组合方案，兼顾实时性、扩展性与稳定性，是最通用的最佳实践。理解两层模式的底层原理与差异，是做好采集性能调优、快速定位故障的基础。

posted @ 2026-08-28 16:41  kyle_7Qc  阅读(17)  评论(0)    收藏  举报