Belajar Elasticsearch - Monitoring & Observability

#Pendahuluan

Backup (episode 20) melindungi dari kehilangan data — tapi bagaimana mendeteksi masalah sebelum menjadi insiden? Bagaimana tahu disk hampir penuh, heap mendekati penuh, atau query mulai lambat? Jawabannya ada di monitoring dan observability: API pemantauan bawaan (cluster health, node stats, index stats, cat APIs), metrik yang wajib dipantau (JVM, indexing/search rates, thread pool rejections, circuit breaker trips), serta tools monitoring — Kibana, alerting, Metricbeat, dan Prometheus/Grafana.

#API Pemantauan Bawaan

#Cluster Health

GET /_cluster/health adalah detak jantung pertama (episode 3). Untuk pandangan cepat multi-node:

GET /_cluster/health?level=indices&timeout=30s
{
  "cluster_name": "my-cluster",
  "status": "yellow",
  "number_of_nodes": 3,
  "active_primary_shards": 30,
  "active_shards": 45,
  "relocating_shards": 0,
  "unassigned_shards": 15
}

Status yellow dengan unassigned_shards 15 menandakan replica belum ter-assign — misalnya karena hanya 1 dari 3 node yang punya data. Status red adalah darurat.

#Node Stats dan Index Stats

_nodes/stats menampilkan metrik per node — CPU, heap, thread pools, I/O:

GET /_nodes/stats/jvm,thread_pool,os

_stats menampilkan metrik per index — jumlah dokumen, ukuran, kecepatan indexing/search:

GET /logs-*/_stats?filter_path=indices.*.primaries.indexing,indices.*.primaries.search

#Cat APIs

Cat APIs menyajikan output tabel human-readable — paling praktis untuk shell:

GET /_cat/nodes?v&h=name,node.role,heap.percent,ram.percent,cpu,load_1m

Cat APIs yang sering dipakai: _cat/health, _cat/nodes, _cat/shards, _cat/indices, _cat/thread_pool, _cat/allocation.

#Metrik yang Wajib Dipantau

#JVM Heap

Metrik paling penting. Pantau heap.percent dan GC pauses:

GET /_nodes/stats/jvm?filter_path=nodes.*.jvm.mem,nodes.*.jvm.gc

Ambatang alarm yang wajar: heap di bawah 75% (ideal), GC pause kurang dari 1 detik. Heap mendekati 100% atau promotion failed yang sering adalah sinyal masalah serius.

#Indexing dan Search Rates

Kecepatan rata-rata indexing (indexing.index_total) dan search (search.query_total) per detik menunjukkan volume dan tren. Kenaikan tiba-tiba bisa berarti beban naik; penurunan tiba-tiba bisa berarti node bermasalah.

#Thread Pool Rejections

Metrik thread_pool punya counter rejection:

GET /_nodes/stats/thread_pool?filter_path=nodes.*.thread_pool.write.rejected,nodes.*.thread_pool.search.rejected

Rejection adalah alarm paling serius — menandakan node kewalahan dan mulai menolak request (episode 14). Nol rejection adalah target; rejection yang naik terus berarti sudah waktunya scaling.

#Circuit Breaker Trips

_nodes/stats/breaker (episode 14) menunjukkan berapa kali breaker memblokir request. Breaker yang sering trip berarti query/aggregation boros memori — benahi penyebabnya, bukan naikkan batasnya.

#Kibana Monitoring dan Alerting

#Stack Monitoring

Kibana punya modul Stack Monitoring yang menampilkan dashboard lengkap kesehatan cluster dari data yang dikumpulkan Metricbeat. Aktifkan dulu di sisi Elasticsearch:

xpack.monitoring.collection.enabled: true

Lalu di Kibana: Management → Stack Monitoring. Di sana kalian melihat health, shard distribution, heap, indexing rates, dan lag antar node dalam satu layar.

#Alerting

Alerting (dulu Watcher) membuat notifikasi otomatis saat kondisi terpenuhi:

{
  "name": "Heap terlalu tinggi",
  "condition": {
    "script": {
      "source": "ctx.monitoring.cluster.elasticsearch.cluster_stats.indices.fielddata.memory_size_in_bytes > 1073741824"
    }
  },
  "actions": {
    "email_admin": {
      "email": {
        "to": ["oncall@example.com"],
        "subject": "Heap tinggi"
      }
    }
  }
}

Di Kibana 8.x, alert dibuat lewat Management → Stack Management → Alerts and Insights dengan UI — mencakup threshold untuk CPU, heap, disk, dan rejection. Rule yang bagus: alert yang spesifik, actionable, dan tidak noise.

#Metricbeat dan Elastic APM

#Metricbeat

Metricbeat adalah agent ringan yang mengumpulkan metrik dari banyak sistem — termasuk Elasticsearch itu sendiri:

metricbeat.modules:
  - module: elasticsearch
    metricsets: ["node", "node_stats", "index", "cluster_stats"]
    period: 10s
    hosts: ["https://node1:9200"]
    username: "metricbeat_user"
    password: "secret"

Metricbeat mengirim metrik ke cluster monitoring, memberi data untuk Stack Monitoring dan alerting (episode 24 membahas Beats lebih dalam).

#Elastic APM

Elastic APM memantau performa aplikasi: latensi, throughput, error rate, dan distributed tracing antar service. Integrasinya dengan Elasticsearch menampilkan "query mana yang lambat dan dari aplikasi mana" — data penting saat mengoptimasi performa (episode 19). Episode 26 membahas APM dalam konteks microservices.

#Prometheus dan Grafana

Untuk organisasi yang sudah memakai stack Prometheus/Grafana, Elasticsearch menyediakan endpoint metrik Prometheus:

xpack.monitoring.enabled: false

GET /_prometheus/metrics

Prometheus bisa men-scrape endpoint ini, dan Grafana menampilkannya dalam dashboard kustom. Banyak organisasi memakai keduanya: Prometheus/Grafana untuk platform-wide metrics, Kibana Monitoring untuk konteks Elasticsearch yang lebih dalam.

#Penutup

Di episode 21 kalian menguasai monitoring dan observability: API pemantauan bawaan (cluster health, node stats, index stats, cat APIs), metrik kunci (JVM heap dan GC, indexing/search rates, thread pool rejections, circuit breaker trips), serta tools — Kibana Stack Monitoring, alerting, Metricbeat, Elastic APM, dan Prometheus/Grafana.

Inti yang harus dibawa pulang:

• Mulai dari cat APIs untuk debugging cepat; Stack Monitoring untuk dashboard.
• Rejection dan disk adalah metrik yang paling sering menandakan insiden.
• Baseline membuat metrik bisa dibaca — kumpulkan sebelum insiden.
• Alert yang baik: sedikit, spesifik, dan actionable.
• Kibana dan Prometheus/Grafana bisa dipakai berdampingan.

Satu cluster tidak selalu cukup — organisasi besar sering punya banyak cluster. Di episode 22 kita bahas cross-cluster search dan replication: mengatur remote cluster untuk pencarian lintas cluster, kasus penggunaan data federation, serta cross-cluster replication dengan leader-follower untuk disaster recovery dan geo-distribution, lengkap dengan monitoring replication lag. Sampai jumpa!