Belajar Elasticsearch - Index Lifecycle Management (ILM)

#Pendahuluan

Data time-series seperti log dan metrik tumbuh terus-menerus tanpa henti. Jika semua index diperlakukan sama — disimpan di storage cepat, memiliki banyak replica — biaya storage akan meledak. Padahal nilai data tidak konstan: log kemarin sangat sering diakses, log 3 bulan lalu hampir tidak pernah dibuka, dan log 2 tahun lalu cukup disimpan untuk compliance. Index Lifecycle Management (ILM) menjawab masalah ini: mengotomatiskan perjalanan index dari "panas dan cepat" ke "dingin dan murah" berdasarkan umur dan ukuran. Episode 10 membahas arsitektur hot-warm-cold-frozen, fase-fase ILM, rollover, pembuatan dan penempelan policy, index priority, allocation filtering, serta searchable snapshots untuk tier frozen.

#Konsep ILM dan Arsitektur Tier

ILM memperlakukan index seperti barang dengan nilai yang menurun seiring waktu. Setiap tier (tingkatan) punya karakteristik storage berbeda:

Tier	Karakteristik	Contoh
hot	Aktif ditulis dan sering dibaca; SSD cepat	Index hari ini
warm	Tidak lagi ditulis, tapi sering dibaca	Index 1–30 hari lalu
cold	Jarang dibaca, dikompresi, storage murah	Index 1–6 bulan lalu
frozen	Sangat jarang diakses; hanya via searchable snapshot	Index > 6 bulan
delete	Data kadaluarsa; dihapus untuk compliance	Tidak lagi dibutuhkan

Tier ini diimplementasikan lewat data node dengan atribut data tier (data_hot, data_warm, data_cold, data_frozen). Allocation filtering di fase ILM mengarahkan index ke node yang tepat.

#Fase-Fase ILM dan Rollover

#Rollover

Dengan pola index berbasis tanggal, kalian tidak ingin membuat index baru secara manual. Rollover otomatis membuat index baru saat index lama mencapai kondisi tertentu — misalnya berumur 7 hari atau berukuran 50 GB:

Kondisi rollover dalam policy ILM

{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": { "max_age": "7d", "max_size": "50gb", "max_primary_shard_size": "20gb" }
        }
      }
    }
  }
}

Mengapa rollover penting? Index yang dibiarkan membesar tanpa batas akan sulit dikelola dan memperlambat pencarian. Dengan rollover, tiap index "generasi" berukuran terkendali, dan ILM bisa memperlakukan tiap generasi secara berbeda.

#Fase Hot, Warm, Cold, Frozen, Delete

Policy ILM lengkap lima fase

{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": { "rollover": { "max_age": "7d", "max_size": "50gb" }, "set_priority": { "priority": 100 } }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "shrink": { "number_of_shards": 1 },
          "forcemerge": { "max_num_segments": 1 },
          "allocate": { "number_of_replicas": 1, "include": { "data_tier_preference": "data_warm" } },
          "set_priority": { "priority": 50 }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": { "allocate": { "include": { "data_tier_preference": "data_cold" } }, "set_priority": { "priority": 0 } }
      },
      "frozen": {
        "min_age": "90d",
        "actions": { "searchable_snapshot": { "snapshot_repository": "backup-s3" } }
      },
      "delete": { "min_age": "365d", "actions": { "delete": {} } }
    }
  }
}

Mari baca alurnya: index hidup 7 hari atau sampai 50 GB di tier hot (prioritas tulis 100), lalu masuk warm (di-shrink jadi 1 shard, di-force-merge, prioritas turun ke 50), setelah 30 hari masuk cold dengan prioritas 0, setelah 90 hari berubah menjadi searchable snapshot di tier frozen, dan akhirnya dihapus setelah 1 tahun.

Important

Shrink (mengurangi jumlah shard) dan force merge hanya dilakukan di fase warm, ketika index tidak lagi menerima tulis. Melakukan force merge di fase hot akan mengganggu proses tulis dan memboroskan resource. Urutan fase di atas bukan sekadar saran — ini pola yang sudah terbukti di production.

#Membuat dan Menempelkan Policy

#Membuat Policy

Buat policy ILM

PUT /_ilm/policy/logs-policy

Dengan body policy JSON di atas. Policy yang sama bisa dipakai banyak index.

#Menempelkan Policy ke Index

Sertakan policy saat membuat index

PUT /logs-2026.08.03

Settings index dengan policy ILM

{
  "settings": {
    "index.lifecycle.name": "logs-policy",
    "index.lifecycle.rollover_alias": "logs",
    "index.routing.allocation.include.data_tier": "data_hot",
    "index.number_of_shards": 2,
    "index.number_of_replicas": 1
  }
}

Ada dua cara menempel: lewat settings saat membuat index, atau lebih baik lagi — otomatis lewat index template (episode 4 dan 11), agar tidak ada index yang "lolos" dari manajemen lifecycle.

#Index Priority dan Allocation Filtering

Index priority (0–100) menentukan urutan pemulihan saat cluster melakukan recovery — misalnya setelah restart massal. Index dengan prioritas lebih tinggi dipulihkan lebih dulu. Fase hot punya prioritas tertinggi karena datanya paling aktif.

Allocation filtering mengontrol di node mana index boleh ditempatkan. Dalam policy, aksi allocate dengan include/exclude memindahkan index ke tier yang benar. Ini juga berguna untuk maintenance: POST /_cluster/allocation/explain membantu mencari tahu mengapa sebuah shard belum ter-assign.

#Searchable Snapshot untuk Tier Frozen

Fase frozen memakai searchable snapshot: index yang datanya hidup di repository snapshot (S3, misalnya), dengan sebagian kecil metadata dan cache lokal di node. Hasilnya: penyimpanan yang sangat murah, sementara pencarian masih mungkin — hanya dengan latensi lebih tinggi karena data harus di-fetch dari storage dingin saat pertama kali diakses (lalu di-cache).

Ini trade-off menarik: data 2 tahun bisa disimpan hampir gratis, dan jika suatu hari dibutuhkan untuk investigasi compliance, datanya tetap bisa dicari. Episode 20 akan membahas snapshot secara menyeluruh.

#Monitoring ILM

ILM berjalan di background; pastikan kalian bisa melihat progresnya:

Cek fase yang sedang dijalankan tiap index

GET /_ilm/explain/logs-*

Ringkasan explain ILM

{
  "indices": {
    "logs-2026.08.03": {
      "index": "logs-2026.08.03", "managed": true, "policy": "logs-policy",
      "phase": "hot", "action": "rollover", "step": "check-rollover-ready"
    }
  }
}

_ilm/explain menunjukkan policy mana yang menempel, fase apa yang sedang berjalan, dan langkah apa yang dieksekusi. Jika ada error, field step_info memuat detailnya — ini alat debugging utama saat policy tidak berjalan sesuai harapan.

Tip

Saat menulis policy baru, jangan langsung terapkan ke index production. Buat index uji kecil, lampirkan policy, lalu pantau _ilm/explain sampai melewati semua fase. ILM yang keliru — misalnya rollover yang terlalu cepat atau delete yang terlalu dini — bisa menghabiskan storage atau menghapus data berharga.

#Kesalahan Umum

Rollover tanpa alias. Rollover butuh index.lifecycle.rollover_alias yang menunjuk ke alias yang berisi index tersebut.
Force merge di fase hot. Mencekik performa tulis. Lakukan hanya di warm.
Tier tidak ada di cluster. Jika tidak ada node data_cold, index cold tidak bisa di-allocate — cek ketersediaan node sesuai tier.
Prioritas default semua sama. Jika semua index prioritasnya sama, urutan recovery tidak terkontrol. Set prioritas berbeda per fase.
Mengubah policy tidak memicu re-evaluasi instan. ILM mengevaluasi secara berkala — butuh beberapa menit sebelum aksi baru berjalan.

#Penutup

Di episode 10 kalian menguasai ILM: arsitektur hot-warm-cold-frozen, fase-fase dengan aksinya masing-masing (rollover, shrink, force merge, allocate, searchable_snapshot, delete), pembuatan dan penempelan policy lewat index template, index priority, allocation filtering, searchable snapshots untuk tier frozen, serta monitoring dengan _ilm/explain.

Inti yang harus dibawa pulang:

ILM mengotomatiskan siklus hidup index sesuai umur dan ukuran.
Rollover menjaga ukuran index terkendali; lakukan di fase hot.
Shrink dan force merge adalah aksi fase warm.
Tier frozen memakai searchable snapshot untuk storage termurah.
Policy ditempel lewat template agar semua index ter-manage.
_ilm/explain adalah alat debugging utama ILM.

ILM dan pola index berbasis tanggal membawa kita pada konsep berikutnya. Di episode 11 kita bahas data streams dan time-series data: perbedaan data stream vs index biasa, backing indices, rollover otomatis, template data stream, mode TSDB dengan dimension dan metrics, downsampling, serta runtime fields. Sampai jumpa!