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

Laufzeitsteuerung

Optionen der Laufzeitsteuerung:

Option	Beschreibung	Ziel
`config_cache_reload`	Konfigurationscache neu laden. Wird ignoriert, wenn der Cache derzeit geladen wird.
`diaginfo[=<section>]`	Diagnoseinformationen in der Server-Logdatei sammeln.	`historycache` - Statistiken des History-Caches; `valuecache` - Statistiken des Value-Caches; `preprocessing` - Statistiken des Preprocessing-Managers; `alerting` - Statistiken des Alert-Managers; `lld` - Statistiken des LLD-Managers; `locks` - Liste der Mutexes (ist auf BSD-Systemen leer); `connector` - Statistiken für Connectoren mit der größten Warteschlange.
`ha_status`	Status des High-Availability-(HA)-Clusters protokollieren.
`ha_remove_node=target`	Den High-Availability-(HA)-Knoten entfernen, der durch seinen Namen oder seine ID angegeben ist. 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 High Availability (HA) festlegen. Zeitsuffixe werden unterstützt, z. B. 10s, 1m.
`proxy_config_cache_reload[=<target>]`	Konfigurationscache des Proxy 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 bei der Fehlerbehebung von SNMP-Problemen eine globale Cache-Löschung 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 geben Sie das target als 'process type,N' an.
`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 geben Sie das target als 'process type,N' an. 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 geben Sie das target als 'process type,N' an.

Beispiel für die Verwendung der Laufzeitsteuerung zum Neuladen des Server-Konfigurationscaches:

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 Proxies 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

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 des History-Cache in der Server-Logdatei sammeln:
zabbix_server -R diaginfo=historycache

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

zabbix_server -R snmp_cache_reload

Wenn eine SNMPv3-Schnittstelle über die Zabbix UI aktualisiert wird, lädt Zabbix in den meisten Fällen die neuen SNMPv3-Zugangsdaten für diese Schnittstelle automatisch neu; verwenden Sie -R snmp_cache_reload nur, wenn das Polling nach Änderungen der Zugangsdaten weiterhin fehlschlägt (zum Beispiel aufgrund von Inkonsistenzen bei engineBoots/engineID oder bei Geräten, die nicht RFC-konform sind), oder wenn Sie zum Troubleshooting ein globales Leeren des SNMP-Caches 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 Protokollstufe:

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

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

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

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

Beispiel zum 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 Nicht-Root-Benutzer ausgeführt zu werden. Er wird mit genau dem Nicht-Root-Benutzer ausgeführt, mit dem er gestartet wurde. Sie können den Server daher ohne Probleme als beliebigen 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 Serverkonfigurationsdatei 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

Weitere Informationen zur Konfiguration von zabbix_server finden Sie unter den Optionen der Konfigurationsdatei.

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-Makro-Werten 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 von 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ückgeblieben sind;
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 Berichterstellungsaufgaben;
report writer - Prozess zum Generieren 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-Services verantwortlich ist.

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

Seit Zabbix 7.0.22 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.

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