Zabbix server is the central process of Zabbix software.
The server performs the polling and trapping of data, it calculates triggers, sends notifications to users. It is the central component to which Zabbix agents and proxies report data on availability and integrity of systems. The server can itself remotely check networked services (such as web servers and mail servers) using simple service checks.
The server is the central repository in which all configuration, statistical and operational data is stored, and it is the entity in Zabbix that will actively alert administrators when problems arise in any of the monitored systems.
The functioning of a basic Zabbix server is broken into three distinct components; they are: Zabbix server, web frontend and database storage.
All of the configuration information for Zabbix is stored in the database, which both the server and the web frontend interact with. For example, when you create a new item using the web frontend (or API) it is added to the items table in the database. Then, about once a minute Zabbix server will query the items table for a list of the items which are active that is then stored in a cache within the Zabbix server. This is why it can take up to two minutes for any changes made in Zabbix frontend to show up in the latest data section.
Zabbix server runs as a daemon process. The server 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, use the following commands:
shell> service zabbix-server stop
shell> service zabbix-server restart
shell> service zabbix-server status
Runtime control options:
Option | Description | Target |
---|---|---|
config_cache_reload | Reload configuration cache. Ignored if cache is being currently loaded. | |
diaginfo[=<target>] | Gather diagnostic information in the server log file. | historycache - history cache statistics valuecache - value cache statistics preprocessing - preprocessing manager statistics alerting - alert manager statistics lld - LLD manager statistics locks - list of mutexes (is empty on **BSD* systems) |
ha_status | Log high availability (HA) cluster status. | |
ha_remove_node=target | Remove the high availability (HA) node specified by its listed number. Note that active/standby nodes cannot be removed. |
target - number of the node in the list (can be obtained by running ha_status) |
ha_set_failover_delay=delay | Set high availability (HA) failover delay. Time suffixes are supported, e.g. 10s, 1m. |
|
secrets_reload | Reload secrets from Vault. | |
service_cache_reload | Reload the service manager cache. | |
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. | |
trigger_housekeeper_execute | Start the trigger housekeeping procedure. Ignored if the trigger 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 server 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 server configuration cache:
Examples of using runtime control to gather diagnostic information:
Gather all available diagnostic information in the server log file:
shell> zabbix_server -R diaginfo
Gather history cache statistics in the server log file:
shell> zabbix_server -R diaginfo=historycache
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_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase
Increase log level of second poller process:
shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=poller,2
Increase log level of process with PID 1234:
shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=1234
Decrease log level of all http poller processes:
shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_decrease="http poller"
Example of setting the HA failover delay to the minimum of 10 seconds:
Zabbix server 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 server 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 server as 'root' if you modify the 'AllowRoot' parameter in the server configuration file accordingly.
If Zabbix server and agent are run on the same machine it is recommended to use a different user for running the server than for running the agent. Otherwise, if both are run as the same user, the agent can access the server configuration file and any Admin level user in Zabbix can quite easily retrieve, for example, the database password.
See the configuration file options for details on configuring zabbix_server.
The scripts are used to automatically start/stop Zabbix processes during system's start-up/shutdown. The scripts are located under directory misc/init.d.
alert manager
- alert queue manageralert syncer
- alert DB writeralerter
- process for sending notificationsavailability manager
- process for host availability updatesconfiguration syncer
- process for managing in-memory cache of configuration datadiscoverer
- process for discovery of devicesescalator
- process for escalation of actionshistory poller
- process for handling calculated and internal checks requiring a database connectionhistory syncer
- history DB writerhousekeeper
- process for removal of old historical datahttp poller
- web monitoring pollericmp pinger
- poller for icmpping checksipmi manager
- IPMI poller manageripmi poller
- poller for IPMI checksjava poller
- poller for Java checkslld manager
- manager process of low-level discovery taskslld worker
- worker process of low-level discovery tasksodbc poller
- poller for ODBC checkspoller
- normal poller for passive checkspreprocessing manager
- manager of preprocessing taskspreprocessing worker
- process for data preprocessingproblem housekeeper
- process for removing problems of deleted triggersproxy poller
- poller for passive proxiesreport manager
- manager of scheduled report generation tasksreport writer
- process for generating scheduled reportsself-monitoring
- process for collecting internal server statisticssnmp trapper
- trapper for SNMP trapstask manager
- process for remote execution of tasks requested by other components (e.g. close problem, acknowledge problem, check item value now, remote command functionality)timer
- timer for processing maintenancestrapper
- trapper for active checks, traps, proxy communicationunreachable poller
- poller for unreachable devicesvmware collector
- VMware data collector responsible for data gathering from VMware servicesThe server log file can be used to observe these process types.
Various types of Zabbix server processes can be monitored using the zabbix[process,<type>,<mode>,<state>] internal item.
Due to the security requirements and mission-critical nature of server operation, UNIX is the only operating system that can consistently deliver the necessary performance, fault tolerance and resilience. Zabbix operates on market leading versions.
Zabbix server is tested on the following platforms:
Zabbix may work on other Unix-like operating systems as well.
Note that the server 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.
If the above does not work you have to start it manually. Find the path to the zabbix_server binary and execute:
You can use the following command line parameters with Zabbix server:
-c --config <file> path to the configuration file (default is /usr/local/etc/zabbix_server.conf)
-f --foreground run Zabbix server in foreground
-R --runtime-control <option> perform administrative functions
-h --help give this help
-V --version display version number
Examples of running Zabbix server with command line parameters: