
- ILM automatisiert den Lebenszyklus Ihrer Elasticsearch-Indizes: von der Erstellung bis zur Löschung.
- Die vier Phasen Hot, Warm, Cold und Delete optimieren Speicher und Performance.
- Rollover verhindert unkontrolliert wachsende Indizes und hält die Suche schnell.
- Konfigurieren Sie ILM über Kibana oder die REST-API – ohne zusätzliche Kosten.
- Fehler wie fehlende Aliasse oder falsche min_age-Werte lassen sich vermeiden.
Warum ILM für Ihre Elasticsearch-Cluster unverzichtbar ist
Wenn Sie Elasticsearch betreiben, kennen Sie das Problem: Mit der Zeit wachsen die Indizes unkontrolliert, Speicher wird knapp, und die Suchleistung nimmt spürbar ab. Genau hier setzt das Index Lifecycle Management (ILM) an – eine Funktion, die den gesamten Lebenszyklus Ihrer Indizes automatisiert. Ich zeige Ihnen, wie Sie ILM Schritt für Schritt konfigurieren.
Kurz gesagt :
- ILM automatisiert den Lebenszyklus von Elasticsearch-Indizes über die vier Phasen Hot, Warm, Cold und Delete, um Speicher und Performance zu optimieren.
- Rollover begrenzt das Indexwachstum durch Kriterien wie max_size, max_age oder max_docs und erfordert einen Alias mit Schreibrechten.
- Die Konfiguration erfolgt über Kibana oder die REST-API, z. B. mit PUT _ilm/policy, ohne zusätzliche Kosten.
- Häufige Fehler wie fehlende Aliasse oder falsche min_age-Werte lassen sich durch klare Anforderungsdefinition und Überwachung vermeiden.
Was ist Index Lifecycle Management?
ILM ist ein eingebautes Framework von Elasticsearch, das Indizes automatisch durch verschiedene Lebensphasen führt. Es ist ein entscheidendes Werkzeug für das Informationslebenszyklus-Management (ILM) Ihrer Daten.
| Phase | Zweck | Typische Aktionen |
|---|---|---|
| Hot | Aktive Schreib- und Lesezugriffe | Hohe Replikation, SSD-Speicher |
| Warm | Lesezugriffe, keine Schreibzugriffe | Reduzierte Replikation, günstigerer Speicher |
| Cold | Seltene Zugriffe, Archivierung | Read-only, komprimierte Daten |
| Delete | Endgültige Entfernung | Vollständige Löschung nach Ablauf |
Die vier Phasen sind das Herzstück von ILM. Sie bestimmen, wie Ihre Daten behandelt werden, je nachdem, wie aktuell und wie häufig sie benötigt werden. Ich empfehle, sich mit diesen Phasen vertraut zu machen, bevor Sie mit der Konfiguration beginnen.
Wie definieren Sie Ihre Anforderungen?
Bevor Sie eine ILM-Policy erstellen, sollten Sie sich folgende Fragen stellen:
- Wie groß sind Ihre täglichen Datenmengen? (z. B. 5 GB Logdaten pro Tag)
- Wie lange müssen Daten im Hot-Speicher bleiben? (z. B. 7 Tage für aktive Analyse)
- Wann werden Daten nur noch selten benötigt? (z. B. nach 30 Tagen)
- Wie lange müssen Daten aus Compliance-Gründen aufbewahrt werden? (z. B. 12 Monate)
Diese Fragen sind entscheidend, um die richtigen Parameter für Ihre Policy festzulegen. Ich rate Ihnen, diese Anforderungen schriftlich zu fixieren – das erleichtert die spätere Anpassung.
Wie erstellen Sie Ihre erste ILM-Policy?
Die Erstellung einer ILM-Policy erfolgt über die Kibana-Oberfläche oder die REST-API. Ich zeige Ihnen die API-Variante, da sie sich gut automatisieren lässt.
Zunächst definieren Sie die Grundstruktur Ihrer Policy. Ein Beispiel für eine einfache Log-Policy:
PUT _ilm/policy/meine_log_policy
{ "policy": { "phases": { "hot": { "actions": { "rollover": { "max_size": "50GB", "max_age": "30d" } } }, "delete": { "min_age": "90d", "actions": { "delete": {} } } } }
}Diese Policy definiert, dass Indizes nach 50 GB oder 30 Tagen umgeschaltet werden und nach 90 Tagen gelöscht werden. Ich empfehle, die Werte an Ihre eigenen Anforderungen anzupassen.
Wie konfigurieren Sie den Rollover?
Der Rollover ist das Herzstück einer effizienten ILM-Konfiguration. Er sorgt dafür, dass Indizes nicht unbegrenzt wachsen.
Warum ist der Rollover wichtig? Er begrenzt die Indexgröße, verbessert die Performance und erleichtert das Management. Ich habe in der Praxis gesehen, wie Cluster ohne Rollover regelrecht zusammenbrechen – glauben Sie mir, das will niemand erleben.
- Erstellen Sie einen Alias mit Schreibrechten.
- Definieren Sie Rollover-Kriterien wie max_size, max_age oder max_docs.
- Überwachen Sie den Rollover in Kibana.
Ein Beispiel für die Erstellung eines Alias:
PUT /mein-log-000001
{ "aliases": { "mein-log": { "is_write_index": true } }
}Ohne diesen Alias funktioniert der Rollover nicht. Das ist ein häufiger Fehler, den ich oft sehe.
Wie optimieren Sie Warm- und Cold-Phase?
Die Warm- und Cold-Phase sind entscheidend, um Speicherkosten zu senken. Ich zeige Ihnen, wie Sie diese Phasen konfigurieren.
In der Warm-Phase können Sie die Anzahl der Shards reduzieren und Segmente zusammenführen. Ein Beispiel:
{ "policy": { "phases": { "warm": { "min_age": "7d", "actions": { "shrink": { "number_of_shards": 1 }, "forcemerge": { "max_num_segments": 1 } } } } }
}Die Cold-Phase eignet sich für die Archivierung auf kostengünstigem Speicher. In Deutschland nutzen viele Unternehmen AWS S3 in Frankfurt (eu-central-1) oder die Open Telekom Cloud.
Wie richten Sie automatisierte Backups ein?
Eine vollständige ILM-Strategie umfasst auch die Datensicherung. Snapshots sind hier das Mittel der Wahl.
Zunächst erstellen Sie ein Snapshot-Repository:
PUT _snapshot/mein_repo
{ "type": "fs", "settings": { "location": "/mount/backups", "compress": true }
}Dann können Sie einen Snapshot-Lifecycle einrichten, der regelmäßig Snapshots erstellt und alte löscht. Ein Beispiel:
PUT _slm/policy/naechtlicher_snapshot
{ "schedule": "0 30 2 * * ?", "name": "snapshot-{now/d}", "repository": "mein_repo", "config": { "indices": ["mein-log-*"], "ignore_unavailable": true }, "retention": { "expire_after": "30d", "min_count": 5, "max_count": 50 }
}Diese Konfiguration erstellt täglich um 2:30 Uhr einen Snapshot und behält die letzten 30 Tage.
Wie überwachen Sie Ihre ILM-Policies?
Eine Konfiguration ist nur so gut wie ihre Überwachung. In Kibana können Sie den Zustand Ihrer Policies einsehen.
Wichtige Kennzahlen sind die Anzahl der Indizes pro Phase, fehlgeschlagene Aktionen und der Speicherverbrauch. Ich empfehle, Alerts einzurichten, um bei Problemen sofort benachrichtigt zu werden.
Hier sind einige nützliche API-Abfragen:
- GET _ilm/policy – alle Policies anzeigen
- GET mein-log-*/_ilm/explain – Status einer Policy prüfen
- GET _ilm/status – Fehler in ILM-Aktionen anzeigen
Welche Fehler sollten Sie vermeiden?
Ich habe in meiner Beratungspraxis viele Fehler gesehen, die Sie leicht vermeiden können. Hier sind die häufigsten:
- Fehlender Rollover-Alias – ohne Alias funktioniert der Rollover nicht.
- Zu kurze min_age-Werte – Indizes werden zu schnell gelöscht.
- Policy-Änderungen wirken nicht sofort – sie werden erst beim nächsten Zyklus angewendet.
- Shrink schlägt fehl, wenn der neue Shard zu groß wird.
- Snapshot-Repository nicht erreichbar – Cold-Phase-Aktionen schlagen fehl.
Diese Fehler können zu Datenverlust oder Performance-Problemen führen. Ich rate Ihnen, diese Punkte vor dem Produktivgang zu testen.
Was sind Best Practices für Produktionsumgebungen?
Für den produktiven Einsatz empfehlen sich zusätzliche Optimierungen. Hier sind meine empfohlenen Standardwerte:
| Parameter | Empfehlung | Begründung |
|---|---|---|
| max_size | 30–50 GB | Optimale Balance zwischen Performance und Verwaltung |
| max_age | 7–14 Tage | Ermöglicht regelmäßige Archivierung |
| number_of_replicas (Hot) | 1–2 | Redundanz für aktive Daten |
| number_of_replicas (Warm) | 0–1 | Kosteneinsparung bei seltenen Zugriffen |
| forcemerge | 1 Segment | Maximale Komprimierung für Lesezugriffe |
Diese Werte haben sich in meinen Projekten bewährt. Sie können sie natürlich an Ihre spezifischen Anforderungen anpassen.
Wie beantworten Sie häufige Fragen?
Hier sind Antworten auf die häufigsten Fragen, die mir in meiner Arbeit begegnen.
Wie lange dauert es, bis eine ILM-Policy angewendet wird?
Die Überprüfung erfolgt standardmäßig alle 10 Minuten. Sie können das Intervall anpassen, für Tests empfehle ich ein kürzeres Intervall.
Kann ich ILM auch für bestehende Indizes nutzen?
Ja, Sie können eine Policy nachträglich zuweisen. Die Phasen werden ab dem aktuellen Alter des Indizes berechnet.
Was passiert, wenn eine ILM-Aktion fehlschlägt?
Elasticsearch wiederholt fehlgeschlagene Aktionen automatisch. Nach mehreren Fehlversuchen wird der Index in den ‘error’-Status versetzt. Sie können mit POST /mein-index/_ilm/retry einen manuellen Neustart auslösen.
Kann ich ILM in der kostenlosen Version nutzen?
Ja, ILM ist in allen Elasticsearch-Versionen enthalten, auch in der kostenlosen Basic-Lizenz. Einige erweiterte Funktionen wie searchable_snapshot erfordern jedoch eine kostenpflichtige Lizenz.
Wie kann ich testen, ob meine Policy korrekt funktioniert?
Erstellen Sie einen Test-Index mit einem kurzen min_age und beobachten Sie das Verhalten in Kibana. Setzen Sie danach die Werte auf Ihre Produktionswerte zurück.
Mein Fazit: Mit ILM zu einem wartungsarmen Cluster
Index Lifecycle Management ist kein optionales Extra, sondern ein essenzielles Werkzeug für jeden ernsthaften Elasticsearch-Betrieb. Mit den hier vorgestellten Schritten können Sie Ihre Indizes automatisiert verwalten, Speicherkosten senken und die Performance stabil halten. Die wichtigsten Erkenntnisse zusammengefasst: Verstehen Sie die vier Phasen, planen Sie Ihre Datenlebenszyklen sorgfältig, nutzen Sie Rollover, kombinieren Sie ILM mit Snapshots und überwachen Sie Ihre Policies regelmäßig. Starten Sie noch heute mit einer einfachen Policy für Ihre Logdaten. Ihr Elasticsearch-Cluster wird es Ihnen danken.
ILM arbeitet Hand in Hand mit der Indexierung, daher sollten Sie auch die Elasticsearch-Indexierung optimieren, um die Gesamtleistung Ihres Clusters zu verbessern.




