1 Server

Übersicht

Der Zabbix Server ist der zentrale Prozess der Zabbix-Software.

Der Server führt die Abfrage und das Empfangen von Daten durch, berechnet Auslöser und sendet Benachrichtigungen an Benutzer. Er ist die zentrale Komponente, an die Zabbix Agents und Proxys Daten über die Verfügbarkeit und Integrität von Systemen melden. Der Server kann selbst Netzwerkdienste (wie Webserver und Mailserver) mithilfe einfacher Service-Prüfungen aus der Ferne überprüfen.

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 alarmiert, wenn in einem der überwachten Systeme Probleme auftreten.

Die Funktionsweise eines grundlegenden Zabbix Servers ist in drei unterschiedliche Komponenten unterteilt: 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 mit dem Web-Frontend (oder der 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; diese wird dann in einem Cache innerhalb des Zabbix Servers gespeichert. Deshalb kann es bis zu zwei Minuten dauern, bis Änderungen, die im Zabbix Frontend vorgenommen wurden, im Abschnitt „Neueste Daten“ sichtbar 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

Falls das oben Genannte nicht funktioniert, müssen Sie ihn manuell starten. Suchen Sie den Pfad zur zabbix_server-Binärdatei 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 prüfen und beenden
-h --help                       diese Hilfe anzeigen
-V --version                    Versionsnummer anzeigen

Beispiele für das Ausführen von Zabbix Server mit Befehlszeilenparametern:

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

Optionen zur Laufzeitsteuerung:

Option Beschreibung Ziel
config_cache_reload Konfigurations-Cache 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 erfassen. historycache - Statistiken zum History-Cache
valuecache - Statistiken zum Wert-Cache
preprocessing - Statistiken zum Präprozessing-Manager
alerting - Statistiken zum Alert-Manager
lld - Statistiken zum LLD-Manager
locks - Liste der Mutexe (ist auf BSD-Systemen leer)
connector - Statistiken für Konnektoren 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>] Konfigurations-Cache des Proxy neu laden. target - kommagetrennte Liste von Proxy-Namen
Wenn kein target angegeben ist, wird die Konfiguration für alle Proxys neu geladen
secrets_reload Secrets aus Vault neu laden.
service_cache_reload Den Cache des Service-Managers neu laden.
snmp_cache_reload SNMP-Cache neu laden — SNMP-Engine-Eigenschaften (Engine-Zeit, Engine-Boots, Engine-ID, Zugangsdaten) für alle Hosts löschen. Verwenden Sie dies, um bei der Fehlerbehebung 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 Auslöser-Housekeeping-Prozedur starten.
Wird ignoriert, wenn die Housekeeping-Prozedur für Auslöser derzeit ausgeführt wird.
log_level_increase[=<target>] Log-Level erhöhen; wirkt sich auf alle Prozesse aus, wenn kein target angegeben ist.
Auf BSD-Systemen nicht unterstützt.		 process type - Alle Prozesse des angegebenen Typs (z. B. poller)
Siehe alle Server-Prozesstypen.
process type,N - Prozesstyp und Nummer (z. B. poller,3)
pid - Prozesskennung (1 bis 65535). Bei größeren Werten geben Sie target als 'process type,N' an.
log_level_decrease[=<target>] Log-Level verringern; wirkt sich auf alle Prozesse aus, wenn kein target angegeben ist.
Auf BSD-Systemen nicht unterstützt.
prof_enable[=<target>] Profiling aktivieren.
Wirkt sich auf alle Prozesse aus, wenn kein target angegeben ist.
Aktiviertes Profiling liefert Details zu allen rwlocks/Mutexen nach Funktionsname.		 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). Bei größeren Werten geben Sie target als 'process type,N' an.
scope - rwlock, mutex, processing können mit Prozesstyp und Nummer verwendet werden (z. B. history syncer,1,processing) oder für alle Prozesse eines Typs (z. B. history syncer,rwlock)
prof_disable[=<target>] Profiling deaktivieren.
Wirkt sich auf alle Prozesse aus, 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). Bei größeren Werten geben Sie target als 'process type,N' an.

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 Nicht-Root-Benutzer ausgeführt zu werden. Er wird als derjenige Nicht-Root-Benutzer ausgeführt, als der er gestartet wird. Daher können Sie den Server problemlos als jeden beliebigen Nicht-Root-Benutzer ausführen.

Wenn Sie versuchen, ihn als 'root' auszuführen, wechselt er zu einem fest kodierten 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 Server-Konfigurationsdatei 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 Server-Konfigurationsdatei zugreifen, und jeder Benutzer mit Admin-Rechten in Zabbix kann dann beispielsweise das Datenbankpasswort relativ leicht 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 der Alarmwarteschlange
  • alert syncer - Alarm-DB-Schreiber
  • 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 von Konfigurationsdaten
  • configuration syncer worker - Prozess zum Auflösen und Synchronisieren von Benutzermakro-Werten in Datenpunkt-Namen
  • connector manager - Manager-Prozess für Konnektoren
  • connector worker - Prozess zur Verarbeitung von Anfragen vom Connector Manager
  • discovery manager - Manager-Prozess für die Geräteerkennung
  • discovery worker - Prozess zur Verarbeitung von Erkennungsaufgaben vom Discovery Manager
  • 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 - Verlaufs-DB-Schreiber
  • housekeeper - Prozess zum Entfernen veralteter Daten (Datenpunkt-Verlauf 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 - IPMI-Poller-Manager
  • 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 Proxys
  • proxy group manager - Manager für Proxy-Lastverteilung und Hochverfügbarkeit
  • report manager- Manager für Aufgaben zur geplanten Berichtserstellung
  • report writer - Prozess zur Erstellung geplanter Berichte
  • self-monitoring - Prozess zum Sammeln interner Server-Statistiken
  • service manager - Prozess zur Verwaltung von Services durch 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, Datenpunkt-Wert jetzt prüfen, Remote-Befehlsfunktionalität)
  • timer - Timer für die Verarbeitung von Wartungszeiträumen
  • trapper - Trapper für aktive Prüfungen, Traps, 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.

Die Server-Logdatei wird 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-Server-Prozessen können mit dem internen zabbix[process,<type>,<mode>,<state>]-Datenpunkt überwacht werden.

Transaktionsstatistiken des History-Syncers

Der Prozesstitel 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]

In „A+B Auslöser“:

  • A - Auslöser, die aufgrund von Verlaufswerten verarbeitet wurden;
  • B - Auslöser, die aufgrund von Timern verarbeitet wurden.

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

  • Zeit für das Schreiben von Datenpunkt-Werten in die Datenbank;
  • Zeit für die Aktualisierung von Datenpunkt-Daten (Status, Fehler, Host-Inventar usw.);
  • Zeit für das Schreiben von Trends in die Datenbank;
  • Zeit für die Berechnung von Auslösern;
  • Zeit für die Verarbeitung von Ereignissen und Aktionen.
Housekeeping-Verfahren

Der Prozess housekeeper entfernt periodisch veraltete Daten (Datenpunkt-Verlauf und Trends, Benutzersitzungen, Ereignisse usw.) sowie Daten, die von gelöschten Objekten zurückgelassen wurden. Er läuft in Zyklen, wobei die Häufigkeit und das Löschlimit pro Zyklus durch HousekeepingFrequency und MaxHousekeeperDelete bestimmt werden. Daten, die in einem Zyklus nicht entfernt werden, werden in den nächsten übernommen. Automatisches Housekeeping kann unter Administration > Housekeeping aktiviert und konfiguriert werden.

Zum Entfernen von Daten, die von gelöschten Objekten zurückgelassen wurden, verwendet der Prozess housekeeper Aufgaben aus der Tabelle housekeeper, die jedes Mal befüllt wird, wenn ein Objekt gelöscht wird. Wenn Sie beispielsweise einen Host löschen, löscht Zabbix auch dessen Datenpunkte, jedoch nicht deren Verlauf, Trends oder Probleme. Stattdessen befüllen Datenbank-Trigger die Tabelle housekeeper mit Aufgaben, die aus folgenden Feldern bestehen:

  • housekeeperid - Aufgaben-ID
  • object - Objekttyp (0 - Datenpunkt; 1 - Auslöser; 2 - Service; 3 - entdeckter Host; 4 - entdeckter Service)
  • objectid - Objekt-ID (hilft dem housekeeper, objektbezogene Daten zu finden)

Wenn Sie beispielsweise einen Host mit zwei Datenpunkten und einem Auslöser löschen, wird die Tabelle housekeeper wie folgt befüllt:

+---------------+--------+----------+
| housekeeperid | object | objectid |
+---------------+--------+----------+
|             1 |      1 |    28724 |
|             2 |      0 |    59396 |
|             3 |      0 |    59397 |
+---------------+--------+----------+

Datenbank-Trigger befüllen die Tabelle housekeeper, ohne auf objektbezogene Daten zu prüfen; diese Prüfung wird vom Prozess housekeeper durchgeführt.

Jede Aufgabe führt zu einer oder mehreren housekeeper-Operationen, die vom Objekttyp abhängen:

  • Für Datenpunkte (einschließlich LLD-Regeln) - entfernt Daten aus allen Verlaufs- und Trendtabellen (history, history_str, history_log, history_uint, history_text, history_bin, history_json, trends, trends_uint), die Werte für diese Datenpunkte enthalten. Außerdem wird die Tabelle problems geprüft und veraltete interne Ereignisse entfernt, die mit diesen Datenpunkten verknüpft sind.

  • Für Auslöser - prüft ereignisbezogene Tabellen (problem, event_symptom, event_recovery, events) und entfernt veraltete Ereignisse, die mit diesen Auslösern verknüpft sind, und benachrichtigt außerdem den Prozess service manager über entfernte Ereignisse.

Ein separater Prozess trigger housekeeper übernimmt eine engere Aufgabe – das Entfernen von Problemen und Ereignissen, die keinen bekannten Quell-Auslöser haben. Seine Ausführungshäufigkeit wird durch ProblemHousekeepingFrequency gesteuert.

Bis das Housekeeping-Verfahren für Auslöser gestartet wird, können Probleme, die durch inzwischen gelöschte Auslöser verursacht wurden, weiterhin Serviceprobleme erzeugen und diese Services zuweisen. Wenn Ihre Umgebung viele Regeln zur Statusberechnung für Services umfasst, die auf häufig entdeckten/nicht mehr entdeckten Auslösern basieren, sollten Sie erwägen, die Häufigkeit des Housekeeping-Verfahrens durch Anpassen des Server-Konfigurationsparameters ProblemHousekeepingFrequency zu erhöhen.

  • Für Services - prüft die Tabelle problems und entfernt veraltete Service-Ereignisse sowie veraltete Serviceprobleme und löst diese damit zum Zeitpunkt des Housekeepings.

  • Für die Netzwerkdiscovery - entfernt veraltete Discovery-Ereignisse aus der Tabelle problems.

Der housekeeper entfernt nur Ereignisse, die nicht mit Problemen verknüpft sind. Beispielsweise wird ein veraltetes Problem-/Wiederherstellungsereignis nicht entfernt, wenn es mit einem offenen Problem verknüpft ist. Wenn der housekeeper veraltete Entitäten entfernt, entfernt er zuerst Probleme und dann Ereignisse.

Tabellen, die den Modus partition verwenden (von TimescaleDB partitionierte Tabellen), werden übersprungen; nur Tabellen, die den Modus regular verwenden, werden verarbeitet.

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.