前两篇分别处理服务器和数据库纳管。当监控对象分布在多个数据中心、工厂、分支、云区域和安全区时，让所有 Agent、SNMP 设备、HTTP 检查都直接连接中心 Zabbix Server，会带来防火墙规则复杂、广域网不稳定、采集延迟和中心采集进程压力。Zabbix Proxy 用于把采集职责放到靠近监控对象的位置，再把数据发送到中心 Server。

分布式监控不是简单“多装几台 Proxy”。需要回答：按地域还是安全区切分；主动还是被动 Proxy；每台 Proxy 承载多少 item 和 values per second；链路断开时缓存多久；Proxy 数据库怎么选；是否需要 Proxy group；Agent 如何在 Proxy 故障后切换；SNMP trap、主动 Agent 和被动 Agent 的行为有什么差异；如何迁移和演练。

本文以 Zabbix 7.0 LTS 为主要范围。7.0 引入 Proxy group 的负载均衡与高可用，能够在组内 Proxy 离线时自动重新分配主机，也能根据主机数量进行再平衡。本文会把传统单 Proxy 架构和 7.0 Proxy group 分开说明。

中心 Server 仍负责全局配置、触发器评估、事件、告警和历史数据存储。Proxy 负责本区域采集、部分预处理、发现和自动注册数据接收、离线缓存以及向 Server 发送数据。Proxy 不是下级 Server，也不形成多级 Proxy 树。

什么情况下需要 Proxy

第一个信号是网络边界。生产区、办公区、DMZ、工厂 OT 边缘、云 VPC 和分支机构之间通常有严格 ACL。与其允许中心 Server 访问每台主机和设备，不如每个区域部署 Proxy，只开放 Proxy 到 Server 的必要通信，再让本区域对象访问 Proxy。

第二个信号是广域网质量。远程站点链路会抖动或中断，Proxy 可以在本地继续采集并缓存数据，链路恢复后上报。如果 Agent 直接连接中心 Server，中断期间的主动数据可能丢失，被动检查也无法执行。

第三个信号是采集压力。SNMP、ICMP、JMX、ODBC、HTTP 和被动 Agent 检查会占用 Server poller。Proxy 可以把这些采集进程分散到区域。它不能消除中心数据库写入和触发器处理，但能降低中心直接采集压力。

第四个信号是管理半径。多个机房或云区域由不同团队负责时，区域 Proxy 是清晰的故障边界。某区域大量主机无数据时，先看该区域 Proxy 和链路，而不是逐台主机排查。

不是规模大才需要 Proxy。一个只有几十台主机但网络隔离严格的工厂，也很适合 Proxy。反过来，一个单机房、网络简单、几百台主动 Agent 的环境，未必必须马上引入多 Proxy。架构选择取决于边界、可靠性和运维能力。

Proxy 的真实职责

Zabbix Proxy 配置同步与数据上报流程

Proxy 从 Server 获取分配给它的监控配置，在本地执行支持的采集，接收主动 Agent 和 sender 数据，把历史、发现和自动注册数据缓存后发送给 Server。链路中断时，Proxy 按配置保留离线数据。

需要纠正一个常见误解：Proxy 不负责最终触发器计算和告警。中心 Server 接收数据后进行全局触发器评估、事件生成和动作执行。Proxy 也不是数据长期存储节点，本地数据库主要保存配置和待发送数据。长期历史仍在 Server 数据库。

另一个误解是 Proxy 可以级联。Zabbix 的架构是 Proxy 与 Server 通信，监控对象由 Server 或一个 Proxy/Proxy group 负责，不支持 Proxy 下再挂 Proxy 的两级采集树。超大规模应增加平行 Proxy、Proxy group、拆分监控域或评估多套 Zabbix，而不是设计虚构的一级、二级 Proxy。

Proxy 支持 Agent、SNMP、IPMI、JMX、simple check、ODBC、HTTP 等多种采集，具体能力取决于安装组件和配置。Java 监控需要 Java gateway，SNMP trap 需要 snmptrapd 与文件管道，ICMP 需要 fping。部署前要按区域对象清单准备依赖。

架构模式选择

Zabbix 分布式架构设计模式对比

最简单模式是一站点一 Proxy。每个机房、工厂、云区域或安全区部署一台 Proxy，主机固定分配给它。优点是结构清晰，缺点是 Proxy 单点。适合规模较小、可接受短时采集中断、链路缓存能覆盖修复时间的区域。

第二种模式是一站点 Proxy group。Zabbix 7.0 可以把多个 Proxy 组成 group，主机配置为由 group 监控。官方文档说明，Proxy 离线时其主机会重新分配给其他 Proxy；主机数量明显不均衡时也会再平衡。这个模式适合关键区域和大量主机。

第三种模式是按协议或对象类型拆 Proxy。例如网络设备 SNMP 与服务器 Agent 分开，数据库 ODBC 与普通主机分开。这样可以隔离慢协议和不同依赖，但会增加运维复杂度。只有当采集特征明显不同、容量或安全边界要求明确时使用。

第四种模式是多套 Zabbix，而不是一套 Server 加无限 Proxy。如果不同组织、合规域、客户、国家区域之间不允许共享配置和数据，或者中心数据库和事件处理无法继续扩展，应评估多套 Server 和上层汇总。Proxy 不能解决所有中心瓶颈。

主动与被动 Proxy

主动 Proxy 默认主动连接 Server，获取配置并发送数据。防火墙只需允许 Proxy 到 Server，适合分支、云 VPC、DMZ 和多数区域。主动 Proxy 的 Hostname 必须与前端 Proxy 名称匹配。

被动 Proxy 由 Server 连接。适合中心可以访问区域 Proxy、区域不允许主动出站或组织安全策略要求中心发起的场景。它需要 Server 到 Proxy 的网络和防火墙规则。主动与被动不是性能等级，主要区别是连接方向和运维方式。

官方 zabbix_proxy 参数文档说明，ProxyMode=0 是主动，ProxyMode=1 是被动。Server 参数在主动模式下定义连接的 Server 或 HA 集群，在被动模式下定义允许访问 Proxy 的 Server 地址列表。实际配置必须按当前版本参数说明。

主动 Proxy 需要身份保护。官方参数文档提醒，未使用加密认证时，能够访问 Server trapper 端口的攻击者可能冒充主动 Proxy 请求敏感配置。生产环境应使用 TLS PSK 或证书，并限制网络来源。

Proxy group 与高可用

Zabbix 7.0 Proxy group 提供组内主机自动分配、故障转移和负载再平衡。创建 group 时配置 failover period 和 minimum number of proxies。failover period 表示 Proxy 多久未与 Server 通信会被视为离线，范围和默认值以官方界面为准；设置过短可能因网络抖动频繁迁移主机，过长则延迟故障转移。

官方文档说明，主机重新分配只在满足条件时工作：Proxy 运行 7.0 或更高；版本与 Server 匹配；group 处于 online；主机配置为由 Proxy group 而不是单个 Proxy 监控。主动 Agent 也需要 7.0 或更高才能使用 group 地址机制。

Proxy group 的高可用不是共享数据库双机。组内每个 Proxy 是独立实例，Server 决定主机当前由谁监控。故障后主机被重新分配，新的 Proxy 获取配置并开始采集。被动检查通常较直接；主动 Agent 需要能够连接组内可用 Proxy，Agent 配置、DNS 或地址列表要按官方方案设计。

同一时刻一个主机由组内一个 Proxy 负责，不是所有 Proxy 同时采集。这样避免重复数据。重新分配期间可能存在短暂采集间隔，因此告警窗口和 nodata() 要避免过度敏感。

Proxy group 不能自动解决所有协议。SNMP trap、固定来源推送、sender、设备 ACL 和外部系统回调可能指向具体 Proxy。故障转移前要验证这些数据源是否能切换，不能只测试被动 Agent。

缓存与断网设计

Proxy 的核心价值之一是断网缓存。官方配置参数包括 ProxyOfflineBuffer、ProxyLocalBuffer、ProxyBufferMode、ProxyMemoryBufferSize 和 ProxyMemoryBufferAge。7.0 新安装采用 hybrid buffer，优先使用内存，停止、内存满或数据过旧时把未发送数据刷到数据库。

disk 模式依赖数据库保存缓存，可靠但有 I/O；memory 模式性能高，但 Proxy 停止或内存溢出可能丢数据；hybrid 在性能与保护之间折中。选择时要结合区域断网时长、VPS、可接受丢失和磁盘能力。

缓存容量必须计算。大致需要考虑每秒新值、平均记录大小、离线小时数、发现和自动注册数据、数据库开销。不要只把 ProxyOfflineBuffer 改成很大，而不检查本地数据库和磁盘是否能容纳。断网恢复后还会出现集中回传，Server、网络和数据库要有余量。

本地缓存不是永久历史。超过 offline buffer 的旧数据会丢失。对于长期离线站点，需要提高缓存和磁盘，或者重新评估监控目标和网络可靠性。Proxy 不能替代本地长期监控系统。

数据库选择

Proxy 可以使用 SQLite、MySQL 或 PostgreSQL 等支持的数据库，具体包由发行版和官方仓库提供。SQLite 部署简单，适合中小规模和低运维复杂度；独立数据库适合更高写入、较大缓存和严格数据库治理。

SQLite 并不等于只能测试。是否适合取决于 VPS、离线缓存、发现任务、磁盘和并发。选择前做容量测试。使用 MySQL 或 PostgreSQL 会增加数据库服务、备份、账号和监控成本，不应只因为“生产环境”三个字机械选择。

Proxy 数据库不应和 Server 数据库共用 schema，也不应手工复制 Server 数据。安装时使用对应 Proxy schema。数据库损坏时，Proxy 可以重建配置，但未发送数据可能丢失，因此本地数据盘和服务恢复仍需规划。

部署流程

Zabbix Proxy 安装部署流程

部署前先记录区域名称、Proxy 模式、Server 地址、主机数量、item 数量、VPS、协议、预计断网时间、TLS 方式和数据库。然后从 Zabbix 官方下载页面选择与 Server 版本一致的 Proxy 包和数据库类型。

命令和包名随发行版与版本变化，落地时按官方下载页面执行。通用流程是安装 Proxy 包和数据库依赖；初始化 Proxy schema；配置 Server、Hostname、DBName、TLS、缓存和进程参数；在前端创建 Proxy 或加入 group；启动服务；查看日志和 last access。

配置片段示意如下，具体参数按现场复核：

conf
ProxyMode=0
Server=zabbix.example.internal:10051
Hostname=proxy-bj-prod-01
DBName=/var/lib/zabbix/zabbix_proxy.db
ProxyBufferMode=hybrid
ProxyOfflineBuffer=24
TLSConnect=psk
TLSPSKIdentity=proxy-bj-prod-01
TLSPSKFile=/etc/zabbix/proxy.psk

这个示例只表示结构，没有在当前机器执行。数据库类型不同，DB 参数不同；加入 Proxy group 时还要在前端配置 local address 和 port；生产参数应来自容量测试。

启动后检查服务状态、Proxy 日志、前端 last seen、配置同步、内部指标和一台测试主机。先迁移少量非关键主机，确认 latest data、告警和缓存，再扩大范围。

多区域设计

多区域 Proxy 设计

多区域设计建议按故障域切分。北京数据中心、上海数据中心、云华东、云华南、生产区、DMZ 分别有 Proxy 或 group。一个区域故障时，不应影响其他区域采集。Proxy 命名、主机组和标签反映区域。

Server 到 Proxy 的链路要有 TLS、DNS、路由和带宽设计。跨公网使用证书或 PSK，不裸露管理端口。Proxy 到本区域对象的 ACL 由区域团队维护。中心团队负责 Server 和 group，区域团队负责 Proxy 主机和网络，双方共同负责容量和演练。

关键区域使用至少两个 Proxy 的 group，并把主机分配给 group。普通分支可单 Proxy，通过离线缓存覆盖修复时间。不要所有分支共用中心一组 Proxy，否则失去本地采集和故障隔离价值。

主机迁移到 Proxy

迁移前记录主机当前数据时间、模板、Agent 模式、TLS 和告警状态。创建维护窗口，先迁移测试主机。前端把 monitored by 从 Server 或旧 Proxy 改为新 Proxy/group。主动 Agent 同步修改 ServerActive，被动 Agent允许新 Proxy 地址。

迁移后检查 Agent 日志、Proxy latest data、Server queue、主机可用性和告警。不要同时修改主机名、TLS、模板和 Proxy，否则失败时难以定位。批量迁移按主机组分批，并保留回滚路径。

网络设备迁移还要更新 SNMP ACL 和 trap 目的地址。ODBC/JMX/HTTP 检查要确认新 Proxy 有驱动、Java gateway、DNS 和网络。只是前端改 monitored by 并不能保证所有协议可用。

容量规划

Proxy 容量从 required VPS、item 类型、超时、预处理、网络和缓存估算。相同 VPS 下，快速 Agent item 与慢 SNMP/HTTP/ODBC 的资源消耗不同。不能只按主机数量分配。

使用 Zabbix internal items 监控 Proxy process busy、queue、cache、last seen、version、host count、item count 和 required VPS。Proxy group 也有 internal discovery 和 state item，可以显示 group 的 online、recovering、degrading、offline 状态。

进程参数只在证据表明瓶颈时调整。poller busy 高可能是慢检查、超时或进程不足；trapper busy 高可能是主动数据集中；preprocessing busy 高可能是复杂模板；数据库 I/O 高可能是缓存和磁盘。先找原因，再改 StartPollers、cache 等参数。

容量设计不能只看“正常日”。需要分别估算平稳采集、业务高峰、网络中断和链路恢复四种状态。平稳状态决定长期资源消耗；业务高峰可能增加日志、事件和自动发现结果；网络中断决定本地缓存空间；链路恢复则决定短时间内的上行带宽、Server trapper、预处理和数据库写入峰值。只按平均值配置的 Proxy，往往不是在断网时失败，而是在恢复回传时把中心端压满。

可以先用一张区域容量表整理输入：

维度 需要记录的内容 设计用途
主机与设备 Agent、SNMP、JMX、IPMI、HTTP、ODBC 数量 判断协议依赖和采集进程
监控项 启用 item 数、更新间隔、主动与被动比例 估算 required VPS
慢检查 超时、脚本、网页步骤、数据库查询 判断 poller 被占用风险
数据体量 数值、文本、日志、发现数据比例 估算缓存与回传带宽
链路 平均带宽、时延、抖动、最长中断 设计 offline buffer
恢复目标 允许的数据缺口和恢复时间 决定冗余、磁盘与演练标准

required VPS 是规划起点，不是最终硬件答案。两个区域都显示每秒一千个新值，其中一个主要是本地 Agent 数值，另一个包含大量高延迟 SNMP、HTTP 和数据库检查，它们对 CPU、进程、网络和数据库的要求不会相同。应在模板接近真实、链路条件接近真实的测试环境中逐步增加对象，观察进程繁忙率、队列、缓存、日志和数据库延迟，再决定单 Proxy 的边界。

缓存估算也要保留安全系数。假设一个站点 required VPS 为五百，计划覆盖二十四小时断网，不能简单认为只需要保存四千三百二十万条“很小的记录”。不同值类型、索引、事务日志和数据库页都会产生额外开销，发现数据和日志型 item 还可能显著放大体量。实践中应通过短时断链实验测量每小时数据库或缓冲区增长，再按目标离线时长、增长波动和磁盘预留反推容量。

恢复速度必须有限制意识。链路恢复后，Proxy 一边上送积压，一边继续接收新值。如果上行带宽不足，积压会长时间不降；如果中心数据库写入接近极限，多个区域同时恢复可能造成全局队列。演练时应记录“中断一小时后需要多久清空积压”，并验证这段时间不会影响实时数据和告警。大型环境可以错开区域恢复、限制其他批量任务，或为中心端预留明确的突发吞吐。

站点分级与部署基线

分布式架构需要把站点按业务影响和恢复目标分级，而不是给所有区域复制同一套配置。普通办公室、关键生产区和跨国数据中心在监控连续性、人员响应和网络条件上不同，Proxy 数量、数据库和缓存策略也应不同。

普通站点可以采用单主动 Proxy、SQLite 或受支持的轻量数据库、一天左右的离线缓存，以及工作时间内恢复。关键站点更适合两个或更多 Proxy 组成 group，独立故障域部署，使用可靠本地存储，并要求自动切换和定期演练。强隔离区域可能不能加入 group，或者只能单向通信，这时应以更长缓存、备机恢复手册和本地告警补偿连续性。

每个站点都应有一份最小部署基线：操作系统和 Zabbix 版本；Proxy 名称与 group；Server 地址；主动或被动模式；TLS 身份；数据库类型与位置；缓存策略；时间同步源；DNS；日志轮转；数据盘阈值；服务自启动；备份范围；升级渠道；负责人和维护窗口。基线的价值是让故障处理者能够判断当前实例是否偏离设计，而不是依赖最初部署者的记忆。

Proxy 命名最好表达地域、环境、职责和序号，例如 proxy-sh-prod-net-01。名称一旦用于主动 Proxy 身份、TLS PSK identity、自动化脚本和告警标签，就不应随意修改。前端显示名、主机名和配置文件 Hostname 的关系要在命名规范中写清，避免因为大小写、空格或重命名导致配置同步失败。

group 内成员应尽量处于不同宿主机、机架、电源或可用区。如果两台 Proxy 共用同一虚拟化集群、同一存储和同一上联，它们只能覆盖进程故障，无法覆盖底层平台故障。高可用设计必须先列出希望覆盖的故障：服务崩溃、操作系统损坏、宿主机宕机、机架断电、网络设备故障、区域断链，然后检查成员是否真的独立。

不同采集协议的切换边界

Proxy group 对“主机重新分配”负责，但每种数据路径能否自动跟随，需要单独验证。被动 Agent、SNMP 轮询和 simple check 由当前 Proxy 发起，只要新 Proxy 能访问目标、拥有相同依赖并获得配置，通常可以继续。主动 Agent、trap、sender 和外部推送则涉及目标地址或允许列表，不能假定天然切换。

主动 Agent 会向 ServerActive 指定的地址请求检查并发送数据。使用 Proxy group 时，要按照目标 Zabbix 版本的官方方式让 Agent 获取或访问组内可用成员，并确认 DNS、地址列表、证书名称和防火墙都支持切换。老版本 Agent 即使能够向单个 Proxy 工作，也不代表支持 7.0 的 group 行为。升级顺序应把 Agent 兼容性纳入。

被动 Agent 的 Server 允许列表必须包含可能发起连接的 Proxy。若只允许原 Proxy，故障转移后新成员会被拒绝。TLS 证书模式还要验证颁发机构、主体或签发者约束是否适用于所有成员；PSK 模式要决定组内共用身份还是逐成员管理，并评估密钥轮换的复杂度。

SNMP 轮询通常只要求设备 ACL 允许所有候选 Proxy 地址。SNMP trap 则相反，设备主动把消息发往固定接收端。要实现 trap 高可用，需要虚拟地址、负载入口、网络侧多目标能力或独立 trap 接收层，再把数据交给 Zabbix。直接把 trap 目的地址写成某一台 Proxy，会在该节点故障时留下盲区。

zabbix_sender、日志转发器、Webhook 和自研采集程序同样属于推送路径。它们可能写死服务器地址、端口和 TLS 参数，也可能在失败后不重试。迁移到 group 前，应列出所有推送源，验证连接失败、DNS 切换、重试和重复数据行为。架构图里的一条箭头不能代替真实故障测试。

JMX、ODBC、浏览器检查、外部检查和自定义脚本依赖本地运行环境。新 Proxy 即使接管主机，如果缺少 Java gateway、数据库驱动、DSN、证书、脚本、密钥、浏览器组件或环境变量，监控项仍会 unsupported。组内成员要用自动化方式保持依赖一致，并把文件校验、包版本和连通性纳入发布检查。

配置与密钥治理

Proxy 配置不应靠逐台手工编辑长期维护。可以使用 Ansible、Salt、Puppet 或企业配置平台管理软件仓库、配置模板、证书、PSK 文件权限、日志轮转、systemd 覆盖项和监控 Agent。敏感值通过密钥系统或加密变量下发，不写进普通 Git 仓库和工单正文。

自动化模板要区分通用参数和站点参数。通用部分包括日志、缓存模式、TLS 策略和基线进程；站点部分包括 Hostname、Server 地址、数据库、缓存时长和协议依赖。把所有参数复制成一个巨大的静态文件，会使不同站点的合理差异难以审计，也容易在升级时继续携带已废弃参数。

每次变更应先执行配置语法或前台检查，再在测试成员验证服务启动、配置同步和数据发送。生产发布按一个 Proxy、一个站点逐步展开。group 内不要同时重启全部成员；先确认其余成员在线并有能力接管，再维护单个节点。变更完成后检查版本、last access、group state、主机分布和 unsupported item。

TLS PSK 和证书需要生命周期管理。记录签发或生成日期、用途、负责人、到期时间、轮换窗口和回滚密钥。证书轮换要验证 Server 与 Proxy 两端的信任链，PSK 轮换要避免前端身份和本地文件不同步。权限上，密钥文件只允许服务账号读取，日志和命令行不得输出密钥内容。

升级、迁移与版本治理

Proxy 版本不能脱离 Server 独立规划。尤其是 Proxy group，官方条件明确要求成员与 Server 版本匹配。升级前应阅读目标版本的升级说明和配置参数变化，确认数据库 schema、Agent 兼容、TLS、插件或自定义模块，并在与生产近似的 Proxy 副本上演练。

推荐的升级节奏是先建立兼容矩阵，再选择低风险区域试点。备份配置、密钥和数据库，记录升级前内部指标和数据时间；将一个节点从 group 中有序维护，升级后检查服务、日志、配置同步、数据上报和协议依赖；稳定后再处理下一个节点。不要把所有 Proxy 与 Server 同时升级，否则发生异常时无法区分中心、网络和区域问题。

从单 Proxy 迁移到 group 时，先新增成员并完成依赖一致性检查，再创建 group，配置 local address 与 failover 参数，把少量测试主机改为由 group 监控。分别停止当前承载成员、断开 Server 链路和模拟主机网络故障，确认主机重新分配与数据恢复。试点通过后按主机组分批迁移，不要一次修改全部站点。

跨主机迁移 Proxy 数据库要明确目标。配置会从 Server 重新同步，真正需要保护的是尚未发送的数据和必要运行状态。若停机窗口允许，先恢复链路并等待积压清空，再迁移服务通常更简单。直接复制正在写入的 SQLite 文件或数据库目录可能产生不一致，必须采用数据库支持的备份方式，并在恢复后检查日志。

回滚标准要在变更前确定。例如服务无法启动、配置长时间未同步、unsupported item 快速增加、group 进入 degrading、数据延迟超过阈值，都应触发回滚。回滚不是只降软件包，还包括恢复配置、数据库、密钥、前端对象和主机分配。没有验证数据恢复的“服务已启动”不算回滚完成。

灾难恢复与重建

Proxy 通常可以重建，但“可以重建”不等于不需要灾难恢复。至少要备份配置文件、TLS 材料、自动化变量、数据库初始化方法、自定义脚本、ODBC DSN、外部检查、Java gateway 配置和站点资产清单。对于要求保留断网数据的区域，还要设计数据库一致性备份。

重建手册应从一台空白主机开始，说明如何获得软件包、创建数据库、下发配置和密钥、注册到现有 Proxy/group、验证身份、启动服务并恢复协议依赖。手册中不要保存明文密码，而要写密钥获取路径和授权角色。至少每年在隔离环境执行一次，确认文档不是理论步骤。

中心 Server 故障期间，Proxy 只能缓存，不能替代中心告警。关键工厂若要求中心不可用时仍能产生本地告警，需要额外的本地监控或控制系统，不应误以为 Proxy 会独立评估触发器。业务连续性评审要明确“数据不丢”和“告警不中断”是两个不同目标。

灾难恢复还要考虑多个 Proxy 同时恢复。中心长时间中断后，所有区域可能积累大量数据。恢复 Server 前先评估数据库、磁盘和网络，必要时分批恢复区域连接，持续观察写缓存、trapper、预处理和数据库延迟。恢复顺序按业务关键性和数据时效确定，而不是谁先连上谁先回传。

验收方法

新站点或新 group 上线前，可以用分阶段验收代替“看到绿色就结束”。第一阶段验证控制面：Proxy 与 Server 版本、last access、配置同步、TLS、group state 和主机分配。第二阶段验证数据面：主动 Agent、被动 Agent、SNMP、ICMP、HTTP、ODBC、JMX、trap、sender 和自动注册按实际使用范围抽测。

第三阶段验证故障面。断开 Proxy 到 Server 的链路，确认本地缓存增长且磁盘可控；恢复链路，确认积压下降和历史时间线连续。停止当前 Proxy，确认 group 在设定窗口内重新分配主机；恢复节点，确认不会频繁抖动。阻断目标到 Proxy 的网络，确认告警能指出区域或协议问题。

第四阶段验证运维面：监控 Proxy 自身是否产生告警；日志是否轮转；磁盘满、证书到期、时间偏差和数据库异常是否有提前预警；自动化能否重新部署；值班人员能否根据拓扑和手册定位问题。只有数据、故障和运维三个方向都通过，分布式架构才算完成交付。

验收记录应保留时间、操作、预期、实际、证据和遗留风险。涉及告警的测试要区分“监控项恢复”和“问题事件恢复”，确认通知链路没有遗漏。对于无法自动切换的 trap 或推送路径，要形成明确补偿措施，而不是把限制隐藏在架构说明之外。

监控 Proxy 自身

Proxy 健康监控与排障

Proxy 必须被监控。至少包括服务状态、CPU、内存、磁盘、数据库、时间同步、到 Server 延迟、last access、队列、进程繁忙、缓存使用、版本和未发送数据。Proxy group 还要监控 group state、在线 Proxy 数和主机分布。

Proxy 主机自身最好由另一个路径监控。官方文档提醒，在 group 中监控单个 Proxy 健康时，应把监控该 Proxy 的 host 分配给特定 Proxy，否则结果可能不一致。架构设计时避免 Proxy 只监控自己导致盲区。

时间同步非常重要。Proxy、Server 和被监控主机时间偏差会影响数据时间戳、事件和缓存。所有节点使用可靠 NTP，并对偏差告警。

故障演练

分布式架构必须演练三类故障。第一，Proxy 到 Server 链路中断，确认本地继续采集、缓存增长、恢复后数据补传。第二，Proxy 进程或主机故障，单 Proxy 架构验证告警和恢复，group 架构验证主机重新分配。第三，区域对象到 Proxy 断开，确认故障定位清晰。

演练要记录数据缺口、故障转移时间、告警噪音、恢复回传速度和 Server 压力。nodata() 窗口过短会在切换期间产生大量告警，需要根据实测调整。

恢复后不能只看 Proxy online。要抽查主动 Agent、被动 Agent、SNMP、ICMP、HTTP、ODBC、自动注册和 sender。不同类型切换行为不同。

常见反模式

第一，把 Proxy 当作下级 Server，误以为它计算告警。第二，设计多级 Proxy。第三，只按主机数分配，不看 VPS 和慢检查。第四，把 offline buffer 设置很大但没有磁盘容量。第五，Proxy 使用明文无认证连接。第六，只测试 Agent，不测试 SNMP trap 和推送数据。第七，Proxy group 建好但主机仍绑定单 Proxy。

另一个反模式是过度集中。所有区域都通过一个巨大 Proxy 接入，Proxy 变成新单点。正确做法是按故障域、网络和容量拆分，并对关键区域使用 group。

用架构决策记录保存取舍

分布式监控会随着站点、网络和版本变化，不能只留一张最终拓扑图。建议为关键选择建立简短的架构决策记录，写清问题、约束、候选方案、最终决定、放弃原因、风险和复审条件。例如“上海生产区为什么使用两个主动 Proxy 组成 group，而不是单 Proxy”“SNMP trap 为什么暂时仍指向固定接收节点”“为什么缓存目标是二十四小时而不是七十二小时”。

决策记录能防止后续人员看到两个 Proxy 就误删一个，也能在条件变化时快速判断是否需要重做选择。复审条件应可观察，例如主机数超过某值、required VPS 持续增长、链路最长中断改变、group 多次进入 degrading、数据库磁盘达到容量阈值或业务恢复目标升级。记录重点是解释取舍，不是重复配置文件。

日常值守也应有一致判定顺序。发现某区域大量主机无数据时，先确认中心 Server 和数据库是否正常，再看 Proxy last access 与 group state；Proxy 离线时检查服务、主机资源、时间同步、数据库和到 Server 的网络；Proxy 在线但数据延迟时检查 queue、进程繁忙、缓存和协议依赖；只有区域链路与 Proxy 正常后，才进入单主机、Agent、SNMP ACL 或模板排查。

如果 group 发生重新分配，要记录原成员、接管成员、切换时间、受影响主机和不同协议的恢复情况。恢复原节点后观察是否发生再次平衡，以及数据是否重复或缺失。长期积累这些事件，可以反推 failover period 是否过短、成员容量是否不均、网络是否频繁抖动，并为下一次扩容提供证据。

分布式监控的成熟度不体现在 Proxy 数量，而体现在边界是否清晰、失败是否可预测、恢复是否经过验证、变更是否可追溯。架构决策记录、容量基线和演练证据共同构成可维护性，缺少其中任何一项，拓扑再复杂也只是部署完成，而不是工程交付。

交付清单

分布式监控交付包括拓扑、区域、Proxy/group 清单、模式、版本、数据库、TLS、Server 地址、local address、主机分配、协议依赖、缓存容量、VPS、网络 ACL、监控模板、告警、维护窗口、故障演练和责任人。

每季度复审 Proxy 版本、last seen、group state、主机分布、VPS、queue、cache、磁盘、证书或 PSK、数据库、断网记录和未发送数据。Server 升级时 Proxy 升级纳入同一计划，Proxy group 对版本匹配有明确要求。

小结

Zabbix 分布式监控的核心是用 Proxy 把采集靠近对象，用缓存抵御链路中断，用 Proxy group 在 7.0 中实现组内故障转移和主机再平衡，同时保持中心 Server 对触发器、事件和历史的统一控制。

下一篇进入性能优化，将从 Server、Proxy、数据库、预处理、缓存、模板和前端一起判断瓶颈，而不是盲目扩大进程参数。

参考资料