[comment]: # ({f9458f4e-f9458f4e})
# 4 Proxy

[comment]: # ({/f9458f4e-f9458f4e})

[comment]: # ({a0844076-05d8de8a})
#### Ü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.

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

Siehe auch: [Verwendung von Proxys in einer verteilten Umgebung](/manual/distributed_monitoring/proxies)

[comment]: # ({/a0844076-05d8de8a})

[comment]: # ({709824a5-709824a5})
#### Proxy ausführen

[comment]: # ({/709824a5-709824a5})

[comment]: # ({70fd3646-a0a6c8d1})
##### Wenn als Paket installiert

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

```bash
systemctl start zabbix-proxy
```

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

```bash
/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:

```bash
systemctl stop zabbix-proxy
systemctl restart zabbix-proxy
systemctl status zabbix-proxy
```

[comment]: # ({/70fd3646-a0a6c8d1})

[comment]: # ({5e827b2c-0b35181b})
##### Manuell starten

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

```bash
zabbix_proxy
```

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

```bash
-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 validieren und beenden
-h --help                       Diese Hilfe anzeigen
-V --version                    Versionsnummer anzeigen
```

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

```bash
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf
zabbix_proxy --help
zabbix_proxy -V
```

[comment]: # ({/5e827b2c-0b35181b})

[comment]: # ({b9a1c6fe-ee4dd6f0})
##### Laufzeitsteuerung

Optionen der Laufzeitsteuerung:

|Option|Beschreibung|Ziel|
|--|------|------|
|`config_cache_reload`|Konfigurationscache neu laden. Wird ignoriert, wenn der Cache derzeit geladen wird.<br>Ein aktiver Zabbix Proxy verbindet sich mit dem Zabbix Server und fordert Konfigurationsdaten an.<br>Ein passiver Zabbix Proxy fordert beim nächsten Verbindungsaufbau des Servers zum Proxy Konfigurationsdaten vom Zabbix Server an.| |
|`history_cache_clear=target`|Den Verlaufscache für den durch seine ID angegebenen Datenpunkt leeren.<br>Wirkt sich auf alle Werte des Datenpunkts aus, außer auf den ersten und den letzten Wert.|**target** - ID des Datenpunkts.|
|`diaginfo[=<section>]`|Diagnoseinformationen in der Protokolldatei des Proxys sammeln.|`historycache` - Statistiken des Verlaufscaches;<br>`preprocessing` - Statistiken des Preprocessing-Managers;<br>`locks` - Liste der Mutexes (auf *BSD*-Systemen leer).|
|`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 einen globalen Cache-Löschvorgang zu erzwingen.| |
|`housekeeper_execute`|Den Housekeeping-Prozess starten. Wird ignoriert, wenn der Housekeeping-Prozess derzeit ausgeführt wird.| |
|`log_level_increase[=<target>]`|Protokollierungsstufe erhöhen, betrifft alle Prozesse, wenn kein Ziel angegeben ist. <br>Auf *BSD*-Systemen nicht unterstützt.|**process type** - alle Prozesse des angegebenen Typs (z. B. `poller`).<br>Siehe alle [Proxy-Prozesstypen](#proxy-process-types-and-threads).<br>**process type,N** - Prozesstyp und Nummer (z. B. `poller,3`).<br>**pid** - Prozesskennung (`1` bis `65535`). Für größere Werte geben Sie das Ziel als 'process type,N' an.|
|`log_level_decrease[=<target>]`|Protokollierungsstufe verringern, betrifft alle Prozesse, wenn kein Ziel angegeben ist.<br>Auf *BSD*-Systemen nicht unterstützt.|^|
|`prof_enable[=<target>]`|Profiling aktivieren.<br>Betrifft alle Prozesse, wenn kein Ziel angegeben ist.<br>Aktiviertes Profiling liefert Details zu allen rwlocks/Mutexes nach Funktionsnamen.|**process type** - alle Prozesse des angegebenen Typs (z. B. `history syncer`).<br>Siehe alle [Proxy-Prozesstypen](#proxy-process-types-and-threads).<br>**process type,N** - Prozesstyp und Nummer (z. B. `history syncer,1`)<br>**pid** - Prozesskennung (`1` bis `65535`). Für größere Werte geben Sie das Ziel als 'process type,N' an.<br>**scope** - `rwlock`, `mutex`, `processing` können 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.<br>Betrifft alle Prozesse, wenn kein Ziel angegeben ist.|**process type** - alle Prozesse des angegebenen Typs (z. B. `history syncer`).<br>Siehe alle [Proxy-Prozesstypen](#proxy-process-types-and-threads).<br>**process type,N** - Prozesstyp und Nummer (z. B. `history syncer,1`).<br>**pid** - Prozesskennung (`1` bis `65535`). Für größere Werte geben Sie das Ziel als 'process type,N' an.|

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

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

Beispiel für die Verwendung der Laufzeitsteuerung zum Leeren des Verlaufscaches für einen Datenpunkt:

```bash
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:

```bash
# Alle verfügbaren Diagnoseinformationen in der Protokolldatei des Proxys sammeln:
zabbix_proxy -R diaginfo

# Statistiken des Verlaufscaches in der Protokolldatei des Proxys sammeln:
zabbix_proxy -R diaginfo=historycache
```

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

```bash
zabbix_proxy -R snmp_cache_reload
```

::: noteimportant
Wenn eine SNMPv3-Schnittstelle über die Zabbix UI aktualisiert wird, lädt Zabbix in den meisten Fällen die neuen SNMPv3-Anmeldedaten für diese Schnittstelle automatisch neu; verwenden Sie `-R snmp_cache_reload` nur, wenn das Polling nach Änderungen der Anmeldedaten weiterhin fehlschlägt (zum Beispiel aufgrund von Inkonsistenzen bei engineBoots/engineID oder bei Geräten, die nicht RFC-konform sind), oder wenn Sie zum Zweck der Fehlerbehebung ein globales Leeren des SNMP-Caches erzwingen müssen.
:::

Beispiel für die Verwendung der Laufzeitsteuerung zum Auslösen der Ausführung von Housekeeper:

```bash
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R housekeeper_execute
```

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

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

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

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

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

[comment]: # ({/b9a1c6fe-ee4dd6f0})

[comment]: # ({2b13e467-a9af55d3})
##### Prozessbenutzer

Der Zabbix Proxy 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 Proxy 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 Proxy nur dann als `root` ausführen, wenn Sie den Parameter `AllowRoot` in der Proxy-Konfigurationsdatei entsprechend ändern.

[comment]: # ({/2b13e467-a9af55d3})

[comment]: # ({6e096a7b-441f5ec7})
##### Konfigurationsdatei

Siehe die Optionen der [Konfigurationsdatei](/manual/appendix/config/zabbix_proxy) für Details zur Konfiguration von `zabbix_proxy`.

[comment]: # ({/6e096a7b-441f5ec7})

[comment]: # ({ee7041c3-2cd46511})
#### Proxy-Prozesstypen und Threads

-   `agent poller` - asynchroner Poller-Prozess für passive Prüfungen mit einem Worker-Thread;
-   `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;
-   `data sender` - Proxy-Datenversender;
-   `discovery manager` - Manager-Prozess für die Entdeckung von Geräten;
-   `discovery worker` - Prozess zur Verarbeitung von Discovery-Aufgaben des Discovery-Managers;
-   `history syncer` - Writer für die Verlaufsdatenbank;
-   `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` - Manager für IPMI-Poller;
-   `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 Vorverarbeitungs-Worker-Threads;
-   `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 bestätigen, Wert eines Datenpunkts jetzt prüfen, Funktion für Remote-Befehle);
-   `trapper` - Trapper für aktive Prüfungen, Traps und Proxy-Kommunikation;
-   `unreachable poller` - Poller für nicht erreichbare Geräte;
-   `vmware collector` - VMware-Datensammler, der für die Erfassung von Daten aus VMware-Diensten verantwortlich ist.

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

Seit Zabbix 7.4.6 wird die Proxy-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-Proxy-Prozessen können mit dem internen `zabbix[process,<type>,<mode>,<state>]` [Datenpunkt](/manual/config/items/itemtypes/internal) überwacht werden.

[comment]: # ({/ee7041c3-2cd46511})

[comment]: # ({93aa4b3e-2bebd420})
##### Statistik der Transaktionen des History-Syncers

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

```bash
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, die für das Schreiben von Datenpunktwerten in die Datenbank aufgewendet wurde.
-   Zeit, die für die Aktualisierung der Datenpunktdaten (Status, Fehler) aufgewendet wurde.

[comment]: # ({/93aa4b3e-2bebd420})

[comment]: # ({99df0923-087c822f})
#### Unterstützte Plattformen

Zabbix Proxy läuft auf derselben Liste von [unterstützten Plattformen](/manual/concepts/server#supported-platforms) wie der Zabbix Server.

[comment]: # ({/99df0923-087c822f})

[comment]: # ({f18fc440-d86eb1a8})
#### Speicherpuffer

Der Speicherpuffer ermöglicht es, neue Daten (Datenpunktwerte, Netzwerkerkennung, Host-Autoregistrierung) im Puffer zu speichern und an den Zabbix Server zu übertragen, ohne auf die Datenbank zuzugreifen.
Der Speicherpuffer wurde für den Proxy in Zabbix 7.0 eingeführt.

In Installationen vor Zabbix 7.0 wurden die gesammelten Daten vor dem Hochladen an den Zabbix Server in der Datenbank gespeichert.
Für diese Installationen bleibt dieses Verhalten nach dem Upgrade auf Zabbix 7.0 standardmäßig erhalten.

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`](/manual/appendix/config/zabbix_proxy#proxybuffermode) von `disk` (fest codierter 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`](/manual/appendix/config/zabbix_proxy#proxymemorybuffersize)).

Im Hybridmodus ist 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 überläuft, 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`](/manual/appendix/config/zabbix_proxy#proxymemorybuffersize) und [`ProxyMemoryBufferAge`](/manual/appendix/config/zabbix_proxy#proxymemorybufferage) definieren die Größe des Speicherpuffers bzw. die maximale Alterung der Daten im Puffer.

Beachten Sie, dass der Proxy bei widersprüchlicher Konfiguration einen Fehler ausgibt und nicht startet, zum Beispiel wenn:
  
-   `ProxyBufferMode` auf `hybrid` oder `memory` gesetzt ist und `ProxyMemoryBufferSize` `0` ist.
-   `ProxyBufferMode` auf `hybrid` oder `memory` gesetzt ist und `ProxyLocalBuffer` nicht `0` ist.

[comment]: # ({/f18fc440-d86eb1a8})

[comment]: # ({b4e0a962-c703b792})
#### 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.

[comment]: # ({/b4e0a962-c703b792})

[comment]: # ({de7d29ed-19fb9631})
#### Berechnung von Warteschlangen während der Wartung

::: noteimportant
Der Zabbix Proxy kennt keine Wartungszeiträume; siehe [Berechnung von Warteschlangen während der Wartung](/manual/maintenance#calculation-of-queues-during-maintenance) für Details.
:::

[comment]: # ({/de7d29ed-19fb9631})