Zabbix proxy is a process that may collect monitoring data from one or more monitored devices and send the information to the Zabbix server, essentially working on behalf of the server. All collected data is buffered locally and then transferred to the Zabbix server the proxy belongs to.
Deploying a proxy is optional, but may be very beneficial to distribute the load of a single Zabbix server. If only proxies collect data, processing on the server becomes less CPU and disk I/O hungry.
A Zabbix proxy is the ideal solution for centralized monitoring of remote locations, branches and networks with no local administrators.
Zabbix proxy requires a separate database.
Note that databases supported with Zabbix proxy are SQLite, MySQL and PostgreSQL. Using Oracle is at your own risk and may contain some limitations as, for example, in return values of low-level discovery rules.
Zabbix proxy runs as a daemon process. The proxy can be started by executing:
This will work on most of GNU/Linux systems. On other systems you may need to run:
Similarly, for stopping/restarting/viewing status of Zabbix proxy, use the following commands:
If the above does not work you have to start it manually. Find the path to the zabbix_proxy binary and execute:
You can use the following command line parameters with Zabbix proxy:
Examples of running Zabbix proxy with command line parameters:
Runtime control options:
|config_cache_reload||Reload configuration cache. Ignored if cache is being currently loaded.
Active Zabbix proxy will connect to the Zabbix server and request configuration data.
Passive Zabbix proxy will request configuration data from Zabbix server the next time when the server connects to the proxy.
|diaginfo[=<target>]||Gather diagnostic information in the proxy log file.||historycache - history cache statistics
preprocessing - preprocessing manager statistics
locks - list of mutexes (is empty on **BSD* systems)
|snmp_cache_reload||Reload SNMP cache, clear the SNMP properties (engine time, engine boots, engine id, credentials) for all hosts.|
|housekeeper_execute||Start the housekeeping procedure. Ignored if the housekeeping procedure is currently in progress.|
|log_level_increase[=<target>]||Increase log level, affects all processes if target is not specified.
Not supported on **BSD* systems.
|process type - All processes of specified type (e.g., poller)
See all proxy process types.
process type,N - Process type and number (e.g., poller,3)
pid - Process identifier (1 to 65535). For larger values specify target as 'process type,N'.
|log_level_decrease[=<target>]||Decrease log level, affects all processes if target is not specified.
Not supported on **BSD* systems.
Example of using runtime control to reload the proxy configuration cache:
Examples of using runtime control to gather diagnostic information:
Example of using runtime control to reload the SNMP cache:
Example of using runtime control to trigger execution of housekeeper
Examples of using runtime control to change log level:
Increase log level of all processes: shell> zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase Increase log level of second poller process: shell> zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=poller,2 Increase log level of process with PID 1234: shell> zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=1234 Decrease log level of all http poller processes: shell> zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_decrease="http poller"
Zabbix proxy is designed to run as a non-root user. It will run as whatever non-root user it is started as. So you can run proxy as any non-root user without any issues.
If you will try to run it as 'root', it will switch to a hardcoded 'zabbix' user, which must be present on your system. You can only run proxy as 'root' if you modify the 'AllowRoot' parameter in the proxy configuration file accordingly.
See the configuration file options for details on configuring zabbix_proxy.
availability manager- process for host availability updates
configuration syncer- process for managing in-memory cache of configuration data
data sender- proxy data sender
discoverer- process for discovery of devices
heartbeat sender- proxy heartbeat sender
history syncer- history DB writer
housekeeper- process for removal of old historical data
http poller- web monitoring poller
icmp pinger- poller for icmpping checks
ipmi manager- IPMI poller manager
ipmi poller- poller for IPMI checks
java poller- poller for Java checks
odbc poller- poller for ODBC checks
poller- normal poller for passive checks
preprocessing manager- manager of preprocessing tasks
preprocessing worker- process for data preprocessing
self-monitoring- process for collecting internal server statistics
snmp trapper- trapper for SNMP traps
task manager- process for remote execution of tasks requested by other components (e.g. close problem, acknowledge problem, check item value now, remote command functionality)
trapper- trapper for active checks, traps, proxy communication
unreachable poller- poller for unreachable devices
vmware collector- VMware data collector responsible for data gathering from VMware services
The proxy log file can be used to observe these process types.
Various types of Zabbix proxy processes can be monitored using the zabbix[process,<type>,<mode>,<state>] internal item.
Zabbix proxy runs on the same list of server#supported platforms as Zabbix server.
Note that the proxy requires a UTF-8 locale so that some textual items can be interpreted correctly. Most modern Unix-like systems have a UTF-8 locale as default, however, there are some systems where that may need to be set specifically.