Wenn TSDS auf ILM trifft: Gestaltung von Zeitreihendatenströmen, die verspätete Daten nicht ablehnen

Kürzlich habe ich den Metrik-Cluster eines Kunden von „alles in der Hot-Tier-Ebene“ auf eine Heiß-Kalt-Eingefroren-Architektur migriert. Es war eine Veränderung, die ich schon dutzende Male zuvor vorgenommen hatte. Innerhalb weniger Minuten stellte Logstash die Datenübertragung vollständig ein.

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.