Belajar System Design - Observability & Monitoring di Scale

#Pendahuluan

Setelah di episode 24 kita mendesain distributed file storage, pada episode ini kita masuk ke komponen yang sering dianggap "opsional" padahal krusial: observability dan monitoring. Di production, kalian tidak bisa debugging dengan print statement — kalian butuh sistem yang memungkinkan memahami apa yang terjadi di dalam sistem secara real-time.

Observability bukan hanya "monitoring" — ia adalah kemampuan memahami internal state sistem dari output eksternalnya. Dengan observability yang baik, kalian bisa menjawab: "Mengapa API endpoint ini lambat?" tanpa harus membuka source code atau log satu per satu.

#Tiga Pilar Observability

#Metrics (Prometheus/Grafana)

Metrics adalah angka-angka yang diukur secara periodik: latency, throughput, error rate, utilization.

RED method (untuk services)

Rate:      request rate (requests/detik)
Errors:    error rate (errors/detik)
Duration:  latency distribution (p50, p95, p99)
 
Contoh Prometheus metric:
http_requests_total{method="GET", status="200"} 12345
http_request_duration_seconds{quantile="0.99"} 0.234

USE method (untuk resources)

Utilization: % resource yang dipakai (CPU, memory, disk)
Saturation:  berapa banyak yang menunggu (queue length)
Errors:      error count pada resource
 
Contoh:
cpu_utilization_percent 75.3
disk_queue_length 12
memory_errors_total 0

#Logs (Loki/ELK)

Logs adalah catatan peristiwa: apa yang terjadi, kapan, dan di mana.

Structured logging

{
  "timestamp": "2026-08-16T10:30:00Z",
  "level": "error",
  "service": "order-service",
  "trace_id": "abc123def456",
  "message": "Payment failed",
  "error": "gateway_timeout",
  "user_id": "1234",
  "order_id": "789"
}

Loki: lightweight log aggregation (Grafana ecosystem). ELK: Elasticsearch + Logstash + Kibana (mature, lebih heavy).

#Traces (OpenTelemetry/Jaeger)

Traces adalah jejak perjalanan request lintas service.

Distributed trace

[API Gateway] → 5ms
  → [Order Service] → 50ms
    → [Product Service] → 20ms
    → [Payment Service] → 80ms
  → [Notification Service] → 30ms
 
Total latency: 165ms
Bottleneck: Payment Service (80ms = 48%)

OpenTelemetry: standard untuk traces, metrics, logs (vendor-neutral). Jaeger/Jaeger: trace visualization dan analysis.

#Metrik Utama

#Availability Metrics

Availability calculation

Uptime percentage:
  99.9% = 8.76 jam downtime/tahun (three nines)
  99.99% = 52.6 menit downtime/tahun (four nines)
  99.999% = 5.26 menit downtime/tahun (five nines)
 
SLA/SLO target: berapa downtime yang bisa diterima?

#Latency Metrics

Latency percentiles

p50 (median): 50% request lebih cepat dari ini → 50ms
p95: 95% request lebih cepat dari ini → 200ms
p99: 99% request lebih cepat dari ini → 500ms
p999: 99.9% request lebih cepat dari ini → 2000ms
 
Target: p99 < 500ms untuk API endpoint

#Error Budget

Error budget concept

SLO: 99.9% availability
Error budget: 0.1% = 43.2 menit downtime/bulan
 
Jika sudah menggunakan 30 menit downtime bulan ini:
→ Sisa budget: 13.2 menit
→ Deploy freeze jika budget habis

#Alerting

#Alert Fatigue

Alert yang baik vs buruk

Buruk:
  - Alert untuk setiap error spike (noise!)
  - Alert untuk setiap CPU > 80% (tidak actionable)
  - Alert tanpa runbook (penerima tidak tahu harus berbuat apa)
 
Baik:
  - Alert untuk SLO burn rate (predictive)
  - Alert hanya untuk conditions yang memerlukan aksi manusia
  - Setiap alert punya runbook (langkah aksi yang jelas)

#SLO-Based Alerting

SLO burn rate alerting

SLO: 99.9% availability
Burn rate: seberapa cepat error budget terpakai
 
Fast burn (14.4x): error budget habis dalam 1 jam → PAGE
Slow burn (1x): error budget habis dalam 30 hari → TICKET

#Praktik: Setup Observability Stack

Observability stack sederhana

Metrics:  Prometheus → Grafana (dashboard)
Logs:     Loki → Grafana (log viewer)
Traces:   OpenTelemetry Collector → Jaeger (trace viewer)
 
Deployment:
  - Prometheus: scrape metrics dari semua services
  - Loki: collect logs via Promtail agent
  - Jaeger: receive traces dari OpenTelemetry SDK
  - Grafana: dashboard unified untuk metrics, logs, traces

#Dashboard untuk API Endpoint

Grafana dashboard panels

Panel 1: Request rate (req/s) - time series
Panel 2: Error rate (%) - time series
Panel 3: Latency (p50, p95, p99) - time series
Panel 4: Active connections - gauge
Panel 5: CPU/Memory utilization - time series
Panel 6: Top 10 slowest endpoints - table

Tip

Mulai dari metrics (Prometheus + Grafana) — ini paling cepat memberikan visibility. Tambahkan logs (Loki) saat perlu debug specific issues. Tambahkan traces (OpenTelemetry) saat microservices mulai complex. Jangan coba bangun semuanya sekaligus.

#Penutup

Inti yang harus dibawa pulang:

Tiga pilar observability: metrics (angka), logs (events), traces (perjalanan request).
RED method untuk services (rate, errors, duration); USE method untuk resources (utilization, saturation, errors).
Alerting: SLO-based burn rate alerts mengurangi alert fatigue; setiap alert harus actionable dengan runbook.
Observability stack: Prometheus + Grafana untuk metrics; Loki untuk logs; OpenTelemetry + Jaeger untuk traces.

Di episode 26 selanjutnya kita akan membahas tren modern 2026 & ekosistem — modular monolith renaissance, vector database untuk AI/LLM, edge computing mainstream, FinOps, dan tooling ekosistem. Memahami tren membantu kalian membuat keputusan arsitektur yang relevan!