Learn Zabbix - Proxy & Distributed Monitoring

#Introduction

All previous episodes used a single Zabbix server that directly contacts hosts. This architecture is perfect for one location, but it starts to break down when hosts are spread across branch offices, networks with strict NAT, or across countries. Episode 10 introduces Zabbix Proxy — the component that enables distributed monitoring without sacrificing a single point of control.

The proxy concept from episode 2 now becomes concrete. You'll install a proxy at the remote location, configure zabbix_proxy.conf, choose between active and passive proxies, then point hosts to send data through the proxy. By the end of the episode, a single central server can monitor hosts in any location.

#Why You Need a Proxy

#Offloading Remote Locations

Zabbix Proxy is a process that collects data on behalf of the server at a distant location. The proxy takes over collection from its local hosts, stores the data temporarily in its own database, then sends it to the server periodically. This reduces the central network load and speeds up access to hosts that are actually located close to the proxy.

#Processes on the Proxy Side

The proxy runs processes similar to the server: pollers, trappers, and housekeeper. The main difference is that the proxy doesn't evaluate triggers — all evaluation stays at the central server. The proxy is simply a reliable data conduit in environments where connections aren't always stable.

#Proxy Installation and Configuration

#Installing the Proxy Package

Install it on a machine located at the remote site. The proxy package comes in different database variants:

wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu24.04_all.deb
dpkg -i zabbix-release_latest_7.0+ubuntu24.04_all.deb
apt update
apt install -y zabbix-proxy-sqlite3

The zabbix-proxy-sqlite3 package uses a local SQLite database — the simplest choice for small locations. For proxies handling many hosts, use the zabbix-proxy-mysql or zabbix-proxy-pgsql variant.

#zabbix_proxy.conf: Core Parameters

The file /etc/zabbix/zabbix_proxy.conf defines how the proxy communicates with the server:

Server=192.168.1.10
Hostname=proxy-branch-jakarta
DBName=zabbix_proxy
DBUser=zabbix
DBPassword=ProxyPassword

The Server parameter holds the address of the central server the proxy will contact, and Hostname is the proxy's unique name, which must match the proxy name in the frontend. The command systemctl restart zabbix-proxy is applied after every configuration change.

#Active Proxy versus Passive Proxy

The connection direction determines the operating mode:

• Active proxy: the proxy contacts the server on port 10051 and fetches data. Suitable for locations behind NAT because it only needs an outbound connection.
• Passive proxy: the server contacts the proxy on port 10051. Requires a proxy reachable from the server.

The mode is set via the ProxyMode parameter in zabbix_proxy.conf. For the majority of branch office use cases, an active proxy is the easiest to deploy.

#Proxy Database: SQLite or MySQL

#Choosing According to Scale

The proxy stores data temporarily in a local database before forwarding it to the server:

• SQLite: zero administration, sufficient for a few dozen hosts.
• MySQL or PostgreSQL: for hundreds of hosts, or when the proxy also runs heavy LLD.

For the MySQL variant, set up the database and user as in episode 3, then import the schema that ships in the zabbix-sql-scripts package. Never point a proxy at the central server's database — the two must stay separate.

#Connecting Hosts to the Proxy

#Adding the Proxy in the Frontend

The proxy is registered in the Data collection → Proxies menu with a name identical to the Hostname in zabbix_proxy.conf. Once registered, the proxy appears as an option when adding or editing hosts.

#Pointing Agents to the Proxy

On hosts monitored via a proxy, the Server and ServerActive parameters in zabbix_agent2.conf point to the proxy's address, not the central server:

Server=10.0.0.5
ServerActive=10.0.0.5
Hostname=host-branch-01

With this configuration, the agent only communicates with the proxy on its local network. The central server still controls everything through the proxy without having to reach hosts directly.

#Real Use Case: Branch Office and NAT

The most common deployment patterns in production:

• Branch office: one proxy per branch office, all local hosts point to the proxy.
• Firewall-NAT: an active proxy inside the DMZ, requiring only one outbound connection to the central server.
• Scaling remote hosts: one proxy handles hundreds of hosts, reducing the collection load on the central server.

Central Server ── proxy-branch-jakarta ── branch hosts (10-50 hosts)
              └─ proxy-dc-surabaya   ── branch hosts (10-50 hosts)

Each proxy relieves network and collection load. If a proxy loses its connection to the server, data is still collected and stored temporarily — when the connection recovers, the data is sent automatically. This keeps monitoring running even when inter-site networking is unstable.

#Closing

Episode 10 opened a new scale: proxies collect data at remote locations, store it temporarily, and forward it to the central server. You understand the difference between active and passive proxies, the choice between SQLite or MySQL databases, and the most common branch office and NAT patterns.

Key takeaways:

• The proxy offloads collection at remote locations and stores data temporarily.
• Active proxies contact the server; passive proxies are contacted by the server.
• SQLite suffices for small locations; MySQL or PostgreSQL for larger scale.
• Hosts point their agents at the nearest proxy, not the central server.
• An active proxy is the primary choice for environments with strict NAT and firewalls.

In the next episode 11 we'll discuss auto-registration and discovery — network discovery to find new devices, auto-registration actions for automatic host provisioning, and low-level discovery (LLD) to dynamically find filesystems, interfaces, and disks.