1 Server

Übersicht

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

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.
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 - 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 angegebenen High-Availability-(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 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 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.
log_level_increase[=<target>] Protokollierungsstufe 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 target als 'process type,N' an.
log_level_decrease[=<target>] Protokollierungsstufe 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/Mutexen 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 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 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 unter dem jeweiligen Nicht-Root-Benutzer ausgeführt, mit dem er gestartet wurde. Sie können den Server daher problemlos unter jedem 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 Konfigurationsdatei des Servers 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 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 Erkennungsaufgaben 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 Historie;
  • housekeeper - Prozess zum Entfernen veralteter Daten (Datenpunkt-Historie 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 zur Generierung 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 inzwischen gelöschten Auslösern erzeugt 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.

Die Server-Logdatei wird mit Lese- und Schreibberechtigungen 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>] item ü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.
Housekeeping-Verfahren

Der Prozess housekeeper entfernt in regelmäßigen Abständen veraltete Daten (Datenpunkthistorie und Trends, Benutzersitzungen, Ereignisse usw.) sowie Daten, die von gelöschten Objekten zurückgeblieben sind. Er läuft in Zyklen, wobei die Häufigkeit und das Löschlimit pro Zyklus durch HousekeepingFrequency und MaxHousekeeperDelete bestimmt werden. Alle Daten, die in einem Zyklus nicht entfernt werden, werden in den nächsten übernommen. Die automatische Bereinigung kann unter Administration > Housekeeping aktiviert und konfiguriert werden.

Zum Entfernen von Daten, die von gelöschten Objekten zurückgeblieben sind, verwendet der Prozess housekeeper Aufgaben aus der Tabelle housekeeper, die immer dann gefüllt wird, wenn ein Objekt gelöscht wird. Wenn Sie beispielsweise einen Host löschen, löscht Zabbix auch dessen Datenpunkte, jedoch nicht deren Historie, Trends oder Probleme. Stattdessen füllen Datenbank-Trigger die Tabelle housekeeper mit Aufgaben, die aus den folgenden Feldern bestehen:

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

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

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

Datenbank-Trigger füllen die Tabelle housekeeper, ohne objektspezifische 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 Historien- und Trend-Tabellen (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 prüft er die Tabelle problems und entfernt veraltete interne Ereignisse, die mit diesen Datenpunkten verknüpft sind.

  • Für Auslöser - prüft er 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 keine bekannte Quell-Auslöser haben. Seine Ausführungsfrequenz wird durch ProblemHousekeepingFrequency gesteuert.

Bis das Trigger-Housekeeping-Verfahren gestartet wird, können Probleme, die durch inzwischen gelöschte Auslöser verursacht wurden, weiterhin Service-Probleme erzeugen und diesen Diensten zuweisen. Wenn Ihr Setup viele Statusberechnungsregeln für Dienste auf Basis häufig erkannter/nicht erkannter Auslöser umfasst, sollten Sie die Häufigkeit des Housekeeping-Verfahrens erhöhen, indem Sie den Server-Konfigurationsparameter ProblemHousekeepingFrequency anpassen.

  • Für Dienste - prüft die Tabelle problems und entfernt veraltete Service-Ereignisse sowie veraltete Service-Probleme und löst diese damit zum Zeitpunkt des Housekeeping auf.

  • Für Netzwerkerkennung - entfernt veraltete Erkennungsereignisse aus der Tabelle problems.

Der housekeeper entfernt nur solche Ereignisse, die nicht mit Problemen verknüpft sind. Ein veraltetes Problem-/Wiederherstellungsereignis wird beispielsweise 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 im partition-Modus (TimescaleDB-partitionierte Tabellen) werden übersprungen; nur Tabellen im regular-Modus 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.