Observabilitas dibangun atas tiga pilar — log, metrik, dan jejak — dan tujuannya adalah menjawab "apa yang salah dan mengapa" untuk sistem yang terlalu besar untuk diperiksa secara manual. Dalam skala besar, strateginya adalah tentang korelasi, sampling, dan biaya.
| Pilar | Menjawab | Alat |
|---|
| Metrik | Apakah ada yang salah? (tingkat, latensi) | Prometheus, Grafana |
| Jejak | Di mana dalam alur? | OpenTelemetry, Jaeger |
| Log | Apa yang sebenarnya terjadi? | ELK, Loki |
Metrics alert ─▶ trace pinpoints the slow service ─▶ logs explain the cause
(broad) (path) (detail)
ID jejak/korelasi harus melewati label metrik, baris log, dan rentang, sehingga Anda dapat beralih di antara keduanya.
log line: level=error trace_id=abc123 service=payments msg="gateway timeout"
^^^^^^^^^^^^^^^ same id appears in the trace + metrics
✓ Standardize: OpenTelemetry across all services
✓ Use structured (JSON) logs — queryable, not grep-only
✓ Sample traces (e.g. keep all errors + 1% of success) to control cost
✓ Define SLOs and alert on symptoms (latency/error rate), not noise
✓ RED/USE method for dashboards (Rate, Errors, Duration)
Mencatat segalanya pada 100% tidak terjangkau dan menenggelamkan sinyal. Sebaliknya, sampling, struktur, dan beri peringatan pada SLO.
Dengan ratusan layanan, Anda tidak dapat SSH masuk dan melihat — observabilitas adalah satu-satunya cara untuk memahami perilaku produksi.
Strategi pemenang adalah terkorelasi, tersampel, dan didorong SLO: ini mengungkap masalah nyata dengan cepat tanpa membuat Anda bangkrut dalam penyimpanan telemetri atau menenggelamkan on-call dalam kebisingan.