Bagaimana Anda mengatur monitoring dan observability untuk menangkap masalah sejak dini?

Question

Accepted Answer

Tujuannya adalah **mengetahui sistem Anda tidak sehat sebelum pengguna memberitahu Anda**. Observability yang baik memungkinkan Anda menjawab pertanyaan yang tidak Anda antisipasi, bukan hanya memeriksa dashboard tetap. Sebagai tech lead, Anda mengaturnya *sebelum* insiden, bukan saat terjadi.

## Tiga pilar

- **Metrics** — time series numerik murah (request rate, error rate, latency, queue depth). Bagus untuk tren, alerting, dan SLOs.
- **Logs** — catatan event terperinci untuk *mengapa* sesuatu terjadi. Buatnya **terstruktur** (JSON) dan lampirkan **correlation ID** sehingga Anda dapat mengikuti satu request di seluruh layanan.
- **Traces** — jalur satu request di seluruh layanan, menunjukkan di mana waktu benar-benar dihabiskan. Penting dalam sistem terdistribusi.

## Alert pada gejala, bukan noise

Page apa yang **pengguna rasakan**, bukan internal jitter. Jangkarkan alert ke **SLOs**: error rate, latency (p95/p99), dan availability. Lonjakan CPU bukanlah insiden; checkout gagal untuk 2% pengguna adalah.

| Alert pada | Jangan page ||
| --- | --- |
| Error rate melanggar SLO | Lonjakan CPU tunggal |
| p99 latency di atas budget | Satu request lambat |
| Health checks gagal | Disk di 60% |

## Buat alert dapat ditindaklanjuti

Setiap alert harus **urgent, real, dan dapat ditindaklanjuti** — menamai apa yang salah dan menunjuk ke langkah berikutnya. Alert yang terus firing melatih tim untuk mengabaikannya; **alert fatigue** adalah bagaimana insiden nyata terlewatkan. Tambahkan **health checks** dan dashboard yang menampilkan golden signals sekilas.

## Mengapa ini penting

Tim yang hanya observe setelah insiden terbang buta: mereka belajar tentang outage dari pelanggan marah dan debug dengan tebakan. Berinvestasi dalam observability di awal mengubah misteri jam 3 pagi menjadi diagnosa 5 menit, mengurangi downtime, dan membebaskan tim untuk ship daripada firefight.