Neuindizierung von Datenströmen aufgrund von Mapping-Konflikten

Wenn es zu Mapping-Konflikten in Feldern kommt, egal ob diese dem Elastic Common Schema-Standard (ECS-Standard) entsprechen oder spezifisch für die Datenquelle sind, ist eine Neuindizierung Ihrer Daten mithilfe der Entwickler-Tools erforderlich. Diese Konflikte können jede nachgelagerte Funktion nach der Ingestion negativ beeinflussen, was möglicherweise zu ungenauen Ergebnissen führt oder die Nutzung des vollständigen Datensatzes in Funktionen wie Visualisierungen, Dashboards, der Security App und Aggregationen verhindert. Dieser Blogbeitrag beschreibt die Schritte dieses Neuindizierungsprozesses.

Der Inhalt dieses Blogbeitrags wurde mit den Elastic-Versionen 9.2.8 und 8.19.14 sowie den Filestream Integration Versionen 2.3.0 und 1.2.0 entwickelt und verifiziert.

Wichtiger Hinweis: Je nach Umgebung sind für einige Schritte spezielle Anpassungen erforderlich. Beachten Sie außerdem, dass dynamische Vorlagen ab Filestream Integration Version 2.3.3 aus der @package-Komponentenvorlage entfernt wurden.

Bevor Sie mit dem Reindexierungsprozess beginnen, ist es wichtig, die aktuelle Speicherzuweisung in Ihrer Umgebung zu berücksichtigen. Die unten beschriebenen Schritte beinhalten das Erstellen einer Kopie des bestehenden Backing-Index, der vorübergehend im hot Tier liegt.

Elasticsearch-Datenebenen

• Heiß: Die heiße Ebene ist der Einstiegspunkt von Elasticsearch für Zeitreihendaten, in der die aktuellsten und am häufigsten durchsuchten Daten gespeichert werden. Nodes der heißen Ebene erfordern schnelle Lese- und Schreibvorgänge, also mehr Ressourcen und schnelleren Speicher (SSDs). Diese Ebene ist obligatorisch und neue Datenstromindizes werden ihr automatisch zugeordnet.
• Warm: Zeitreihendaten können in die warme Ebene verschoben werden, sobald sie seltener abgefragt werden als die kürzlich indizierten Daten in der heißen Ebene. Die warme Ebene enthält in der Regel Daten der letzten Wochen. Aktualisierungen sind weiterhin erlaubt, aber wahrscheinlich selten. Die Nodes in der warmen Ebene müssen im Allgemeinen nicht so schnell sein wie die in der heißen Ebene. Für die Ausfallsicherheit sollten Indizes in der warmen Ebene so konfiguriert werden, dass sie eine oder mehrere Replikate verwenden.
• Kalt: Daten, die nur selten durchsucht werden, können von der warmen in die kalte Ebene verschoben werden. Die kalte Ebene ist zwar immer noch durchsuchbar, aber die geringeren Speicherkosten haben Vorrang vor der Suchgeschwindigkeit. Alternativ kann die kalte Ebene reguläre Indizes mit Replikaten anstelle von durchsuchbaren Snapshots speichern, wodurch für ältere Daten kostengünstigere Hardware verwendet werden kann, ohne dass der Festplattenspeicherbedarf im Vergleich zur warmen Ebene reduziert wird.
• Eingefroren: Daten, die nur selten oder gar nicht mehr abgefragt werden, werden für den Rest ihres Lebenszyklus von der Kategorie „Kalt“ in die Kategorie „Eingefroren“ verschoben. Diese Ebene nutzt ein Snapshot-Repository und teilweise eingebundene Indizes zum Speichern und Laden von Daten, wodurch der lokale Speicherplatz und die Kosten reduziert werden, während die Suche weiterhin möglich ist. Suchvorgänge auf der eingefrorenen Ebene sind im Allgemeinen langsamer als auf der kalten Ebene, da Elasticsearch möglicherweise eingefrorene Daten aus dem Snapshot-Repository abrufen muss. Wir empfehlen dedizierte Nodes für die eingefrorene Ebene.

Voraussetzungen: Ermitteln Sie, welche Felder Konflikte aufweisen

Um festzustellen, welche Felder Mapping-Konflikte aufweisen, navigieren Sie zu Stack Management –> Data Views –> Logs-* (die Verwendung der Data View Logs- ist die höchste Hierarchie der vorhandenen Daten mit dem Präfix Logs-.) Sollten Konflikte auftreten, wird dies in einem gelben Feld vermerkt. Sie können entweder auf Konflikte anzeigen klicken, oder unter dem Feld Feldtyp neben dem Suchfeld die Option Konflikt auswählen.

Wenn Sie auf die gelbe Schaltfläche Konflikt klicken, wird angezeigt, welche Indizes mit welchen Mapping-Typen verknüpft sind.

Diese Situation (in der das Feld sowohl als keyword als auch als long zugeordnet ist) tritt normalerweise auf, weil Daten ingestiert wurden, bevor ein spezifischer Mapping-Typ im Komponenten-Template für den relevanten Datenstrom definiert wurde. In solchen Fällen versucht Elasticsearch, das Mapping auf Basis seiner dynamischen Vorlagen festzulegen.

Um festzustellen, welches Mapping für das Feld geeignet ist und ob es sich um ein ECS-Feld handelt, ist eine Verifizierung mit ECS-Feldreferenz erforderlich. Wenn das betreffende Feld kein ECS-Feld ist, muss sein Wert überprüft werden, um das korrekte Mapping zu bestimmen.

Wenn ein Feld, wie log.offset in diesem Beispiel, im ECS nicht dokumentiert ist, bestehen die nächsten Schritte darin, den Feldwert zu untersuchen, den widersprüchlichen Mapping-Typ mit den meisten Backing-Indizes zu bestimmen und die Komponentenvorlagen der anderen Indizes zu prüfen.

In der Regel ist der Mapping-Typ mit der höchsten Anzahl an Indizes der richtige. Wir empfehlen Ihnen jedoch, den Wert des betreffenden Feldes zu überprüfen, um dies zu bestätigen. Um die Gültigkeit eines Mapping-Typs (zum Beispiel long) zu bestätigen, müssen Sie außerdem überprüfen, ob der Wert des Feldes für diesen Typ angemessen ist. Diese Verifizierung kann erfolgen, indem Sie Discover verwenden, um nach dem betreffenden Feld zu suchen. Die Überprüfung anderer Datenströme, die dasselbe Feld enthalten, kann ebenfalls zusätzliche Bestätigungen liefern.

Um die Werte für das Feld mit dem Mapping-Konflikt zu überprüfen, navigieren Sie zurück zu der bereits erwähnten gelben Schaltfläche Konflikt, klicken auf die Schaltfläche Konflikt, markieren einen der Backing-Indizes und fügen ihn in eine Discover-Sitzung ein. Die Anweisung Ihrer Kibana-Abfragesprache (KQL) sollte wie der folgende Screenshot aussehen, um den Feldbegrenzer _index: einzuschließen.

Bereiten Sie die neue benutzerdefinierte Komponentenvorlage für den Backing-Index vor

Um den Mapping-Konflikt im Datenstrom zu beheben, untersuchen Sie zuerst die relevante @package-Komponentenvorlage. Sie finden diese unter Stack Management -> Index Management -> Component Template. Suchen Sie nach dem Datenstrom und wählen Sie den entsprechenden @package Link aus. Diese Vorlage enthält grundlegend Mappings für die Felder, denn selbst wenn ein Mapping-Konflikt nicht häufig vorkommt, kann der passendere Typ leicht übersehen werden.

Überprüfen Sie die Vorlage, um sicherzustellen, dass sie die notwendige Feldverschachtelung und das Mapping für das betreffende Feld enthält. Wenn zum Beispiel die Vorlage log.offset fälschlicherweise als keyword angibt, ist dies die Ursache des Problems.

Wichtig: Da das Ändern von @package/Managed-Vorlagen nicht empfohlen wird, müssen Sie eine @custom-Komponentenvorlage verwenden oder erstellen, um den Mapping-Typ (zum Beispiel log.offset) für alle zukünftigen Daten zu korrigieren.

• Wir empfehlen nicht, die @package/Managed-Vorlagen zu ändern, da beim Aktualisieren der Integration auf eine neuere Version alle Änderungen, die Sie an der @package-Vorlage vornehmen, überschrieben werden. Deshalb empfehlen wir die Verwendung der @custom-Vorlagen.
• Wenn ein Datenstrom Mapping-Konflikte aufweist, müssen Sie alle fehlenden Feld-Nestings (ECS und Nicht-ECS) oder Mappings zur @custom Komponentenvorlage des Datenstroms hinzufügen. Erstellen Sie diese Vorlage, falls sie noch nicht existiert, und stellen Sie sicher, dass Sie den korrekten Mapping-Typ für das Feld angeben.
• Wenn mehrere Konflikte in Ihrer Datenquelle vorliegen, wenden Sie alle erforderlichen fehlenden Mappings für den Datenstrom gleichzeitig an, damit die Neuindizierung einmal statt mehrmals durchgeführt wird. Einträge für die korrekte Datentypisierung in der @custom-Komponentenvorlage stellen sicher, dass jede zukünftige Daten-Ingestion der gleichen Mapping-Richtlinie folgt.

Um die @custom-Komponentenvorlage zu erstellen (oder zu überprüfen, ob sie verwendet und ausgefüllt ist), navigieren Sie zu Index Templates, geben den Namen des betreffenden Datenstroms ein und klicken auf die entsprechende @custom-Vorlage, die vom Datenstrom verwendet wird. Falls die Vorlage noch nicht erstellt wurde, erscheint ein gelbes Feld, über das Sie die Vorlage mithilfe der Benutzeroberfläche erstellen können.

Der untenstehende Screenshot zeigt die nächste Seite, sobald die Create Component Vorlage ausgewählt ist. Lassen Sie die Standardwerte auf der ersten Seite unverändert und klicken Sie auf Mappings oder Weiter, bis Sie die Mappings-Seite erreichen.

Um das Mapping für ein neu eingehendes Feld explizit festzulegen oder ein Feld zu aktualisieren, bei dem ein Mapping-Konflikt besteht, wenn der Datenstrom aufgrund einer in der Indexlebenszyklusrichtlinie festgelegten Konfiguration überschrieben wird, ist ein Eintrag für das Feld erforderlich, in dem der Konflikt besteht.

Im Folgenden wird das Mapping für das Feld log.offset in der Komponentenvorlage @custom für den Filestream-Datenstrom festgelegt. Wiederholen Sie die Schritte, um gegebenenfalls benutzerdefinierte Felder hinzuzufügen oder notwendige Felder aus dem @package mit den entsprechenden Mappings für diesen Datensatz zu aktualisieren. In diesem Beispiel ist bei der Einstellung des Offsets auf Long der Feldtyp Numeric und der numerische Typ Long. Klicken Sie auf Feld hinzufügen und dann außerhalb des Bereichs, um fortzufahren.

Sobald alle benötigten Felder hinzugefügt wurden, gehen Sie sie zum Überprüfen durch und wählen Sie Komponenten-Vorlage erstellen, wenn Sie bereit sind. Alle neuen Daten, die ab diesem Schritt importiert werden, haben log.offset auf long gesetzt.

Erstellung der neuen Backing-Index-Struktur

Der neue Backing-Index muss die vorhandenen Mappings aus der Komponentenvorlage des Datenstroms sowie der ECS- ecs@mappings-Komponentenvorlage enthalten. Die ecs@mappings-Komponentenvorlage wird nach der Komponente des Datenstroms als Auffangbecken für zusätzliche Mappings angewendet, die möglicherweise in den vorherigen Komponentenvorlagen nicht erfasst wurden.

Navigieren Sie zum Browser-Tab für die @package Mappings des Datenstreams. (Gehen Sie zu Stack Management -> Index Management -> Component Template -> logs-filestream.generic@package -> Verwalten -> Bearbeiten.) Dort klicken Sie dann auf den Abschnitt Überprüfen , dann auf Anfrage und schließlich auf die Schaltfläche Kopieren rechts. Der JSON-Inhalt der kopierten Komponentenvorlage stellt sicher, dass die verbleibenden Feld-Mappings und Einstellungen erhalten bleiben, während wir das log.offset Feld-Mapping aktualisieren. Das JSON bildet die Basisstruktur für den neu indizierten Basisindex.

Wichtig: Wenn das JSON der Vorlage nicht kopiert wurde und die Arbeit mit der Neuindizierung fortgesetzt wurde, würde der log.offset-Konflikt gelöst werden, es würden jedoch neue Konflikte mit der Integration entstehen, da die Integrität der aktuellen Mappings nicht aufrechterhalten wurde, was doppelte Arbeit zur Lösung des ursprünglichen Problems nach sich zieht.

Öffnen Sie einen zweiten Tab im Browser, wechseln Sie zu Dev Tools und fügen Sie den kopierten Inhalt ein. Nun muss das Eingefügte entfernt werden:

Änderungen an der Anfrage

1. Indexname: Ersetzen Sie _component_template/logs-filestream.generic@package durch den Namen des Backing-Indexes, den Sie neu indizieren möchten, und fügen Sie -1 am Ende an. Verwenden Sie zum Beispiel PUT <backing index to reindex>-1.

• Das angehängte -1 steht für eine Neuindizierung und steht nicht in Konflikt mit den Standard-ILM-Rollover-Einstellungen, die auf dem Erstellungsdatum des Index basieren.

2. Einstellungen: Entfernen Sie die Zeile "template" (Zeile 3) sowie die allerletzte schließende Klammer für die gesamte JSON-Nutzlast. Zeile 3 sollte mit "settings": { beginnen.

• Ersetzen Sie den Inhalt des Abschnitts „Einstellungen“ durch "index.codec": "best_compression". Diese Aktion wendet die beste Kompression von Elastic auf den Index bei der Erstellung an.
• Fügen Sie "index.lifecycle.name": "logs" sowie eine Zeile für "index.lifecycle.rollover_alias": "" hinzu.
  1. Der Eintrag "index.lifecycle.name": "logs" wendet die ILM-Richtlinie für Logs auf den neuen zugrunde liegenden Index an. Ändern Sie den Namen der ILM-Richtlinie, wenn Sie keine Logs verwenden.
  2. Der "index.lifecycle.rollover_alias": "" ist leer, da dieser Backing-Index nicht übertragen wird, aber die Einstellung ist erforderlich, um ILM-Rollover-Fehler in die nächste ILM-Phase nach der heißen Ebene zu vermeiden.

3. Struktur: Die Anfrage sollte nun sowohl einen Settings-Abschnitt als auch einen Mappings-Abschnitt enthalten. Innerhalb von "mappings": { sollten Sie "dynamic_templates" und einen "properties" Abschnitt finden, der fest codierte Felder und deren Mappings enthält.

4. Änderung dynamischer Vorlagen: Der aktuelle Abschnitt für dynamische Vorlagen enthält Einträge für Felder, die überschrieben werden können, wenn die nächsten ecs@mappings dynamischen Vorlagen hinzugefügt werden, was Redundanz und zusätzliche Zeilen verursacht, die nicht benötigt werden.

• Entfernen Sie alle Abschnitte in "dynamic_templates" außer dem zweiten Abschnitt mit dem Titel "_embedded_ecs-data_stream_to_constant": {.
• Wiederholen Sie den gleichen Vorgang wie oben beschrieben, indem Sie die dynamischen Mappings für die @package-Komponentenvorlage sammeln, aber diesmal die dynamischen Mappings für die ecs@mappings-Komponentenvorlage.
  • Es kann einfacher sein, den gesamten Inhalt der Mappings aus der Benutzeroberfläche für die ecs@mappings-Komponentenvorlage zu kopieren, in den Arbeitsbereich des Dev-Tools- dynamic_templates-Abschnitts einzufügen und doppelte und unnötige Zeilen entsprechend zu entfernen. Fügen Sie diese dynamischen Template-Einstellungsinhalte nach dem"_embedded_ecs-data_stream_to_constant": {-Eintrag ein. Der Abschnitt dynamic_templates sollte den untenstehenden Beispielinhalten in den Dev-Tools sehr entsprechen.
• Wenn dynamic_templates nicht einbezogen oder vollständig entfernt werden, haben andere Felder (siehe untenstehenden Screenshot) doppelte Mappings: text und keyword im Vergleich zu den entsprechenden Mappings, falls der Abschnitt dynamic_templates enthalten geblieben wäre. Was übrig bleibt, sollte der Abschnitt "properties" unter "mappings" sein. Dies wird auch Probleme in der Datenquelle verursachen, da die Felder doppelt zugeordnet werden (falls sie nicht bereits auf diese Weise zugeordnet sind) und zusätzliche Mapping-Konflikte verursachen.

5. Metadaten-Entfernung: Löschen Sie den letzten Abschnitt mit der Bezeichnung "_meta", sowie den Abschnitt mit der Bezeichnung "version", falls vorhanden.

6. Formatierung: Die verbleibenden Abschnitte automatisch einrücken und unnötige geschweifte Klammern anpassen oder entfernen, die eine erfolgreiche Ausführung verhindern würden.

7. Mapping-Änderung: Navigieren Sie zum Abschnitt "properties", suchen Sie "log" und dann "offset", das darunter verschachtelt ist. Ändern Sie den Typ von keyword zu long und entfernen Sie den Zeileneintrag (inklusive Komma) mit der Bezeichnung "ignore_above": 1024,. Wenn mehr als ein Eintrag zur zuvor erstellten @custom Komponentenvorlage hinzugefügt wurde, fügen Sie diesen hier hinzu.

Ihre Dev Tools-Konsolenansicht sollte jetzt dem unten angegebenen Beispiel entsprechen.

Wenn Ihre Konsole dem Beispiel entspricht (mit allen zusätzlichen benutzerdefinierten Feldern und benutzerspezifischen Werten für Ihre Umgebung), führen Sie den Befehl aus, um das Gerüst des neuen Backing-Index zu erstellen. Pausieren Sie, wenn auftretende Fehler behoben werden müssen.

Neuindizierung beginnen

Wenn das Gerüst des neuen Backing-Index erfolgreich erstellt wurde, besteht der nächste Schritt darin, neu zu indizieren und die Mapping-Konflikte zu lösen.

Wichtig: Wenn der Backing-Index, der den Mapping-Konflikt aufweist, der aktuellste Index ist und der aktuelle Schreibindex (zum Beispiel ist die Endzahl des Backing-Index -000001), muss der Datenstrom übertragen werden. Das Übertragen des Datenstroms ist erforderlich, da der aktuelle Schreibindex, in den Dokumente eingespeist werden, ein Live-Backing-Index ist und nicht modifiziert werden kann.

Mit dem korrekten Feld-Mapping, das nun über die zuvor erstellte @custom Komponentenvorlage auf den neueren Schreibindex angewendet wird, spiegeln alle neuen Dokumente diese Änderung wider.

Dies wird durch Ausführen des Folgenden erreicht:

Zum Beispiel:

Die Neuindizierung beinhaltet das Kopieren der Daten aus einem bestehenden Backing-Index in einen neuen innerhalb derselben Namenskonvention, normalerweise um notwendige Änderungen vorzunehmen. Diese Änderungen könnten Aktualisierungen einer Komponentenvorlage oder das Hinzufügen einer neuen Ingest-Pipeline für die zu verarbeitenden Daten beinhalten.

Als Nächstes werden die Daten aus dem Backing-Index mit den falschen Mappings in einen neuen Backing-Index kopiert. Der ursprüngliche Backing-Index wird überschrieben, sodass keine neuen Dokumente mehr hinzugefügt werden können. Der neue Backing-Index folgt derselben Namenskonvention, die die Datentransparenz und -integrität bei Anwendung der korrekten ILM-Richtlinie bewahrt, aber ein -1-Suffix enthält, das anzeigt, dass er neu indexiert wurde.

Passen Sie die Indexnamen nach Bedarf an und fügen Sie den folgenden Code in die Konsole ein. Indem Sie wait_for_completion=false einbeziehen, können Sie den Fortschritt des Dokumentenkopierens verfolgen, was hilft, die verbleibende Reindexierungszeit abzuschätzen. Ohne diese Einstellung können Sie den Status nicht mit dem untenstehenden Befehl GET _tasks verfolgen und nur die Dokumentenanzahl im neueren Backing-Index mit GET <backing index name>-1/_count überprüfen.

Wichtig: Wenn während der Neuindizierung Probleme auftreten, führen Sie den Befehl Neuindizierung nicht erneut aus. Dadurch wird der Prozess neu gestartet und doppelte Einträge im Index mit -1 erstellt. Wenn ein Neustart notwendig ist, löschen Sie zunächst den Index mit dem nachlaufenden -1 und führen Sie dann den vorherigen PUT-Befehl aus, um das neue Backing-Index-Gerüst zu erstellen.

Nach der Ausführung enthält die Reaktion eine Aufgaben-ID. Sie können den Fortschritt der Neuindizierung mit dieser ID mit dem Befehl GET _tasks/<task ID> überwachen.

Die Dauer der Neuindizierung hängt vom Datenvolumen im ursprünglichen Index ab. Die Verarbeitung verfolgen Sie, indem Sie bei der Ausführung des Befehls GET nach "completed": true suchen, was zu einer ähnlichen Ausgabe führen sollte.

GET _tasks/<task ID>

Die Neuindizierung für die Dokumentenzählung ist nun abgeschlossen. Der nächste Schritt besteht darin, zu überprüfen, ob die Mappings für den neuen Backing-Index und das betreffende Feld korrekt sind.

Zum Beispiel:

Sie können überprüfen, ob das Mapping für log.offset wie unten dargestellt aussieht. Um zu bestätigen, dass andere Felder nur einen einzigen Mapping-Eintrag haben (nicht sowohl text als auch keyword), vergleichen Sie sie mit einem Feld, das nicht Teil des dynamischen Template-Abschnitts im vorherigen PUT-Befehl war.

Wenn der neu indizierte Backing-Index eine große Anzahl von Dokumenten enthält, ist es hilfreich, den Status der Dokumente zu überprüfen, die in den neuen Backing-Index kopiert werden. Dies kann mit den folgenden beiden Dev Tools-Befehlen zum Vergleich der Zählungen erfolgen.

GET .ds-logs-filestream.generic-default-2026.04.14-000001/_count

GET .ds-logs-filestream.generic-default-2026.04.14-000001-1/_count

Sobald die Zählungen als übereinstimmend verifiziert wurden und die korrekten Mappings vorhanden sind, aktualisieren Sie den Datenstrom, um den neuen zugrunde liegenden Index zu integrieren. Dadurch wird verhindert, dass ein verwaister zugrunde liegender Index in der Indexverwaltung entsteht, bei dem die ILM-Richtlinie niemals auf den zugrunde liegenden Index angewendet wird.

• Die Rückgabe sollte im Erfolgsfall eine Bestätigung von true sein.

Überprüfen Sie mit folgendem Befehl, ob der neue Backing-Index hinzugefügt wurde und ob die ilm_policy korrekt ist:

Überprüfen Sie als Nächstes den ILM-Status des Backing-Index mit folgendem Befehl:

• Es ist normal, dass der Index als heiß angezeigt wird, da er gerade erst erstellt wurde (überprüfen Sie Zeile 8 oder 10).

Führen Sie Folgendes aus, um den Backing-Index von der heißen Ebene auf die nächste geeignete Ebene zu übertragen, die nach der heißen Ebene für die ILM-Richtlinie für diesen Datenstrom liegt. Die spezifischen Werte für phase, action und name in den folgenden current_step können in den Zeilen 11, 13 und 15 im obigen Screenshot nachgeschlagen werden.

Der next_step-Wert gibt die anschließende ILM-Phase oder Datenebene an, zu der der Index übergeht.

Zum Beispiel:

• Es ist nicht zwingend notwendig, aber als Sicherheitsmaßnahme können Sie den Befehl _ilm/explain erneut ausführen, um sicherzustellen, dass sich der Backing-Index in die nächste Phase verschoben hat und sich nicht mehr in der heißen Phase befindet.

Sobald die folgenden Bedingungen erfüllt sind, können Sie den ursprünglichen Backing-Index, der Mapping-Konflikte aufwies, sicher löschen:

1. Ein neuer Backing-Index wurde erfolgreich erstellt.
2. Dokumente wurden in den neuen Index verschoben, und die Dokumentanzahlen stimmen überein.
3. Die Mappings wurden korrigiert (sowohl datenstromspezifisch als auch ECS-spezifisch).
4. Der Datenstrom beinhaltet den neuen Backing-Index.
5. Die ILM-Richtlinie wurde angewendet und der Index hat die heiße Phase überwunden.

Wichtig: Alternativ können Sie vor dem Löschen des ursprünglichen Index die Seite Data Views überprüfen. Wählen Sie logs-* aus und überprüfen Sie, dass der neuindizierte Backing-Index (der auf -1endet) nun im Abschnitt long erscheint. Der ursprüngliche Backing-Index sollte unter keywordnoch vorhanden sein. Wenn der neuindizierte Backing-Index nicht im long-Abschnitt enthalten ist, gehen Sie zurück, überprüfen die vorherigen Schritte und nehmen gegebenenfalls Korrekturen vor.

Zum Beispiel:

Nachdem Sie die Konflikte gelöst haben, kehren Sie zur Seite Data Views zurück und wählen Sie logs-* aus. Wenn der Konflikt ausschließlich mit log.offset zusammenhängt, sollten keine Konflikte mehr aufgeführt sein. Wenn es weitere Konflikte gab, sollte der ursprüngliche Backing-Index nicht mehr in der Konfliktliste erscheinen. Stattdessen sollte der neue Backing-Index nun im Abschnitt long aufgeführt werden.

Sie können auch in Discover überprüfen, ob das log.offset-Feld jetzt die entsprechenden Symbole anzeigt.

Führen Sie diesen Prozess fort, indem Sie die obigen Schritte für jeden Backing-Index wiederholen, der einen Mapping-Konflikt aufweist, bis alle erfolgreich gelöst sind.

Referenzen:

• Referenz zu den ECS-Feldern
• Dokumente neu indexieren

Fazit

Indem Sie die Schritte in diesem Blog befolgen, lösen Sie Mapping-Konflikte und stellen sicher, dass alle neuen Daten korrekt zugeordnet sind. Dafür verknüpfen Sie die erforderlichen Komponentenvorlagen mit Ihrer Datenquelle. Dieser Workflow behebt nicht nur die unmittelbaren Probleme, sondern etabliert auch einen sicheren und wiederholbaren Prozess zur Verwaltung von Schemaänderungen, während sich Ihre Daten und Anforderungen weiterentwickeln.