Elasticsearch lehnte verspätet eintreffende Metriken ab. Dies führte zu Verzögerungen in der Pipeline. Dadurch wurden wiederum weitere verspätete Daten generiert, was noch mehr Ablehnungen zur Folge hatte. Schließlich kam die Pipeline vollständig zum Stillstand.

Wir mussten die Daten aus einem Snapshot wiederherstellen, die Daten neu indizieren und die Ingestion-Pipeline neu gestalten, um die Wiederherstellung zu ermöglichen.

Die eigentliche Ursache lag nicht in der Verwaltung des Indexlebenszyklus (ILM) selbst. Es ging um Zeitreihendatenströme (TSDS) und wie diese zeitgebundene Sicherungsindizes erzwingen.

TSDS kann die Speicherplatzanforderungen für Metriken um 40–70 % reduzieren, aber die architektonischen Änderungen, die TSDS effizient machen, verändern auch das Verhalten von Indizes im Laufe der Zeit. Diese Änderungen sind wichtig bei der Gestaltung von ILM-Richtlinien oder wenn Ihre Ingestion-Pipelines möglicherweise verspätet eintreffende Daten erzeugen.

TL;DR

Bei Verwendung von TSDS:

• Sicherungsindizes akzeptieren nur Dokumente innerhalb eines bestimmten Zeitfensters.

• Wenn verspätete Daten eintreffen, nachdem ein Index in den Status „kalt“ oder „eingefroren“ versetzt wurde, weist Elasticsearch diese Dokumente zurück oder leitet sie, falls konfiguriert, an den Fehlerspeicher weiter.

Designregel:

Was ist ein Zeitreihendatenstrom?

Ein Zeitreihendatenstrom (TSDS) ist ein spezieller Datenstrom, der für Metrikdaten optimiert ist. Die Daten werden so weitergeleitet, dass zugehörige Dokumente innerhalb derselben Shards liegen, wodurch sie für Abfrage und Abruf optimiert werden. So funktioniert dies in Elasticsearch:

Jedes Dokument enthält:

• Ein Zeitstempel.

• Dimensionsfelder, die die Zeitreihen identifizieren.

• Metrische Felder, die Messwerte darstellen.

Dazu ein paar Beispiele:

• CPU-Auslastung pro Host.

• Anfragenlatenzen pro Dienst.

• Temperaturmessungen pro Sensor.

Dimensionen geben an, was wir messen möchten, während Metriken Werte darstellen, die sich im Laufe der Zeit ändern.

Abmessungen

Die Abmessungen beschreiben das gemessene Objekt.

Beispiele:

Wir definieren sie in den Mappings mit:

Metriken

Metriken stellen numerische Werte dar und werden wie folgt definiert:

Gängige Arten von Metriken:

• Messanzeigen: Werte, die steigen und fallen.

• Zähler: Werte, die bis zum Zurücksetzen ansteigen.

Elastic Agent sammelt in erster Linie Metriken und Protokolldaten. Selbst wenn Sie also keine TSDS-Indizes manuell aktiviert haben, können diese dennoch in Ihrem Cluster vorhanden sein.

Das _tsid-Feld

Elasticsearch generiert intern einen _tsid-Wert aus Dimensionsfeldern. Dadurch können Dokumente mit identischen Abmessungen an denselben Shard weitergeleitet werden, was folgende Vorteile mit sich bringt:

• Kompression.

• Abfrageort.

• Aggregationsleistung.

Der wesentliche Unterschied: zeitgebundene Sicherungsindizes

Herkömmliche Datenströme schreiben immer in den aktuellsten Sicherungsindex, der als Schreibindex bezeichnet wird, aber TSDS verhält sich anders.

Jeder TSDS-Sicherungsindex hat ein definiertes Zeitfenster und akzeptiert nur Dokumente mit @timestamp-Werten, die in dieses Zeitfenster fallen:

Wenn ein Dokument indexiert wird, leitet Elasticsearch es an den für diesen Zeitstempel zuständigen Sicherungsindex weiter. Das bedeutet, dass ein TSDS im Gegensatz zu herkömmlichen Indizes gleichzeitig auf mehrere Sicherungsindizes schreiben kann.

Zum Beispiel:

• Echtzeit-Daten → aktuellster Index.

• Verspätete Daten → ein früherer Index, der diesen Zeitbereich abdeckt.

Gestaltung für verspätet eintreffende Daten

Echte Ingestion-Pipelines liefern Metriken nur selten perfekt und pünktlich. Die Metriken können sich aufgrund von Netzwerkausfällen, Rückständen auf dem Übertragungsweg, Batch-Ingestion und dem Ausfall von Edge-Geräten verzögern, die sich dann wieder verbinden und den Rückstand aufholen.

Herkömmliche Indizes gleichen diese Verzögerungen stillschweigend aus. TSDS tut dies nicht.

Wenn der Zeitstempel eines Dokuments außerhalb des Bereichs der beschreibbaren Sicherungsindizes liegt, wird es von Elasticsearch abgelehnt. Das bedeutet, dass Ihre ILM-Richtlinie verspätete Daten berücksichtigen muss.

Die kritische Einschränkung

Unterstützende Indizes müssen lange genug beschreibbar bleiben, um verzögerte Daten zu akzeptieren.

Konkret bedeutet dies:

Da ILM das Alter ab dem Rollover misst, lautet die operative Regel:

Wenn beispielsweise Metriken bis zu sechs Stunden verspätet eintreffen können, müssen Indizes mindestens sechs Stunden nach dem Rollover beschreibbar bleiben.

Dass diese Einschränkung nicht berücksichtigt wurde, war genau die Ursache für den zuvor beschriebenen Ingestion-Fehler. Verspätet eintreffende Daten wurden an einen früheren Index weitergeleitet, der sich bereits im Cold Tier befand und daher für Schreibvorgänge gesperrt war.

Umgang mit abgelehnten Dokumenten

Wenn TSDS ein Dokument ablehnt, gibt Elasticsearch eine Fehlermeldung aus, die darauf hinweist, dass der Zeitstempel nicht in den Bereich der beschreibbaren Indizes fällt. Die Art und Weise, wie Ihre Ingestion-Pipeline mit diesem Fehler umgeht, bestimmt, ob Sie Daten verlieren oder die Ingestion unterbrechen.

Der primäre Mechanismus für den Umgang mit abgelehnten Dokumenten ist der Fehlerspeicher.

Fehlerspeicher (empfohlen in Elasticsearch 9.1+)

Mit Elasticsearch 9.1 wurde der Fehlerspeicher eingeführt, der automatisch abgelehnte Dokumente erfasst. Anstatt Fehler an Clients zurückzuleiten, schreibt Elasticsearch fehlgeschlagene Dokumente in einen dedizierten Fehlerindex innerhalb des Datenstroms.

Sie können Fehler inspizieren, indem Sie:

Die Verwendung des Fehlerspeichers verhindert, dass Ingestion-Pipelines aufgrund von Ablehnungsfehlern überlastet werden, während fehlgeschlagene Daten für Analysen oder erneute Indexierung aufbewahrt werden.

Probleme bei der Ablehnung überwachen

Bei spät auftretenden Problemen zeigen sich zunächst meist Ingestion-Anomalien. Zunächst fallen sie Ihnen möglicherweise auf als:

• Plötzliche Rückgänge der Indexierungsrate.

• Sprunghafte Anstiege bei abgelehnten Dokumenten.

• Eine wachsende Anzahl von Einträgen im Fehlerspeicher.

• Abweichungen zwischen den Eingangs- und Ausgangswerten der Pipeline.

Durch die Warnmeldung bei diesen Signalen können die Betreiber Probleme erkennen, bevor es zu einem Stillstand der Pipelines kommt. Workflows, Machine Learning-Jobs und andere Mechanismen können verwendet werden, um die Erkennung und Benachrichtigung zu automatisieren.

Migrationscheckliste für TSDS + ILM

Wenn Sie einen Metrik-Cluster auf TSDS migrieren, ILM-Tiering einsetzen oder auf eine Elasticsearch-Version upgraden, bei der die Metriken standardmäßig als TSDS erfasst sind, überprüfen Sie diese Punkte zuerst.

1. Ingestion-Latenz messen

Vor der Änderung der ILM-Richtlinien ist Folgendes festzulegen:

• Normale Ingestion-Verzögerung.

• Maximale Verzögerung bei Vorfällen.

• Verzögerungen durch Batch-Pipelines.

Ihr ILM-Design muss die maximale realistische Verzögerung berücksichtigen.

2. Indexzeitfenster überprüfen

Inspizieren Sie Ihre TSDS-Sicherungsindizes:

Suchen Sie nach:

• time_series.start_time

• time_series.end_time

Diese Grenzen legen fest, welche Indizes Dokumente aufnehmen können. Das Verständnis dieser Zeitfenster kann Ihnen dabei helfen, zu ermitteln, wie spät Daten eintreffen dürfen, bevor sie abgelehnt werden.

3. Die Dimension der „heißen“ Ebene für verspätet eintreffende Daten bestimmen

Stellen Sie sicher, dass die unterstützenden Indizes lange genug beschreibbar bleiben, um verzögerte Daten zu verarbeiten.

Betriebsregel:

• warm_min_age > rollover_max_age + maximum_expected_lateness

Denken Sie daran, dass Indizes mindestens sechs Stunden beschreibbar bleiben müssen, wenn Metriken sechs Stunden zu spät eintreffen.

4. Entscheiden Sie, wie mit abgelehnten Dokumenten umgegangen werden soll

Wählen Sie eine Strategie, bevor Sie TSDS aktivieren:

• Fehlerspeicher (empfohlen in Elasticsearch 9.1+).

• Warteschlange für unzustellbare Nachrichten in Logstash.

• Fallback-Index für verspätete Eingänge.

• Akzeptanz von begrenztem Datenverlust.

5. Ingestion-Status überwachen

Warnmeldungen hinzufügen für:

• Die Indexierungsrate sinkt.

• Abgelehnte Dokumente.

• Das Fehlerspeicherwachstum.

• Diskrepanzen zwischen Pipeline-Eingabe und -Ausgabe.

Verspätete Datenprobleme treten oft zuerst als Ingestion-Anomalien auf.

Zusammenfassung

Zeitreihendatenströme bieten erhebliche Speicher- und Leistungsverbesserungen für Metrik-Workloads, bringen aber eine wichtige architektonische Änderung mit sich: Sicherungsindizes sind zeitgebunden, was das Verhalten von ILM beeinflusst.

Bei Verwendung von TSDS:

• Indizes müssen lange genug beschreibbar bleiben, um verzögerte Daten zu akzeptieren.

• Ingestion-Pipelines sollten abgelehnte Dokumente sicher verarbeiten.

Die wichtigste Regel lautet:

Wenn Sie Ihre ILM-Richtlinien unter Berücksichtigung dieser Einschränkung gestalten, eignet sich TSDS hervorragend für Metrik-Workloads.

Wenn Sie dies jedoch ignorieren, könnte Ihre Ingestion-Pipeline diese Zeitgrenzen auf die harte Tour erfahren.

Traditionell war die Verwaltung von Webcrawlern ein manueller, fehleranfälliger Prozess. Dabei ging es um das direkte Bearbeiten von Konfigurationen in der Benutzeroberfläche sowie um das Klonen von Crawl-Konfigurationen, das Zurücksetzen von Einstellungen, die Versionsverwaltung und vieles mehr. Die Behandlung von Crawler-Konfigurationen als Code löst dieses Problem, indem sie die gleichen Vorteile bietet, die wir von der Softwareentwicklung erwarten: Wiederholbarkeit, Nachvollziehbarkeit und Automatisierung.

Dieser Workflow erleichtert es, den Open Web Crawler in Ihre CI/CD-Pipeline für Rollbacks, Backups und Migrationen einzubinden – Aufgaben, die mit früheren Elastic Crawlern wie dem Elastic Web Crawler oder dem App Search Crawler wesentlich schwieriger waren.

In diesem Artikel erfahren Sie, wie Sie:

• Verwalten Sie unsere Crawl-Konfigurationen mit GitHub.

• Eine lokale Testumgebung für Pipelines vor der Bereitstellung einrichten

• Wir erstellen eine Produktionsumgebung, um den Webcrawler jedes Mal mit neuen Einstellungen auszuführen, wenn wir Änderungen an unseren Hauptzweig übertragen.

Das Projekt-Repository finden Sie hier. Zum Zeitpunkt der Erstellung dieses Dokuments verwende ich Elasticsearch 9.1.3 und Open Web Crawler 0.4.2.

Voraussetzungen

• Docker Desktop

• Elasticsearch-Instanz

• Virtuelle Maschine mit SSH-Zugriff (z. B. AWS EC2) und installiertem Docker

Schritte

1. Ordnerstruktur

2. Raupenkonfiguration

3. Docker-Compose-Datei (lokale Umgebung)

4. GitHub Actions

5. Lokale Tests

6. Bereitstellung in der Produktionsumgebung

7. Änderungen vornehmen und erneut bereitstellen

Ordnerstruktur

Für dieses Projekt werden wir folgende Dateistruktur verwenden:

Raupenkonfiguration

Unter crawler-config.yml, wird Folgendes eingetragen:

Dies führt einen Crawl von https://web-scraping.dev/products durch, einer simulierten Website für Produkte. Wir werden nur die ersten drei Produktseiten durchsuchen. Die Einstellung max_crawl_depth verhindert, dass der Crawler mehr Seiten als die als seed_urls definierten Seiten entdeckt, indem er die darin enthaltenen Links nicht öffnet.

Elasticsearch host und api_key werden dynamisch befüllt, abhängig von der Umgebung, in der das Skript ausgeführt wird.

Docker-Compose-Datei (lokale Umgebung)

Für die lokale Umgebung docker-compose.yml, werden wir den Crawler und einen einzelnen Elasticsearch-Cluster + Kibana bereitstellen, damit wir unsere Crawling-Ergebnisse vor der Bereitstellung in der Produktionsumgebung einfach visualisieren können.

Beachten Sie, wie der Crawler wartet, bis Elasticsearch bereit ist, ausgeführt zu werden.

GitHub Actions

Nun müssen wir eine GitHub-Aktion erstellen, die die neuen Einstellungen kopiert und den Crawler bei jedem Push auf den Hauptzweig in unserer virtuellen Maschine ausführt. Dadurch wird sichergestellt, dass wir immer die aktuellste Konfiguration im Einsatz haben, ohne manuell in die virtuelle Maschine eingreifen zu müssen, um Dateien zu aktualisieren und den Crawler auszuführen. Wir werden AWS EC2 als Anbieter virtueller Maschinen verwenden.

Der erste Schritt besteht darin, den Host (VM_HOST), den Maschinenbenutzer (VM_USER), den SSH-RSA-Schlüssel (VM_KEY), den Elasticsearch-Host (ES_HOST) und den Elasticsearch-API-Schlüssel (ES_API_KEY) zu den GitHub Action Secrets hinzuzufügen:

Auf diese Weise kann die Aktion auf unseren Server zugreifen, um die neuen Dateien zu kopieren und den Crawl auszuführen.

Nun erstellen wir unsere .github/workflows/deploy.yml -Datei:

Diese Aktion führt jedes Mal die folgenden Schritte aus, wenn wir Änderungen an der Crawler-Konfigurationsdatei vornehmen:

1. Tragen Sie den Elasticsearch-Host und den API-Schlüssel in die YAML-Konfiguration ein.

2. Kopieren Sie den Konfigurationsordner auf unsere VM

3. Stellen Sie über SSH eine Verbindung zu unserer VM her.

4. Führen Sie den Crawl mit der Konfiguration aus, die wir gerade aus dem Repository kopiert haben.

Lokale Tests

Um unseren Crawler lokal zu testen, haben wir ein Bash-Skript erstellt, das den Elasticsearch-Host mit dem lokalen Docker-Repository befüllt und einen Crawl startet. Sie können ./local.sh eingeben, um es auszuführen.

Schauen wir uns die Kibana DevTools an, um zu bestätigen, dass web-crawler-index korrekt befüllt wurde:

Bereitstellung in der Produktionsumgebung

Jetzt sind wir bereit, die Änderungen auf den Hauptzweig zu übertragen. Dadurch wird der Crawler in Ihrer virtuellen Maschine bereitgestellt und beginnt, Protokolle an Ihre Serverless Elasticsearch-Instanz zu senden.

Dadurch wird die GitHub-Aktion ausgelöst, die das Bereitstellungsskript innerhalb der virtuellen Maschine ausführt und mit dem Crawling beginnt.

Sie können die Ausführung der Aktion überprüfen, indem Sie zum GitHub-Repository gehen und den Tab „Aktionen“ aufrufen:

Änderungen vornehmen und erneut bereitstellen

Vielleicht ist Ihnen aufgefallen, dass die price jedes Produkts Teil des Body-Felds des Dokuments ist. Ideal wäre es, den Preis in einem separaten Feld zu speichern, damit wir Filter darauf anwenden können.

Fügen wir diese Änderung zur Datei crawler.yml hinzu, um Extraktionsregeln zu verwenden, mit denen der Preis aus der CSS-Klasse product-price extrahiert werden kann:

Wir sehen auch, dass der Preis ein Dollarzeichen ($) enthält, das wir entfernen müssen, wenn wir Bereichsabfragen ausführen wollen. Dafür können wir eine Ingest-Pipeline verwenden. Beachten Sie, dass wir in unserer neuen Crawler-Konfigurationsdatei oben darauf verweisen:

Wir können diesen Befehl in unserem Elasticsearch-Produktionscluster ausführen. Da die Entwicklungsversion ephemer ist, können wir die Pipeline-Erstellung in die docker-compose.yml -Datei integrieren, indem wir den folgenden Dienst hinzufügen. Beachten Sie, dass wir dem Crawler-Dienst auch eine depends_on hinzugefügt haben, damit er erst startet, nachdem die Pipeline erfolgreich erstellt wurde.

Führen wir nun `./local.sh` aus, um die Änderung lokal zu sehen:

Großartig! Jetzt lasst uns die Veränderung vorantreiben:

Um sicherzustellen, dass alles funktioniert, können Sie Ihre Produktions-Kibana-Datei überprüfen. Dort sollten die Änderungen sichtbar sein und der Preis als neues Feld ohne Dollarzeichen angezeigt werden.

Fazit

Mit dem Elastic Open Web Crawler können Sie Ihren Crawler als Code verwalten. Das bedeutet, dass Sie die gesamte Pipeline – von der Entwicklung bis zur Bereitstellung – automatisieren und beispielsweise ephemere lokale Umgebungen und Tests anhand der gecrawlten Daten programmatisch hinzufügen können.

Sie sind eingeladen, das offizielle Repository zu klonen und mit der Indizierung Ihrer eigenen Daten mithilfe dieses Workflows zu beginnen. In diesem Artikel erfahren Sie auch, wie Sie eine semantische Suche auf den vom Crawler erzeugten Indizes durchführen.

1. Verwendung der _mapping -API zum Abrufen von Feldinformationen

2. Verwendung der _search API zum Anzeigen von Feldwerten

3. Unterfelder anzeigen

4. Synthetisches Feld „_source“

5. Laufzeitfelder

1. Verwendung der _mapping-API zum Abrufen von Feldinformationen

Die _mapping API ermöglicht es Ihnen, die Mapping-Definition für einen oder mehrere Indizes abzurufen. Dies umfasst Informationen über die Felder, ihre Datentypen und weitere Eigenschaften. Um die Zuordnung für einen bestimmten Index abzurufen, verwenden Sie die folgende Anfrage:

Wenn Sie beispielsweise einen Index mit dem Namen my_index haben, können Sie dessen Zuordnung mit der folgenden Anfrage abrufen:

Die Antwort enthält die Mapping-Definition für den Index, die Informationen über die Felder und deren Eigenschaften enthält.

Es ist auch möglich, die Zuordnung eines bestimmten Feldes abzurufen. Dies kann nützlich sein, wenn Ihre Kartierung recht umfangreich ist und Sie sich nur auf ein bestimmtes Feld konzentrieren möchten. Um die Zuordnung eines bestimmten Feldes abzurufen, verwenden Sie die folgende Anfrage:

Sie können die Zuordnungen mehrerer Felder auch abrufen, indem Sie deren Namen durch Kommas trennen, wie in der folgenden Anfrage:

2. Verwenden der _search-API zum Anzeigen von Feldwerten

Um die Werte von Feldern in einem Elasticsearch-Index anzuzeigen, können Sie die _search API verwenden. Die _search API bietet Ihnen mehrere Möglichkeiten, die zurückgegebenen Felder zu steuern; die beiden wichtigsten sind:

1. _sourceDas Feld _source enthält den ursprünglichen JSON-Dokumentkörper genau so, wie er indexiert wurde, einschließlich aller Änderungen, die durch Ingestionspipelines oder Vorverarbeitungsschritte vorgenommen wurden. Um bestimmte Felder aus dem Quelldokument anzuzeigen, implementieren Sie eine Quellfilterung, wie wir im Folgenden sehen werden.

2. fieldsMit dem Parameter fields können Sie beim Durchführen einer Suche bestimmte Felder aus Ihren Dokumenten auf Basis der Indexzuordnung abrufen. Im Gegensatz zu _source kann fields auch Werte aus gespeicherten Feldern, Dokumentwerten oder Laufzeitfeldern zurückgeben, ohne auf _source zu verweisen. Für Standardfelder ohne Dokumentwerte oder gespeicherte Einstellungen wird jedoch auf _source zurückgegriffen. Dies kann viele Vorteile mit sich bringen, wie zum Beispiel eine höhere Leistungsfähigkeit und mehr, wie wir im Folgenden sehen werden.

Verwendung des Feldes _source

Standardmäßig gibt die _search -API das Feld _source zurück, welches das ursprüngliche, indizierte JSON-Dokument enthält. Um bestimmte Felder anzuzeigen, können Sie Filter im Parameter _source der Suchanfrage hinzufügen; dies wird als Quellfilterung bezeichnet.

Hier ist ein Beispiel für eine Suchanfrage, die die Werte der Felder title und author für Dokumente im Index my_index zurückgibt:

In diesem Beispiel gibt der Parameter _source die zurückzugebenden Felder an.

Falls Sie noch mehr Kontrolle benötigen, können Sie die Eigenschaften includes und excludes des Objekts _source verwenden. Beispielsweise gibt die folgende Abfrage das Feld der obersten Ebene title und alle Unterfelder von author außer author.description zurück.

In diesem Beispiel verwenden wir das Muster author.* , um jedes direkte Unterfeld des Objekts author abzurufen. Dann schließen wir author.description explizit aus, sodass nur die übrigen Autorenfelder zurückgegeben werden. Beachten Sie, dass dies keine Leistungsverbesserungen mit sich bringt, da das Quell-JSON weiterhin geladen und analysiert werden muss, aber es kann die Größe der über das Netzwerk gesendeten Antwort verringern.

Verwendung des Parameters „fields“

Mit dem Parameter fields können Sie die in der Suchergebnisseinduktion zurückgegebenen Felder filtern. Die Verwendung fields anstelle von _source bietet mehrere Vorteile, darunter:

• Verbesserte Performance: fields kann Werte direkt aus gespeicherten Feldern oder Dokumentwerten zurückgeben, ohne die vollständige _source laden zu müssen, wodurch die Größe der Antwortnutzlast kleiner wird.

• Formatierte Ausgabe: Bei Standardfeldern kann fields auf _source zurückgreifen, um die Werte zu erfassen. Dabei wird jedoch die Indexzuordnung herangezogen, um die Ausgabe korrekt zu formatieren, z. B. formatierte Datumsangaben, sodass sie mit den für Aggregationen und Sortierungen verwendeten Formaten konsistent sind.

• Zugriff auf Laufzeitfelder: fields kann Laufzeitfelder zurückgeben, die im ursprünglichen _source nicht existieren.

• Weitere Vorteile finden Sie hier.

Um beispielsweise nur die Felder title und author im Index my_index zurückzugeben, können Sie die folgende Suchanfrage verwenden:

In der obigen Abfrage setzen wir das Feld _source auf false, damit wir das Quelldokument nicht zurückgeben. Dadurch kann die Nutzlastgröße der Antwort drastisch reduziert werden. Beachten Sie jedoch, dass dies nur funktioniert, weil die Felder title und author vom Feldtyp keyword sind, bei dem standardmäßig doc_values aktiviert ist. Wenn das Feld doc_values nicht aktiviert hat und _source auf false gesetzt ist, hat Elasticsearch keine Möglichkeit, diese abzurufen, und sie werden in der Antwort übersprungen.

Wichtig zu beachten ist, dass die fields -Antwort immer ein Array von Werten für jedes Feld zurückgibt, selbst wenn es nur einen einzigen Wert gibt. Dies liegt daran, dass Elasticsearch keinen dedizierten Array-Typ besitzt und jedes Feld mehrere Werte haben kann. Für weitere Informationen zu Arrays in Elasticsearch klicken Sie hier.

Weitere Möglichkeiten zum Abrufen von Feldern

Obwohl das Abrufen von Feldern mit _source oder fields die empfohlenen Methoden sind, stehen für bestimmte Anwendungsfälle verschiedene Methoden zur Verfügung, wie zum Beispiel:

Doc-Wertfelder: Wenn Sie _source komplett vermeiden möchten, können Sie mit dem Parameter docvalue_fieldssuchen. Doc-Werte speichern die gleichen Feldwerte wie _source , jedoch in einer auf der Festplatte gespeicherten Datenstruktur, die für Sortierung und Aggregation optimiert ist.

Da es sich um separate Werte handelt, die nicht mit _source gespeichert sind, können Sie bestimmte Felder anfordern, ohne das gesamte _source zu laden. Dies ist nützlich, wenn Sie große Dokumente abfragen, aber nur wenige kleine Felder benötigen, die Dokumentwerte unterstützen. Ein weiterer Anwendungsfall für docvalue_fields besteht darin, dass Sie eine benutzerdefinierte Formatierung für die Felder date und numeric verwenden möchten, wie wir im folgenden Beispiel sehen werden.

Beachten Sie, dass dies nur für Felder funktioniert, für die Sie doc_values aktivieren, oder für Feldtypen, bei denen dies standardmäßig aktiviert ist, wie z. B. keyword, date, numerische Typen und boolean, nicht für text oder annotated_text.

In diesem Beispiel verwenden wir den Parameter docvalue_fields , um die Felder title, author und published abzurufen, ohne das vollständige Dokument _source zu laden:

Wenn diese Abfrage ausgeführt wird, greift Elasticsearch direkt auf die Werte in seinem spaltenorientierten Speicher auf der Festplatte zu, anstatt für jedes Dokument auf _source zu verweisen. Das Feld published wird dank des in der Abfrage angegebenen Parameters format im Format epoch_millis anstatt im Standardformat zurückgegeben.

Gespeicherte Felder: Wenn Sie in der Zuordnung explizit bestimmte Felder als gespeichert markiert haben, können Sie mit dem Parameter stored_fields nach diesen Feldern filtern. Dies ist nützlich, wenn Sie kurze Antworten nur mit diesen spezifischen Feldern wünschen oder Felder, die Sie absichtlich zum späteren Abruf gespeichert haben. Es wird separat von _source gespeichert, daher ist diese Methode auch nützlich, um das Laden von _source zu vermeiden.

Wichtig zu beachten ist, dass diese Option standardmäßig deaktiviert und generell nicht empfehlenswert ist. Verwenden Sie stattdessen Quellfilter, um bestimmte Teilmengen des ursprünglichen Quelldokuments zurückzugeben.

In der folgenden Beispielabfrage verwenden wir den Parameter stored_fields , um das Feld summary abzurufen, das die Indexzuordnungskonfiguration ”store”: true hat.

Wenn diese Abfrage ausgeführt wird, prüft Elasticsearch, ob dieses Feld mit ”store”: true markiert wurde. Falls dies nicht der Fall ist, wird das Feld vollständig übersprungen.

3. Unterfelder anzeigen

Wenn Ihr Index Unterfelder enthält, können Sie die Punktnotation verwenden, um den Feldpfad im Parameter fields anzugeben. Beachten Sie, dass Unterfelder sich vom verschachtelten Feldtyp unterscheiden. Wenn Sie beispielsweise ein Unterfeld mit dem Namen address.city haben, können Sie es wie folgt in die Suchergebnisseinlösung einbinden:

In diesem Beispiel enthält die Suchergebnisseinsendung die Werte der Felder title, author und address.city .

4. Synthetische Quelle

Wenn Sie die Funktionalität der Verwendung von _source beibehalten, aber gleichzeitig Speicherplatz sparen möchten, haben Sie die Möglichkeit, in Ihrer Indexzuordnung synthetisches _source zu verwenden. Die Funktion Synthetic _source ermöglicht es Elasticsearch, die _source aus vorhandenen Daten wie gespeicherten Feldern und Dokumentwerten zu rekonstruieren, selbst wenn _source deaktiviert ist. Dadurch lässt sich viel Speicherplatz sparen, allerdings auf Kosten etwas geringerer Abfragegeschwindigkeiten, da die Rekonstruktion in Echtzeit erfolgt. Aktivieren Sie diese Funktion, indem Sie die folgenden Werte in Ihren Indexeinstellungen verwenden:

Zu den Vorteilen der Verwendung von synthetischem _source gehören: vollständige Dokumentanzeige bei Verwendung der _search API, Quellfilterung und Kompatibilität mit anderen Funktionen und Tools wie Kibana, die die Verfügbarkeit _source voraussetzen, und das alles, ohne dass das vollständige _source Dokument gespeichert werden muss.

5. Laufzeitfelder

Mit Laufzeitfeldern können Sie skriptgesteuerte Felder zur Abfragezeit oder in Ihrer Indexzuordnung unter einem Laufzeitblock definieren. Diese Felder werden nie indiziert, daher erhöht das Hinzufügen eines Laufzeitfelds nicht die Indexgröße, es wird aber niemals in _source angezeigt. Die in der Zuordnung definierten Laufzeitfelder sind persistent und für alle Abfragen verfügbar, während die zur Abfragezeit definierten Laufzeitfelder temporär sind und nur in dieser Suchanfrage verfügbar sind.

Der Hauptvorteil der Verwendung von Laufzeitfeldern besteht darin, dass man Felder zu Dokumenten hinzufügen kann, nachdem man sie bereits importiert hat, was die Zuordnungsentscheidungen vereinfacht. Laufzeitfelder eignen sich auch hervorragend, um Ihre Dokumente mit Werten anzureichern, die im Originaldokument nicht vorhanden sind, sondern mithilfe eines Skripts generiert werden, z. B. durch Formatieren einer Zeichenkette oder Berechnen einer Punktzahl.

Es ist außerdem zu beachten, dass Laufzeitfelder die Leistung beeinträchtigen können, da für jedes Dokument im Ergebnissatz ein Skript ausgeführt werden muss. Um ein Laufzeitfeld abzurufen, können Sie auch den Parameter fields der API _search verwenden.

Fazit

Die Anzeige von Feldern eines Elasticsearch-Index kann von der einfachen Abfrage von Werten mithilfe der Indexzuordnung oder _source bis hin zu fortgeschritteneren Methoden mit fields, docvalue_fields oder Laufzeitfeldern für mehr Kontrolle und Effizienz reichen. Das Verständnis der Vor- und Nachteile verschiedener Methoden ist der Schlüssel zur Optimierung Ihrer Sucherfahrung. Egal ob Sie Nutzdaten optimieren, Dokumente anreichern oder synthetische Daten _source verwenden, um Speicherplatz zu sparen, Elasticsearch bietet Ihnen zahlreiche Tools und Funktionen, um die benötigten Daten so zu finden, wie Sie sie benötigen. Mithilfe dieser Techniken können Sie die Struktur Ihrer Daten verstehen, bestimmte Felder identifizieren und Probleme beheben.

Logstash enthält mehrere integrierte Filter für häufige Aufgaben wie das Parsen, Anreichern und Modifizieren von Daten. Manchmal stößt man jedoch auf Szenarien, die eine benutzerdefinierte Logik erfordern, die über das hinausgeht, was diese Standardfilter bieten können. Hier kommt das Ruby-Filter-Plugin ins Spiel.

Mit dem Ruby-Filter-Plugin können Sie benutzerdefinierten Ruby-Code direkt in Ihrer Logstash-Pipeline ausführen. Wenn Standardfilter nicht ausreichen, ermöglicht Ihnen der Ruby-Filter die Durchführung komplexer Datentransformationen, die Implementierung benutzerdefinierter Geschäftslogik oder die Integration mit externen Systemen.

In diesem Blogbeitrag zeigen wir Ihnen, wie Sie Ruby-Filter verwenden – von den Grundlagen bis hin zu fortgeschrittenen Anwendungsfällen.

Wann sollte man den Ruby-Filter verwenden?

Als beratender Architekt bei Elastic sehe ich oft, dass Kunden Logstash für die Datenverarbeitungspipeline verwenden, obwohl es heutzutage keine hochmoderne Datenverarbeitungs-Engine mehr ist. Bei komplexen Datenmanipulationen oder benutzerdefinierter Logik stoßen sie häufig an die Grenzen von Standardfiltern. In diesen Fällen kann der Ruby-Filter dazu beitragen, diese Herausforderungen zu bewältigen.

Der Ruby-Filter ist nützlich, wenn die Standard-Logstash-Filter Ihre spezifischen Anforderungen nicht erfüllen können. Hier einige typische Anwendungsfälle:

• Tief verschachtelte Datenmanipulation: Komplexe JSON-Strukturen, Arrays innerhalb von Arrays modifizieren oder Daten dynamisch anhand ihres Inhalts umstrukturieren.

• Erweiterte Stringverarbeitung: Strukturierte Daten aus unstrukturiertem Text analysieren und extrahieren

• Implementierung komplexer Geschäftslogik: Erstellen benutzerdefinierter Transformationen, die bedingte Logik, Schleifen oder komplexe Berechnungen erfordern.

Grundlegende Verwendung

Beginnen wir mit einem einfachen Beispiel, um zu verstehen, wie der Ruby-Filter funktioniert.

Konfigurieren des Ruby-Filters

Wenn Sie eine Logstash-Pipeline erstellen, sollten Sie die Konfigurationsdatei im Verzeichnis /etc/logstash/conf.d ablegen. Alternativ können Sie die Option -f verwenden, um beim manuellen Starten von Logstash den Pfad zur Konfigurationsdatei anzugeben, sodass Sie problemlos mit Ihren Pipelines experimentieren können.

Die Konfigurationsdatei sollte die Dateiendung .conf haben.

Um den Ruby-Filter zu verwenden, definieren Sie einen ruby -Filter im Filterabschnitt Ihrer Logstash-Pipeline-Konfigurationsdatei (*.conf). Hier ein einfaches Beispiel:

Dieser Inline-Ruby-Filter definiert eine Ruby-Filterinstanz innerhalb Ihrer Logstash-Konfiguration. Der Parameter code stellt das Inline-Ruby-Skript bereit, das Logstash für jedes von diesem Filter verarbeitete Ereignis ausführt. Innerhalb dieses Skripts gibt es eine event Variable, die das Ereignis selbst repräsentiert. Das Ereignisobjekt enthält die Originaldaten, die an Logstash gesendet wurden, sowie alle zusätzlichen Felder, die während der Filterphasen von Logstash erstellt wurden. Sie können auf diese Felder über die Logstash Event API zugreifen, zum Beispiel über event.get() und event.set(). In diesem Beispielcode hat event.set('new_field', 'Hello from Ruby!') ein neues Feld mit dem Namen new_field auf den Zeichenkettenwert Hello from Ruby! gesetzt. Sie können bei Bedarf weiteren Code in diesen code -Block einfügen.

Beachten Sie, dass dieses event -Objekt kein gewöhnliches Ruby-Hash-Objekt ist, obwohl es als Datencontainer vom Typ Schlüssel-Wert fungiert. In dieser offiziellen Dokumentation erfahren Sie mehr über die Event-API.

Ruby-Skript auslagern

Für einfache Transformationen ist Inline-Ruby-Code praktisch. Für komplexe Logik oder wiederverwendbare Funktionen empfiehlt es sich jedoch, den Code in ein externes Ruby-Skript auszulagern. Dies verbessert die Wartbarkeit und sorgt für eine saubere Logstash-Pipeline-Konfiguration.

Zuerst erstellen Sie ein Ruby-Skript und speichern es unter dem Namen my_ruby_script.rb. Das Skript muss eine filter Methode definieren, die das Ereignis verarbeitet. Es benötigt ein Ereignisobjekt als Argument, das das aktuell verarbeitete Ereignis repräsentiert. Die Methode filter muss ein Array von Ereignissen zurückgeben, die ausgelöst werden sollen. Um das Ereignis zu verwerfen, geben Sie ein leeres Array zurück.

Das folgende Skript liest beispielsweise das Feld message , berechnet seine Länge und speichert das Ergebnis in einem neuen Feld namens message_length.

Als Nächstes muss die Ruby-Filterkonfiguration so eingestellt werden, dass sie mit der Option path auf das Skript verweist. Dies weist Logstash an, das externe Skript zu laden und auszuführen. Bei der Verwendung externer Skripte muss sichergestellt werden, dass die Datei existiert und über die korrekten Berechtigungen verfügt.

Nun wird jedes Ereignis an die Methode filter in my_ruby_script.rb übergeben und von dieser verarbeitet.

Dieser Ansatz hilft Ihnen, komplexe Logik effektiver zu handhaben und erleichtert so das Testen, Debuggen und Wiederverwenden Ihres Ruby-Codes.

Erweiterte Nutzung

In diesem Abschnitt werden wir einige fortgeschrittene Beispiele für die Verwendung des Ruby-Filters in Logstash untersuchen. Anhand dieser Beispiele wird demonstriert, wie man Datentransformationen durchführt, Ereignisse anreichert und benutzerdefinierte Logik mit Ruby implementiert.

Manipulation verschachtelter Datenstrukturen

Ein Logstash-Ereignis ist die zentrale Datenstruktur, die von Logstash verarbeitet wird. Es kann verschiedene Felder enthalten, darunter auch verschachtelte Datenstrukturen wie Arrays und Hashes. Der Ruby-Filter ermöglicht Ihnen die einfache Bearbeitung dieser verschachtelten Strukturen.

Der Ruby-Filter kann verschachtelte Datenstrukturen wie Hashes und Arrays verarbeiten und ermöglicht es Ihnen, Felder innerhalb dieser Strukturen zu ändern oder hinzuzufügen. Dies ist hilfreich beim Umgang mit komplexen Datenformaten wie JSON.

Dieses Beispiel enthält ein verschachteltes JSON-Objekt in den Eingabedaten. Der Ruby-Filter modifiziert die verschachtelten Daten, indem er ein neues Schlüssel-Wert-Paar hinzufügt. Diese Art der Manipulation von verschachtelten Daten ist mit den Standard-Logstash-Filtern nicht möglich, wodurch der Ruby-Filter eine praktische Option für komplexe Datenstrukturen darstellt.

Teile ein einzelnes Ereignis in mehrere Ereignisse auf

Ruby-Filter können auch verwendet werden, um ein einzelnes Ereignis in mehrere Ereignisse aufzuteilen. Dies ist nützlich, wenn Sie ein einzelnes Ereignis haben, das ein Array von Elementen enthält, und Sie für jedes Element ein separates Ereignis erstellen möchten.

Beachten Sie, dass weder die Ingest-Pipeline von Elasticsearch noch die Prozessoren von Beats/Elastic Agent das Aufteilen von Ereignissen unterstützen. Dies ist einer der überzeugendsten Anwendungsfälle für Logstash.

Mit geteiltem Filter

Mit dem Filter split können Sie ein Ereignis anhand eines bestimmten Feldes in mehrere Ereignisse aufteilen. Wenn Sie jedoch während der Aufteilung zusätzliche Transformationen oder Logik durchführen müssen, können Sie den Ruby-Filter in Kombination mit dem Split-Filter verwenden.

Im folgenden Beispiel haben wir einen RSS-Feed als einzeiligen XML-Text. Es enthält mehrere <item> -Elemente. Der Ruby-Filter dient dazu, die <item> -Elemente aus dem XML zu extrahieren und in einem neuen Feld namens items zu speichern. Anschließend wird der Split-Filter verwendet, um das Ereignis anhand des Feldes items in mehrere Ereignisse aufzuteilen.

Die Ausgabe lautet wie folgt:

Wie Sie vielleicht bemerkt haben, ist der ruby -Filter in diesem Fall nicht unbedingt erforderlich. Mit dem Filter split kann das Ereignis anhand des Feldes items in mehrere Ereignisse aufgeteilt werden, und mit dem Filter mutate können unnötige Felder entfernt werden. Wenn Sie jedoch während der Aufteilung zusätzliche Transformationen oder Logik durchführen müssen, können Sie den Ruby-Filter verwenden.

Verwenden Sie das Inline-Ruby-Skript.

Sie können auch ein Inline-Ruby-Skript verwenden, um ein einzelnes Ereignis in mehrere Ereignisse aufzuteilen, indem Sie die Methode event.clone und die Methode new_event_block variable verwenden, z. B. new_event_block.call(new_event). Dies ermöglicht es Ihnen, neue Ereignisse auf Basis des ursprünglichen Ereignisses zu erstellen und dabei dessen Daten zu erhalten.

Hier ist ein Beispiel, wie man den Ruby-Filter verwendet, um ein einzelnes Ereignis in mehrere Ereignisse aufzuteilen. Eingabe und Ausgabe sind die gleichen wie im vorherigen Beispiel.

Externes Ruby-Skript verwenden

Alternativ können Sie ein externes Ruby-Skript verwenden, um ein einzelnes Ereignis in mehrere Ereignisse aufzuteilen.

Konfigurationsdatei:

Das Ruby-Skript muss als split_event.rb externalisiert werden:

Denken Sie daran, dass die Methode filter ein Array von Ereignissen zurückgeben muss. Sie können mehrere Ereignisse zurückgeben, indem Sie ein eingehendes Ereignisobjekt klonen und die Ergebnisse dem Array hinzufügen, oder Sie können ein einzelnes Ereignis als Array mit einem Element zurückgeben.

Dies ermöglicht es Ihnen, ein einzelnes Ereignis in mehrere Ereignisse aufzuteilen.

Führe externe Befehle aus und analysiere deren Ausgabe.

Das Logstash exec input-Plugin ermöglicht die Ausführung externer Befehle, deren Ausgabe ein Logstash-Ereignis darstellt. Die Ausgabe des Befehls wird im Feld message des Ereignisses gespeichert.

Normalerweise sind die Ausgaben von Systembefehlen für Menschen lesbar, aber nicht als JSON oder in anderen Formaten strukturiert, die Logstash problemlos parsen kann. Um dies zu handhaben, können Sie den Ruby-Filter verwenden, um die Ausgabe zu analysieren und die Informationen daraus zu extrahieren.

Hier ist ein Beispiel für die Verwendung des exec -Input-Plugins zur Ausführung des ps -ef -Befehls, der alle laufenden Prozesse auf einem Unix-ähnlichen System auflistet. Die Ausgabe wird vom Ruby-Filter analysiert, um relevante Informationen über jeden Prozess zu extrahieren.

Dieses Beispiel verwendet das exec -Input-Plugin, um den ps -ef -Befehl alle 60 Sekunden auszuführen. Der Ruby-Filter verarbeitet die Ausgabe und extrahiert relevante Felder wie UID, PID, PPID, CPU-Auslastung (C), Startzeit (STIME), TTY, Gesamt-CPU-Zeit (TIME) und den ausgeführten Befehl (CMD). Auf meiner macOS-Umgebung funktioniert es einwandfrei, aber möglicherweise müssen Sie die Regex-Muster an das Ausgabeformat des Befehls ps -ef auf Ihrem System anpassen.

Verwenden Sie integrierte Bibliotheken

Das Ruby-Filter-Plugin ermöglicht die Verwendung integrierter Ruby-Bibliotheken, was für verschiedene Aufgaben sehr nützlich sein kann. Beispielsweise können Sie die json -Bibliothek zum Parsen von JSON-Zeichenketten oder die date -Bibliothek zum Bearbeiten von Datumsangaben verwenden.

Hier ist ein Beispiel für die Verwendung der json -Bibliothek zum Parsen einer in einem Feld gespeicherten JSON-Zeichenkette:

Um zu vermeiden, dass die Bibliothek jedes Mal neu geladen werden muss, sollten Sie Ihren Ruby-Code auslagern, damit Sie die require -Anweisung am Anfang Ihres Ruby-Filterskripts verwenden können. Dadurch wird die Bibliothek einmalig geladen und steht Ihnen anschließend in Ihrem Skript zur Verfügung.

Um zu überprüfen, welche Bibliotheken in Ihrer Umgebung verfügbar sind, können Sie die integrierten Bibliotheken auflisten, indem Sie den folgenden Code im Ruby-Filter ausführen:

Hinweis: Die integrierten Bibliotheken werden von Logstash nicht offiziell unterstützt, und ihr Verhalten kann sich ändern oder sie sind in zukünftigen Versionen möglicherweise nicht mehr verfügbar. Die Benutzung erfolgt auf eigene Gefahr.

Fazit

Mit dem Logstash Ruby-Filter können Sie die Funktionen Ihrer Logstash-Pipelines anpassen und erweitern. In diesem Beitrag haben wir die Grundlagen der Verwendung des Ruby-Filters behandelt und fortgeschrittene Anwendungsbeispiele vorgestellt.

Durch die Nutzung des Ruby-Filters können Sie komplexe Datenverarbeitungsaufgaben bewältigen, die benutzerdefinierte Logik oder fortgeschrittene Manipulationen erfordern. Egal ob Sie mit verschachtelten Datenstrukturen arbeiten, Ereignisse aufteilen oder komplexen/unstrukturierten Text in strukturiertes JSON parsen und konvertieren, der Ruby-Filter bietet die Flexibilität, Ihre spezifischen Anforderungen zu erfüllen.

Wir hoffen, dass Ihnen dieser Leitfaden das Wissen und die Inspiration vermittelt hat, das volle Potenzial des Logstash Ruby-Filters auszuschöpfen. Viel Spaß beim Skripten!

1. Verwendung der _mapping API zum Abrufen von Feldinformationen

2. Verwendung der _search API zum Anzeigen von Feldwerten

3. Filtern von Feldern mithilfe des Parametersfields

4. Verschachtelte Felder anzeigen

1. Verwendung der _mapping-API zum Abrufen von Feldinformationen

Die _mapping API ermöglicht es Ihnen, die Mapping-Definition für einen oder mehrere Indizes abzurufen. Dies umfasst Informationen über die Felder, ihre Datentypen und weitere Eigenschaften. Um die Zuordnung für einen bestimmten Index abzurufen, verwenden Sie die folgende Anfrage:

Wenn Sie beispielsweise einen Index mit dem Namen my_index haben, können Sie dessen Zuordnung mit der folgenden Anfrage abrufen:

Die Antwort enthält die Mapping-Definition für den Index, die Informationen über die Felder und deren Eigenschaften enthält.

Es ist auch möglich, die Zuordnung eines bestimmten Feldes abzurufen. Dies kann nützlich sein, wenn Ihre Kartierung recht umfangreich ist und Sie sich nur auf ein bestimmtes Feld konzentrieren möchten. Um die Zuordnung eines bestimmten Feldes abzurufen, verwenden Sie die folgende Anfrage:

Sie können die Zuordnungen mehrerer Felder auch abrufen, indem Sie deren Namen durch Kommas trennen, wie in der folgenden Anfrage:

2. Verwenden der _search-API zum Anzeigen von Feldwerten

Um die Werte von Feldern in einem Elasticsearch-Index anzuzeigen, können Sie die _search API verwenden. Standardmäßig gibt die _search API das Feld _source zurück, welches das ursprüngliche JSON-Dokument enthält, das indiziert wurde. Um nur bestimmte Felder anzuzeigen, können Sie den Parameter _source in der Suchanfrage verwenden.

Hier ist ein Beispiel für eine Suchanfrage, die die Werte der Felder title und author für Dokumente im Index my_index zurückgibt:

In diesem Beispiel gibt der Parameter _source die zurückzugebenden Felder an.

3. Filtern von Feldern mithilfe des Parameters „fields“

Sie können auch den Parameter fields verwenden, um die in der Suchantwort zurückgegebenen Felder zu filtern. Dies kann nützlich sein, wenn Sie nur bestimmte Felder benötigen und die Größe der Antwort reduzieren möchten. Der Parameter fields akzeptiert ein Array von Feldnamen oder Platzhaltermustern.

Um beispielsweise nur die Felder title und author für Dokumente im Index my_index zurückzugeben, können Sie die folgende Suchanfrage verwenden:

Beachten Sie, dass der Parameter _source auf false gesetzt ist, um das Quelldokument nicht zurückzugeben.

Um alle Felder mit dem Datentyp text zurückzugeben, können Sie ein Wildcard-Muster wie dieses verwenden:

4. Anzeigen verschachtelter Felder

Wenn Ihr Index verschachtelte Felder enthält, können Sie die Punktnotation verwenden, um den Pfad des verschachtelten Feldes im Parameter fields anzugeben. Wenn Sie beispielsweise ein verschachteltes Feld mit dem Namen address.city haben, können Sie es wie folgt in die Suchergebnisseinlösung einbinden:

In diesem Beispiel enthält die Suchergebnisseinsendung die Werte der Felder title, author und address.city .

Fazit

Zusammenfassend lässt sich sagen, dass die Anzeige von Feldern in einem Elasticsearch-Index durch die Verwendung der _mapping -API zum Abrufen von Feldinformationen und der _search -API zum Anzeigen von Feldwerten erreicht werden kann. Sie können die in der Suchantwort zurückgegebenen Felder entweder mit den Parametern _source oder fields filtern und verschachtelte Felder mit der Punktnotation anzeigen. Mithilfe dieser Techniken können Sie die Struktur Ihrer Daten verstehen, bestimmte Felder identifizieren und Probleme beheben.

In diesem Artikel werden wir die Gründe für den Ausschluss von Feldern aus der Indizierung, die Konfiguration von Elasticsearch zum Ausschluss bestimmter Felder und einige bewährte Vorgehensweisen dabei erläutern.

Gründe für den Ausschluss von Feldern aus der Indizierung

1. Leistung: Die Indizierung aller Felder in einem Dokument kann zu längeren Indizierungszeiten und einer langsameren Suchleistung führen. Durch den Ausschluss von Feldern, die für die Suche oder Aggregation nicht erforderlich sind, können Sie die Gesamtleistung Ihres Elasticsearch-Clusters verbessern.

2. Speicherplatz: Das Indizieren von Feldern benötigt Speicherplatz. Durch das Ausschließen von Feldern, die für die Suche oder Aggregation nicht benötigt werden, können die Speicheranforderungen Ihres Elasticsearch-Clusters reduziert werden.

3. Indexgröße: Die Größe eines Elasticsearch-Index steht in direktem Zusammenhang mit der Anzahl der indizierten Felder. Durch den Ausschluss unnötiger Felder können Sie die Größe Ihres Index minimieren, was zu einer schnelleren Such- und Indexierungsleistung führen kann.

Elasticsearch so konfigurieren, dass Felder ausgeschlossen werden

Um ein Feld von der Indizierung in Elasticsearch auszuschließen, können Sie die „index“-Eigenschaft in der Feldzuordnung verwenden. Wenn die Eigenschaft „index“ auf „false“ gesetzt wird, wird Elasticsearch das Feld nicht indizieren, und es ist weder durchsuchbar noch für Aggregationen verfügbar.

Hier ist ein Beispiel dafür, wie man ein Feld mithilfe des Elasticsearch-Mappings von der Indizierung ausschließt:

In diesem Beispiel erstellen wir einen neuen Index namens „my_index“ mit einem einzigen Feld namens „field_to_exclude“. Indem wir die Eigenschaft „index“ auf „false“ setzen, weisen wir Elasticsearch an, dieses Feld nicht zu indizieren. Das Feld wird jedoch im Quelldokument weiterhin verfügbar sein.

Bewährte Verfahren zum Ausschließen von Feldern von der Indizierung

1. Analysieren Sie Ihre Daten: Bevor Sie Felder von der Indizierung ausschließen, ist es unerlässlich, Ihre Daten zu analysieren und zu verstehen, welche Felder für die Suche und Aggregation notwendig sind. Dies wird Ihnen helfen, fundierte Entscheidungen darüber zu treffen, welche Felder ausgeschlossen werden sollen.

2. Testen Sie Ihre Änderungen: Wenn Sie Felder von der Indizierung ausschließen, ist es unerlässlich, Ihre Änderungen zu testen, um sicherzustellen, dass Ihre Such- und Aggregationsfunktionen weiterhin wie erwartet funktionieren. Dies kann Ihnen helfen, unerwartete Probleme oder Leistungsstörungen zu vermeiden.

3. Leistungsüberwachung: Nachdem Sie Felder von der Indizierung ausgeschlossen haben, sollten Sie die Leistung Ihres Elasticsearch-Clusters überwachen, um sicherzustellen, dass Ihre Änderungen den gewünschten Effekt erzielt haben. Dies kann Ihnen dabei helfen, eventuell erforderliche zusätzliche Optimierungen zu identifizieren.

4. Quellfilterung nutzen: Wenn Sie ein Feld in Elasticsearch speichern müssen, es aber nicht durchsuchbar oder für Aggregationen verfügbar sein soll, sollten Sie die Quellfilterung in Betracht ziehen. Dies ermöglicht es Ihnen, das Feld im Feld _source zu speichern, es aber vom Index auszuschließen.

Fazit

Das Ausschließen von Feldern von der Indizierung in Elasticsearch kann die Leistung verbessern, die Speicherkosten senken und die Gesamtgröße Ihres Index minimieren. Durch eine sorgfältige Analyse Ihrer Daten und das Verständnis, welche Felder für die Suche und Aggregation notwendig sind, können Sie fundierte Entscheidungen darüber treffen, welche Felder ausgeschlossen werden sollten. Testen Sie Ihre Änderungen stets und überwachen Sie die Leistung Ihres Elasticsearch-Clusters, um sicherzustellen, dass Ihre Optimierungen den gewünschten Effekt erzielen.

• Mapping-Definitionen legen das Datenschema fest.

• In den Einstellungen werden die Shard-Größe und die Aktualisierungsraten festgelegt. 

• Aliase werden verwendet, um dem Index alternative Namen zu geben.

Wenn wir ein Dokument zum ersten Mal indexieren oder einen leeren Index mithilfe der Create Index API erstellen, wird der Index mit Standardeinstellungen, ohne Datenschema und ohne Aliase erstellt. Diese Standardeinstellungen funktionieren in Entwicklungs- und Testumgebungen recht gut, aber für Produktionsumgebungen müssen wir unsere Indizes möglicherweise anpassen.

Die Verwendung der Standardzuordnungen und -einstellungen in der Produktionsumgebung kann zu einer schlechten Indexierungs- und Suchleistung führen. Das manuelle Erstellen von Indizes ist ein mühsamer und zeitaufwändiger Prozess. Die Neuerstellung solcher Indizes in jeder Umgebung ist besonders unpraktisch, wenn wir ein aufwendiges Mapping-Schema sowie benutzerdefinierte Einstellungen und Aliase haben.

Glücklicherweise stellt Elasticsearch uns ein Werkzeug zur Verfügung, mit dem wir beim Erstellen von Indizes automatisch eine vordefinierte Konfiguration in Form von Indexvorlagen anwenden können .

Indexvorlagen

Indexvorlagen ermöglichen es uns, Indizes mit benutzerdefinierter Konfiguration zu erstellen. Ein Index kann die Konfiguration aus diesen Vorlagen abrufen, beispielsweise eine festgelegte Anzahl von Shards und Replikaten oder Feldzuordnungen, während seiner Instanziierung. Es wird eine Vorlage mit einem Namensmuster und einigen Konfigurationseinstellungen definiert. Wenn der Name des Index mit dem Namensmuster der Vorlage übereinstimmt, wird der neue Index mit der in der Vorlage definierten Konfiguration erstellt.

Elasticsearch hat in Version 7.8 seine Template-Funktionalität mit zusammensetzbaren Templates verbessert. Diese neuere Version bietet wesentlich mehr wiederverwendbare Indexvorlagen, wie in diesem Artikel gezeigt wird.

Arten von Indexvorlagen

Indexvorlagen lassen sich in zwei Kategorien einteilen:

• Indexvorlagen (oder zusammensetzbare Indexvorlagen): Die zusammensetzbaren Indexvorlagen können entweder allein existieren oder aus keiner oder mehreren Komponentenvorlagen zusammengesetzt sein (siehe die zweite Kategorie).

• Komponentenvorlagen: Die Komponentenvorlage ist eine wiederverwendbare Vorlage, die die erforderliche Konfiguration definiert. Üblicherweise wird erwartet, dass die Komponentenvorlage mit einer Indexvorlage verknüpft ist. Jede der Komponentenvorlagen kann mit einer oder mehreren Indexvorlagen verknüpft werden. 

Wie Sie im Bild unten sehen können, teilen sich die Indexvorlagen A und B Komponentenvorlagen (in diesem Fall nur eine – Vorlage 3). Eine Indexvorlage kann aus keiner oder mehreren Komponentenvorlagen bestehen, und jede der Komponentenvorlagen kann keiner oder mehreren Indexvorlagen zugeordnet sein. Beide Arten von Vorlagen können eigenständig existieren, jedoch sind Komponentenvorlagen nur dann nützlich, wenn sie an eine Indexvorlage angehängt werden.

Die Grundidee besteht darin, einen Katalog von Komponentenvorlagen zu entwickeln, die eine Organisation für verschiedene Zwecke nutzen kann (z. B. die verschiedenen Komponentenvorlagen für einzelne Umgebungen festlegen) und diese über die zusammensetzbaren Indexvorlagen verschiedenen Indizes zuzuordnen.

Wie man zusammensetzbare (Index-)Vorlagen erstellt

Elasticsearch bietet einen _index_template-Endpunkt zur Verwaltung von Indexvorlagen. Der Benutzer gibt in dieser Vorlage alle erforderlichen Zuordnungen, Einstellungen und Aliase sowie ein Indexnamensmuster an. Betrachten wir ein Beispiel für die Erstellung einer Vorlage für eine Microservice-Anwendung namens customer-order-service , die für die Logik zur Auftragsgenerierung zuständig ist. 

Nehmen wir an, unsere Anforderung ist es, eine Vorlage für Kundenbestellungen zu erstellen, die durch ein Muster mit Platzhaltern dargestellt wird: *orders. Diese Vorlage muss bestimmte Zuordnungen und Einstellungen enthalten, wie zum Beispiel das Feld order_date sowie Shard- und Replikatnummern.

Jeder Index, der bei seiner Erstellung mit dieser Vorlage übereinstimmt, erbt die in dieser Vorlage definierten Konfigurationen. Ein Index namens black_friday_orders beispielsweise hat das Feld order_date, die Anzahl der Shards ist auf 5 und die Anzahl der Replikate auf 2 festgelegt. Darüber hinaus erben alle aus dieser Vorlage erstellten Indizes auch einen einzigen Aliasnamen ! Erstellen wir nun diese orders_template mit einem Indexmuster, das als *orders definiert ist, und einem Mapping-Schema, das aus einem einzigen Feld der_date mit dem vordefinierten Datumsformat dd-MM-yyyy besteht. Der folgende Code zeigt, wie diese Indexvorlage erstellt wird.

Wenn Sie diese Abfrage in den Kibana DevTools ausführen, wird die Vorlage mit dem Indexmuster *orders zusammen mit dem vordefinierten Mapping, den Einstellungen und einem Alias erstellt. index_patterns ist ein Array von Übereinstimmungsmustern; jeder Index, der diesem Muster entspricht, leitet die Vorlagenkonfiguration ab. Sie können folgenden Befehl ausführen, um die gespeicherte Vorlage abzurufen, die unsere Aktionen wiederholen sollte:

Außerdem wird beim Erstellen des Vorlagenattributs, das in der Vorlage definiert ist, eine Priorität, eine positive Zahl, festgelegt: Jede Vorlage wird mit einer Priorität definiert, sodass etwaige Konflikte zwischen Änderungen aus verschiedenen Vorlagen durch Verwendung dieses Wertes aufgelöst werden, wobei dem Wert mit der höheren Priorität Vorrang eingeräumt wird. Wir werden uns weiter unten eingehender mit der Priorisierung von Vorlagen befassen.

Erstellen eines Index mit der Vorlage

Jetzt haben wir eine Vorlage – einen Bauplan für die Erstellung von Indizes – der nächste Schritt ist die Erstellung eines Indexes. Wenn der Name des Index mit dem angegebenen Muster übereinstimmt, werden die Vorlagenkonfigurationen automatisch angewendet. Um dies zu beweisen, erstellen wir, wie der folgende Code zeigt, einen brandneuen Index mit dem Namen: blackfriday_orders:

Da der Name des Index (blackfriday_orders) mit dem im Template definierten Namensmuster übereinstimmt (d. h. *orders), sollte der Index alle aus der Vorlage abgeleiteten Konfigurationen erhalten. Lassen Sie uns diesen neu erstellten Index abrufen und überprüfen, ob dies tatsächlich zutrifft, indem wir den folgenden Code ausführen:

Dies sollte folgendes Ergebnis liefern:

Wie die Antwort zeigt, wurde die Konfiguration von blackfriday_orders aus der Vorlage übernommen. Wir können verschiedene Kombinationen der Indizes ausprobieren, die die Vorlagenkonfiguration erfolgreich übernehmen:

Die folgenden Indizes werden die Konfiguration jedoch nicht übernehmen, da ihr Name nicht dem Muster entspricht:

Wichtig zu beachten ist, dass alle von einer Vorlage abgeleiteten Indizes in diesem Fall denselben Alias haben – all_orders. Ein solcher Alias hat den Vorteil, dass wir einfach über diesen einen Alias anstatt über mehrere Indizes abfragen können.

Während wir eine Vorlage für *orders erstellen, wird erwartet, dass jeder übereinstimmende Index die Konfiguration der Vorlage übernimmt. In der Regel erstellen Teams, bewusst oder unbewusst, aus verschiedenen Gründen einige zusätzliche Vorlagen. Das bedeutet, dass der Indexname unter Umständen mit zwei verschiedenen Vorlagenmustern übereinstimmen kann! Elasticsearch muss entscheiden, welche der Konfigurationen aus diesen Vorlagen angewendet werden soll. Glücklicherweise lässt sich dieses Dilemma durch die Verwendung der Vorlagenpriorität lösen.

Erstellung von Komponentenvorlagen

Wir haben im vorangegangenen Teil dieses Artikels etwas über Indexvorlagen gelernt. Es gibt ein paar Nachteile bei der Erstellung der Vorlagen mit integrierter Konfiguration – einer dieser Nachteile ist, dass die Konfiguration nicht für andere Vorlagen exportiert werden kann. Wenn wir eine ähnliche Konfiguration wünschen, beispielsweise für kundenbezogene Vorlagen (*customers), müssen wir möglicherweise die gesamte Vorlage neu erstellen. Das bedeutet, dass wir in einer typischen Organisation Dutzende davon erstellen (und je nach Umgebung können noch einige weitere hinzukommen).

Da wir stets auf Wiederverwendbarkeit Wert legen, hat Elasticsearch die Templates unter Berücksichtigung der Wiederverwendbarkeit neu gestaltet. Die Komponentenvorlagen erfüllen diese Anforderung. Wenn Sie aus dem DevOps-Bereich kommen, besteht für Sie höchstwahrscheinlich die Anforderung, Indizes mit einer vordefinierten Konfiguration für jede Umgebung zu erstellen. Anstatt jede dieser Konfigurationen mühsam manuell anzuwenden, können Sie für jede Umgebung eine Komponentenvorlage erstellen.

Eine Komponentenvorlage ist nichts anderes als ein wiederverwendbarer Konfigurationsblock, mit dem wir weitere Indexvorlagen erstellen können. Beachten Sie, dass die Komponentenvorlagen nur dann einen Nutzen haben, wenn sie mit Indexvorlagen kombiniert werden. Sie werden über einen _component_template-Endpunkt bereitgestellt. Mal sehen, wie das alles zusammenpasst.

Einstellungen in einer Indexvorlage

Lassen Sie uns die Einstellungen, die wir zuvor in unserer Indexvorlage definiert haben, extrahieren und daraus eine Komponentenvorlage erstellen. Es wird erwartet, dass die settings_component_template fünf primäre Shards mit jeweils zwei Replikaten pro primärem Shard besitzt. Der erste Schritt besteht, wie die untenstehende Codeauflistung zeigt, darin, eine Komponentenvorlage mit dieser Konfiguration zu deklarieren und auszuführen.

Wie der obige Code zeigt, verwenden wir den Endpunkt _component_template, um eine Komponentenvorlage zu erstellen. Der Anfragetext enthält die Vorlageninformationen in einem Vorlagenobjekt. Die settings_component_template kann nun auch an anderer Stelle in den Indexvorlagen verwendet werden. Ein wesentlicher Unterschied besteht darin, dass diese Vorlage kein Indexmuster definiert; es handelt sich lediglich um einen Codeblock, der einige Eigenschaften für uns konfiguriert.

Mapping-Vorlage

Erstellen wir auf die gleiche Weise eine weitere Vorlage. Dieses Mal extrahieren wir das Mapping-Schema, das wir zuvor in den eigenständigen Indexvorlagen definiert hatten. Der folgende Code zeigt das Skript:

Aliasvorlage

Im gleichen Sinne können wir auch eine Komponentenvorlage mit den Aliasen haben – zwei Aliase (all_orders und sales_orders):

Vorlage für einen zusammensetzbaren Index

Nachdem wir nun diese drei Komponentenvorlagen haben, besteht der nächste Schritt darin, sie einzusetzen. Wir können dies erreichen, indem wir eine Indexvorlage, beispielsweise für christmas_orders, diese verwenden lassen:

Das `composed_of`-Tag ist eine Sammlung aller Komponentenvorlagen, aus denen diese Vorlage besteht. In diesem Fall wählen wir die Komponentenvorlagen für Einstellungen, Zuordnungen und Aliase aus. Wir erhöhen außerdem die Priorität, sodass diese Vorlage alle anderen übertrifft. Sobald die Vorlage fertig ist, erben alle Indizes, die dem Muster *orders entsprechen, die Konfiguration von diesen drei Komponentenvorlagen.

Wenn wir nun eine neue Vorlage, beispielsweise für Kunden, mit nur einer der bestehenden Vorlagen (settings_component_template) und einer neu erstellten Aliasvorlage (aliases_component_template – siehe unten) erstellen möchten, können wir dies wie folgt tun:

Die Indexvorlage sieht folgendermaßen aus:

Ist Ihnen aufgefallen, dass die settings_component_template in zwei verschiedenen Templates (wieder)verwendet wurde? Das ist die Stärke von Komponentenvorlagen.

Indexvorlagenpriorität

Es besteht die Möglichkeit, dass Entwickler mehrere Indexvorlagen erstellen, ohne den vorhandenen Bestand zu berücksichtigen. Es ist wichtig, jeder dieser Vorlagen eine Priorität zuzuweisen, damit diejenige mit der höheren Priorität verwendet wird. Beispielsweise überschreibt my_orders_template_1 im folgenden Codeausschnitt my_orders_template_2:

Wenn mehrere Vorlagen zu den zu erstellenden Indizes passen, wendet Elasticsearch alle Konfigurationen aus allen passenden Vorlagen an, überschreibt aber alle Konfigurationen mit höherer Priorität.

Priorität der Vorlagen

Abschließend stellt sich vielleicht die Frage nach der Priorität der Vorlagen – überschreibt die in der Komponentenvorlage definierte Konfiguration diejenige, die in der Hauptindexvorlage selbst definiert ist? Oder umgekehrt? Nun ja, es gibt einige Regeln:

• Ein Index, der mit expliziten Konfigurationen erstellt wurde, hat Vorrang vor allem anderen – das bedeutet, wenn Sie einen Index mit expliziten Konfigurationen erstellen, können Sie nicht davon ausgehen, dass diese von den Vorlagen überschrieben werden.

• Legacy-Vorlagen (Vorlagen, die vor Version 7.8 erstellt wurden) haben eine niedrigere Priorität als die zusammensetzbaren Vorlagen.

Zusammenfassung

• Ein Index enthält Mappings, Einstellungen und Aliase: Die Mappings definieren das Feldschema, die Einstellungen legen die Indexparameter wie die Anzahl der Shards und Replikate fest, und die Aliase geben dem Index alternative Namen.

• Mithilfe von Vorlagen können wir Indizes mit vordefinierten Konfigurationen erstellen. Wenn ein Index mit einem Namen benannt wird, der dem in einer bestimmten Vorlage definierten Indexmuster entspricht, wird dieser Index automatisch gemäß der Vorlage konfiguriert.

• Elasticsearch führte in Version 7.8 zusammensetzbare Indexvorlagen ein. Zusammensetzbare Indexvorlagen ermöglichen Modularität und Versionierung von Vorlagen.

• Die zusammensetzbaren Vorlagen bestehen aus keiner oder mehreren Komponentenvorlagen.

• Eine Indexvorlage kann auch über eine eigene Konfiguration verfügen.

• Eine Komponentenvorlage ist eine wiederverwendbare Vorlage mit vordefinierter Konfiguration, genau wie eine zusammensetzbare Indexvorlage.

• Allerdings wird von Komponentenvorlagen erwartet, dass sie Teil einer Indexvorlage sind; sie sind nutzlos, wenn sie nicht in eine Indexvorlage „zusammengesetzt“ werden.

• Komponentenvorlagen haben kein definiertes Indexmuster – was ein weiterer Grund dafür ist, dass sie „erwartet“ werden, Teil einer Indexvorlage zu sein.

• Jede der Vorlagen hat eine Priorität – eine positive Zahl. Je höher die Zahl, desto höher ist die Priorität für die Anwendung dieser Vorlage.

In diesem Artikel erklären wir, wie Sie Airbyte für die Datenaufnahme in Elasticsearch konfigurieren. Dabei gehen wir auf wichtige Konzepte, Voraussetzungen und die schrittweise Integration ein.

Grundkonzepte von Airbyte

Airbyte basiert auf mehreren grundlegenden Nutzungskonzepten. Im Folgenden heben wir die wichtigsten hervor:

• Quellen: Definiert den Ursprung der zu extrahierenden Daten.

• Ziele: Definiert, wohin die Daten gesendet und gespeichert werden.

• Verbindungen: Konfiguriert die Beziehung zwischen Quelle und Ziel, einschließlich der Synchronisierungsfrequenz.

Airbyte-Integration mit Elasticsearch

In dieser Demonstration führen wir eine Integration durch, bei der Daten, die in einem S3-Bucket gespeichert sind, in einen Elasticsearch-Index migriert werden. Wir zeigen Ihnen, wie Sie die Quelle (S3) und das Ziel (Elasticsearch) in Airbyte konfigurieren.

Voraussetzungen

Um dieser Demonstration folgen zu können, müssen folgende Voraussetzungen erfüllt sein:

1. Erstellen Sie einen Bucket in AWS, in dem die JSON-Dateien mit den Daten gespeichert werden.

2. Installieren Sie Airbyte lokal mit Docker.

3. Erstellen Sie einen Elasticsearch-Cluster in Elastic Cloud, um die aufgenommenen Daten zu speichern.

Im Folgenden werden wir jeden dieser Schritte detailliert beschreiben.

Airbyte installieren

Airbyte kann lokal mit Docker oder in der Cloud ausgeführt werden, wobei mit der Nutzung Kosten verbunden sind. Für diese Demonstration verwenden wir die lokale Version mit Docker.

Die Installation kann einige Minuten dauern. Nach Befolgung der Installationsanweisungen ist Airbyte unter folgender Adresse erreichbar: http://localhost:8000.

Nach dem Einloggen können wir mit der Konfiguration der Integration beginnen.

Erstellen des Buckets

In diesem Schritt benötigen Sie ein AWS-Konto, um einen S3-Bucket zu erstellen. Darüber hinaus ist es unerlässlich, die korrekten Berechtigungen festzulegen, indem eine Richtlinie und ein IAM-Benutzer erstellt werden, um den Zugriff auf den Bucket zu ermöglichen.

In den Bucket laden wir JSON-Dateien mit verschiedenen Log-Einträgen hoch, die später zu Elasticsearch migriert werden. Die Dateiprotokolle haben folgenden Inhalt:

Nachfolgend sind die in den Bucket geladenen Dateien aufgeführt:

Elastic Cloud-Konfiguration

Um die Demonstration zu vereinfachen, verwenden wir Elastic Cloud. Falls Sie noch kein Konto besitzen, können Sie hier ein kostenloses Testkonto erstellen: Elastic Cloud-Registrierung.

Nach der Konfiguration der Bereitstellung in Elastic Cloud benötigen Sie Folgendes:

• Die URL des Elasticsearch-Servers.

• Ein Benutzer, der auf Elasticsearch zugreifen kann.

Um die URL zu erhalten, gehen Sie zu Deployments > My deployment, suchen Sie unter Anwendung nach Elasticsearch und klicken Sie auf 'Endpunkt kopieren'.

Um den Benutzer anzulegen, befolgen Sie die folgenden Schritte:

1. Zugriff auf Kibana > Stack-Management > Benutzer.

2. Erstellen Sie einen neuen Benutzer mit der Rolle des Superusers.

3. Füllen Sie die Felder aus, um den Benutzer zu erstellen.

Nachdem wir nun alles eingerichtet haben, können wir mit der Konfiguration der Konnektoren in Airbyte beginnen.

Quellanschluss konfigurieren

In diesem Schritt erstellen wir den Quellkonnektor für S3. Dazu rufen wir die Airbyte-Benutzeroberfläche auf und wählen im Menü die Option „Quelle“ aus. Als Nächstes suchen wir nach dem S3-Anschluss. Im Folgenden beschreiben wir die erforderlichen Schritte zur Konfiguration des Konnektors:

1. Öffnen Sie Airbyte und gehen Sie zum Menü „Quellen“.

2. Suchen und wählen Sie den S3-Anschluss aus.

3. Konfigurieren Sie die folgenden Parameter:

   1. Quellname: Geben Sie einen Namen für die Datenquelle an.

   2. Zustellungsmethode: Datensätze replizieren (empfohlen für strukturierte Daten).

   3. Datenformat: Wählen Sie das JSON-Format.

   4. Stream-Name: Definieren Sie den Namen des Index in Elasticsearch.

   5. Bucket-Name: Geben Sie den Namen des Buckets in AWS ein.

   6. AWS-Zugriffsschlüssel und AWS-Geheimschlüssel: Geben Sie die Zugangsdaten ein.

Klicken Sie auf „Quelle einrichten“ und warten Sie auf die Validierung.

Konfigurationszielkonnektor

In diesem Schritt konfigurieren wir den Zielkonnektor, und zwar Elasticsearch. Dazu rufen wir das Menü auf und wählen die Option „Ziel“. Anschließend suchen wir nach Elasticsearch und klicken auf das angezeigte Ergebnis. Nun fahren wir mit der Konfiguration dieser Verbindung fort:

1. Öffnen Sie Airbyte und gehen Sie zum Menü „Ziele“.

2. Suchen und wählen Sie den Elasticsearch-Connector aus.

3. Konfigurieren Sie die folgenden Parameter:

   1. Authentifizierungsmethode: Benutzername/Passwort auswählen.

   2. Benutzername und Passwort: Verwenden Sie die in Kibana erstellten Zugangsdaten.

   3. Server-Endpunkt: Fügen Sie die aus Elastic Cloud kopierte URL ein.

Klicken Sie auf „Ziel einrichten“ und warten Sie auf die Bestätigung.

Erstellen der Quell- und Zielverbindung

Sobald Quelle und Ziel erstellt sind, wird die Verbindung zwischen ihnen hergestellt, womit die Integration abgeschlossen ist.

Nachfolgend finden Sie die Anweisungen zum Herstellen der Verbindung:

1. Im Menü gehen Sie zu Verbindungen und klicken Sie auf Erste Verbindung erstellen.

2. Im nächsten Bildschirm können Sie eine bestehende Quelle auswählen oder eine neue erstellen. Da wir bereits eine Quelle erstellt haben, wählen wir Quelle S3 aus.

3. Im nächsten Schritt muss das Reiseziel ausgewählt werden. Da wir den Elasticsearch-Connector bereits erstellt haben, wird dieser zur Vervollständigung der Konfiguration ausgewählt.

Im nächsten Schritt muss der Synchronisierungsmodus und das zu verwendende Schema definiert werden. Da nur das Protokollschema erstellt wurde, ist dies die einzige auswählbare Option.

4. Wir fahren nun mit dem Schritt „Verbindung konfigurieren“ fort. Hier können wir den Namen der Verbindung und die Häufigkeit der Integrationsausführung festlegen. Die Frequenz kann auf drei Arten konfiguriert werden:

• Cron: Führt die Synchronisierungen gemäß dem benutzerdefinierten Cron-Ausdruck aus (z. B. 0 0 15 * * ?, Jeden Tag um 15:00 Uhr);

• Geplant: Führt die Synchronisierungen im angegebenen Zeitintervall aus (z. B. alle 24 Stunden, alle 2 Stunden);

• Manuell: Synchronisierungen manuell ausführen.

Für diese Demonstration wählen wir die Option „Manuell“.

Durch Klicken auf „Verbindung einrichten“ wird abschließend die Verbindung zwischen Quelle und Ziel hergestellt.

Synchronisierung von Daten von S3 zu Elasticsearch

Wenn Sie zum Bildschirm „Verbindungen“ zurückkehren, können Sie die erstellte Verbindung sehen. Um den Vorgang auszuführen, klicken Sie einfach auf Synchronisieren. Ab diesem Zeitpunkt beginnt die Migration der Daten von S3 zu Elasticsearch.

Wenn alles reibungslos verläuft, erhalten Sie den Synchronisierungsstatus.

Datenvisualisierung in Kibana

Nun werden wir zu Kibana wechseln, um die Daten zu analysieren und zu überprüfen, ob sie korrekt indiziert wurden. Im Abschnitt „Kibana Discovery“ erstellen wir eine Datenansicht namens „logs“. Damit können wir die Daten untersuchen, die nur im Protokollindex vorhanden sind, der nach der Synchronisierung erstellt wurde.

Nun können wir die indizierten Daten visualisieren und Analysen daran durchführen. Auf diese Weise haben wir den gesamten Migrationsablauf mit Airbyte validiert, wo wir die im Bucket vorhandenen Daten geladen und in Elasticsearch indiziert haben.

Fazit: Integration von Airbyte und Elasticsearch

Airbyte erwies sich als effizientes Werkzeug zur Datenintegration, mit dem wir mehrere Quellen und Ziele automatisiert verbinden konnten. In diesem Tutorial haben wir gezeigt, wie man Daten aus einem S3-Bucket in einen Elasticsearch-Index einliest, und dabei die wichtigsten Schritte des Prozesses hervorgehoben.

Dieser Ansatz erleichtert die Aufnahme großer Datenmengen und ermöglicht Analysen innerhalb von Elasticsearch, wie z. B. komplexe Suchvorgänge, Aggregationen und Datenvisualisierungen.

Referenzen

Quickstart Airbyte:

https://docs.airbyte.com/using-airbyte/getting-started/oss-quickstart#part-1-install-abctl

Kernkonzepte:

https://docs.airbyte.com/using-airbyte/core-concepts/

Was ist LlamaIndex?

LlamaIndex ist ein Framework, das die Erstellung von Agenten und Workflows erleichtert, die auf großen Sprachmodellen (LLMs) basieren und mit spezifischen oder privaten Daten interagieren. Es ermöglicht die Integration von Daten aus verschiedenen Quellen (APIs, PDFs, Datenbanken) in LLMs und ermöglicht so Aufgaben wie Recherche, Informationsgewinnung und die Generierung kontextbezogener Antworten.

Schlüsselkonzepte:

• Agenten: Intelligente Assistenten, die LLMs verwenden, um Aufgaben auszuführen, die von einfachen Antworten bis hin zu komplexen Aktionen reichen.

• Workflows: Mehrstufige Prozesse, die Agenten, Datenkonnektoren und Tools für fortgeschrittene Aufgaben kombinieren.

• Kontexterweiterung: Eine Technik, die das LLM mit externen Daten anreichert und so seine Trainingsbeschränkungen überwindet.

LlamaIndex- Integration mit Elasticsearch:

Elasticsearch kann auf verschiedene Weise mit LlamaIndex verwendet werden:

• Datenquelle: Verwenden Sie den Elasticsearch Reader, um Dokumente zu extrahieren.

• Einbettungsmodell: Daten werden für semantische Suchen in Vektoren kodiert.

• Vektorspeicherung: Verwenden Sie Elasticsearch als Repository für die Suche nach vektorisierten Dokumenten.

• Erweiterter Speicher: Konfigurieren Sie Strukturen wie Dokumentzusammenfassungen oder Wissensgraphen.

Verwendung von LlamaIndex und Elasticsearch zum Erstellen einer FAQ-Suche

Datenaufbereitung

Wir werden die FAQ zum Elasticsearch-Dienst als Beispiel verwenden. Jede Frage wurde von der Webseite extrahiert und in einer separaten Textdatei gespeichert. Sie können jeden beliebigen Ansatz zur Organisation der Daten verwenden; in diesem Beispiel haben wir uns dafür entschieden, die Dateien lokal zu speichern.

Beispieldatei:

Nach dem Speichern aller Fragen sieht das Verzeichnis folgendermaßen aus:

Installation der Abhängigkeiten

Die Datenerfassung und -suche werden wir mit Hilfe der Programmiersprache Python implementieren; ich habe Version 3.9 verwendet. Als Voraussetzung müssen die folgenden Abhängigkeiten installiert werden:

Elasticsearch und Kibana werden mit Docker erstellt und über docker-compose.yml so konfiguriert, dass sie in Version 8.16.2 ausgeführt werden. Dadurch wird die Schaffung der lokalen Umgebung erleichtert.

Dokumentenaufnahme mit LlamaIndex

Die Dokumente werden mithilfe von LlamaIndex in Elasticsearch indexiert. Zuerst laden wir die Dateien mit SimpleDirectoryReader, das das Laden von Dateien aus einem lokalen Verzeichnis ermöglicht. Nach dem Laden der Dokumente werden wir sie mithilfe des VectorStoreIndex indizieren.

Die Vektorspeicher in LlamaIndex sind für das Speichern und Verwalten von Dokumenteneinbettungen zuständig. LlamaIndex unterstützt verschiedene Arten von Vektorspeichern, und in diesem Fall verwenden wir Elasticsearch. Im StorageContext konfigurieren wir die Elasticsearch-Instanz. Da der Kontext lokal ist, waren keine zusätzlichen Parameter erforderlich. Für Konfigurationen in anderen Umgebungen konsultieren Sie bitte die Dokumentation, um die erforderlichen Parameter zu überprüfen: ElasticsearchStore-Konfiguration.

Standardmäßig verwendet LlamaIndex das OpenAI text-embedding-ada-002- Modell zur Generierung von Einbettungen. In diesem Beispiel verwenden wir jedoch das Modell text-embedding-3-small . Wichtig zu beachten ist, dass für die Nutzung des Modells ein OpenAI-API-Schlüssel erforderlich ist.

Nachfolgend finden Sie den vollständigen Code für die Dokumentenaufnahme.

Nach der Ausführung werden die Dokumente wie unten dargestellt im FAQ- Index indexiert:

Suche mit RAG

Um Suchvorgänge durchzuführen, konfigurieren wir den ElasticsearchStore- Client, indem wir die Felder index_name und es_url mit der Elasticsearch-URL belegen. In retrieval_strategy haben wir die AsyncDenseVectorStrategy für Vektorsuchen definiert. Es stehen auch andere Strategien zur Verfügung, wie zum Beispiel AsyncBM25Strategy (Stichwortsuche) und AsyncSparseVectorStrategy (dünnbesetzte Vektoren). Weitere Einzelheiten finden Sie in der offiziellen Dokumentation.

Als nächstes wird ein VectorStoreIndex- Objekt erstellt, in dem wir den vector_store mithilfe des ElasticsearchStore-Objekts konfigurieren. Mit der Methode as_retriever führen wir die Suche nach den relevantesten Dokumenten für eine Anfrage durch und legen die Anzahl der zurückgegebenen Ergebnisse über den Parameter similarity_top_k auf 5 fest.

Der nächste Schritt ist RAG. Die Ergebnisse der Vektorsuche werden in eine formatierte Eingabeaufforderung für das LLM integriert, wodurch eine kontextbezogene Antwort auf Basis der abgerufenen Informationen ermöglicht wird.

In der PromptTemplate definieren wir das Prompt-Format, das Folgendes umfasst:

• Kontext ({context_str}): Vom Abrufer abgerufene Dokumente.

• Anfrage ({query_str}): die Frage des Benutzers.

• Anleitung: Richtlinien für das Modell, um kontextbezogen zu reagieren, ohne auf externes Wissen zurückzugreifen.

Schließlich verarbeitet das LLM die Eingabeaufforderung und gibt eine präzise und kontextbezogene Antwort zurück.

Der vollständige Code ist unten aufgeführt:

Nun können wir unsere Suche durchführen, zum Beispiel: „Sind Elastic-Dienste kostenlos?“, und erhalten eine kontextbezogene Antwort, die auf den FAQ-Daten selbst basiert.

Zur Erstellung dieser Antwort wurden folgende Dokumente verwendet:

Fazit

Anhand von LlamaIndex haben wir demonstriert, wie man ein effizientes FAQ-Suchsystem mit Unterstützung für Elasticsearch als Vektordatenbank erstellt. Die Dokumente werden mithilfe von Einbettungen erfasst und indexiert, wodurch Vektorsuchen ermöglicht werden. Mithilfe einer PromptTemplate werden die Suchergebnisse in den Kontext eingebunden und an das LLM gesendet, das auf Basis der abgerufenen Dokumente präzise und kontextbezogene Antworten generiert.

Dieser Workflow integriert die Informationsabfrage mit der kontextbezogenen Antwortgenerierung, um genaue und relevante Ergebnisse zu liefern.

Referenzen

https://www.elastic.co/guide/en/cloud/current/ec-faq-getting-started.html

https://docs.llamaindex.ai/en/stable/api_reference/readers/elasticsearch/

https://docs.llamaindex.ai/en/stable/module_guides/indexing/vector_store_index/

https://docs.llamaindex.ai/en/stable/examples/query_engine/custom_query_engine/

https://www.elastic.co/search-labs/integrations/llama-index

Apache Airflow ist eine Plattform, die zum Erstellen, Planen und Überwachen von Arbeitsabläufen entwickelt wurde. Es dient zur Orchestrierung von ETL-Prozessen, Datenpipelines und anderen komplexen Arbeitsabläufen und bietet Flexibilität und Skalierbarkeit. Die visuelle Benutzeroberfläche und die Echtzeit-Überwachungsfunktionen machen das Pipeline-Management zugänglicher und effizienter und ermöglichen es Ihnen, den Fortschritt und die Ergebnisse Ihrer Ausführungen zu verfolgen. Nachfolgend sind die vier Hauptpfeiler aufgeführt:

• Dynamisch: Pipelines werden in Python definiert, was eine dynamische und flexible Workflow-Generierung ermöglicht.

• Erweiterbar: Airflow lässt sich in eine Vielzahl von Umgebungen integrieren, benutzerdefinierte Operatoren können erstellt und spezifischer Code nach Bedarf ausgeführt werden.

• Elegant: Pipelines werden sauber und explizit geschrieben.

• Skalierbar: Dank seiner modularen Architektur nutzt es eine Message Queue, um eine beliebige Anzahl von Workern zu orchestrieren.

In der Praxis kann Airflow in Szenarien wie den folgenden eingesetzt werden:

• Datenimport: Orchestrieren Sie die tägliche Datenaufnahme in eine Datenbank wie Elasticsearch.

• Protokollüberwachung: Verwaltung der Erfassung und Verarbeitung von Protokolldateien, die anschließend in Elasticsearch analysiert werden, um Fehler oder Anomalien zu identifizieren.

• Integration mehrerer Datenquellen: Informationen aus verschiedenen Systemen (APIs, Datenbanken, Dateien) werden in einer einzigen Ebene in Elasticsearch kombiniert, was die Suche und Berichterstellung vereinfacht.

Verständnis von gerichteten azyklischen Graphen (DAGs) in der Luftströmung

In Airflow werden Workflows durch DAGs (gerichtete azyklische Graphen) dargestellt. Ein DAG ist eine Struktur, die die Reihenfolge definiert, in der Aufgaben ausgeführt werden. Die Hauptmerkmale von DAGs sind:

• Zusammensetzung aus unabhängigen Aufgaben: Jede Aufgabe stellt eine Arbeitseinheit dar und ist so konzipiert, dass sie unabhängig ausgeführt werden kann.

• Sequenzierung: Die Reihenfolge, in der die Aufgaben ausgeführt werden, ist im DAG explizit definiert.

• Wiederverwendbarkeit: DAGs sind so konzipiert, dass sie wiederholt ausgeführt werden können, was die Prozessautomatisierung erleichtert.

Luftstromkomponenten

Das Airflow-Ökosystem besteht aus mehreren Komponenten, die zusammenarbeiten, um Aufgaben zu orchestrieren:

• Scheduler: Verantwortlich für die Planung von DAGs und die Zuweisung von Aufgaben zur Ausführung an die Worker.

• Ausführender: Steuert die Ausführung von Aufgaben und delegiert diese an Mitarbeiter.

• Webserver: Bietet eine grafische Benutzeroberfläche zur Interaktion mit DAGs und Tasks.

• Dags-Ordner: Ordner, in dem wir in Python geschriebene DAGs speichern.

• Metadaten: Datenbank, die als Repository für das Tool dient und vom Scheduler und Executor zur Speicherung des Ausführungsstatus verwendet wird.

Apache Airflow und Elasticsearch

Wir werden die Verwendung von Apache Airflow und Elasticsearch zur Orchestrierung von Aufgaben und zur Indizierung von Ergebnissen in Elasticsearch demonstrieren. Ziel dieser Demonstration ist es, eine Aufgabenpipeline zu erstellen, um Datensätze in einem Elasticsearch-Index zu aktualisieren. Dieser Index enthält eine Datenbank mit Filmen, in der Benutzer Bewertungen abgeben und andere Bewertungen vergeben können. Stellt man sich ein Szenario mit Hunderten von täglichen Bewertungen vor, ist es notwendig, die Bewertungsstatistik stets aktuell zu halten. Hierfür wird ein DAG entwickelt, der täglich ausgeführt wird und für das Abrufen der neuen konsolidierten Ratings sowie die Aktualisierung der Datensätze im Index zuständig ist.

Im DAG-Ablauf gibt es eine Aufgabe zum Abrufen der Bewertungen, gefolgt von einer Aufgabe zur Validierung der Ergebnisse. Falls die Daten nicht vorhanden sind, wird der DAG zu einer Fehleraufgabe weitergeleitet. Andernfalls werden die Daten in Elasticsearch indexiert. Ziel ist es, das Bewertungsfeld von Filmen in einem Index zu aktualisieren, indem die Bewertungen mithilfe einer Methode abgerufen werden, die den Mechanismus zur Berechnung der Punktzahlen beinhaltet.

Verwendung von Apache Airflow und Elasticsearch mit Docker

Um eine containerisierte Umgebung zu erstellen, verwenden wir Apache Airflow mit Docker. Folgen Sie den Anweisungen im Leitfaden „Airflow in Docker ausführen“, um Airflow praktisch einzurichten.

Was Elasticsearch betrifft, werde ich einen Cluster auf Elastic Cloud verwenden, aber wenn Sie es vorziehen, können Sie Elasticsearch auch mit Docker konfigurieren. Es wurde bereits ein Index erstellt, der einen Filmkatalog mit den indexierten Filmdaten enthält. Das Feld „Bewertung“ dieser Filme wird aktualisiert.

Erstellung des DAG

Nach der Installation via Docker wird eine Ordnerstruktur erstellt, die unter anderem den Ordner „dags“ enthält. In diesem Ordner müssen wir unsere DAG-Dateien ablegen, damit Airflow sie erkennt.

Zuvor müssen wir sicherstellen, dass die notwendigen Abhängigkeiten installiert sind. Hier sind die Abhängigkeiten für dieses Projekt:

Wir werden die Datei update_ratings_movies.py erstellen und mit der Codierung der Aufgaben beginnen.

Nun importieren wir die benötigten Bibliotheken:

Wir werden den ElasticsearchPythonHook verwenden, eine Komponente, die die Integration zwischen Airflow und einem Elasticsearch-Cluster vereinfacht, indem sie die Verbindung und die Verwendung externer APIs abstrahiert.

Als Nächstes definieren wir den DAG und geben seine Hauptargumente an:

• dag_id: der Name des DAG.

• start_date: wann der DAG startet.

• schedule: definiert die Periodizität (in unserem Fall täglich).

• doc_md: Dokumentation, die importiert und in der Airflow-Oberfläche angezeigt wird.

Definition der Aufgaben

Nun definieren wir die Aufgaben des DAG. Die erste Aufgabe besteht darin, die Daten zur Filmbewertung abzurufen. Wir werden den PythonOperator verwenden, wobei task_id auf 'get_movie_ratings' gesetzt ist. Der Parameter python_callable ruft die Funktion auf, die für das Abrufen der Bewertungen zuständig ist.

Als nächstes müssen wir überprüfen, ob die Ergebnisse gültig sind. Hierfür verwenden wir eine Bedingung mit einem BranchPythonOperator. Die task_id wird zu 'validate_result', und die python_callable ruft die Validierungsfunktion auf. Der Parameter op_args wird verwendet, um das Ergebnis der vorherigen Aufgabe, 'get_movie_ratings', an die Validierungsfunktion zu übergeben.

Wenn die Validierung erfolgreich ist, werden wir die Daten aus der 'get_movie_ratings' -Aufgabe nehmen und in Elasticsearch indizieren. Um dies zu erreichen, erstellen wir eine neue Aufgabe, 'index_movie_ratings', die den PythonOperator verwendet. Der Parameter op_args übergibt die Ergebnisse der Aufgabe 'get_movie_ratings' an die Indexierungsfunktion.

Wenn die Validierung einen Fehler anzeigt, fährt der DAG mit einer Fehlerbenachrichtigungsaufgabe fort. In diesem Beispiel geben wir einfach eine Meldung aus, aber in einem realen Szenario könnten wir Warnmeldungen konfigurieren, um über die Fehler zu informieren.

Abschließend definieren wir die Aufgabenabhängigkeiten und stellen sicher, dass sie in der richtigen Reihenfolge ausgeführt werden:

Hier folgt nun der vollständige Code unseres DAG:

Visualisierung der DAG-Ausführung

In der Apache Airflow-Oberfläche können wir die Ausführung der DAGs visualisieren. Gehen Sie einfach auf die Registerkarte „DAGs“ und suchen Sie den von Ihnen erstellten DAG.

Im Folgenden können wir die Ausführung der Aufgaben und ihre jeweiligen Status visualisieren. Durch die Auswahl einer Ausführung für ein bestimmtes Datum können wir auf die Protokolle der einzelnen Aufgaben zugreifen. Beachten Sie, dass wir in der index_movie_ratings -Aufgabe die Indexierungsergebnisse im Index sehen können und dass sie erfolgreich abgeschlossen wurde.

In den anderen Registerkarten können Sie auf zusätzliche Informationen zu den Aufgaben und dem DAG zugreifen, die Ihnen bei der Analyse und Lösung potenzieller Probleme helfen.

Fazit

In diesem Artikel haben wir gezeigt, wie man Apache Airflow mit Elasticsearch integriert, um eine Datenerfassungslösung zu erstellen. Wir haben gezeigt, wie man den DAG konfiguriert, die Aufgaben definiert, die für das Abrufen, Validieren und Indizieren von Filmdaten zuständig sind, und wie man die Ausführung dieser Aufgaben in der Airflow-Oberfläche überwacht und visualisiert.

Dieser Ansatz lässt sich leicht an verschiedene Datentypen und Arbeitsabläufe anpassen, wodurch Airflow zu einem nützlichen Werkzeug für die Orchestrierung von Datenpipelines in unterschiedlichen Szenarien wird.

Referenzen

Apache AirFlow

https://airflow.apache.org/

Apache Airflow mit Docker installieren

https://airflow.apache.org/docs/apache-airflow/stable/howto/docker-compose/index.html

Elasticsearch Python Hook

https://airflow.apache.org/docs/apache-airflow-providers-elasticsearch/stable/hooks/elasticsearch_python_hook.html

Python-Operator

https://airflow.apache.org/docs/apache-airflow/stable/howto/operator/python.html

Voraussetzungen

• Docker und Docker Compose: Stellen Sie sicher, dass Docker und Docker Compose auf Ihrem Rechner installiert sind.

• Python 3.x: Zum Ausführen der Producer- und Consumer-Skripte.

Einführung in Apache Kafka

Apache Kafka ist eine verteilte Streaming-Plattform, die hohe Skalierbarkeit und Verfügbarkeit sowie Fehlertoleranz ermöglicht. In Kafka erfolgt die Datenverwaltung über die Hauptkomponenten:

• Broker: zuständig für die Speicherung und Verteilung von Nachrichten zwischen Produzenten und Konsumenten.

• Zookeeper: verwaltet und koordiniert die Kafka-Broker und kontrolliert den Zustand des Clusters, die Partitionsleiter und die Verbraucherinformationen.

• Themen: Kanäle, auf denen Daten veröffentlicht und zur Nutzung gespeichert werden.

• Konsumenten und Produzenten: Während Produzenten Daten an die Themen senden, rufen Konsumenten diese Daten ab.

Diese Komponenten arbeiten zusammen und bilden das Kafka-Ökosystem, das ein robustes Framework für das Datenstreaming bietet.

Projektstruktur

Um den Datenerfassungsprozess zu verstehen, haben wir ihn in Phasen unterteilt:

• Infrastrukturbereitstellung: Einrichtung der Docker-Umgebung zur Unterstützung von Kafka, Elasticsearch und Kibana.

• Producer-Erstellung: Implementierung des Kafka-Producers, der Daten an das Logs-Topic sendet.

• Consumer Creation: Entwicklung des Kafka-Consumers zum Lesen und Indizieren von Nachrichten in Elasticsearch.

• Aufnahmevalidierung: Überprüfung und Validierung der gesendeten und empfangenen Daten.

Infrastrukturkonfiguration mit Docker Compose

Wir haben Docker Compose verwendet, um die notwendigen Dienste zu konfigurieren und zu verwalten. Nachfolgend finden Sie den Docker Compose-Code, der die für die Integration von Apache Kafka, Elasticsearch und Kibana erforderlichen Dienste einrichtet und so einen Datenaufnahmeprozess sicherstellt.

Sie können direkt über das Elasticsearch Labs GitHub- Repository auf die Datei zugreifen.

Datenübertragung mit dem Kafka Producer

Der Produzent ist für das Senden von Nachrichten an das Log-Thema verantwortlich. Durch das Senden von Nachrichten in Stapeln wird die Netzwerknutzungseffizienz gesteigert. Optimierungen sind mit den Einstellungen batch_size und linger_ms möglich, die die Anzahl bzw. die Latenz der Stapel steuern. Die Konfiguration acks='all' gewährleistet, dass Nachrichten dauerhaft gespeichert werden, was für wichtige Protokolldaten unerlässlich ist.

Beim Starten des Producers werden die Nachrichten in Batches an das Topic gesendet, wie unten dargestellt:

Konsum und Indizierung von Daten mit dem Kafka Consumer

Der Consumer ist so konzipiert, dass er Nachrichten effizient verarbeitet, indem er Batches aus dem Logs-Topic empfängt und diese in Elasticsearch indexiert. Mit auto_offset_reset='latest' wird sichergestellt, dass der Consumer mit der Verarbeitung der neuesten Nachrichten beginnt und die älteren ignoriert, und max_poll_records=10 begrenzt den Batch auf 10 Nachrichten. Bei fetch_max_wait_ms=2000 wartet der Konsument bis zu 2 Sekunden, um genügend Nachrichten zu sammeln, bevor er den Batch verarbeitet.

Im Hauptzyklus verarbeitet der Consumer die Logmeldungen, speichert sie in Elasticsearch und indexiert sie, um eine kontinuierliche Datenaufnahme zu gewährleisten.

Datenvisualisierung in Kibana

Mit Kibana können wir die von Kafka aufgenommenen und in Elasticsearch indexierten Daten untersuchen und validieren. Durch den Zugriff auf die Entwicklertools in Kibana können Sie die indizierten Nachrichten anzeigen und überprüfen, ob die Daten den Erwartungen entsprechen. Wenn beispielsweise unser Kafka-Producer 5 Batches mit jeweils 10 Nachrichten sendet, sollten wir insgesamt 50 Datensätze im Index sehen.

Um die Daten zu überprüfen, können Sie die folgende Abfrage im Abschnitt „Entwicklertools“ verwenden:

Abwehr:

Darüber hinaus bietet Kibana die Möglichkeit, Visualisierungen und Dashboards zu erstellen, die die Analyse intuitiver und interaktiver gestalten können. Nachfolgend sehen Sie einige Beispiele der von uns erstellten Dashboards und Visualisierungen, die die Daten in verschiedenen Formaten veranschaulichen und so unser Verständnis der verarbeiteten Informationen verbessern.

Datenaufnahme mit Kafka Connect

Kafka Connect ist ein Dienst, der die Integration zwischen Datenquellen und Zielen (Senken) wie Datenbanken oder Dateisystemen erleichtert. Es arbeitet mit vordefinierten Konnektoren, die den Datentransfer automatisch abwickeln. In unserem Fall fungiert Elasticsearch als Datensenke.

Mit Kafka Connect können wir den Datenaufnahmeprozess vereinfachen und die Notwendigkeit eliminieren, den Datenaufnahme-Workflow manuell in Elasticsearch zu implementieren. Mit dem passenden Konnektor ermöglicht Kafka Connect die direkte Indizierung von Daten, die an ein Kafka-Topic gesendet werden, in Elasticsearch – mit minimalem Einrichtungsaufwand und ohne zusätzliche Programmierung.

Arbeiten mit Kafka Connect

Um Kafka Connect zu implementieren, fügen wir den kafka-connect-Dienst zu unserem Docker Compose-Setup hinzu. Ein wichtiger Bestandteil dieser Konfiguration ist die Installation des Elasticsearch-Connectors, der für die Datenindizierung zuständig ist.

Nach der Konfiguration des Dienstes und der Erstellung des Kafka Connect-Containers wird eine Konfigurationsdatei für den Elasticsearch-Connector benötigt. Diese Datei definiert wichtige Parameter wie zum Beispiel:

• connection.url: Verbindungs-URL für Elasticsearch.

• topics: Das Kafka-Thema, das der Connector überwachen wird (in diesem Fall "logs").

• type.name: Dokumenttyp in Elasticsearch (typischerweise _doc).

• value.converter: Konvertiert Kafka-Nachrichten in das JSON-Format.

• value.converter.schemas.enable: Gibt an, ob das Schema einbezogen werden soll.

• schema.ignore und key.ignore: Einstellungen zum Ignorieren von Kafka-Schemas und -Schlüsseln während der Indizierung.

Nachfolgend der Befehl curl zum Erstellen des Elasticsearch-Connectors in Kafka Connect:

Mit dieser Konfiguration beginnt Kafka Connect automatisch mit der Erfassung der an das Topic "logs" gesendeten Daten und deren Indizierung in Elasticsearch. Dieser Ansatz ermöglicht die vollautomatische Datenerfassung und -indizierung ohne zusätzlichen Programmieraufwand und vereinfacht so den gesamten Integrationsprozess.

Fazit

Durch die Integration von Kafka und Elasticsearch entsteht eine leistungsstarke Pipeline für die Datenerfassung und -analyse in Echtzeit. Dieser Leitfaden bietet einen grundlegenden Ansatz für den Aufbau einer robusten Datenerfassungsarchitektur mit nahtloser Visualisierung und Analyse in Kibana, die sich zukünftig an komplexere Anforderungen anpassen lässt.

Darüber hinaus vereinfacht die Verwendung von Kafka Connect die Integration zwischen Kafka und Elasticsearch zusätzlich, wodurch die Notwendigkeit von zusätzlichem Code zur Verarbeitung und Indizierung von Daten entfällt. Kafka Connect ermöglicht es, Daten, die an ein bestimmtes Thema gesendet werden, mit minimalem Konfigurationsaufwand automatisch in Elasticsearch zu indizieren.

Was ist Apache Camel?

Apache Camel ist ein Open-Source-Integrationsframework, das die Verbindung verschiedener Systeme vereinfacht und es Entwicklern ermöglicht, sich auf die Geschäftslogik zu konzentrieren, ohne sich um die Komplexität der Systemkommunikation kümmern zu müssen. Das zentrale Konzept in Camel sind „Routen“, die den Weg definieren, den eine Nachricht vom Ursprung zum Ziel zurücklegt, einschließlich potenzieller Zwischenschritte wie Transformationen, Validierungen und Filterungen.

Apache Camel-Architektur

Camel verwendet „Komponenten“, um Verbindungen zu verschiedenen Systemen und Protokollen wie Datenbanken und Messaging-Diensten herzustellen, sowie „Endpunkte“, um die Ein- und Austrittspunkte von Nachrichten darzustellen. Diese Konzepte bieten ein modulares und flexibles Design, wodurch die Konfiguration und Verwaltung komplexer Integrationen effizienter und skalierbarer wird.

Verwendung von Elasticsearch und Apache Camel

Wir zeigen Ihnen, wie Sie eine einfache Java-Anwendung konfigurieren, die Apache Camel verwendet, um Daten in einen Elasticsearch-Cluster einzuspeisen. Die Prozesse zum Erstellen, Aktualisieren und Löschen von Daten in Elasticsearch mithilfe von in Apache Camel definierten Routen werden ebenfalls behandelt.

1. Hinzufügen von Abhängigkeiten

Der erste Schritt bei der Konfiguration dieser Integration besteht darin, die notwendigen Abhängigkeiten zur pom.xml -Datei Ihres Projekts hinzuzufügen. Dies umfasst die Apache Camel- und Elasticsearch-Bibliotheken. Wir werden die neue Java API Client-Bibliothek verwenden, daher müssen wir die Komponente camel-elasticsearch importieren, und zwar in der Version, die mit der der Bibliothek camel-core übereinstimmen muss.

Wenn Sie den Java Low Level Rest Client verwenden möchten, müssen Sie die Elasticsearch Low Level Rest Client-Komponente verwenden.

2. Konfigurieren und Ausführen des Camel-Kontexts

Die Konfiguration beginnt mit der Erstellung eines neuen Camel-Kontexts mithilfe der Klasse DefaultCamelContext , die als Basis für die Definition und Ausführung von Routen dient. Als Nächstes konfigurieren wir die Elasticsearch-Komponente, die es Apache Camel ermöglicht, mit einem Elasticsearch-Cluster zu interagieren. Die ESlasticsearchComponent -Instanz ist so konfiguriert, dass sie eine Verbindung zur Adresse localhost:9200 herstellt. Dies ist die Standardadresse für einen lokalen Elasticsearch-Cluster. Für eine Umgebungskonfiguration, die eine Authentifizierung erfordert, sollten Sie die Dokumentation zur Konfiguration der Komponente und zur Aktivierung der Basisauthentifizierung lesen, die unter dem Titel „Komponente konfigurieren und Basisauthentifizierung aktivieren“ bezeichnet wird.

Diese Komponente wird dann dem Camel-Kontext hinzugefügt, wodurch die definierten Routen diese Komponente nutzen können, um Operationen in Elasticsearch durchzuführen.

Anschließend werden die Routen dem Kontext hinzugefügt. Wir werden Routen für die Massenindizierung, Aktualisierung und Löschung von Dokumenten erstellen.

3. Konfiguration von Camel-Routen

Datenindizierung

Die erste Route, die wir konfigurieren werden, dient der Datenindizierung. Wir werden eine JSON-Datei verwenden, die einen Filmkatalog enthält. Die Route wird so konfiguriert, dass die unter src/main/resources/movies.json befindliche Datei gelesen, der JSON-Inhalt in Java-Objekte deserialisiert und anschließend eine Aggregationsstrategie angewendet wird, um mehrere Nachrichten zu einer einzigen zusammenzufassen, wodurch Batch-Operationen in Elasticsearch ermöglicht werden. Es wurde eine Größe von 500 Elementen pro Nachricht konfiguriert, d. h., der Massenindex indexiert jeweils 500 Filme.

Route Elasticsearch Operation Bulk

Der Dokumentenstapel wird an den Bulk-Operations-Endpunkt von Elasticsearch gesendet. Dieser Ansatz gewährleistet Effizienz und Geschwindigkeit bei der Verarbeitung großer Datenmengen.

Datenaktualisierung

Der nächste Schritt besteht darin, die Dokumente zu aktualisieren. Im vorherigen Schritt haben wir einige Filme indexiert. Nun erstellen wir neue Routen, um anhand des Referenzcodes nach einem Dokument zu suchen und anschließend das Bewertungsfeld zu aktualisieren.

Wir richten einen Camel-Kontext (DefaultCamelContext) ein, in dem eine Elasticsearch-Komponente registriert und eine benutzerdefinierte Route IngestionRoute hinzugefügt wird. Der Vorgang beginnt mit dem Senden des Dokumentcodes über die ProducerTemplate, wodurch die Route vom Endpunkt direct:update-ingestion gestartet wird.

Als nächstes haben wir die IngestionRoute, die der Eingabeendpunkt für diesen Datenfluss ist. Die Route führt mehrere nacheinander ausgeführte Operationen durch. Zunächst wird in Elasticsearch eine Suche durchgeführt, um das Dokument anhand des Codes (direct:search-by-id) zu finden. Der SearchByCodeProcessor stellt die Abfrage auf Basis des Codes zusammen. Anschließend wird das abgerufene Dokument vom UpdateRatingProcessor verarbeitet, der das Ergebnis in Movie-Objekte umwandelt, die Filmbewertung auf einen bestimmten Wert aktualisiert und das aktualisierte Dokument für die Rücksendung an Elasticsearch zur Aktualisierung vorbereitet.

Der SearchByCodeProcessor -Prozessor wurde nur für die Ausführung der Suchanfrage konfiguriert:

Der UpdateRatingProcessor -Prozessor ist für die Aktualisierung des Bewertungsfelds zuständig.

Datenlöschung

Abschließend wird der Weg zum Löschen von Dokumenten konfiguriert. Hier löschen wir ein Dokument anhand seiner ID. Um in Elasticsearch ein Dokument zu löschen, benötigen wir die Dokumentkennung, den Index, in dem das Dokument gespeichert ist, und müssen eine Löschanforderung ausführen. In Apache Camel führen wir diese Operation durch, indem wir eine neue Route erstellen, wie unten gezeigt.

Die Route beginnt am Endpunkt direct:op-delete, der als Einstiegspunkt dient. Wenn ein Dokument gelöscht werden muss, wird seine Kennung (_id) im Nachrichtentext empfangen. Die Route setzt dann den IndexId-Header mit dem Wert dieser Kennung mithilfe von einfachem("${body}"), wodurch die _id aus dem Nachrichtentext extrahiert wird.

Schließlich wird die Nachricht an den durch URI_DELETE_OPERATION angegebenen Endpunkt weitergeleitet, der eine Verbindung zu Elasticsearch herstellt, um die Dokumentenlöschung im entsprechenden Index durchzuführen. Nachdem wir die Route erstellt haben, können wir einen Camel-Kontext (DefaultCamelContext) erstellen, der so konfiguriert ist, dass er die Elasticsearch-Komponente enthält.

Als nächstes wird die durch die Klasse OperationDeleteRoute definierte Löschroute zum Kontext hinzugefügt. Nachdem der Kontext initialisiert wurde, wird ein ProducerTemplate verwendet, um die Kennung des zu löschenden Dokuments an den direct:op-delete Endpunkt zu übergeben, wodurch die Löschroute ausgelöst wird.

Fazit

Die Integration zwischen Apache Camel und Elasticsearch ermöglicht eine robuste und effiziente Datenaufnahme, indem die Flexibilität von Camel genutzt wird, um Routen zu definieren, die verschiedene Datenmanipulationsszenarien wie Indizierung, Aktualisierung und Löschung bewältigen können. Mit diesem Setup können Sie komplexe Prozesse skalierbar orchestrieren und automatisieren und so sicherstellen, dass Ihre Daten in Elasticsearch effizient verwaltet werden. Dieses Beispiel demonstrierte, wie diese Werkzeuge zusammen verwendet werden können, um eine effiziente und anpassungsfähige Lösung für die Datenerfassung zu schaffen.

Referenzen

• Apache Camel

• Apache Camel-Architektur

• Aggregate Apache Camel

• Dateikomponente

• Elasticsearch-Komponente