[comment]: # ({30385a91-30385a91})
# 2 Details zur Vorverarbeitung
[comment]: # ({/30385a91-30385a91})
[comment]: # ({e20db496-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.0.17 alle Werte), die von verschiedenen Datensammlern empfangen werden, durchlaufen den Vorverarbeitungs-Manager, bevor sie zum History-Cache hinzugefügt werden. Für die IPC-Kommunikation auf Socket-Basis wird zwischen Datensammlern (Poller, Trapper usw.) und dem Vorverarbeitungsprozess verwendet. Entweder der Zabbix Server oder der Zabbix Proxy (für die vom Proxy überwachten Datenpunkte) führt die Vorverarbeitungsschritte aus.
[comment]: # ({/e20db496-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 Preprocessing-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 Wechselwirkungen 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 um die Konfigurationsdaten ergänzt).
- Ein socketbasiertes IPC-Mechanismus wird verwendet, um Daten von Datensammlern an den Preprocessing-Manager zu übergeben. Zu diesem Zeitpunkt sammelt der Datensammler weiterhin Daten, ohne auf die Antwort des Preprocessing-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 in den Zustand NOT SUPPORTED wechseln, wenn einer der Vorverarbeitungsschritte fehlschlägt.
:::
- Die Verlaufsdaten aus dem lokalen Daten-Cache des Preprocessing-Managers werden in den History-Cache geschrieben.
- An diesem Punkt stoppt der Datenfluss bis zur nächsten Synchronisierung des History-Cache (wenn der Prozess history syncer die Datensynchronisierung ausfü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 (der Typ ist in der Item-Konfiguration definiert), 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). Die Daten werden nach Abschluss der Normalisierung an die Zabbix-Datenbank gesendet.
::: noteclassic
Ein Item kann in den Zustand NOT SUPPORTED wechseln, 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]: # ({107e489a-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.0.17 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 unbesetzter Vorverarbeitungs-Worker vorhanden ist, der also keine Aufgaben ausführt.
- Wenn ein Vorverarbeitungs-Worker verfügbar ist, nimmt er die nächste Aufgabe aus der Warteschlange.
- Nach Abschluss der Vorverarbeitung (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 abhängige Datenpunkte für den verarbeiteten Datenpunkt gibt, werden diese mit dem vorverarbeiteten Wert des Master-Datenpunkts zur Vorverarbeitungswarteschlange hinzugefügt. Abhängige Datenpunkte werden unter Umgehung der normalen Anfragen zur Wertvorverarbeitung 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 im Diagramm die Vorverarbeitung des Master-Datenpunkts leicht vereinfacht dargestellt ist, indem das Caching der Vorverarbeitung übersprungen wird.
[comment]: # ({/107e489a-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-Servers ermöglicht es Benutzern, die Anzahl der Preprocessing-Worker-Threads 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 die Konfiguration zusätzlicher Worker empfohlen.
Die optimale Anzahl von Preprocessing-Workern kann von vielen Faktoren abhängen, darunter die Anzahl der "preprocessable" Datenpunkte (Datenpunkte, die die Ausführung von Preprocessing-Schritten erfordern), die Anzahl der Datenerfassungsprozesse, die durchschnittliche Anzahl von Schritten für das Preprocessing von Datenpunkten usw.
Zu wenige Worker können zu einer hohen Speicherauslastung führen. Informationen zur Fehlerbehebung bei übermäßiger Speicherauslastung in Ihrer Zabbix-Installation finden Sie unter [Profiling excessive memory usage with tcmalloc](/manual/installation/known_issues#profiling-excessive-memory-usage-with-tcmalloc).
Wenn jedoch keine aufwendigen Preprocessing-Operationen wie das Parsen großer XML/JSON-Blöcke durchgeführt werden, kann die Anzahl der Preprocessing-Worker der Gesamtzahl der Datensammler entsprechen. Auf diese Weise steht für die erfassten Daten meist mindestens ein unbesetzter Preprocessing-Worker zur Verfügung, außer in Fällen, in denen Daten vom Sammler in großen Mengen eintreffen.
::: notewarning
Zu viele Datenerfassungsprozesse (Poller, unreachable pollers, ODBC pollers, HTTP pollers, Java pollers, pingers, trappers, proxypollers) zusammen mit dem IPMI manager, SNMP trapper und den Preprocessing-Workern können das pro Prozess zulässige Limit für Dateideskriptoren des Preprocessing-Managers erschöpfen.
Wenn das pro Prozess zulässige Limit für Dateideskriptoren erschöpft ist, wird der Zabbix-Server angehalten, typischerweise kurz nach dem Start, manchmal jedoch erst nach längerer Zeit.
Um solche Probleme zu vermeiden, überprü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 Limit für Dateideskriptoren ausreichend hoch gesetzt ist, indem Sie die Systemlimits überprü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})