Zabbix proxies and proxy groups

From Zabbix 7.0, proxy groups automatically redistribute monitored hosts among member proxies when a proxy goes offline, which provides load balancing and high availability for proxied monitoring. The exact mechanics, including how hosts are assigned and when they move back, are described in the Zabbix proxy load balancing and high availability documentation. Read that page against the exact version you plan to run before you design around it, because the behavior you rely on is what the documentation defines. This section covers the design decisions that sit on top of that behavior.

The first decision is which proxies belong to a group. Members should be proxies that are meant to share the same pool of hosts, not proxies that merely sit close to each other on the network. The second decision is whether members sit in the same network zone. Members in one zone usually reach the same hosts, so inherited monitoring behaves predictably. Members split across zones may inherit hosts they cannot reach. The third decision is whether each proxy can reach every host it might inherit, including the ports, agent connections, SNMP access and credentials that each item type needs.

A group does not fix a host that is unreachable from every member. If no proxy in the group can reach a host, redistribution only moves a failing check from one proxy to another, and the host still shows no data. Inherited hosts also add load. The receiving proxy must absorb their items, and its capacity, its own network reach and its share of the database writes all determine whether the extra work is handled. Confirm this with a test that removes one member from a group that carries production-like host and item counts, and watch the remaining proxies during that test rather than assuming they will cope.

Before you go live, map each host to at least two group members that can reach it, and record the expected item load each proxy would carry if a peer failed. Run a planned outage of one member in a test environment, then confirm that hosts moved, that data resumed on the receiving proxies and that alerts still fired. Keep monitoring the proxies themselves, since the failover only helps if a proxy failure is noticed. Ask your implementation partner or your own team to document these checks as acceptance criteria before the design is signed off.

The point of the test is to replace assumptions with recorded evidence before a proxy group carries production hosts. Start with a staging group that mirrors your production layout: the same proxy versions, the same host types, and a representative set of hosts behind each proxy. Before you stop anything, confirm that every member reports fresh data. In the Zabbix frontend, check each proxy's last-seen status and the host count assigned to it, then sample a few items per host to confirm values are arriving on schedule. Write this baseline down. Without it, you cannot tell later whether a gap was caused by your test or was already there. Next, stop one proxy and watch what happens to its hosts. The hosts should move to another group member and resume sending data. Record four timestamps: when the proxy stopped, when the host assignment changed, when the first value arrived from the new proxy, and when the item history resumed. The difference between the last value before the stop and the first value after the move is your monitoring gap. Confirm with your Zabbix version's documentation how the group decides a proxy is offline and what delay applies, since the failover timing depends on that setting rather than on how quickly you act in the console.

Three failure modes need their own test cases, because group redistribution does not cover all of them. The first is a set of hosts that cannot be reached from any group member. Redistribution moves the assignment, but the new proxy cannot collect data either, so the test should show alerts firing for those hosts and confirm that nobody mistakes the group for protection against a network-wide fault. The second is a proxy that is running but cannot reach the Zabbix server. Its process looks healthy from the host it runs on, yet the server receives nothing from it. Check whether the group treats this case as offline, and confirm this against the proxy and server logs rather than process status alone. The third case is queued data after a restart. Stop a proxy while it is still collecting, then restart it and watch the buffer drain. Confirm that values collected during the outage arrive at the server with their original timestamps, and that the history graphs fill in without duplicate points. Check the proxy's buffer settings in your version's documentation before the test, because the amount of data a proxy can hold depends on configuration and on the storage it uses. Record the buffer size at the start, the peak during the outage, and the drain time after restart.

Restore the stopped proxy and check rebalancing. Decide in advance whether hosts should move back automatically, stay where they were moved, or be rebalanced by a defined process. Confirm this against the proxy group documentation for your version, because the expected behavior is a design decision you should document, not something you assume. Then verify that each proxy carries the number of hosts you expect and that no host is assigned to two places at once. Keep the evidence together: frontend screenshots or exports of proxy and host assignments, server and proxy log excerpts covering the stop and restart, item history for a sample of hosts across the gap, and the four timestamps from the failover run. A reviewer should be able to reconstruct the test from this record alone. If redistribution does not happen as designed, stop the test and fail safely. Do not keep stopping proxies to see if the group recovers on its own. Instead, manually reassign the affected hosts to a known working proxy through their host configuration, one batch at a time, and confirm each batch receives data before moving the next. Log every manual change with the time, the host, the old and new proxy, and the reason. Then compare the final assignment with the baseline you recorded at the start. Treat any unexplained difference as a finding to resolve before production use, and never run this test against live hosts without a written rollback plan agreed with the owners of those hosts.

The handover for a Zabbix proxy engagement is a set of records your team can operate without us. It starts with the proxy and proxy group design: which sites or network segments each proxy serves, which hosts sit in which group, and how monitored hosts are expected to move when a proxy goes offline. Alongside that comes a network diagram showing each proxy, the server or server cluster it reports to, and every firewall path it uses. Each path is written as a source, destination, port and direction, so a security team can check it against its own rule base. Where a proxy group relies on automatic redistribution, the diagram also shows the paths each candidate proxy needs to reach the hosts it might inherit.

Configuration records cover the settings that were actually applied: proxy names, operating mode, the proxy group assignments, and the encryption and certificate choices made for server to proxy and proxy to agent traffic. You also receive test evidence from the failover exercise. That evidence should show which proxy was stopped, when the group redistributed hosts, how long data gaps lasted in the frontend, and whether alerts still fired during the event. Ask for the raw output and the time stamps, not only a summary sentence. A runbook for adding a proxy or moving hosts between proxies completes the set, with pre-checks, the exact frontend and configuration steps, rollback steps and the checks that confirm monitoring resumed. Operator training notes explain how to read proxy queue and last-seen values, which conditions should prompt escalation, and which changes should go through the change process.

Several inputs decide whether this package can be produced on the written timeline. You need to provide network access to the sites and segments in scope, along with the change windows in which firewall rules can be opened and proxies restarted or moved. Ask your network and security teams to confirm these windows before scoping, because failover testing usually depends on them. You also need a host inventory: hostnames or addresses, the segment each one sits in, the monitoring role it plays, and whether it is reachable from more than one proxy. An incomplete inventory is the most common cause of late changes to the group design.

Each site needs a named owner who can answer questions about its hosts, approve changes within that site, and accept the failover results. Owners should be people with authority over the network segment, not only the application team. You also need to make two policy decisions early: how proxy and agent traffic is encrypted, and who may change proxy assignments in the frontend or through the API. These decisions affect certificate work, firewall rules and the role design in the Zabbix frontend, so they should be recorded in the written scope rather than settled during testing.

The scope and the quote define how much of this package is included, how many sites and proxies it covers, and when each deliverable is due. Confirm with us in writing which records, diagrams and training sessions are included, and which are optional. If your environment has more sites, stricter change control or more complex firewall approval, ask how those factors change the schedule and the effort before work starts.