Der Server übernimmt das Abfragen und Entgegennehmen von Daten, berechnet Auslöser und sendet Benachrichtigungen an Benutzer. Er ist die zentrale Komponente, an die Zabbix Agenten und Proxys Daten zur Verfügbarkeit und Integrität von Systemen melden. Der Server kann Netzwerkdienste (z. B. Webserver und Mailserver) auch selbst aus der Ferne mit einfachen Dienstprüfungen überwachen.

Der Server ist das zentrale Repository, in dem alle Konfigurations-, Statistik- und Betriebsdaten gespeichert werden, und er ist die Instanz in Zabbix, die Administratoren aktiv benachrichtigt, wenn in einem der überwachten Systeme Probleme auftreten.

Die Funktionsweise eines grundlegenden Zabbix Servers ist in drei unterschiedliche Komponenten unterteilt; diese sind: Zabbix Server, Web-Frontend und Datenbankspeicher.

Alle Konfigurationsinformationen für Zabbix werden in der Datenbank gespeichert, mit der sowohl der Server als auch das Web-Frontend interagieren. Wenn Sie beispielsweise über das Web-Frontend (oder die API) einen neuen Datenpunkt erstellen, wird er der Tabelle items in der Datenbank hinzugefügt. Anschließend fragt der Zabbix Server etwa einmal pro Minute die Tabelle items nach einer Liste der aktiven Datenpunkte ab, die dann in einem Cache innerhalb des Zabbix Servers gespeichert wird. Daher kann es bis zu zwei Minuten dauern, bis Änderungen, die im Zabbix Frontend vorgenommen wurden, im Abschnitt für die neuesten Daten angezeigt werden.

Server ausführen

Wenn als Paket installiert

Der Zabbix Server läuft als Daemon-Prozess. Der Server kann mit folgendem Befehl gestartet werden:

systemctl start zabbix-server

Dies funktioniert auf den meisten GNU/Linux-Systemen. Auf anderen Systemen müssen Sie möglicherweise Folgendes ausführen:

/etc/init.d/zabbix-server start

Entsprechend verwenden Sie zum Stoppen/Neustarten/Anzeigen des Status die folgenden Befehle:

systemctl stop zabbix-server
systemctl restart zabbix-server
systemctl status zabbix-server

Manuell starten

Wenn das oben nicht funktioniert, müssen Sie es manuell starten. Suchen Sie den Pfad zur Binärdatei zabbix_server und führen Sie Folgendes aus:

zabbix_server

Sie können die folgenden Befehlszeilenparameter mit dem Zabbix Server verwenden:

-c --config <file>              Pfad zur Konfigurationsdatei (Standard ist /usr/local/etc/zabbix_server.conf)
-f --foreground                 Zabbix Server im Vordergrund ausführen
-R --runtime-control <option>   Administrative Funktionen ausführen
-T --test-config                Konfigurationsdatei validieren und beenden
-h --help                       Diese Hilfe anzeigen
-V --version                    Versionsnummer anzeigen

Beispiele für die Ausführung des Zabbix Server mit Befehlszeilenparametern:

zabbix_server -c /usr/local/etc/zabbix_server.conf
zabbix_server --help
zabbix_server -V

Runtime-Steuerung

Optionen der Runtime-Steuerung:

Option	Beschreibung	Ziel
`config_cache_reload`	Konfigurationscache neu laden. Wird ignoriert, wenn der Cache derzeit geladen wird.
`history_cache_clear=target`	History-Cache für den durch seine ID angegebenen Datenpunkt leeren. Wirkt sich auf alle Werte des Datenpunkts aus, außer auf den ersten und letzten Wert.	target - ID des Datenpunkts
`diaginfo[=<section>]`	Diagnoseinformationen in der Server-Logdatei sammeln.	`historycache` - Statistik des History-Caches; `valuecache` - Statistik des Value-Caches; `preprocessing` - Statistik des Preprocessing-Managers; `alerting` - Statistik des Alert-Managers; `lld` - Statistik des LLD-Managers; `locks` - Liste der Mutexes (ist auf BSD-Systemen leer); `connector` - Statistik für Connectoren mit der größten Warteschlange.
`ha_status`	Status des Hochverfügbarkeits-(HA)-Clusters protokollieren.
`ha_remove_node=target`	Den angegebenen Hochverfügbarkeits-(HA)-Knoten anhand seines Namens oder seiner ID entfernen. Beachten Sie, dass aktive/Standby-Knoten nicht entfernt werden können.	target - Name oder ID des Knotens (kann durch Ausführen von `ha_status` ermittelt werden).
`ha_set_failover_delay=delay`	Failover-Verzögerung für Hochverfügbarkeit (HA) festlegen. Zeitsuffixe werden unterstützt, z. B. 10s, 1m.
`proxy_config_cache_reload[=<target>]`	Proxy-Konfigurationscache neu laden.	target - durch Kommas getrennte Liste von Proxy-Namen. Wenn kein target angegeben ist, wird die Konfiguration für alle Proxys neu geladen.
`secrets_reload`	Geheimnisse aus Vault neu laden.
`service_cache_reload`	Cache des Service-Managers neu laden.
`snmp_cache_reload`	SNMP-Cache neu laden — SNMP-Engine-Eigenschaften (Engine-Zeit, Engine-Boots, Engine-ID, Anmeldedaten) für alle Hosts löschen. Verwenden Sie dies, um beim Beheben von SNMP-Problemen ein globales Leeren des Caches zu erzwingen.
`housekeeper_execute`	Die Housekeeping-Prozedur starten. Wird ignoriert, wenn die Housekeeping-Prozedur derzeit ausgeführt wird.
`trigger_housekeeper_execute`	Die Trigger-Housekeeping-Prozedur starten. Wird ignoriert, wenn die Trigger-Housekeeping-Prozedur derzeit ausgeführt wird. Bis die Trigger-Housekeeping-Prozedur gestartet wird, können Probleme, die durch inzwischen gelöschte Auslöser verursacht wurden, weiterhin Service-Probleme erzeugen und diesen Services zuweisen. Wenn Ihr Setup viele Service-Statusberechnungsregeln auf Basis häufig erkannter/nicht erkannter Auslöser umfasst, sollten Sie die Häufigkeit der Housekeeping-Prozedur erhöhen, indem Sie den Server-Konfigurationsparameter `ProblemHousekeepingFrequency` anpassen.
`log_level_increase[=<target>]`	Logstufe erhöhen, betrifft alle Prozesse, wenn kein target angegeben ist. Auf BSD-Systemen nicht unterstützt.	process type - alle Prozesse des angegebenen Typs (z. B. `poller`). Alle Server-Prozesstypen anzeigen. process type,N - Prozesstyp und Nummer (z. B. `poller,3`). pid - Prozesskennung (`1` bis `65535`). Für größere Werte target als 'process type,N' angeben.
`log_level_decrease[=<target>]`	Logstufe verringern, betrifft alle Prozesse, wenn kein target angegeben ist. Auf BSD-Systemen nicht unterstützt.
`prof_enable[=<target>]`	Profiling aktivieren. Betrifft alle Prozesse, wenn kein target angegeben ist. Aktiviertes Profiling liefert Details zu allen rwlocks/mutexes nach Funktionsnamen.	process type - alle Prozesse des angegebenen Typs (z. B. `history syncer`) Unterstützte Prozesstypen als Profiling-Ziele: `alerter`, `alert manager`, `availability manager`, `configuration syncer`, `discovery manager`, `escalator`, `history poller`, `history syncer`, `housekeeper`, `http poller`, `icmp pinger`, `ipmi manager`, `ipmi poller`, `java poller`, `lld manager`, `lld worker`, `odbc poller`, `poller`, `preprocessing manager`, `preprocessing worker`, `proxy poller`, `self-monitoring`, `service manager`, `snmp trapper`, `task manager`, `timer`, `trapper`, `unreachable poller`, `vmware collector`. process type,N - Prozesstyp und Nummer (z. B. `history syncer,1`). pid - Prozesskennung (`1` bis `65535`). Für größere Werte target als 'process type,N' angeben. scope - `rwlock`, `mutex`, `processing` kann mit dem Prozesstyp und der Nummer verwendet werden (z. B. `history syncer,1,processing`) oder mit allen Prozessen eines Typs (z. B. `history syncer,rwlock`).
`prof_disable[=<target>]`	Profiling deaktivieren. Betrifft alle Prozesse, wenn kein target angegeben ist.	process type - alle Prozesse des angegebenen Typs (z. B. `history syncer`). Unterstützte Prozesstypen als Profiling-Ziele: siehe `prof_enable`. process type,N - Prozesstyp und Nummer (z. B. `history syncer,1`). pid - Prozesskennung (`1` bis `65535`). Für größere Werte target als 'process type,N' angeben.

Beispiel für die Verwendung der Laufzeitsteuerung zum Neuladen des Konfigurations-Cache des Servers:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R config_cache_reload

Beispiele für die Verwendung der Laufzeitsteuerung zum Neuladen der Proxy-Konfiguration:

# Konfiguration aller Proxys neu laden:
zabbix_server -R proxy_config_cache_reload

# Konfiguration von Proxy1 und Proxy2 neu laden:
zabbix_server -R proxy_config_cache_reload=Proxy1,Proxy2

Beispiel für die Verwendung der Laufzeitsteuerung zum Leeren des Verlaufs-Cache für einen Datenpunkt:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R history_cache_clear=42243

Beispiele für die Verwendung der Laufzeitsteuerung zum Sammeln von Diagnoseinformationen:

# Alle verfügbaren Diagnoseinformationen in der Server-Logdatei sammeln:
zabbix_server -R diaginfo

# Statistiken zum Verlaufs-Cache in der Server-Logdatei sammeln:
zabbix_server -R diaginfo=historycache

Beispiel für die Verwendung der Laufzeitsteuerung zum Neuladen des SNMP-Cache:

zabbix_server -R snmp_cache_reload

Wenn eine SNMPv3-Schnittstelle über die Zabbix-Benutzeroberfläche aktualisiert wird, lädt Zabbix in den meisten Fällen automatisch die neuen SNMPv3-Anmeldedaten für diese Schnittstelle neu; verwenden Sie -R snmp_cache_reload nur, wenn die Abfrage nach Änderungen der Anmeldedaten weiterhin fehlschlägt (zum Beispiel aufgrund von Inkonsistenzen bei engineBoots/engineID oder bei nicht RFC-konformen Geräten) oder wenn Sie zur Fehlerbehebung das globale Leeren des SNMP-Cache erzwingen müssen.

Beispiel für die Verwendung der Laufzeitsteuerung zum Auslösen der Ausführung des Housekeepers:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R housekeeper_execute

Beispiele für die Verwendung der Laufzeitsteuerung zum Ändern der Protokollierungsstufe:

# Protokollierungsstufe aller Prozesse erhöhen:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase

# Protokollierungsstufe des zweiten Poller-Prozesses erhöhen:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=poller,2

# Protokollierungsstufe des Prozesses mit PID 1234 erhöhen:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=1234

# Protokollierungsstufe aller http poller-Prozesse verringern:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_decrease="http poller"

Beispiel für das Setzen der HA-Failover-Verzögerung auf das Minimum von 10 Sekunden:

zabbix_server -R ha_set_failover_delay=10s

Prozessbenutzer

Der Zabbix Server ist dafür ausgelegt, als Benutzer ohne Root-Rechte ausgeführt zu werden. Er wird unter dem Nicht-Root-Benutzer ausgeführt, mit dem er gestartet wurde. Sie können den Server daher ohne Probleme als jeden Nicht-Root-Benutzer ausführen.

Wenn Sie versuchen, ihn als 'root' auszuführen, wechselt er zu einem fest codierten Benutzer 'zabbix', der auf Ihrem System vorhanden sein muss. Sie können den Server nur dann als 'root' ausführen, wenn Sie den Parameter 'AllowRoot' in der Konfigurationsdatei des Servers entsprechend ändern.

Wenn Zabbix Server und Agent auf demselben Rechner ausgeführt werden, wird empfohlen, für den Server einen anderen Benutzer zu verwenden als für den Agent. Andernfalls kann der Agent, wenn beide unter demselben Benutzer ausgeführt werden, auf die Konfigurationsdatei des Servers zugreifen, und jeder Benutzer mit Admin-Rechten in Zabbix kann dann recht einfach beispielsweise das Datenbankpasswort auslesen.

Konfigurationsdatei

Siehe die Optionen der Konfigurationsdatei für Details zur Konfiguration von zabbix_server.

Startskripte

Die Skripte werden verwendet, um Zabbix-Prozesse während des Systemstarts/-herunterfahrens automatisch zu starten/stoppen. Die Skripte befinden sich im Verzeichnis misc/init.d.

Server-Prozesstypen und Threads

agent poller - asynchroner Poller-Prozess für passive Prüfungen mit einem Worker-Thread;
alert manager - Manager für die Alarmwarteschlange;
alert syncer - DB-Schreiber für Alarme;
alerter - Prozess zum Senden von Benachrichtigungen;
availability manager - Prozess für Aktualisierungen der Host-Verfügbarkeit;
browser poller - Poller für Browser-Datenpunkt-Prüfungen;
configuration syncer - Prozess zur Verwaltung des In-Memory-Caches für Konfigurationsdaten;
configuration syncer worker - Prozess zum Auflösen und Synchronisieren von Benutzer-Makrowerten in Datenpunktnamen;
connector manager - Manager-Prozess für Connectoren;
connector worker - Prozess zur Verarbeitung von Anfragen des Connector-Managers;
discovery manager - Manager-Prozess für die Erkennung von Geräten;
discovery worker - Prozess zur Verarbeitung von Discovery-Aufgaben des Discovery-Managers;
escalator - Prozess für die Eskalation von Aktionen;
ha manager - Prozess zur Verwaltung der Hochverfügbarkeit;
history poller - Prozess zur Verarbeitung berechneter Prüfungen, die eine Datenbankverbindung erfordern;
history syncer - DB-Schreiber für Historien;
housekeeper - Prozess zum Entfernen veralteter Daten (Datenpunkthistorie und Trends, Benutzersitzungen, Ereignisse usw.) sowie von Daten, die von gelöschten Objekten zurückgelassen wurden;
http agent poller - asynchroner Poller-Prozess für HTTP-Prüfungen mit einem Worker-Thread;
http poller - Poller für Web-Monitoring;
icmp pinger - Poller für icmpping-Prüfungen;
internal poller - Poller für interne Prüfungen;
ipmi manager - Manager für IPMI-Poller;
ipmi poller - Poller für IPMI-Prüfungen;
java poller - Poller für Java-Prüfungen;
lld manager - Manager-Prozess für Low-Level-Discovery-Aufgaben;
lld worker - Worker-Prozess für Low-Level-Discovery-Aufgaben;
odbc poller - Poller für ODBC-Prüfungen;
poller - normaler Poller für passive Prüfungen;
preprocessing manager - Manager für Vorverarbeitungsaufgaben mit Vorverarbeitungs-Worker-Threads;
preprocessing worker - Thread für die Datenvorverarbeitung;
proxy poller - Poller für passive Proxies;
proxy group manager - Manager für Proxy-Lastverteilung und Hochverfügbarkeit;
report manager- Manager für geplante Berichtserstellungsaufgaben;
report writer - Prozess zur Erstellung geplanter Berichte;
self-monitoring - Prozess zum Sammeln interner Serverstatistiken;
service manager - Prozess zur Verwaltung von Services durch den Empfang von Informationen über Probleme, Problem-Tags und Problembehebung von history syncer, task manager und alert manager;
snmp poller - asynchroner Poller-Prozess für SNMP-Prüfungen mit einem Worker-Thread (nur walk[OID]- und get[OID]-Datenpunkte);
snmp trapper - Trapper für SNMP-Traps;
task manager - Prozess zur Remote-Ausführung von Aufgaben, die von anderen Komponenten angefordert werden (z. B. Problem schließen, Problem bestätigen, Datenpunktwert jetzt prüfen, Funktion für Remote-Befehle);
timer - Timer zur Verarbeitung von Wartungsfenstern;
trapper - Trapper für aktive Prüfungen, Traps und Proxy-Kommunikation;
trigger housekeeper - Prozess zum Entfernen von Problemen und Ereignissen, die von Auslösern erzeugt wurden, die inzwischen gelöscht wurden;
unreachable poller - Poller für nicht erreichbare Geräte;
vmware collector - VMware-Datensammler, der für die Datenerfassung von VMware-Diensten verantwortlich ist.

Die Server-Logdatei kann verwendet werden, um diese Prozesstypen zu beobachten.

Seit Zabbix 7.4.6 wird die Server-Logdatei mit Lese- und Schreibrechten nur für den Dateieigentümer erstellt. Zusätzlich ist die Datei für die Eigentümergruppe lesbar. Alle anderen Berechtigungen werden verweigert.

Verschiedene Typen von Zabbix-Serverprozessen können mit dem internen zabbix[process,<type>,<mode>,<state>] Datenpunkt überwacht werden.

Statistik der Transaktionen des History-Syncers

Der Prozessname des History-Syncers zeigt detaillierte Statistiken zu den Transaktionen des History-Syncers an:

205182 ?        S      0:00  zabbix_server: history syncer #2 [processed 0 values, 0+0 triggers in 0.000021 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]
205183 ?        S      0:00  zabbix_server: history syncer #3 [processed 18 values, 7+0 triggers in 0.002612 (0.001108,0.000000,0.000000,0.001208,0.000014) sec, idle 1 sec]
205184 ?        S      0:00  zabbix_server: history syncer #4 [processed 0 values, 0+0 triggers in 0.000027 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]

Bei "A+B triggers":

A - Auslöser, die aufgrund von History-Werten verarbeitet wurden;
B - Auslöser, die aufgrund von Timern verarbeitet wurden.

Die Zeitangaben in processed...in N (<timings>) sec sind:

Zeit, die zum Schreiben von Datenpunkt-Werten in die Datenbank aufgewendet wurde;
Zeit, die zum Aktualisieren von Datenpunkt-Daten (Status, Fehler, Host-Inventar usw.) aufgewendet wurde;
Zeit, die zum Schreiben von Trends in die Datenbank aufgewendet wurde;
Zeit, die zur Berechnung von Auslösern aufgewendet wurde;
Zeit, die für die Verarbeitung von Ereignissen und Aktionen aufgewendet wurde.

Unterstützte Plattformen

Aufgrund der Sicherheitsanforderungen und des geschäftskritischen Charakters des Server-Betriebs ist UNIX das einzige Betriebssystem, das die erforderliche Leistung, Fehlertoleranz und Ausfallsicherheit zuverlässig bereitstellen kann. Zabbix läuft auf marktführenden Versionen.

Der Zabbix Server wird auf den folgenden Plattformen getestet:

Linux
Solaris
AIX
HP-UX
Mac OS X
FreeBSD
OpenBSD
NetBSD
SCO Open Server

Zabbix kann auch auf anderen Unix-ähnlichen Betriebssystemen funktionieren.

Gebietsschema

Beachten Sie, dass der Server ein UTF-8-Gebietsschema benötigt, damit einige textuelle Datenpunkte korrekt interpretiert werden können. Die meisten modernen Unix-ähnlichen Systeme verwenden standardmäßig ein UTF-8-Gebietsschema, jedoch gibt es einige Systeme, bei denen dies ausdrücklich festgelegt werden muss.

What’s next?

1 Hochverfügbarkeit

Docs

1 Server

Übersicht