We'll start with an active proxy—one that connects to the Zabbix server.
When setting up the proxy for this exercise, it is suggested to use a separate machine. If that is not possible, you can choose to run the proxy on the Zabbix server system.
If installing the proxy from packages, we will have to choose a database. Zabbix proxy uses its own database. If compiling the proxy from the sources, use the --enable proxy parameter and the corresponding database parameter.
Additionally, the proxy must have support compiled in for all features it should monitor, including SNMP, IPMI, web monitoring, and VMware support. See Chapter 1, Getting Started with Zabbix, for compilation options.
If a proxy is compiled from the same source directory the server was compiled from, and the compilation fails, try running make clean first.
Which database should you choose for the Zabbix proxy? If the proxy will be monitoring a small environment, SQLite might be a good choice. Using SQLite for the Zabbix server backend is not supported, as it is likely to have locking and performance issues. On a Zabbix proxy, it should be much less of a problem. If setting up a large proxy, MySQL or PostgreSQL would be a better choice. During this chapter, we will use the proxy with a SQLite database, as that is very easy to set up.
If compiling from the sources, SQLite development headers will be needed. In most distributions, they will be provided in a package named sqlite-devel or similar. If you install from the package, then you have to install it with yum or apt and the package name will look similar to zabbix-proxy-sqlite3, but this is something you have to check. For other databases than SQLite, you need to replace sqlite3 with the correct database name.
Edit zabbix_proxy.conf. We will change three parameters:
- DBName
- Hostname
- Server
Change them to read as follows:
DBName=/tmp/zabbix_proxy.db Hostname=First proxy Server=<Zabbix server IP address>
The parameters in the preceding code block are explained as follows:
- The first parameter, DBName, is the same as for the Zabbix server, except we do not just specify the database name here. For SQLite, the path to database file is specified here. While a relative path may be used, in most situations it will be much more complicated to start the proxy, thus an absolute path is highly suggested. We used a file in /tmp to make the setup of our first proxy simpler, no need to worry about filesystem permissions. What about the database username and password? As the comments in the configuration file indicate, they are both ignored when SQLite is used.
Placing the SQLite database on a tmpfs filesystem can also be useful if you run your proxy on embedded devices at one of you clients. In case things go wrong you could just ask your client to restart the device. You will lose some data, but the database will be created again once the proxy is up. With corrupt databases, you would have some more work to recover data or fix the corrupt DB.
- The second parameter, Hostname, will be used by the proxy to identify itself to the Zabbix server. The principle is the same as with the active agent: the value, specified here, must match the proxy name as configured on the server side (we will set that up in a moment), and is case-sensitive.
- The third parameter, Server, acts the same way as it did with active agents. The active proxy connects to the Zabbix server and we specify the server IP address here.
As with the Zabbix server, you must ensure that the appropriate pollers are configured to start. For example, if you want to monitor IPMI devices through a proxy, make sure to set the StartIPMIPollers parameter in the proxy configuration file to a value other than the default 0.
Start the Zabbix proxy now. Wait, we did not create the database for the proxy. What will it do? Let's look at the proxy log file—check /tmp/zabbix_proxy.log, or the location set in the proxy configuration file. Paying close attention, we can find some interesting log records:
3890:20181228:123654.746 using configuration file: /etc/zabbix/zabbix_proxy.conf
3890:20181228:123654.746 cannot open database file "/tmp/zabbix_proxy.db": [2] No such file or directory
3890:20181228:123654.746 creating database ...
It first failed to open an existing database file, then proceeded to create the database. The Zabbix proxy can automatically create the required SQLite database and populate it. Note that this is true for SQLite only—if using any other database, we would have to create the database manually and insert schema. This is also possible for SQLite—using the sqlite3 utility, we would do it like this:
$ sqlite3 /tmp/zabbix_proxy.db < schema.sql
But schema only! Not just for SQLite—for all databases—the proxy needs schema only. No data and no image SQL files should be used. If the Zabbix proxy detects some extra data in the database, it exits, complaining that it cannot use the server database. Older proxy versions could crash or even corrupt the server database in such a case. A link to the documentation on where to find the DB schemas is provided at the end of this chapter.
If a proxy complains that it cannot work with a server database, it will have found entries in the users table.
We could also verify that the Zabbix proxy is listening on the port it should be by running the following:
$ ss -ntl | grep 10051
The output should confirm that everything is correct:
LISTEN 0 128 *:10051 *:*
If installing on the same machine, check for port 11051, or whichever other port you chose.
There are a few log entries that indicate something is not working properly:
cannot send heartbeat message to server at "192.168.56.10": proxy "First proxy" not found cannot obtain configuration data from server at "192.168.56.10": proxy "First proxy" not found
We only configured and started the proxy daemon, but we did not configure anything related to proxies on the server side. Let's monitor a host through our new proxy.