Belajar Spring Boot - Observability & Production Support

#Pendahuluan

Di episode 9 kalian membangun observability dasar dengan Actuator dan Micrometer. Di microservices dengan banyak service, itu belum cukup — kalian harus bisa melacak satu request yang melewati banyak service, mengkorelasikan log antar komponen, dan bertindak cepat saat insiden terjadi. Episode 22 membahas observability dan production support.

Kalian akan mempelajari distributed tracing dengan OpenTelemetry, centralized logging dengan structured logs, pemantauan health dan metrics yang menyeluruh, serta praktik incident management.

#Distributed Tracing dengan OpenTelemetry

#Mengapa Tracing Diperlukan

Di arsitektur microservices, satu request user bisa melewati lima service. Saat aplikasi lambat, di service mana waktunya hilang? Distributed tracing menjawabnya dengan melacak setiap request melewati seluruh sistem — setiap hop memiliki span dengan waktu mulai dan selesai.

OpenTelemetry adalah standar open-source untuk tracing, metrics, dan log. Spring Boot 3 memiliki integrasi native lewat Micrometer Tracing:

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-tracing-bridge-otel</artifactId>
</dependency>
<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-exporter-otlp</artifactId>
</dependency>

Dengan kedua dependency ini, Spring mengirimkan trace ke collector OpenTelemetry secara otomatis.

#Trace dan Span

Sebuah trace mewakili satu request end-to-end, terdiri dari banyak span — setiap span adalah satu unit kerja, misalnya pemanggilan HTTP atau query database. Setiap span membawa konteks: traceId dan spanId, yang di-propagasi dari satu service ke service berikutnya lewat header HTTP.

management:
  tracing:
    sampling:
      probability: 1.0
  otlp:
    tracing:
      endpoint: http://otel-collector:4317

Klik satu trace di Jaeger atau Grafana Tempo, dan kalian melihat peta lengkap: mana service yang lambat, mana query yang mahal, dan berapa lama setiap hop berlangsung.

#Centralized Logging dan Structured Log

#Structured Logging

Structured log ditulis dalam format terstruktur — biasanya JSON — agar mesin bisa mem-parsing dan mencari dengan cepat. Spring Boot 3 mendukung logging JSON dengan logback-encoder atau konfigurasi YAML:

logging:
  pattern:
    console: '{"timestamp":"%d{ISO8601}","level":"%level","logger":"%logger{36}","message":"%msg"}'

Setiap baris log menjadi satu object JSON yang siap dikirim ke aggregator log seperti Loki, Elasticsearch, atau Datadog.

#Correlation ID untuk Mengaitkan Log

Log terstruktur saja belum cukup — log harus bisa dikaitkan dengan trace. Saat tracing aktif, Spring menambahkan traceId dan spanId ke log secara otomatis. Inilah log correlation: kalian mencari satu traceId di log dan melihat seluruh aktivitas yang berkaitan dengan satu request:

{"timestamp":"2026-08-10T08:00:00Z","level":"INFO",
 "logger":"com.example.ItemService","traceId":"abc123def456",
 "spanId":"789ghi","message":"Membuat item baru: Laptop"}

Dengan traceId di log dan trace, kalian bisa berpindah dari satu log yang mencurigakan ke visualisasi trace lengkap — alat yang sangat berharga saat debug di production.

#Monitoring Health dan Metrics

#Dashboard dari Metrics

Metrics yang diekspor Micrometer (episode 9) divisualisasikan dengan Grafana. Dashboard yang baik menampilkan:

• RED method: Rate (jumlah request), Error (jumlah error), Duration (latency).
• JVM metrics: heap usage, GC pause, thread count.
• Database: connection pool aktif, query latency.
• Infrastructure: CPU, memory, disk.

curl -s http://localhost:8080/actuator/prometheus | grep jvm_memory_used

Perintah curl -s http://localhost:8080/actuator/prometheus | grep jvm_memory_used menampilkan pemakaian memory JVM dari perspektif Prometheus. Kombinasikan dengan alert rules — misalnya alert saat error rate melebihi 1% selama 5 menit.

#Alert yang Bermakna

Jangan membuat alert untuk segalanya — fokus pada gejala yang berdampak pada pengguna. Contoh aturan yang baik: latency p99 di atas threshold, error rate tinggi, atau health check yang turun. Setiap alert harus punya runbook: langkah diagnostik yang jelas untuk on-call engineer.

#Incident Management dan Readiness/Liveness

#Proses Menangani Insiden

Ketika aplikasi bermasalah, alur yang terstruktur mempercepat pemulihan:

1. Deteksi — alert dari metrics atau health check.
2. Diagnosis — telusuri trace dan log untuk menemukan akar masalah.
3. Mitigasi — rollback, scale out, atau perbaikan cepat.
4. Pasca-insiden — tulis postmortem dan tindak lanjut.

#Readiness vs Liveness di Production

Pemahaman yang tepat tentang kedua probe ini mencegah insiden yang dibuat sendiri:

• Readiness probe — kalian siap menerima traffic. Jika gagal, pod dikeluarkan dari Service, tapi tidak di-restart. Turunnya readiness bisa jadi normal — misalnya saat aplikasi terlalu sibuk.
• Liveness probe — kalian masih hidup. Jika gagal, pod di-restart. Liveness yang salah dikonfigurasi bisa memicu restart loop saat aplikasi sebenarnya hanya lambat.

Gunakan readiness probe dengan check yang mencerminkan kesiapan sebenarnya (misalnya database), dan liveness probe dengan check yang paling dasar (proses hidup). Kesalahan mengatur keduanya adalah salah satu penyebab insiden produksi paling umum di Kubernetes.

#Penutup

Episode 22 membekali kalian dengan observability dan support produksi: distributed tracing dengan OpenTelemetry, centralized logging dengan structured logs dan correlation ID, pemantauan health dan metrics dengan Grafana dan alert, serta praktik incident management dengan pemahaman yang benar tentang readiness dan liveness.

Inti yang harus dibawa pulang:

• OpenTelemetry melacak request end-to-end antar service dengan trace dan span.
• traceId di log mengkorelasikan log dengan visualisasi trace.
• Structured log JSON memudahkan pencarian di aggregator log.
• Metrics divisualisasikan di Grafana dengan metrik RED dan JVM.
• Alert harus bermakna dan disertai runbook yang jelas.
• Readiness menentukan siap menerima traffic; liveness menentukan kapan restart.

Di episode 23 — episode terakhir — kita akan membahas stable modern features dan ecosystem — fitur Spring Boot 3.x yang stabil, native support dan observability, ekosistem Spring Cloud, Data, dan Security, serta best practice menjaga aplikasi tetap future-proof.