[comment]: # ({30385a91-30385a91})
# 2 Details zur Vorverarbeitung
[comment]: # ({/30385a91-30385a91})
[comment]: # ({e6d564d3-67b39eda})
#### Übersicht
Dieser Abschnitt enthält Details zur Vorverarbeitung von Datenpunktwerten. Die Vorverarbeitung von Datenpunktwerten ermöglicht es, [Transformationsregeln](/manual/config/items/preprocessing) für die empfangenen Datenpunktwerte zu definieren und auszuführen.
Die Vorverarbeitung wird vom Prozess des Vorverarbeitungs-Managers zusammen mit Vorverarbeitungs-Workern verwaltet, die die Vorverarbeitungsschritte ausführen.
Alle Werte mit Vorverarbeitung (vor Zabbix 7.4.1 alle Werte), die von verschiedenen Datensammlern empfangen werden, durchlaufen vor dem Hinzufügen zum History-Cache den Vorverarbeitungs-Manager. Für die Kommunikation zwischen Datensammlern (Poller, Trapper usw.) und dem Vorverarbeitungsprozess wird eine socketbasierte IPC-Kommunikation verwendet. Entweder der Zabbix Server oder der Zabbix Proxy (für die vom Proxy überwachten Datenpunkte) führt die Vorverarbeitungsschritte aus.
[comment]: # ({/e6d564d3-67b39eda})
[comment]: # ({cbc4231a-7aff5db5})
#### Item-Wertverarbeitung
Um den Datenfluss von der Datenquelle zur Zabbix-Datenbank zu visualisieren, können wir das folgende vereinfachte Diagramm verwenden:
Das obige Diagramm zeigt nur Prozesse, Objekte und Aktionen, die mit der Item-Wertverarbeitung in vereinfachter Form zusammenhängen. Das Diagramm zeigt keine bedingten Richtungsänderungen, Fehlerbehandlung oder Schleifen. Der lokale Daten-Cache des Vorverarbeitungs-Managers wird ebenfalls nicht angezeigt, da er den Datenfluss nicht direkt beeinflusst. Ziel dieses Diagramms ist es, die an der Item-Wertverarbeitung beteiligten Prozesse und ihre Interaktion darzustellen.
- Die Datenerfassung beginnt mit Rohdaten aus einer Datenquelle. Zu diesem Zeitpunkt enthalten die Daten nur ID, Zeitstempel und Wert (es können auch mehrere Werte sein).
- Unabhängig davon, welcher Typ von Datensammler verwendet wird, ist das Prinzip für aktive oder passive Prüfungen, für Trapper-Items usw. dasselbe, da sich nur das Datenformat und der Initiator der Kommunikation ändern (entweder wartet der Datensammler auf eine Verbindung und Daten, oder der Datensammler initiiert die Kommunikation und fordert die Daten an). Die Rohdaten werden validiert, die Item-Konfiguration wird aus dem Konfigurations-Cache abgerufen (die Daten werden mit den Konfigurationsdaten angereichert).
- Ein socketbasiertes IPC-Mechanismus wird verwendet, um Daten von Datensammlern an den Vorverarbeitungs-Manager zu übergeben. Zu diesem Zeitpunkt sammelt der Datensammler weiterhin Daten, ohne auf die Antwort des Vorverarbeitungs-Managers zu warten.
- Die Datenvorverarbeitung wird ausgeführt. Dazu gehören die Ausführung von Vorverarbeitungsschritten und die Verarbeitung abhängiger Items.
::: noteclassic
Ein Item kann während der Vorverarbeitung seinen Status auf NOT SUPPORTED ändern, wenn einer der Vorverarbeitungsschritte fehlschlägt.
:::
- Die Verlaufsdaten aus dem lokalen Daten-Cache des Vorverarbeitungs-Managers werden in den Verlaufs-Cache geschrieben.
- An diesem Punkt stoppt der Datenfluss bis zur nächsten Synchronisierung des Verlaufs-Caches (wenn der Prozess history syncer die Datensynchronisierung durchführt).
- Der Synchronisierungsprozess beginnt mit der Datennormalisierung, bevor die Daten in der Zabbix-Datenbank gespeichert werden. Die Datennormalisierung führt Konvertierungen in den gewünschten Item-Typ durch (den in der Item-Konfiguration definierten Typ), einschließlich der Kürzung von Textdaten auf Grundlage der für diese Typen zulässigen [vordefinierten Größen](/manual/config/items/item#text-data-limits) (HISTORY\_STR\_VALUE\_LEN für string, HISTORY\_TEXT\_VALUE\_LEN für text und HISTORY\_LOG\_VALUE\_LEN für log-Werte). Nachdem die Normalisierung abgeschlossen ist, werden die Daten an die Zabbix-Datenbank gesendet.
::: noteclassic
Ein Item kann seinen Status auf NOT SUPPORTED ändern, wenn die Datennormalisierung fehlschlägt
(zum Beispiel, wenn ein Textwert nicht in eine Zahl umgewandelt werden kann).
:::
- Die erfassten Daten werden verarbeitet - Auslöser werden geprüft, die Item-Konfiguration wird aktualisiert, wenn das Item zu NOT SUPPORTED wird, usw.
- Dies gilt aus Sicht der Item-Wertverarbeitung als Ende des Datenflusses.
[comment]: # ({/cbc4231a-7aff5db5})
[comment]: # ({312e1118-44da8577})
#### Datenpunkt-Wertvorverarbeitung
Die Datenvorverarbeitung wird in den folgenden Schritten durchgeführt:
- Wenn der Datenpunkt weder Vorverarbeitung noch abhängige Datenpunkte hat, wird sein Wert entweder zum History-Cache hinzugefügt oder an den LLD-Manager gesendet. Andernfalls wird der Datenpunktwert über einen IPC-Mechanismus auf Basis eines UNIX-Sockets an den Vorverarbeitungs-Manager übergeben (vor Zabbix 7.4.1 wurden alle Werte vor dem Hinzufügen zum History-Cache oder dem Senden an den LLD-Manager durch den Vorverarbeitungs-Manager geleitet).
- Eine Vorverarbeitungsaufgabe wird erstellt, zur Warteschlange hinzugefügt, und die Vorverarbeitungs-Worker werden über die neue Aufgabe benachrichtigt.
- An diesem Punkt stoppt der Datenfluss, bis mindestens ein freier Vorverarbeitungs-Worker vorhanden ist, der keine Aufgaben ausführt.
- Wenn ein Vorverarbeitungs-Worker verfügbar ist, nimmt er die nächste Aufgabe aus der Warteschlange.
- Nachdem die Vorverarbeitung abgeschlossen ist (sowohl bei fehlgeschlagener als auch bei erfolgreicher Ausführung der Vorverarbeitungsschritte), wird der vorverarbeitete Wert zur Warteschlange der abgeschlossenen Aufgaben hinzugefügt, und der Manager wird über eine neue abgeschlossene Aufgabe benachrichtigt.
- Der Vorverarbeitungs-Manager konvertiert das Ergebnis in das gewünschte Format (definiert durch den Datenpunkt-Werttyp) und fügt es entweder dem History-Cache hinzu oder sendet es an den LLD-Manager.
- Wenn es für den verarbeiteten Datenpunkt abhängige Datenpunkte gibt, werden diese mit dem vorverarbeiteten Wert des Master-Datenpunkts zur Vorverarbeitungswarteschlange hinzugefügt. Abhängige Datenpunkte werden unter Umgehung der normalen Anfragen zur Datenpunktwertvorverarbeitung eingereiht, jedoch nur für Master-Datenpunkte, deren Wert gesetzt ist und die sich nicht im Zustand NOT SUPPORTED befinden.
{width="600"}
Beachten Sie, dass in der Abbildung die Vorverarbeitung des Master-Datenpunkts leicht vereinfacht dargestellt ist, indem das Caching der Vorverarbeitung übersprungen wird.
[comment]: # ({/312e1118-44da8577})
[comment]: # ({73f49808-4b6fc468})
#### Vorverarbeitungswarteschlange
Die Vorverarbeitungswarteschlange ist wie folgt organisiert:
* die Liste der ausstehenden Aufgaben:
* Aufgaben, die direkt aus Anfragen zur Wertvorverarbeitung in der Reihenfolge erstellt wurden, in der sie empfangen wurden
* die Liste der sofortigen Aufgaben (werden vor ausstehenden Aufgaben verarbeitet):
* Testaufgaben (erstellt als Reaktion auf Anfragen zum Testen von Datenpunkt/Vorverarbeitung durch das Frontend)
* Aufgaben abhängiger Datenpunkte
* Sequenzaufgaben (Aufgaben, die in einer strikten Reihenfolge ausgeführt werden müssen):
* mit Vorverarbeitungsschritten, die den letzten Wert verwenden:
* Änderung
* Drosselung
* JavaScript (Bytecode-Caching)
* Caching der Vorverarbeitung abhängiger Datenpunkte
* die Liste der abgeschlossenen Aufgaben
[comment]: # ({/73f49808-4b6fc468})
[comment]: # ({abb85873-c9d6405f})
#### Caching für die Vorverarbeitung
Das Caching für die Vorverarbeitung wurde eingeführt, um die Leistung der Vorverarbeitung für mehrere abhängige Datenpunkte mit ähnlichen Vorverarbeitungsschritten zu verbessern (was ein häufiges Ergebnis von LLD ist).
Das Caching erfolgt, indem ein abhängiger Datenpunkt vorverarbeitet wird und einige der internen Vorverarbeitungsdaten für die übrigen abhängigen Datenpunkte wiederverwendet werden. Der Vorverarbeitungs-Cache wird nur für den ersten Vorverarbeitungsschritt der folgenden Typen unterstützt:
* Prometheus-Muster (indiziert die Eingabe nach Metriken)
* JSONPath (parst die Daten in einen Objektbaum und indiziert den ersten Ausdruck `[?(@.path == "value")]`)
[comment]: # ({/abb85873-c9d6405f})
[comment]: # ({c79ec0eb-98589fcd})
#### Preprocessing-Worker
Die Konfigurationsdatei des Zabbix-Server ermöglicht es Benutzern, die Anzahl der Threads für Preprocessing-Worker festzulegen.
Der Konfigurationsparameter [StartPreprocessors](/manual/appendix/config/zabbix_server#startpreprocessors) sollte verwendet werden, um die Anzahl der vorab gestarteten Instanzen von Preprocessing-Workern festzulegen; diese sollte mindestens der Anzahl der verfügbaren CPU-Kerne entsprechen.
Wenn Preprocessing-Aufgaben nicht CPU-gebunden sind und häufige Netzwerkanfragen beinhalten, wird empfohlen, zusätzliche Worker zu konfigurieren.
Die optimale Anzahl von Preprocessing-Workern kann von vielen Faktoren abhängen, darunter die Anzahl der „vorverarbeitbaren“ Datenpunkte (Datenpunkte, für die Preprocessing-Schritte ausgeführt werden müssen), die Anzahl der Prozesse zur Datenerfassung, die durchschnittliche Anzahl der Schritte bei der Datenpunkt-Vorverarbeitung usw.
Eine unzureichende Anzahl an Workern kann zu hoher Speicherauslastung führen. Informationen zur Fehlerbehebung bei übermäßiger Speichernutzung in Ihrer Zabbix-Installation finden Sie unter [Profiling excessive memory usage with tcmalloc](/manual/installation/known_issues#profiling-excessive-memory-usage-with-tcmalloc).
Unter der Annahme, dass keine aufwendigen Preprocessing-Operationen wie das Parsen großer XML-/JSON-Blöcke stattfinden, kann die Anzahl der Preprocessing-Worker jedoch der Gesamtzahl der Datensammler entsprechen. Auf diese Weise steht für erfasste Daten in den meisten Fällen (außer wenn Daten vom Sammler gesammelt gebündelt eintreffen) mindestens ein freier Preprocessing-Worker zur Verfügung.
::: notewarning
Zu viele Prozesse zur Datenerfassung (Poller, Poller für nicht erreichbare Hosts, ODBC-Poller, HTTP-Poller, Java-Poller, Pinger, Trapper, Proxy-Poller) zusammen mit IPMI-Manager, SNMP-Trapper und Preprocessing-Workern können das Dateideskriptor-Limit pro Prozess für den Preprocessing-Manager ausschöpfen.
Wenn das Dateideskriptor-Limit pro Prozess ausgeschöpft wird, führt dies dazu, dass der Zabbix-Server stoppt, typischerweise kurz nach dem Start, manchmal aber auch erst später.
Um solche Probleme zu vermeiden, prüfen Sie die [Zabbix-Server-Konfigurationsdatei](/manual/appendix/config/zabbix_server), um die Anzahl gleichzeitiger Prüfungen und Prozesse zu optimieren.
Stellen Sie außerdem bei Bedarf sicher, dass das Dateideskriptor-Limit ausreichend hoch gesetzt ist, indem Sie die Systemlimits prüfen und anpassen.
:::
[comment]: # ({/c79ec0eb-98589fcd})
[comment]: # ({a459312a-ad691011})
##### Pipeline zur Wertverarbeitung
Die Verarbeitung von Datenpunktwerten wird in mehreren Schritten (oder Phasen) von
mehreren Prozessen ausgeführt. Dies kann dazu führen:
- Ein abhängiger Datenpunkt kann Werte empfangen, während der Master-Wert dies nicht kann.
Dies lässt sich mit folgendem Anwendungsfall erreichen:
- Der Master-Datenpunkt hat den Werttyp `UINT` (es kann ein Trapper-Datenpunkt verwendet werden),
der abhängige Datenpunkt hat den Werttyp `TEXT`.
- Für weder den Master- noch den abhängigen Datenpunkt sind Vorverarbeitungsschritte erforderlich.
- Ein Textwert (zum Beispiel „abc“) soll an den Master-Datenpunkt übergeben werden.
- Da keine Vorverarbeitungsschritte auszuführen sind, prüft der Vorverarbeitungsmanager, ob sich der Master-Datenpunkt nicht im Zustand NOT SUPPORTED befindet und ob ein Wert gesetzt ist (beides trifft zu), und reiht den abhängigen Datenpunkt mit demselben Wert wie den des Master-Datenpunkts in die Warteschlange ein (da es keine Vorverarbeitungsschritte gibt).
- Wenn sowohl der Master- als auch der abhängige Datenpunkt die Phase der History-Synchronisierung erreichen, wird der Master-Datenpunkt aufgrund eines Fehlers bei der Wertkonvertierung zu NOT SUPPORTED (Textdaten können nicht in eine vorzeichenlose Ganzzahl konvertiert werden).
Als Ergebnis empfängt der abhängige Datenpunkt einen Wert, während der Master-Datenpunkt
seinen Zustand in NOT SUPPORTED ändert.
- Ein abhängiger Datenpunkt empfängt einen Wert, der in der History des Master-Datenpunkts nicht vorhanden ist.
Der Anwendungsfall ist dem vorherigen sehr ähnlich, mit Ausnahme
des Typs des Master-Datenpunkts. Wenn zum Beispiel der Typ `CHAR` für den
Master-Datenpunkt verwendet wird, dann wird der Wert des Master-Datenpunkts in der Phase
der History-Synchronisierung abgeschnitten, während abhängige Datenpunkte ihre
Werte aus dem ursprünglichen (nicht abgeschnittenen) Wert des Master-Datenpunkts erhalten.
[comment]: # ({/a459312a-ad691011})