Data Streams für zeitbasierte Daten verwalten

1. Das klassische Muster: manuell verwaltete Zeitreihen-Indizes

Vor Data Streams bestand eine Zeitreihen-Verwaltung typischerweise aus mehreren Teilen: einem Index-Template, das für jeden neuen Index mit einem bestimmten Namensmuster wie logs-2026.08.08 automatisch das passende Mapping anwendet, einem Schreib-Alias wie logs-write, der stets auf den aktuellen, beschreibbaren Index zeigt, und einer ILM-Policy, die anhand von Größen- oder Altersbedingungen einen Rollover auslöst und den Alias auf den neu angelegten Index umbiegt.

Diese Konstruktion funktioniert, verlangt aber, dass jeder dieser Teile korrekt zusammenspielt: Das Template muss is_write_index richtig setzen, die ILM-Policy muss auf den richtigen Alias referenzieren, und neue Indizes müssen exakt dem erwarteten Namensmuster folgen, damit Suchanfragen über einen Lese-Alias weiterhin alle relevanten Indizes erfassen. Ein Konfigurationsfehler an irgendeiner dieser Stellen führt oft erst Wochen später zu Problemen, wenn ein Rollover nicht wie erwartet funktioniert.

2. Das Data-Stream-Konzept: ein logischer Name, mehrere Backing-Indizes

Ein Data Stream präsentiert sich nach außen als ein einziger, logischer Name, hinter dem sich eine geordnete Folge versteckter Backing-Indizes verbirgt, benannt nach dem Muster .ds-<stream-name>-<generation>. Schreibvorgänge gehen immer an den aktuell aktiven, letzten Backing-Index, während Lesezugriffe über den Data-Stream-Namen transparent über alle zugehörigen Backing-Indizes hinweg suchen, ohne dass die Anwendung deren genaue Namen kennen muss.

Diese Backing-Indizes sind als versteckte Indizes markiert und tauchen deshalb nicht standardmäßig in _cat/indices auf, was die Übersicht in einem Cluster mit vielen Zeitreihen-Datenströmen deutlich aufräumt. Die Rotation auf einen neuen Backing-Index geschieht automatisch anhand der an den Data Stream gekoppelten Rollover-Bedingungen, ohne dass eine Anwendung selbst einen neuen Index anlegen oder einen Alias umbiegen muss.

3. Ein Data Stream entsteht aus einem Index-Template

Ein Data Stream wird nicht direkt angelegt, sondern implizit durch ein zusammengesetztes Index-Template definiert, das im Feld data_stream eine leere Konfiguration enthält und über ein Namensmuster wie logs-search-queries* auf die passenden Datenströme greift. Sobald das erste Dokument unter diesem Namen geschrieben wird, erstellt Elasticsearch automatisch den Data Stream samt seinem ersten Backing-Index, ganz ohne expliziten Anlage-Befehl.

Jedes Dokument in einem Data Stream benötigt zwingend ein Zeitstempelfeld, standardmäßig @timestamp, das im Mapping als solches deklariert sein muss. Fehlt dieses Feld in einem eingehenden Dokument, lehnt Elasticsearch den Schreibvorgang ab, da die zeitliche Einordnung fester Bestandteil des Data-Stream-Konzepts ist.

PUT _index_template/logs-search-queries-template
{
  "index_patterns": ["logs-search-queries*"],
  "data_stream": {},
  "template": {
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "query": { "type": "keyword" },
        "hits": { "type": "integer" },
        "response_time_ms": { "type": "integer" }
      }
    }
  }
}

4. ILM-Policy-Integration für automatischen Rollover

Die eigentliche Rollover-Logik eines Data Stream stammt aus einer verknüpften ILM-Policy, die im selben Index-Template referenziert wird. Die Policy definiert Bedingungen wie eine maximale Shard-Größe oder ein maximales Alter, bei deren Erreichen automatisch ein Rollover auf einen neuen Backing-Index ausgelöst wird, exakt wie bei klassischen, alias-basierten Zeitreihen, nur ohne dass die Verwaltung des Alias selbst manuell definiert werden muss.

Zusätzlich zur klassischen ILM-Policy existiert seit neueren Versionen eine schlankere, direkt am Data Stream konfigurierbare Datenaufbewahrungsregel für einfache Anwendungsfälle, bei denen ausschließlich eine maximale Aufbewahrungsdauer relevant ist, ohne die volle Flexibilität mehrerer ILM-Phasen wie Warm oder Cold zu benötigen.

5. Schreiben und Lesen: nur Anhängen statt beliebiger Änderungen

Data Streams sind grundsätzlich für anhängende Schreibvorgänge konzipiert: Neue Dokumente werden über die Aktion create hinzugefügt, direkte Updates oder Löschungen einzelner Dokumente über den Data-Stream-Namen selbst sind nur eingeschränkt möglich, da nicht ohne Weiteres feststeht, in welchem der mehreren Backing-Indizes sich ein bestimmtes Dokument befindet.

Für Änderungen an einzelnen Dokumenten muss stattdessen der konkrete Backing-Index adressiert werden, ermittelbar über eine vorherige Suchanfrage, die den Metadaten-Feldnamen des zugehörigen Backing-Index liefert. Für klassische Log- oder Event-Daten, bei denen jedes Dokument nach dem Schreiben unverändert bleibt, spielt diese Einschränkung praktisch selten eine Rolle.

6. Praxisbeispiel: ein Suchanfragen-Log für die spätere Analyse

Ein naheliegender Anwendungsfall für Data Streams ist das Protokollieren von Suchanfragen einer Magento-Suche: Jede eingehende Suchanfrage wird als Dokument mit Feldern wie Suchbegriff, Trefferanzahl, angewendeten Filtern, Antwortzeit und dem zwingenden @timestamp-Feld in einen Data Stream namens logs-search-queries geschrieben, ohne dass sich die Anwendung um Indexrotation oder Aufbewahrung kümmern muss.

Für die spätere Analyse, etwa welche Suchbegriffe häufig zu null Treffern führen oder wie sich die Antwortzeit über die Zeit entwickelt, lassen sich Aggregationen direkt über den Data-Stream-Namen ausführen, als würde es sich um einen einzelnen Index handeln. Die ILM-Policy löscht ältere Backing-Indizes automatisch nach der konfigurierten Aufbewahrungsdauer, sodass das Datenvolumen dauerhaft begrenzt bleibt, ohne manuelles Aufräumen.

POST logs-search-queries/_doc
{
  "@timestamp": "2026-08-08T10:15:30Z",
  "query": "laufschuhe herren",
  "hits": 0,
  "filters": ["category:schuhe"],
  "response_time_ms": 42
}

GET logs-search-queries/_search
{
  "size": 0,
  "query": { "term": { "hits": 0 } },
  "aggs": { "top_zero_hit_terms": { "terms": { "field": "query" } } }
}

7. Der praktische Unterschied zum manuell verwalteten Alias-Muster

Der größte praktische Unterschied liegt in der Fehleranfälligkeit: Beim klassischen Alias-Muster muss jede einzelne Komponente, das Namensmuster neuer Indizes, das korrekte Setzen von is_write_index und die Alias-Referenz in der ILM-Policy, von Hand korrekt konfiguriert und bei Änderungen konsistent gehalten werden. Data Streams kapseln diese Logik vollständig im Template und garantieren strukturell, dass Backing-Indizes korrekt benannt und rotiert werden.

Ein weiterer Unterschied ist die Sichtbarkeit: Während klassische Zeitreihen-Indizes als reguläre, sichtbare Indizes in jeder Cluster-Übersicht erscheinen und potenziell versehentlich direkt beschrieben werden können, sind Backing-Indizes versteckt und für direkte Schreibvorgänge nicht vorgesehen, was die Fehlerquelle einer versehentlichen Schreiboperation am falschen, veralteten Index praktisch ausschließt.

8. Downsampling und Datenaufbewahrung für ältere Backing-Indizes

Für Zeitreihen-Datenströme mit sehr hohem Datenvolumen unterstützt Elasticsearch zusätzlich Downsampling, bei dem ältere Backing-Indizes auf gröbere Zeitintervalle aggregiert werden, etwa von minutengenauen auf stundengenaue Werte, was den Speicherbedarf für historische Daten deutlich reduziert, ohne sie vollständig zu löschen.

Für ein Suchanfragen-Log ist die genaue Einzelanfrage nach einigen Wochen meist weniger relevant als aggregierte Trends, weshalb sich eine ILM-Phase mit Downsampling oder eine reine Löschregel nach Ablauf der Aufbewahrungsfrist gut eignet, je nachdem, ob historische Trendanalysen langfristig gebraucht werden oder nicht.

9. Migration von einem bestehenden Alias-Muster zu Data Streams

Eine bestehende, manuell verwaltete Zeitreihen-Konfiguration lässt sich nicht einfach in einen Data Stream umbenennen, da sich die interne Struktur grundlegend unterscheidet. Ein gangbarer Weg ist, ein neues Index-Template mit Data-Stream-Konfiguration unter einem neuen oder demselben Namensmuster anzulegen, sodass ab einem festgelegten Zeitpunkt neue Schreibvorgänge in den Data Stream fließen, während die alten, klassischen Indizes bis zum Ablauf ihrer eigenen Aufbewahrungsfrist bestehen bleiben.

Für eine vollständige historische Migration lässt sich zusätzlich die Reindex-API einsetzen, um bestehende Alt-Indizes in den neuen Data Stream zu überführen, wobei zu beachten ist, dass jedes migrierte Dokument ein gültiges @timestamp-Feld benötigt und der Zielindex innerhalb des Data Stream korrekt in die Backing-Index-Reihenfolge passt.

10. Zusammenfassung

11. FAQ: Data Streams: Das Wichtigste auf einen Blick