When proxies are useful

A server is not always able to connect directly to the monitored machines. We could use active items everywhere (where Zabbix agents connect to a Zabbix server, discussed in Chapter 3), but that would require access from all of the monitored hosts to the Zabbix server. Additionally, that would not work for SNMP, IPMI, and other monitoring methods. This is common when devices from other organizations have to be monitored, or when such restrictions are in place in a large corporate network.

This is where Zabbix proxy comes in. When set up, only connections to the Zabbix server come from the proxy, which, in turn, does all the monitoring on behalf of the Zabbix server.

In this example, there’s no need for individual connections from Zabbix to individual devices in the remote location or the other way around—single firewall rule to allow Zabbix proxy connections to the Zabbix server is sufficient.

So how does the proxy work? Let’s repeat: Only the Zabbix proxy connects to the Zabbix serverv. This bit of information is crucial to understanding how it actually works. When the proxy connects to the server, it requests configuration information about what it has to monitor, then goes and does just that. As data is gathered, proxy sends it back to the server. Does that sound familiar? It should, because that part sounds just like an active agent, except that the proxy can gather data from different systems pretty much like the Zabbix server can. It sounds almost like a super agent. Actually, it is said that the proxy was at first internally named “super agent”, which confirms the similarity.

The Zabbix proxy is a very useful feature, the first stable Zabbix version to introduce it was 1.6, back in 2008. Given the usefulness of the Zabbix proxy, it is surprising that for a long time no other solutions provided something comparable. Today, Zabbix proxies continue to lead the way by having and improving features that are considered most useful for remote data collection. As we will see later, there are other benefits that proxies can provide, so let’s get to actually setting one up.

Setting up the proxy

W hen setting up the proxy for this exercise, it is suggested you use a separate (physical or virtual) machine. If not possible, you can choose to run proxy on the same machine, as hints will be provided for such a setup as well.

Before proceeding, we will have to compile the proxy itself. When compiling the proxy there are a few mandatory parameters, –enable-proxy being one. Zabbix proxy also needs a database, so you have to include support for one. While it is not suggested to use SQLite on Zabbix itself because of the performance issue, the proxy might be a good candidate. Unless it is going to monitor lots of systems, SQLite’s performance can be satisfactory, and it is trivial to set up because Zabbix server creates and populates the database automatically.

Additionally, Zabbix proxy must have support compiled in for things it will be monitoring, like SNMP, IPMI, and web monitoring. Let’s say we want to compile Zabbix proxy with SQLite support and the ability to monitor web, SNMP, and IPMI. Obviously, we will need all the relevant support libraries mentioned when we first compiled Zabbix, but this time we’ll also need another one—SQLite development headers. On most distributions they will be included in a package named sqlite-devel or similar, so make sure to install this package before proceeding. Then, on the machine where you plan to install Zabbix proxy, enter the directory where the Zabbix installation source has been extracted to and execute:

$ ./configure --enable-proxy --with-sqlite3 --with-libcurl --with-netsnmp
--with-openipmi && make

This will both configure and compile Zabbix proxy. We can again use the simple and universal solution to create a more or less proper package by executing as root:

# checkinstall --nodoc --install=yes -y --pkgname=zabbix-proxy

The proxy binary is now compiled and in place, we can put our hands on the configuration now. First things first—it must be placed in the correct location:

# cp misc/conf/zabbix_proxy.conf /etc/zabbix

Now open /etc/zabbix/zabbix_proxy.conf as root and make some changes to get the proxy running:

Hostname=proxy

Hostname is an important parameter. As with active agents, if it’s wrong, nothing will work.

Server=<Zabbix server IP address>

Zabbix proxy connects to the Zabbix server, so it must know where to connect to.

DBName=/tmp/zabbix_proxy.db

We will try to use an SQLite database, thus the full path to the database file must be specified.

Let’s try to start the Zabbix proxy now, as root execute:

# zabbix_proxy

Wait, we did not create the database like we did when installing the server—the proxy couldn’t start up, right? Let’s look at the log file—open /tmp/zabbix_proxy.log. Paying close attention we can find some interesting log records.

27982:20090729:131636.530 Cannot open database file "/tmp/zabbix_
proxy.db": No such file or directory
27982:20090729:131636.531 Creating database ...

Wonderful. Zabbix proxy can automatically create the required SQLite database and populate it.

We could also verify that Zabbix proxy is listening on the port it should be by running:

$ netstat -ntl | grep 10051

The output should confirm that everything is correct.

Monitoring a host through a proxy

N ow that we have the proxy compiled, configured, and running, we have to inform Zabbix about it somehow. To do this, open Administration | DM in the frontend, then select Proxies in the first dropdown. No proxies are listed, so we have to create one—click the Create Proxy button and complete the form. Enter proxy in the Proxy name field.

The section below; Hosts, allows us to specify which hosts will be monitored by this proxy. To make one host monitored by proxy, mark Another Host in the Other Hosts list box and click on the << button.

When you are done, click Save.

This server should now be monitored by the proxy, right? Again, not quite. As you might remember, we were setting the Zabbix server IP address in the agent configuration files so that agents would accept connections from these servers and send active check data to them. When we change a host to be monitored by a proxy, all connections will be made from the proxy, thus the proxy address must be added to the agent daemon’s configuration file.

As root, edit /etc/zabbix/zabbix_agentd.conf on Another Host and change the Hostname line to have the Zabbix proxy IP address instead of the Zabbix server IP address. Save the file, then restart the agent daemon. Now this agent will send all data to the proxy only, no connection will be made to or from Zabbix server.

If, on the other hand, you have the proxy running on the same host as Zabbix server, agent will not notice that it is now queried by the proxy, not by the server, because the source IP would not have changed. The agent is still requesting and sending active checks to port 10051, Zabbix server port. To change this for the proxy port, edit /etc/zabbix/zabbix_agentd.conf on Another Host as root and change the ServerPort line to read:

ServerPort=10052

Don’t forget to remove the leading hash mark, then restart the agent daemon.

With the host monitored solely by the proxy, let’s check whether there are any indications 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 proxy:Another Host.

Of course, we are not limited in our proxy name choice, we could have named it “Nothing to see here” for all that the Zabbix server cares.

But do we have to always go to Administration | DM whenever we want to make a host monitored by proxy? Click on Another Host in the Name column, and observe the available properties. There’s one dropdown available, Monitored by proxy. Using this dropdown we can easily assign a host to be monitored by the chosen proxy (remembering to change server IP address in the agent daemon configuration file, if using active checks).