Now that we have the proxy configured and running, we have to inform Zabbix about it somehow. To do this, open Administration | Proxies in the frontend, then click on the Create proxy button. Enter First proxy in the Proxy name field.

In the following section, Hosts allows us to specify which hosts will be monitored by this proxy. To make one host monitored by the proxy, select Another host in the Other hosts list box and click on the button:

When done, click on Add. Next time the proxy connects to the server, the names should match and the proxy should get the information on what it is supposed to monitor. But when will that next time be? By default, the Zabbix proxy connects to the Zabbix server once per hour. The first connection attempt happens upon proxy startup, and at one-hour intervals from then on. If you configured the frontend part soon after the proxy was started, it could take up to an hour for the proxy to get the configuration data and start working. There are two ways to force re-reading of the configuration data from the Zabbix server:

The first one would be acceptable on our test proxy, but it would not be that nice on a larger production proxy that is actively collecting data already. Let's see how we can force reloading of the configuration cache. First run:

# zabbix_proxy --help

In the output, pay attention to the runtime control section and the first parameter in it:

  -R --runtime-control runtime-option   Perform administrative functions
    Runtime control options:
      config_cache_reload        Reload configuration cache

When an active proxy is told to reload its configuration cache, it connects to the server, gets the new configuration data, and then updates the local cache. Let's issue that command now:

# zabbix_proxy --runtime-control config_cache_reload

The reload command should be processed successfully:

zabbix_proxy [19293]: command sent successfully

Check the proxy logfile now:

forced reloading of the configuration cache
received configuration data from server at "192.168.56.10", datalen 6545

First, the proxy logs that it has received an order to reload the configuration cache. Then it connects to the server and successfully retrieves the configuration data from the server.

You can verify whether the proxy can successfully connect to the server by opening Administration | Proxies again. Look at the LAST SEEN (AGE) column for the new proxy. Instead of saying never, it should show some time period. If it does not, check that both the Zabbix server and proxy are running, and that you can open a connection from the proxy host to the Zabbix server, port 10051.

But if you look at the HOSTS column, you'll see that it is empty now. What happened here? We clearly added Another host to be monitored by this proxy—why did it disappear? This could be a challenging task to figure out, and a situation like that could easily arise in a production environment, too. The reason for the host disappearing from the proxy configuration is active-agent auto-registration. We configured it in Chapter 12, Automating Configuration, and the agent has been sort of repeatedly auto-registering ever since. But why does that affect the host assignment to proxy? When an active agent connects and auto-registration is active, it matters where it connects to. Instead of creating a new host, the Zabbix server reassigns that host to the Zabbix server or some proxy, whichever received the agent connection. It considers that agent as having migrated from the server to some proxy or vice versa, or from one proxy to another. We assigned a host to our new proxy, the agent kept on connecting to the server, and the server reassigned that host back to be monitored directly by the server. How could we solve it? We have two options:

Let's try the second, fancier approach. On Another host, edit zabbix_agentd.conf and change ServerActive to the proxy IP address, then restart the agent.

Check the proxy list again. There should be Another host in the HOSTS column now, and it should not disappear anymore. Let's check data for this host in Monitoring | Latest data. Unfortunately, it looks like most items have stopped working. While we changed the active server parameter in the agent daemon configuration file and active agent items work now, there are more item categories that could have failed:

Let's fix at least the passive agent items. Edit zabbix_agentd.conf on Another host and change the Server parameter. Either replace the IP address in there with the proxy address, or add the proxy address to it, then restart the agent. In a few minutes, most of the passive agent items should start receiving data again.

As for the ICMP items, refer to Chapter 3, Monitoring with Zabbix Agents and Basic Protocols for fping configuration. It's the same as on the server side; it's just that the changes have to be performed on the proxy system now.

In general, when a host is monitored by proxy, all connections to and from that host must and will be performed by the proxy. The agent must allow connections from the proxy for passive items and connect to the proxy for active items. Even the Zabbix sender must send data to the proxy for Zabbix trapper items, not the Zabbix server anymore.

With the host monitored by the proxy, let's check whether there is any indication of that in the frontend. Open Configuration | Hosts, make sure Linux servers is selected in the Group dropdown, and take a look at the NAME column. As can be seen, Another host is now prefixed by the proxy name and reads First proxy:Another host:

But do we always have to go to Administration | Proxies whenever we want to have a host monitored by proxy? Click on Another host in the NAME column, and observe the available properties. There's a dropdown available, Monitored by proxy. Using this dropdown, we can easily assign a host to be monitored by the chosen proxy (remembering to change the server IP address in the agent daemon configuration file):