Belajar Elasticsearch - Elasticsearch dalam Microservices Architecture

#Pendahuluan

Arsitektur microservices memecah satu aplikasi besar menjadi puluhan service kecil. Di balik keuntungan deployment yang independen, ada masalah klasik: ketika sesuatu gagal, error bisa muncul di service mana pun — dan mencari sumbernya dari tumpukan log di banyak mesin terasa seperti mencari jarum di jerami. Di sinilah Elasticsearch berperan.

Episode 26 membahas peran Elasticsearch dalam microservices: centralized logging lintas service, praktik structured logging dengan trace IDs, distributed tracing dengan Elastic APM dan OpenTelemetry, service maps, serta pola penggunaan Elasticsearch sebagai service registry.

#Centralized Logging

#Log Aggregation dari Banyak Service

Prinsip pertama: jangan biarkan log berserakan di tiap service. Semua service mengirim log ke satu Elasticsearch (atau cluster observability), sehingga satu pencarian bisa menjawab "apa yang terjadi di seluruh sistem". Arsitekturnya: setiap service menulis log ke stdout/stderr, agent (Filebeat, episode 24) mengambilnya, dan data masuk ke data stream.

service-a ---+
service-b ---+--> Filebeat --> Logstash (opsional) --> Elasticsearch --> Kibana
service-c ---+

Keuntungannya: satu sumber kebenaran, pencarian lintas service, dan dashboard yang mencakup seluruh sistem. Ini arsitektur logging standar yang hampir selalu memakai Elastic Stack.

#Structured Logging

Log harus terstruktur, bukan teks bebas. Log terstruktur (JSON) bisa difilter, di-aggregate, dan di-search berdasarkan field; log bebas hanya bisa di-grok (yang rapuh). Contoh perbandingan:

{
  "timestamp": "2026-08-03T10:00:00.123Z",
  "level": "error",
  "service.name": "order-service",
  "trace.id": "abc123def456",
  "message": "koneksi ke payment-service timeout",
  "http.status": 504,
  "duration_ms": 5230
}

Konsistensi field inilah yang memungkinkan dashboard "error per service" atau query "semua log yang trace.id-nya X" berjalan mulus.

#Trace Correlation dengan Trace IDs

Trace ID adalah identitas unik yang diturunkan dari satu request masuk ke seluruh panggilan antar service di dalamnya. Saat user mengirim satu HTTP request yang melintasi 5 service, semua log dari 5 service itu memakai trace ID yang sama.

Implementasinya: library tracing menyuntikkan header traceparent ke tiap panggilan, dan tiap service membaca lalu meneruskan ID-nya. Di Elasticsearch, kalian lalu mencari:

{
  "query": {
    "term": {
      "trace.id": "abc123def456"
    }
  }
}

Dengan satu pencarian, seluruh perjalanan satu request di semua service terlihat — urutan service mana yang dipanggil, berapa lama tiap hop, dan di mana kegagalan terjadi. Inilah jawaban atas "mengapa request ini lambat" dalam hitungan detik.

#Distributed Tracing dengan Elastic APM

Elastic APM mengotomatiskan penelusuran ini. Agent APM dipasang di tiap service; ia menangkap transaksi (satu request masuk) dan span (tiap panggilan internal), lalu mengirimkannya ke APM Server dan Elasticsearch:

environment: production
server_url: https://apm-server:8200
service_name: order-service
api_key: apm-key-here

Dari data ini, Kibana menyusun timeline transaksi: tiap span dengan durasinya, termasuk panggilan ke database, external API, dan Elasticsearch itu sendiri. Ketika "order-service" lambat, kalian langsung melihat span mana yang memakan waktu.

#OpenTelemetry Support

Elasticsearch/Kibana mendukung OpenTelemetry (OTel) — standar observability terbuka. Kalian bisa meng-instrumentasi service dengan OTel SDK, lalu meneruskan trace ke Elastic observability (melalui OTel collector ke APM). Keuntungannya: vendor-agnostic — kode tidak terkunci ke Elastic; kalian bisa pindah provider tanpa menulis ulang instrumentasi.

exporters:
  otlp:
    endpoint: apm-server:8200
    headers:
      Authorization: "Bearer otel-token"

Dengan OTel, standar industri tetap dipertahankan sambil menikmati integrasi Elastic. Banyak organisasi memakai pola ini sebagai strategi "open standards with Elastic dashboards".

#Service Maps

Kibana Service Map menyajikan visualisasi otomatis dari semua service dan dependensinya, dibangun dari data APM: node mewakili service, garis mewakili koneksi antar mereka, dan warna/ukuran menandakan kesehatan. Satu pandangan langsung menjawab "topologi sistem kita seperti apa" dan "di mana bottleneck-nya".

#Elasticsearch sebagai Service Registry

Pola yang lebih tua, tapi masih relevan di skala kecil: menggunakan Elasticsearch sebagai service registry. Service mendaftarkan dirinya ke index service-registry saat start:

PUT /service-registry/_doc/order-service-1

{
  "service.name": "order-service",
  "instance.id": "order-service-1",
  "host": "10.0.2.15",
  "port": 8080,
  "status": "up",
  "updated_at": "2026-08-03T10:00:00Z"
}

Service lain mencarinya saat butuh berkomunikasi, dan instance yang tidak update heartbeat dalam periode tertentu dianggap mati (health check). Di production modern, Kubernetes service discovery dan konsul biasanya menggantikan pola ini — tapi memahami polanya membantu memahami apa yang sebenarnya dilakukan service discovery.

#Kesalahan Umum

1. Log tidak terstruktur. Teks bebas tidak bisa di-filter dengan andal — gunakan JSON dengan field tetap.

2. Trace ID tidak di-propagasi. Panggilan lintas service harus meneruskan header trace — kalau tidak, trace putus.

3. Schema log tidak konsisten. Standarkan field wajib lintas tim.

4. Setengah service ter-instrumentasi. Trace yang patah lebih membingungkan — terapkan secara penuh.

5. Menggunakan Elasticsearch untuk transaksi stateful. Ia bukan database ACID — jaga pembagian peran.

#Penutup

Di episode 26 kalian menguasai peran Elasticsearch dalam microservices: centralized logging dengan log aggregation lintas service, structured logging dengan field konsisten, korelasi log dengan trace IDs, distributed tracing dengan Elastic APM dan OpenTelemetry, service maps, serta pola service registry dan health check.

Inti yang harus dibawa pulang:

• Centralized logging membuat satu sumber kebenaran lintas service.
• Structured logging + trace ID mengubah log menjadi data yang bisa ditelusuri.
• APM menangkap transaksi dan span untuk melihat perjalanan request.
• OpenTelemetry memberi kebebasan vendor sambil memakai dashboard Elastic.
• Service maps menampilkan topologi dan kesehatan seluruh sistem.

Semua ini dijalankan di atas mesin fisik. Tapi zaman sekarang deployment lebih sering berjalan di atas kontainer dan Kubernetes. Di episode 27 kita bahas container orchestration: image Docker Elasticsearch, Docker Compose multi-node, volume management; deployment di Kubernetes dengan ECK, StatefulSets, PVC, service/ingress, secrets; serta production considerations seperti resource limits, anti-affinity, init containers, dan probes. Sampai jumpa!