In this article by Andrea Dalle Vacche, author of the book Mastering Zabbix, Second Edition, you will learn the basics on how to deploy a Zabbix proxy on a Zabbix server.
(For more resources related to this topic, see here.)
A Zabbix proxy is compiled together with the main server if you add –enable-proxy to the compilation options. The proxy can use any kind of database backend, just as the server does, but if you don’t specify an existing DB, it will automatically create a local SQLite database to store its data. If you intend to rely on SQLite, just remember to add –with-sqlite3 to the options as well.
When it comes to proxies, it’s usually advisable to keep things light and simple as much as we can; of course, this is valid only if the network design permits us to take this decision. A proxy DB will just contain configuration and measurement data that, under normal circumstances, is almost immediately synchronized with the main server. Dedicating a full-blown database to it is usually an overkill, so unless you have very specific requirements, the SQLite option will provide the best balance between performance and ease of management.
If you didn’t compile the proxy executable the first time you deployed Zabbix, just run configure again with the options you need for the proxies:
$ ./configure --enable-proxy --enable-static --with-sqlite3 --with-net-snmp --with-libcurl --with-ssh2 --with-openipmiIn order to build the proxy statically, you must have a static version of every external library needed. The configure script doesn’t do this kind of check.
Compile everything again using the following command:
$ makeBe aware that this will compile the main server as well; just remember not to run make install, nor copy the new Zabbix server executable over the old one in the destination directory.
The only files you need to take and copy over to the proxy machine are the proxy executable and its configuration file. The $PREFIX variable should resolve to the same path you used in the configuration command (/usr/local by default):
# cp src/zabbix_proxy/zabbix_proxy $PREFIX/sbin/zabbix_proxy
# cp conf/zabbix_proxy.conf $PREFIX/etc/zabbix_proxy.confNext, you need to fill out relevant information in the proxy’s configuration file. The default values should be fine in most cases, but you definitely need to make sure that the following options reflect your requirements and network status:
ProxyMode=0This means that the proxy machine is in an active mode. Remember that you need at least as many Zabbix trappers on the main server as the number of proxies you deploy. Set the value to 1 if you need or prefer a proxy in the passive mode. The following code captures this discussion:
Server=n.n.n.nThis should be the IP number of the main Zabbix server or of the Zabbix node that this proxy should report to:
Hostname=Zabbix proxyThis must be a unique, case-sensitive name that will be used in the main Zabbix server’s configuration to refer to the proxy:
LogFile=/tmp/zabbix_proxy.log
LogFileSize=1
DebugLevel=2If you are using a small, embedded machine, you may not have much disk space to spare. In that case, you may want to comment all the options regarding the log file and let syslog send the proxy’s log to another server on the Internet:
# DBHost=
# DBSchema=
# DBUser=
# DBPassword=
# DBSocket=
# DBPort=We need now create the SQLite database; this can be done with the following commands:
$ mkdir –p /var/lib/sqlite/
$ sqlite3 /var/lib/sqlite/zabbix.db < /usr/share/doc/zabbix-proxy-sqlite3-2.4.4/create/schema.sqlNow, in the DBName parameter, we need to specify the full path to our SQLite database:
DBName=/var/lib/sqlite/zabbix.dbThe proxy will automatically populate and use a local SQLite database. Fill out the relevant information if you are using a dedicated, external database:
ProxyOfflineBuffer=1This is the number of hours that a proxy will keep monitored measurements if communications with the Zabbix server go down. Once the limit has been reached, the proxy will housekeep away the old data. You may want to double or triple it if you know that you have a faulty, unreliable link between the proxy and server.
CacheSize=8MThis is the size of the configuration cache. Make it bigger if you have a large number of hosts and items to monitor.
Zabbix’s runtime proxy commands
There is a set of commands that you can run against the proxy to change runtime parameters. This set of commands is really useful if your proxy is struggling with items, in the sense that it is taking longer to deliver the items and maintain our Zabbix proxy up and running.
You can force the configuration cache to get refreshed from the Zabbix server with the following:
$ zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R config_cache_reload This command will invalidate the configuration cache on the proxy side and will force the proxy to ask for the current configuration to our Zabbix server.
We can also increase or decrease the log level quite easily at runtime with log_level_increase and log_level_decrease:
$ zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf –R log_level_increaseThis command will increase the log level for the proxy process; the same command also supports a target that can be PID, process type or process type, number here. What follow are a few examples.
Increase the log level of the three poller process:
$ zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=poller,3Increase the log level of the PID to 27425:
$ zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=27425Increase or decrease the log level of icmp pinger or any other proxy processes with:
$ zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase="icmp pinger"
zabbix_proxy [28064]: command sent successfully
$ zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_decrease="icmp pinger"
zabbix_proxy [28070]: command sent successfullyWe can quickly see the changes reflected in the log file here:
28049:20150412:021435.841 log level has been increased to 4 (debug)
28049:20150412:021443.129 Got signal [signal:10(SIGUSR1),sender_pid:28034,sender_uid:501,value_int:770(0x00000302)].
28049:20150412:021443.129 log level has been decreased to 3 (warning)Deploying a Zabbix proxy using RPMs
Deploying a Zabbix proxy using the RPM is a very simple task. Here, there are fewer steps required as Zabbix itself distributes a prepackaged Zabbix proxy that is ready to use.
What you need to do is simply add the official Zabbix repository with the following command that must be run from root:
$ rpm –ivh http://repo.zabbix.com/zabbix/2.4/rhel/6/x86_64/zabbix-2.4.4-1.el6.x86_64.rpmNow, you can quickly list all the available zabbix-proxy packages with the following command, again from root:
$ yum search zabbix-proxy
============== N/S Matched: zabbix-proxy ================
zabbix-proxy.x86_64 : Zabbix Proxy common files
zabbix-proxy-mysql.x86_64 : Zabbix proxy compiled to use MySQL
zabbix-proxy-pgsql.x86_64 : Zabbix proxy compiled to use PostgreSQL
zabbix-proxy-sqlite3.x86_64 : Zabbix proxy compiled to use SQLite3In this example, the command is followed by the relative output that lists all the available zabbix-proxy packages; here, all you have to do is choose between them and install your desired package:
$ yum install zabbix-proxy-sqlite3Now, you’ve already installed the Zabbix proxy, which can be started up with the following command:
$ service zabbix-proxy start
Starting Zabbix proxy: [ OK ] Please also ensure that you enable your Zabbix proxy when the server boots with the $ chkconfig zabbix-proxy on command.
That done, if you’re using iptables, it is important to add a rule to enable incoming traffic on the 10051 port (that is the standard Zabbix proxy port) or, in any case, against the port that is specified in the configuration file:
ListenPort=10051To do that, you simply need to edit the iptables configuration file /etc/sysconfig/iptables and add the following line right on the head of the file:
-A INPUT -m state --state NEW -m tcp -p tcp --dport 10051 -j ACCEPTThen, you need to restart your local firewall from root using the following command:
$ service iptables restartThe log file is generated at /var/log/zabbix/zabbix_proxy.log:
$ tail -n 40 /var/log/zabbix/zabbix_proxy.log
62521:20150411:003816.801 **** Enabled features ****
62521:20150411:003816.801 SNMP monitoring: YES
62521:20150411:003816.801 IPMI monitoring: YES
62521:20150411:003816.801 WEB monitoring: YES
62521:20150411:003816.801 VMware monitoring: YES
62521:20150411:003816.801 ODBC: YES
62521:20150411:003816.801 SSH2 support: YES
62521:20150411:003816.801 IPv6 support: YES
62521:20150411:003816.801 **************************
62521:20150411:003816.801 using configuration file: /etc/zabbix/zabbix_proxy.confAs you can quickly spot, the default configuration file is located at /etc/zabbix/zabbix_proxy.conf.
The only thing that you need to do is make the proxy known to the server and add monitoring objects to it. All these tasks are performed through the Zabbix frontend by just clicking on Admin | Proxies and then Create. This is shown in the following screenshot:
Please take care to use the same Proxy name that you’ve used in the configuration file, which, in this case, is ZabbixProxy; you can quickly check with:
$ grep Hostname= /etc/zabbix/zabbix_proxy.conf
# Hostname=
Hostname=ZabbixProxyNote how, in the case of an Active proxy, you just need to specify the proxy’s name as already set in zabbix_proxy.conf. It will be the proxy’s job to contact the main server. On the other hand, a Passive proxy will need an IP address or a hostname for the main server to connect to, as shown in the following screenshot:
You don’t have to assign hosts to proxies at creation time or only in the proxy’s edit screen. You can also do that from a host configuration screen, as follows:
One of the advantages of proxies is that they don’t need much configuration or maintenance; once they are deployed and you have assigned some hosts to one of them, the rest of the monitoring activities are fairly transparent. Just remember to check the number of values per second that every proxy has to guarantee as expressed by the Required performance column in the proxies’ list page:
Values per second (VPS) is the number of measurements per second that a single Zabbix server or proxy has to collect. It’s an average value that depends on the number of items and the polling frequency for every item. The higher the value, the more powerful the Zabbix machine must be.
Depending on your hardware configuration, you may need to redistribute the hosts among proxies or add new ones if you notice degraded performances coupled with high VPS.
Considering a different Zabbix proxy database
Nowadays, from Zabbix 2.4 the support for nodes has been discontinued, and the only distributed scenario available is limited to the Zabbix proxy; those proxies now play a truly critical role. Also, with proxies deployed in many different geographic locations, the infrastructure is more subject to network outages. That said, there is a case to consider which database we want to use for those critical remote proxies.
Now SQLite3 is a good product as a standalone and lightweight setup, but if, in our scenario, the proxy we’ve deployed needs to retain a considerable amount of metrics, we need to consider the fact that SQLite3 has certain weak spots:
- The atomic-locking mechanism on SQLite3 is not the most robust ever
- SQLite3 suffers during high-volume writes
- SQLite3 does not implement any kind of user authentication mechanism
Apart from the point that SQLite3 does not implement any kind of authentication mechanism, the database files are created with the standard unmask, due to which, they are readable by everyone, In the event of a crash during high load it is not the best database to use.
Here is an example of the sqlite3 database and how to access it using a third-party account:
$ ls -la /tmp/zabbix_proxy.db
-rw-r--r--. 1 zabbix zabbix 867328 Apr 12 09:52 /tmp/zabbix_proxy.db
]# su - adv
[adv@localhost ~]$ sqlite3 /tmp/zabbix_proxy.db
SQLite version 3.6.20
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>Then, for all the critical proxies, it is advisable to use a different database. Here, we will use MySQL, which is a well-known database.
To install the Zabbix proxy with MySQL, if you’re compiling it from source, you need to use the following command line:
$ ./configure --enable-proxy --enable-static --with-mysql --with-net-snmp --with-libcurl --with-ssh2 --with-openipmiThis should be followed by the usual:
$ makeInstead, if you’re using the precompiled rpm, you can simply run from root:
$ yum install zabbix-proxy-mysqlNow, you need to start up your MySQL database and create the required database for your proxy:
$ mysql -uroot -p<password>
$ create database zabbix_proxy character set utf8 collate utf8_bin;
$ grant all privileges on zabbix_proxy.* to zabbix@localhost identified by '<password>';
$ quit;
$ mysql -uzabbix -p<password> zabbix_proxy < database/mysql/schema.sqlIf you’ve installed using rpm, the previous command will be:
$ mysql -uzabbix -p<password> zabbix_proxy < /usr/share/doc/zabbix-proxy-mysql-2.4.4/create/schema.sql/schema.sqlNow, we need to configure zabbix_proxy.conf and add the proper value to those parameters:
DBName=zabbix_proxy
DBUser=zabbix
DBPassword=<password>Please note that there is no need to specify DBHost as the socket used for MySQL.
Finally, we can start up our Zabbix proxy with the following command from root:
$ service zabbix-proxy start
Starting Zabbix proxy: [ OK ]Summary
In this article, you learned how to start up a Zabbix proxy over a Zabbix server.
Resources for Article:
Further resources on this subject:
- Zabbix Configuration[article]
- Bar Reports in Zabbix 1.8[article]
- Going beyond Zabbix agents [article]