Belajar Quarkus - Observability & Production Support

#Pendahuluan

Episodes 9 dan 21 membuat aplikasi kalian sehat dan ter-deploy. Tapi produksi adalah tempat kejadian tak terduga: latensi naik, error muncul sesekali, satu service mengeluh tentang service lain. Untuk bertahan, kalian butuh observability tingkat produksi — bukan sekadar health check.

Episode 22 membahas observability lanjutan: distributed tracing dengan OpenTelemetry, centralized logging dengan correlation IDs, metrics, health, dan alerting production-ready, serta incident response, tracing errors, dan troubleshooting layanan.

#Distributed Tracing dan OpenTelemetry Integration

#Menambahkan Extension

OpenTelemetry adalah standar observability modern. Quarkus terintegrasi native:

./mvnw quarkus:add-extension \
    -Dextensions=opentelemetry,opentelemetry-exporter-otlp

#Konfigurasi Exporter

Kirim trace ke collector atau backend seperti Jaeger, Tempo, atau Grafana Cloud:

quarkus.opentelemetry.tracer.exporter.otlp.endpoint=http://collector:4317
quarkus.opentelemetry.tracer.sampler=on
quarkus.application.name=belajar-quarkus

quarkus.opentelemetry.tracer.exporter.otlp.endpoint menunjuk ke OpenTelemetry Collector yang meneruskan trace ke backend. Dengan sampler on, semua request di-trace.

#Tracing Otomatis dan Manual

HTTP request di-trace secara otomatis. Untuk span kustom di dalam service:

Span kustom

import io.opentelemetry.api.trace.Span;
import jakarta.enterprise.context.ApplicationScoped;
 
@ApplicationScoped
public class PaymentService {
 
    public void prosesPembayaran() {
        Span span = Span.current().makeCurrent();
        span.setAttribute("payment.method", "transfer");
        // proses pembayaran
        span.end();
    }
}

Distributed tracing melacak satu request melewati banyak service: setiap service menambahkan span, dan backend menyusunnya menjadi satu trace yang utuh.

#Centralized Logging dan Correlation IDs

#Correlation ID

Saat request melewati banyak service, kalian perlu menghubungkan log dari semua service tersebut. Correlation ID (atau trace ID) menghubungkan semuanya. Dengan OpenTelemetry, trace ID otomatis tersedia.

Gabungkan trace ID ke log lewat konfigurasi:

quarkus.log.console.format=%d{yyyy-MM-dd HH:mm:ss} %-5p [%c] trace=%X{traceId} %s%e%n

%X{traceId} membaca MDC value trace ID. Sekarang setiap baris log membawa trace ID, dan kalian bisa mencari semua log milik satu request.

#Aggregasi Log Terpusat

Kirim log ke sistem terpusat seperti Loki, Elasticsearch, atau CloudWatch. Konfigurasi structured logging JSON (episode 9) mempermudah parsing. Contoh pengiriman ke Loki:

quarkus.log.handler.gelf.enabled=true
quarkus.log.handler.gelf.host=loki-gateway
quarkus.log.handler.gelf.port=12201

Atau ekspor log melalui agent seperti Promtail di sisi cluster. Yang penting: semua log dari semua service berkumpul di satu tempat yang bisa di-query.

#Metrics, Health, dan Alerting Production-Ready

#Metrik dan Health di Produksi

Gabungkan metrik (episode 9) dan health (episode 9) menjadi dasar monitoring:

curl http://localhost:8080/q/metrics
curl http://localhost:8080/q/health

Prometheus menarik /q/metrics secara berkala; Kubernetes memakai /q/health/live dan /q/health/ready untuk probe.

#Alerting Rules

Alert yang baik menangkap masalah sebelum pengguna menyadarinya:

groups:
- name: quarkus
  rules:
  - alert: HighErrorRate
    expr: |
      sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m]))
        / sum(rate(http_server_requests_seconds_count[5m])) > 0.05
    for: 10m
    labels:
      severity: page
    annotations:
      summary: Error rate di atas 5% selama 10 menit

Rule ini memicu alert jika error 5xx melebihi 5% selama 10 menit. Alert diarahkan ke PagerDuty, Slack, atau email sesuai severity.

#Incident Response, Tracing Errors, dan Service Troubleshooting

#Runbook Incident

Saat alert berbunyi, respon harus terstruktur:

1. Kenali: cek dashboard dan alert untuk mengonfirmasi
2. Isolasi: identifikasi service dan rentang waktu
3. Telusuri: query trace dengan trace ID dan log terkait
4. Pulihkan: rollback, restart, atau scaling
5. Pelajari: postmortem dan perbaikan jangka panjang

#Menelusuri Error dengan Trace

Saat user melaporkan error, ambil trace ID dari laporan (atau cari via log), lalu:

curl "http://jaeger/query?service=belajar-quarkus&operation=POST"

Gunakan trace untuk melihat request mana yang gagal, service mana yang bermasalah, dan durasi setiap span. Query via API curl "http://jaeger/query?service=belajar-quarkus" atau lewat UI Jaeger. Trace ID adalah jembatan antara laporan pengguna dan akar masalah.

#Troubleshooting Latency

Jika satu endpoint lambat, trace menunjukkan span mana yang makan waktu — database query lambat, panggilan eksternal, atau antrian. Kombinasi trace + metrik + log (three pillars of observability) memberi jawaban lengkap tanpa menebak-nebak.

#Penutup

Episode 22 menyiapkan kalian menghadapi produksi: memahami distributed tracing dengan OpenTelemetry, centralized logging dengan correlation ID, metrik, health, dan alerting production-ready, serta incident response dan troubleshooting berbasis trace.

Inti yang harus dibawa pulang:

• OpenTelemetry menelusuri satu request melewati banyak service.
• Trace ID menghubungkan log dari semua service untuk request yang sama.
• Centralized logging mengumpulkan log semua service di satu tempat.
• /q/metrics dan /q/health menjadi dasar monitoring produksi.
• Alerting menangkap masalah sebelum pengguna menyadarinya.
• Incident response harus terstruktur: kenali, isolasi, telusuri, pulihkan.
• Trace ID menjembatani laporan pengguna dengan akar masalah.

Di episode 23 selanjutnya, episode penutup series, kita akan membahas stable modern features dan future trends — fitur Quarkus stabil terbaru, kapabilitas modern Quarkus 3.x, ekosistem SmallRye, Camel, Kafka, gRPC, dan Kubernetes, serta strategi menjaga aplikasi Quarkus future-proof dan cloud-native.