Zabbix Proxy: Distributed Monitoring and Active Mode - 夜莺博客

Zabbix Proxy: Distributed Monitoring and Active Mode

Zabbix proxies solve the two problems that break centralised monitoring as an estate grows: bandwidth across WAN links and firewall complexity. A proxy collects data on behalf of the server, preprocesses it, and forwards it — and it needs only one TCP connection to the server, which means one firewall rule per remote site instead of a rule for every monitored host. This guide covers the proxy function split, active versus passive mode, the buffer behaviour that determines whether an outage loses data, and how proxy groups give you redundancy.

What a proxy does and does not do

A proxy can perform most item types: Zabbix agent checks (passive and active), SNMP checks and traps, IPMI, JMX, SSH and Telnet checks, external and script items, log file monitoring, dependent items, built-in web monitoring, item value preprocessing, network discovery and low-level discovery, remote commands and active agent autoregistration.

What it deliberately does not do is the analytical half of Zabbix: calculating triggers, processing events, event correlation and sending alerts all remain on the server. That split is why proxies stay lightweight — they collect, preprocess and forward, while the server owns logic and notification. For low-level discovery, the proxy only collects and preprocesses; the server does the final processing.

One hard requirement: a proxy must use its own database. Pointing it at the Zabbix server database breaks the configuration.

Active versus passive mode

  • Active — the proxy initiates the connection to the server, requests configuration data and sends collected values. Only one TCP connection is needed, and it originates inside the remote network, which is usually the easier direction to permit.
  • Passive — the server connects to the proxy. Simpler conceptually, but the server must be able to reach the proxy's listening port (10051 by default) from wherever it runs.
# zabbix_proxy.conf — active mode
ProxyMode=0
Server=zabbix.example.com
Hostname=proxy-site-a
ProxyConfigFrequency=60
DataSenderFrequency=1
ProxyOfflineBuffer=72

# zabbix_proxy.conf — passive mode
ProxyMode=1
Server=10.10.10.20
Hostname=proxy-site-a
ProxyOfflineBuffer=72

In active mode, Server is the server address (or a semicolon-separated cluster of nodes) the proxy pulls configuration from and pushes data to. In passive mode, Server is a comma-delimited list of addresses from which incoming connections are accepted — an empty or wrong value here is the reason a passive proxy shows as unreachable.

Active mode has a security consideration worth designing around: without encryption, configuration data can be requested by anyone who can reach the server's trapper port, because no authentication takes place and any client can claim to be an active proxy. Two mitigations: restrict Proxy address in the frontend to the exact source addresses of your proxies, and enable certificate or PSK encryption on the proxy connection.

Agent configuration on monitored hosts

Hosts monitored by a proxy must know where to send active checks. Add the proxy to ServerActive in the agent configuration so active items are served by the proxy rather than the server, and keep Server pointing at the proxy for passive checks.

The offline buffer decides whether an outage costs you data

ProxyOfflineBuffer sets, in hours, how long the proxy keeps collected values while it cannot reach the server. The default is modest, and a WAN outage longer than the buffer silently discards data — which then appears in reports as a gap nobody can explain. Size it against your worst realistic outage plus a margin, and remember that it is measured in hours of collected data, not hours of wall clock at low volume.

Set ProxyConfigFrequency to control how often an active proxy refreshes its configuration from the server. Shorter means quicker propagation of template changes; it also means more frequent polling of the server. Note that an active proxy still polls the server roughly every second for remote command tasks regardless.

Registering the proxy in the frontend

  1. Administration → Proxies → Create proxy.
  2. Proxy name must exactly match the Hostname parameter in the proxy configuration file. A mismatch is the single most common reason a working proxy never shows as available.
  3. Proxy mode — active or passive, matching the configuration file.
  4. For active mode, optionally restrict Proxy address to the source addresses. For passive mode, supply the interface address and port.
  5. Optionally assign the proxy to a proxy group for load balancing and high availability, and configure Address for active agents so agents and senders connect to the group rather than an individual proxy.
  6. Use the Monitored by field on hosts — or host mass update — to assign hosts to the proxy or proxy group.

Operational checklist

  • Monitor the proxies themselves: availability, queue backlog and the age of the last data sent.
  • Size the proxy host for preprocessing, not just collection — heavy preprocessing shifts CPU to the proxy.
  • Encrypt proxy connections with PSK or certificates in any design where the WAN is not trusted.
  • Use proxy groups if losing one site's visibility is unacceptable; the group provides failover for the hosts assigned to it.
  • Keep the proxy's own database backed up; restoring a proxy is trivial, recreating its history is not.
  • A proxy pair with existing SNMP templates covers most estate-level requirements — see Zabbix SNMP monitoring for network devices for device templates, and LibreNMS deployment for network monitoring if you want a comparison of what a purpose-built network monitoring platform does differently.

原文链接:https://www.zabbix.com/documentation/current/en/manual/distributed_monitoring/proxies