Index Lifecycle Management: ILM-Richtlinien im Detail konfigurieren

1. Warum eine einzelne Rollover-Regel für wachsende Daten nicht reicht

Wer Zeitreihen- oder Logdaten in Elasticsearch verwaltet, kommt an einem grundlegenden Problem nicht vorbei: Ein einzelner, unbegrenzt wachsender Index wird irgendwann zu groß für performante Abfragen und zu unhandlich für Wartungsaufgaben wie Snapshots oder Mapping-Änderungen. Die naheliegende Lösung, den Index regelmäßig per Rollover zu wechseln, löst nur die Hälfte des Problems, denn frische und alte Daten haben völlig unterschiedliche Anforderungen an Hardware, Replikaten-Anzahl und Abfragegeschwindigkeit.

Genau hier setzt Index Lifecycle Management an: Es verbindet die reine Rollover-Mechanik mit einer vollständigen Richtlinie, die festlegt, was mit einem Index in jeder Lebensphase geschehen soll. Statt eines starren Zeitplans entsteht so ein Regelwerk, das automatisch reagiert, sobald ein Index eine bestimmte Größe, ein bestimmtes Alter oder eine bestimmte Dokumentanzahl erreicht, und dabei jede Phase mit exakt den Aktionen versieht, die für die jeweilige Zugriffshäufigkeit sinnvoll sind.

2. Die vier klassischen Phasen: Hot, Warm, Cold und Delete

Eine ILM-Richtlinie gliedert das Leben eines Index in aufeinanderfolgende Phasen. Die Hot-Phase enthält den aktiv beschriebenen Index, auf dem Schreiblast und aktuelle Abfragen konzentriert sind, meist auf performanter Hardware mit SSD-Storage. Die Warm-Phase übernimmt Indizes, die zwar noch abgefragt, aber nicht mehr beschrieben werden, hier lohnen sich Optimierungen wie eine reduzierte Replikaten-Anzahl und eine Verdichtung der Segmente. Die Cold-Phase ist für selten abgefragte Daten gedacht, bei denen eine etwas höhere Latenz akzeptabel ist, während die Delete-Phase am Ende schlicht die endgültige Löschung markiert.

Jede Phase kann eine Mindestdauer definieren, nach der der Übergang zur nächsten Phase geprüft wird, sowie eine eigene Liste von Aktionen. Wichtig ist, dass eine Phase nicht zwingend durchlaufen werden muss: Eine Richtlinie kann problemlos direkt von Hot in Cold springen, wenn eine separate Warm-Phase für den jeweiligen Anwendungsfall keinen Mehrwert bietet, etwa weil Warm- und Cold-Anforderungen ohnehin identisch sind.

3. Rollover-Bedingungen als Trigger für den Phasenübergang

Der Rollover ist die zentrale Aktion der Hot-Phase und entscheidet, wann ein neuer, physischer Index angelegt und der Schreibalias darauf umgehängt wird. Die Bedingungen dafür lassen sich frei kombinieren: eine maximale Indexgröße, eine maximale Anzahl an Primärshard-Größe, ein maximales Alter oder eine maximale Dokumentanzahl. Sobald eine dieser Bedingungen erfüllt ist, löst ILM den Rollover aus, unabhängig davon, ob die anderen Bedingungen noch nicht erreicht wurden.

Diese Kombinierbarkeit ist entscheidend für unregelmäßige Datenmengen: Ein Index mit ungleichmäßigem Traffic, etwa durch saisonale Spitzen, würde bei einer reinen Zeitbedingung entweder zu groß oder zu klein werden. Eine Größenbedingung von etwa fünfzig Gigabyte kombiniert mit einer Altersbedingung von dreißig Tagen sorgt dafür, dass weder ein überdimensionierter Index bei hoher Last noch ein winziger Index bei niedriger Last entsteht, weil jeweils die zuerst erfüllte Bedingung greift.

4. Warm-Phase-Aktionen: Shrink, Force Merge und Allocate

Sobald ein Index nicht mehr beschrieben wird, lohnen sich mehrere Optimierungen, die in der Hot-Phase riskant wären. Die Shrink-Aktion reduziert die Anzahl der Primärshards auf einen kleineren Wert, was bei Indizes sinnvoll ist, die ursprünglich mit vielen Shards für hohe Schreiblast angelegt wurden, deren Datenmenge nach Rollover aber für weniger Shards ausreicht. Die Force-Merge-Aktion verdichtet die Lucene-Segmente auf eine geringere Anzahl und beschleunigt dadurch nachfolgende Leseabfragen spürbar.

Die Allocate-Aktion wiederum steuert, auf welchen Knoten ein Index in dieser Phase liegen soll, etwa auf günstigerer Hardware mit mehr Festplattenspeicher statt schnellem SSD-Speicher, und reduziert zusätzlich häufig die Replikaten-Anzahl von zwei auf eins, da ein etwas geringerer Ausfallschutz für nicht mehr beschriebene Daten meist ausreichend ist. Alle drei Aktionen zusammen sorgen dafür, dass abgeschlossene Indizes deutlich weniger Ressourcen binden als frisch beschriebene.

PUT _ilm/policy/log-lifecycle-policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_primary_shard_size": "40gb",
            "max_age": "7d"
          },
          "set_priority": { "priority": 100 }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "shrink": { "number_of_shards": 1 },
          "forcemerge": { "max_num_segments": 1 },
          "allocate": {
            "number_of_replicas": 1,
            "require": { "data": "warm" }
          },
          "set_priority": { "priority": 50 }
        }
      }
    }
  }
}

5. Die Cold-Phase: Kosteneinsparung ohne weitere strukturelle Eingriffe

In der Cold-Phase geht es primär um Kosteneinsparung, weniger um weitere strukturelle Optimierung der Segmente. Typisch sind eine weitere Reduktion der Replikaten-Anzahl, häufig auf null, sowie die Verlagerung auf noch günstigere Knoten mit langsamerem, aber preiswerterem Speicher. Wichtig ist, dass eine fehlende Replika in dieser Phase ein bewusster Kompromiss ist, denn bei einem Knotenausfall ohne Replika geht der Index verloren, sofern kein aktueller Snapshot existiert. Diese Abwägung gehört daher immer zusammen mit einer funktionierenden Snapshot-Strategie geplant.

Alternativ kann die Cold-Phase einen Index auch als Searchable Snapshot einbinden, statt eine vollständige lokale Kopie zu behalten. Dabei bleiben die Segmentdaten im Objekt-Speicher liegen, während ein gemeinsam genutzter Cache auf den Cold-Knoten häufig abgefragte Blöcke vorhält. Diese Variante senkt den lokalen Speicherbedarf zusätzlich, verwischt aber die Grenze zum später beschriebenen Frozen Tier und sollte deshalb bewusst gegen die tatsächliche Abfragehäufigkeit der jeweiligen Daten abgewogen werden.

6. Die Delete-Phase: unwiderrufliche Löschung nach fester Aufbewahrungsfrist

Die Delete-Phase schließlich benötigt keine weiteren Konfigurationsoptionen außer der Mindestdauer, nach der die Löschung erfolgen soll, etwa neunzig Tage nach Rollover für Log-Daten mit begrenztem regulatorischem Aufbewahrungsbedarf. Wichtig ist, die Mindestdauer der Delete-Phase bewusst so zu wählen, dass sie zur tatsächlichen Aufbewahrungspflicht passt, denn ILM löscht kompromisslos und ohne Rückfrage, sobald die Bedingung erfüllt ist.

Wer neben ILM auch eine SLM-Richtlinie für Sicherungen betreibt, sollte beide Zeitpläne bewusst aufeinander abstimmen: Löscht ILM einen Index, bevor ein passender Snapshot existiert, gehen die betroffenen Daten unwiederbringlich verloren, sobald auch kein aktueller Snapshot mehr vorhanden ist. Eine sinnvolle Reihenfolge stellt sicher, dass der letzte Snapshot vor der endgültigen Löschung des Quellindex bereits erfolgreich abgeschlossen wurde, statt beide Prozesse völlig unabhängig voneinander laufen zu lassen.

7. Praxisbeispiel: vollständige Richtlinie für Log- und Analytics-Daten

Für ein typisches Logging-Szenario mit begrenzter Aufbewahrungsdauer von neunzig Tagen ergibt sich eine vollständige Richtlinie, die alle vier Phasen kombiniert. Der Rollover erfolgt nach vierzig Gigabyte oder einem Tag, je nachdem was zuerst eintritt, was bei Log-Daten mit stark schwankendem Volumen realistisch ist. Nach sieben Tagen wandert der Index in die Warm-Phase, wo Shrink und Force Merge greifen, nach dreißig Tagen folgt die Cold-Phase mit vollständiger Replikaten-Streichung, und nach neunzig Tagen greift die Delete-Phase.

Diese Kombination reduziert den Ressourcenverbrauch über die Lebensdauer der Daten erheblich: Ein Index, der frisch beschrieben mehrere Shards mit zwei Replikaten auf performanten Knoten belegt, benötigt in der Cold-Phase nur noch einen einzelnen, verdichteten Shard ohne Replika auf günstiger Hardware. Für Analytics-Workloads mit Dashboards, die vorwiegend die letzten Tage abfragen, aber gelegentlich historische Vergleiche über Monate benötigen, ist genau dieses gestaffelte Modell der entscheidende Hebel für nachhaltige Cluster-Kosten.

"cold": {
  "min_age": "30d",
  "actions": {
    "allocate": { "number_of_replicas": 0 },
    "set_priority": { "priority": 0 }
  }
},
"delete": {
  "min_age": "90d",
  "actions": {
    "delete": {}
  }
}

8. Monitoring und Fehlerbehandlung mit der ILM Explain API

ILM arbeitet asynchron im Hintergrund, weshalb Sichtbarkeit über den aktuellen Zustand jedes Index unverzichtbar ist. Die Explain API liefert für jeden von einer Richtlinie verwalteten Index die aktuelle Phase, die verbleibende Zeit bis zum nächsten Übergang sowie, im Fehlerfall, eine konkrete Fehlermeldung. Häufige Fehlerursachen sind fehlende Zielknoten für eine Allocate-Aktion, etwa weil kein Knoten mit dem geforderten Attribut existiert, oder ein Shrink-Versuch auf einen Index, dessen Shard-Anzahl bereits kleiner als die Zielgröße ist.

Ein Index, der in einen Fehlerzustand gerät, bleibt in der aktuellen Phase stehen, bis der Fehler behoben und die Aktion über die Retry-API erneut angestoßen wird. Wer ILM produktiv einsetzt, sollte deshalb ein regelmäßiges Monitoring auf den Fehlerzustand aufbauen, denn ein unbemerkt hängen gebliebener Index kann dazu führen, dass Shrink oder Force Merge nie ausgeführt werden und der erwartete Ressourcengewinn ausbleibt, ohne dass dies auf den ersten Blick auffällt.

9. Häufige Fallstricke bei der ILM-Konfiguration

Ein verbreiteter Fehler ist die Verwechslung von min_age mit einer absoluten Uhrzeit: Die Phasendauer bezieht sich auf das Alter des rollover-ausgelösten Index, gemessen ab dem Rollover-Zeitpunkt, nicht ab der Erstellung des allerersten Index in der Sequenz. Ein weiterer typischer Stolperstein ist das Vergessen der set_priority-Aktion, die bei einer Cluster-Neustart-Wiederherstellung bestimmt, in welcher Reihenfolge Indizes wieder verfügbar gemacht werden, ohne sie bleiben Hot- und Delete-Kandidaten gleichrangig, was die Wiederherstellungszeit unnötig verlängert.

Ebenfalls häufig unterschätzt wird die Notwendigkeit, eine ILM-Richtlinie über ein Index-Template mit dem passenden Rollover-Alias zu verknüpfen, bevor der erste Index angelegt wird, denn eine nachträgliche Zuweisung an einen bereits laufenden Index erfordert zusätzliche manuelle Schritte. Schließlich sollte die Force-Merge-Aktion niemals auf einen Index angewendet werden, der noch beschrieben wird, denn ein Force Merge auf einem aktiven Index erzeugt erhebliche I/O-Last und kann die Schreibperformance während der Ausführung deutlich beeinträchtigen.

10. Zusammenfassung

11. FAQ: ILM-Richtlinien in Elasticsearch: Das Wichtigste auf einen Blick