4 Proxy

Übersicht

Der Zabbix Proxy ist ein Prozess, der Monitoring-Daten von einem oder mehreren überwachten Geräten erfassen und die Informationen an den Zabbix Server senden kann und dabei im Wesentlichen im Auftrag des Servers arbeitet. Alle erfassten Daten werden lokal zwischengespeichert und anschließend an den Zabbix Server übertragen, zu dem der Proxy gehört.

Die Bereitstellung eines Proxy ist optional, kann jedoch sehr vorteilhaft sein, um die Last eines einzelnen Zabbix Servers zu verteilen. Wenn nur Proxys Daten erfassen, benötigt die Verarbeitung auf dem Server weniger CPU- und Festplatten-I/O-Ressourcen.

Ein Zabbix Proxy ist die ideale Lösung für zentrales Monitoring von entfernten Standorten, Niederlassungen und Netzwerken ohne lokale Administratoren.

Ein Zabbix Proxy benötigt eine separate Datenbank.

Beachten Sie, dass mit dem Zabbix Proxy unterstützte Datenbanken SQLite, MySQL und PostgreSQL sind.

Siehe auch: Verwendung von Proxys in einer verteilten Umgebung

Proxy ausführen

Wenn als Paket installiert

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

systemctl start zabbix-proxy

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

/etc/init.d/zabbix-proxy start

Verwenden Sie entsprechend die folgenden Befehle, um den Zabbix Proxy zu stoppen, neu zu starten oder seinen Status anzuzeigen:

systemctl stop zabbix-proxy
systemctl restart zabbix-proxy
systemctl status zabbix-proxy
Manuell starten

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

zabbix_proxy

Sie können die folgenden Befehlszeilenparameter mit Zabbix Proxy verwenden:

-c --config <file>              Pfad zur Konfigurationsdatei
-f --foreground                 Zabbix Proxy 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 Proxy mit Befehlszeilenparametern:

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

Optionen der Laufzeitsteuerung:

Option Beschreibung Ziel
config_cache_reload Konfigurations-Cache neu laden. Wird ignoriert, wenn der Cache gerade geladen wird.
Ein aktiver Zabbix Proxy verbindet sich mit dem Zabbix Server und fordert Konfigurationsdaten an.
Ein passiver Zabbix Proxy fordert Konfigurationsdaten vom Zabbix Server an, wenn sich der Server das nächste Mal mit dem Proxy verbindet.
history_cache_clear=target History-Cache für den durch seine ID angegebenen Datenpunkt leeren.
Betrifft alle Werte des Datenpunkts außer dem ersten und letzten Wert.		 target - ID des Datenpunkts
diaginfo[=<section>] Diagnoseinformationen in der Proxy-Logdatei sammeln. historycache - Statistiken zum History-Cache
preprocessing - Statistiken des Präprozessierungsmanagers
locks - Liste der Mutexe (ist auf BSD-Systemen leer)
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 gerade ausgeführt wird.
log_level_increase[=<target>] Log-Level erhöhen; betrifft alle Prozesse, wenn kein Ziel angegeben ist.
Auf BSD-Systemen nicht unterstützt.		 Prozesstyp - Alle Prozesse des angegebenen Typs (z. B. poller)
Siehe alle Proxy-Prozesstypen.
Prozesstyp,N - Prozesstyp und Nummer (z. B. poller,3)
pid - Prozesskennung (1 bis 65535). Geben Sie bei größeren Werten target als 'Prozesstyp,N' an.
log_level_decrease[=<target>] Log-Level verringern; betrifft alle Prozesse, wenn kein Ziel angegeben ist.
Auf BSD-Systemen nicht unterstützt.
prof_enable[=<target>] Profiling aktivieren.
Betrifft alle Prozesse, wenn kein Ziel angegeben ist.
Aktiviertes Profiling liefert Details zu allen rwlocks/Mutexen nach Funktionsname.		 Prozesstyp - Alle Prozesse des angegebenen Typs (z. B. history syncer)
Siehe alle Proxy-Prozesstypen.
Prozesstyp,N - Prozesstyp und Nummer (z. B. history syncer,1)
pid - Prozesskennung (1 bis 65535). Geben Sie bei größeren Werten target als 'Prozesstyp,N' an.
scope - rwlock, mutex, processing können mit Prozesstyp und 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 Ziel angegeben ist.		 Prozesstyp - Alle Prozesse des angegebenen Typs (z. B. history syncer)
Siehe alle Proxy-Prozesstypen.
Prozesstyp,N - Prozesstyp und Nummer (z. B. history syncer,1)
pid - Prozesskennung (1 bis 65535). Geben Sie bei größeren Werten target als 'Prozesstyp,N' an.

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

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

Beispiel für die Verwendung der Laufzeitsteuerung zum Leeren des History-Caches für einen Datenpunkt:

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

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

# Alle verfügbaren Diagnoseinformationen in der Proxy-Logdatei sammeln:
zabbix_proxy -R diaginfo

# Statistiken zum History-Cache in der Proxy-Logdatei sammeln:
zabbix_proxy -R diaginfo=historycache

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

zabbix_proxy -R snmp_cache_reload

Wenn eine SNMPv3-Schnittstelle über die Zabbix-Benutzeroberfläche 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 dann, wenn die Abfrage nach Änderungen der Zugangsdaten weiterhin fehlschlägt (zum Beispiel aufgrund von Inkonsistenzen bei engineBoots/engineID oder nicht RFC-konformen Geräten) oder wenn Sie zur Fehlerbehebung 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_proxy -c /usr/local/etc/zabbix_proxy.conf -R housekeeper_execute

Beispiele für die Verwendung der Laufzeitsteuerung zum Ändern des Log-Levels:

# Log-Level aller Prozesse erhöhen:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase

# Log-Level des zweiten poller-Prozesses erhöhen:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=poller,2

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

# Log-Level aller http poller-Prozesse verringern:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_decrease="http poller"
Prozessbenutzer

Der Zabbix Proxy 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 Proxy problemlos als jeden 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 Proxy nur als „root“ ausführen, wenn Sie den Parameter „AllowRoot“ in der Proxy-Konfigurationsdatei entsprechend anpassen.

Konfigurationsdatei

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

Proxy-Prozesstypen und Threads

  • agent poller - asynchroner Poller-Prozess für passive Prüfungen mit einem Worker-Thread
  • availability manager - Prozess für Host-Verfügbarkeitsaktualisierungen
  • browser poller - Poller für Browser-Datenpunkt-Prüfungen
  • configuration syncer - Prozess zur Verwaltung des In-Memory-Caches von Konfigurationsdaten
  • data sender - Proxy-Datensender
  • discovery manager - Manager-Prozess für die Erkennung von Geräten
  • discovery worker - Prozess zur Verarbeitung von Erkennungsaufgaben vom Discovery Manager
  • history syncer - History-DB-Schreiber
  • housekeeper - Prozess zum Entfernen veralteter Datenpunkt-Historie
  • 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
  • odbc poller - Poller für ODBC-Prüfungen
  • poller - normaler Poller für passive Prüfungen
  • preprocessing manager - Manager für Vorverarbeitungsaufgaben mit Worker-Threads für die Vorverarbeitung
  • preprocessing worker - Thread für die Datenvorverarbeitung
  • self-monitoring - Prozess zum Sammeln interner Server-Statistiken
  • 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 quittieren, Datenpunkt-Wert jetzt prüfen, Remote-Befehlsfunktionalität)
  • trapper - Trapper für aktive Prüfungen, Traps, Proxy-Kommunikation
  • unreachable poller - Poller für nicht erreichbare Geräte
  • vmware collector - VMware-Datensammler, der für die Datenerfassung von VMware-Diensten verantwortlich ist

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

Die Proxy-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-Proxy-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.

205276 ?        S      0:00  zabbix_proxy: history syncer #1 [processed 1 values in 0.001179 (0.001167,0.000000) sec, idle 1 sec]
205277 ?        S      0:00  zabbix_proxy: history syncer #2 [processed 0 values in 0.000022 (0.000000,0.000000) sec, idle 1 sec]

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

  • Zeit zum Schreiben von Datenpunkt-Werten in die Datenbank;
  • Zeit zum Aktualisieren von Datenpunkt-Daten (Status, Fehler).
Housekeeping-Verfahren

Der Zabbix Proxy verfügt über den Prozess housekeeper, der veraltete Datenpunkt-Verläufe und Trends entfernt. Er wird in Zyklen ausgeführt, wobei die Häufigkeit durch HousekeepingFrequency und das Löschlimit pro Zyklus durch ProxyLocalBuffer sowie ProxyOfflineBuffer bestimmt wird. Anders als beim Housekeeping-Verfahren des Zabbix Server verwendet der Proxy-Prozess housekeeper nicht die Tabelle housekeeper – stattdessen löscht er alle veralteten Daten einmal pro Housekeeping-Zyklus.

Unterstützte Plattformen

Zabbix Proxy läuft auf derselben Liste von unterstützten Plattformen wie der Zabbix Server.

Speicherpuffer

Der Speicherpuffer ermöglicht es, neue Daten (Datenpunkt-Werte, Netzwerkdiscovery, automatische Host-Registrierung) im Puffer zu speichern und an den Zabbix Server hochzuladen, ohne auf die Datenbank zuzugreifen. Der Speicherpuffer wurde seit Zabbix 7.0 für den Proxy eingeführt.

In Installationen vor Zabbix 7.0 wurden die erfassten Daten vor dem Hochladen an den Zabbix Server in der Datenbank gespeichert. Für diese Installationen bleibt dies auch nach dem Upgrade auf Zabbix 7.0 das Standardverhalten.

Für eine optimierte Leistung wird empfohlen, die Verwendung des Speicherpuffers auf dem Proxy zu konfigurieren. Dies ist möglich, indem der Wert von ProxyBufferMode von "disk" (fest kodierter Standardwert für bestehende Installationen) auf "hybrid" (empfohlen) oder "memory" geändert wird. Außerdem muss die Größe des Speicherpuffers festgelegt werden (Parameter ProxyMemoryBufferSize).

Im Hybridmodus wird der Puffer vor Datenverlust geschützt, indem nicht gesendete Daten in die Datenbank geschrieben werden, wenn der Proxy gestoppt wird, der Puffer voll ist oder die Daten zu alt sind. Sobald alle Werte in die Datenbank geschrieben wurden, verwendet der Proxy wieder den Speicherpuffer.

Im Speichermodus wird der Speicherpuffer verwendet, es gibt jedoch keinen Schutz vor Datenverlust. Wenn der Proxy gestoppt wird oder der Speicher überfüllt wird, werden die nicht gesendeten Daten verworfen.

Der Hybridmodus (ProxyBufferMode=hybrid) wird seit Zabbix 7.0 auf alle neuen Installationen angewendet.

Zusätzliche Parameter wie ProxyMemoryBufferSize und ProxyMemoryBufferAge definieren jeweils die Größe des Speicherpuffers und das maximale Alter der Daten im Puffer.

Beachten Sie, dass der Proxy bei einer widersprüchlichen Konfiguration einen Fehler ausgibt und nicht startet, zum Beispiel wenn:

  • ProxyBufferMode auf "hybrid" oder "memory" gesetzt ist und ProxyMemoryBufferSize den Wert "0" hat;
  • ProxyBufferMode auf "hybrid" oder "memory" gesetzt ist und ProxyLocalBuffer nicht "0" ist.

Gebietsschema

Beachten Sie, dass der Proxy 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; bei einigen Systemen muss dies jedoch möglicherweise ausdrücklich festgelegt werden.

Berechnung von Warteschlangen während der Wartung

Der Zabbix Proxy kennt keine Wartungszeiträume; siehe Berechnung von Warteschlangen während der Wartung für Details.