Elasticsearch:Error restart atau pembaruan kluster

Mendiagnosis masalah

Periksa status kesehatan kluster:

GET /_cat/health?v

Jika statusnya red atau yellow, identifikasi shard yang tidak ditugaskan:

GET /_cat/shards?v&h=index,shard,prirep,state,node,unassigned.reason&s=state

Untuk memahami mengapa shard tertentu tidak dapat dialokasikan, jalankan:

GET _cluster/allocation/explain

Perintah ini mengembalikan error jika tidak ada shard yang tidak ditugaskan di kluster. Ini merupakan perilaku yang diharapkan.

Contoh output:

{
  "index": "my-index-02",
  "shard": 0,
  "primary": true,
  "current_state": "unassigned",
  "can_allocate": "no",
  "allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes"
}

Gunakan bidang allocate_explanation untuk mengidentifikasi akar penyebabnya. Penyebab umum dan solusinya dijelaskan di bawah ini.

Upaya alokasi ulang shard telah habis

Shard dialokasikan secara otomatis dengan maksimal lima kali percobaan. Jika semua percobaan telah habis, alokasikan ulang shard secara manual:

POST /_cluster/reroute?retry_failed=true

Shard primary dan replika berada di node yang sama

Jika penjelasan alokasi menyatakan "the shard cannot be allocated to the same node on which a copy of the shard already exists", berarti shard primary dan replika dari suatu indeks berada di node yang sama. Untuk mengatasi hal ini:

1. Tetapkan jumlah shard replika menjadi 0:

      PUT /my-index/_settings
      {
        "index": {
          "number_of_replicas": 0
        }
      }

2. Setelah status kluster kembali menjadi green, atur kembali jumlah replika menjadi 1:

      PUT /my-index/_settings
      {
        "index": {
          "number_of_replicas": 1
        }
      }

Batas maksimum alokasi shard simultan tercapai

Jika kluster telah mencapai batas alokasi shard-nya, tunggu hingga alokasi saat ini selesai. Jika shard tetap tidak ditugaskan setelah beberapa menit, periksa penjelasan alokasi:

GET _cluster/allocation/explain

Node terputus koneksi

Satu atau beberapa node mungkin terputus dari kluster. Periksa status node:

GET _cat/nodes?v

Jika ada node yang tidak muncul dalam output, restart node tersebut dari Konsol Elasticsearch.

Penggunaan disk tinggi

Elasticsearch tidak mengalokasikan shard ke node yang penggunaan disk space-nya melebihi 85%. Setelah penggunaan disk pada node yang terpengaruh turun di bawah 85%, restart node tersebut untuk mengembalikan alokasi shard normal.

Untuk memeriksa penggunaan disk per node:

GET _cat/allocation?v

Untuk mengurangi penggunaan disk:

• Hapus indeks historis yang tidak diperlukan lagi.

• Perluas kapasitas disk node.

• Sementara waktu, atur jumlah shard replika menjadi 0.

Penggunaan memori heap tinggi

Penggunaan memori heap yang tinggi dapat menyebabkan kluster menangguhkan operasi. Untuk membebaskan memori:

• Terapkan pembatasan kecepatan (throttling) untuk mengurangi lalu lintas masuk.

• Tutup indeks historis untuk mengurangi konsumsi memori.

Penyebab lainnya

Jika tidak ada penyebab di atas yang berlaku, periksa utilisasi CPU dan penggunaan memori heap di Konsol Elasticsearch. Untuk shard yang tidak ditugaskan, jalankan perintah berikut untuk penjelasan detail:

GET _cluster/allocation/explain

Penggunaan disk mencapai 85%

Diagnosis:

• Periksa data pemantauan penggunaan disk di Konsol Elasticsearch.

• Jalankan GET _cat/allocation untuk melihat alokasi disk per node.

• Jalankan GET _cluster/allocation/explain untuk memeriksa masalah alokasi.

• Periksa log kluster untuk peringatan terkait disk.

Dampak: Saat penggunaan disk mencapai 85%, Elasticsearch berhenti mengalokasikan shard baru ke node yang terpengaruh.

Solusi:

• Hapus indeks historis yang tidak diperlukan lagi.

• Perluas kapasitas disk.

• Sementara waktu, atur jumlah shard replika menjadi 0.

Setelah tindakan diambil, pastikan penggunaan disk telah turun di bawah 85% dalam data pemantauan.

Utilisasi CPU mencapai 85%

Diagnosis:

• Periksa data pemantauan utilisasi CPU di Konsol Elasticsearch.

• Tinjau informasi hot thread untuk mengidentifikasi operasi yang intensif CPU.

Dampak: Utilisasi CPU yang tinggi menurunkan stabilitas kluster.

Solusi:

• Periksa read QPS dan write QPS dalam data pemantauan, lalu kurangi lalu lintas jika memungkinkan.

• Lakukan scale out kluster dengan menambahkan data node.

• Tingkatkan konfigurasi kluster menggunakan tipe instans yang lebih besar.

Penggunaan memori heap mencapai atau melebihi 75%

Diagnosis:

• Periksa data pemantauan penggunaan memori heap di Konsol Elasticsearch.

• Tinjau log kluster untuk peringatan garbage collection (GC).

• Periksa metrik old gc collection count dan old gc collecting.ms untuk jeda GC yang panjang.

Dampak: Penggunaan memori heap yang tinggi menurunkan stabilitas kluster dan dapat menyebabkan operasi hang.

Solusi:

• Kurangi lalu lintas baca dan tulis.

• Tingkatkan konfigurasi kluster.

• Tutup indeks historis untuk membebaskan memori heap.

Beban node melebihi jumlah vCPU

Mendiagnosis:

• Periksa metrik NodeLoad_1m(value) di Konsol Elasticsearch.

• Nilai yang lebih besar dari jumlah vCPU pada node menunjukkan beban berat.

Dampak: Node yang kelebihan beban dapat menjadi tidak responsif dan memengaruhi operasi kluster.

Solusi:

• Periksa read QPS, write QPS, dan throughput disk dalam data pemantauan.

• Kurangi lalu lintas baca atau tulis.

• Lakukan scale out kluster dengan menambahkan data node.

• Tingkatkan konfigurasi kluster.

Kesalahan konfigurasi box_type pada arsitektur hot-warm

Diagnosis:

• Pada arsitektur hot-warm, suatu indeks menggunakan pengaturan box_type untuk menentukan apakah shard-nya dialokasikan ke node panas (hot nodes) atau node hangat (warm nodes). Nilai box_type yang salah mencegah alokasi shard dan memperlambat restart atau pembaruan.

• Jalankan GET /{index_name}/_settings untuk memeriksa pengaturan box_type dalam pengaturan indeks.

Dampak: Jika box_type tidak sesuai dengan tipe node aktual, shard tidak dapat dialokasikan, sehingga memperlambat restart atau pembaruan.

Solusi:

• Pastikan nilai box_type sesuai dengan tipe node target: gunakan hot untuk node panas dan warm untuk node hangat.

routing menentukan bidang _id

Mendiagnosis:

• Jika pengaturan routing suatu indeks menentukan bidang _id, shard tidak dapat dialokasikan seperti yang diharapkan, sehingga memperlambat restart atau pembaruan.

• Jalankan GET /{index_name}/_settings untuk memeriksa pengaturan index.routing.

Dampak: Shard gagal dialokasikan secara normal.

Solusi:

• Jika routing menentukan bidang _id, atur nilainya menjadi null untuk mengembalikan alokasi shard normal.