Observability: metrics, logs, traces; SLI/SLO
Tiga jenis signal untuk melihat ke dalam sistem, empat angka yang selalu diukur, dan cara mengubah "seberapa andal?" menjadi target dan anggaran kegagalan
Sebelumnya, di lesson 0022, timeout diambil dari p99.9 dan circuit breaker terbuka saat error rate melewati ambang. Angka-angka itu harus datang dari suatu tempat. Lesson ini juga menjadi anak tangga pertama di lesson 0025: ukur dulu.
1. Tiga signal: metrics, logs, traces
OpenTelemetry (standar terbuka untuk mengumpulkan data telemetri dari aplikasi) mengelompokkan keluaran sistem menjadi signal. Yang didukung saat ini: traces (jalur request melewati aplikasi), metrics (ukuran yang diambil saat runtime), logs (catatan sebuah event), dan baggage (konteks yang ikut diteruskan antar service). [1]
| Signal | Menjawab | Contoh | Biaya |
|---|---|---|---|
| Metrics | "Ada masalah? Seberapa besar?" | request/detik, error rate, p99 latency | Murah: angka teragregasi, cocok untuk alert dan dashboard |
| Logs | "Apa yang terjadi pada request ini?" | order 981 gagal: kartu ditolak | Sedang: volume besar, perlu struktur (JSON) dan request id |
| Traces | "Di hop mana waktunya habis?" | span gateway → order → payment | Paling mahal: biasanya di-sampling |
Trace tersusun dari span: satu unit kerja dengan nama, waktu mulai, dan durasi. Span anak terhubung ke span induknya, sehingga satu trace memperlihatkan perjalanan request melewati banyak service. [2]
2. Empat golden signals
Kalau hanya boleh mengukur empat metrik untuk sistem yang menghadap user, SRE Book menyuruh fokus pada latency, traffic, errors, dan saturation. [3] Latency: waktu melayani request, dipisahkan antara request sukses dan gagal. Traffic: permintaan per detik. Errors: rasio request gagal. Saturation: seberapa "penuh" sumber daya yang paling terbatas (CPU, memori, koneksi database).
Latihan 1 — Signal dan golden signals
Jawab tanpa scroll ke atas. Soal yang sama akan muncul lagi, diacak, di review 0026.
Kuis di lesson ini adalah feedback cepat, bukan bukti penguasaan; yang dicatat hanya hasil review 0026.
3. SLI, SLO, SLA
SRE Book memisahkan tiga istilah yang sering tertukar [4]:
- SLI (service level indicator): ukuran kuantitatif yang didefinisikan dengan cermat tentang tingkat layanan, misalnya latency request, error rate, atau availability.
- SLO (service level objective): target nilai atau rentang untuk sebuah SLI, misalnya "99% request checkout di bawah 300 ms selama 30 hari".
- SLA (service level agreement): kontrak, tertulis atau tidak, dengan user, yang punya konsekuensi kalau SLO-nya meleset, misalnya refund. Cara cepat membedakan: tanyakan "apa yang terjadi kalau target tidak tercapai?". Kalau tidak ada konsekuensi, itu SLO.
4. Error budget: kegagalan yang boleh dibelanjakan
Error budget adalah selisih antara 100% dan SLO. Selama SLO terpenuhi dan budget masih ada, rilis baru boleh jalan. Kalau pelanggaran SLO menghabiskan budget, rilis ditahan sementara dan tenaga dialihkan ke testing dan keandalan. [5] Jadi perdebatan "rilis cepat atau stabil" diputuskan dengan angka, bukan dengan siapa yang paling keras bicara.
| Availability | Downtime per tahun | Per 30 hari |
|---|---|---|
| 99% | 3,65 hari | 7,2 jam |
| 99,9% | 8,76 jam | 43,2 menit |
| 99,99% | 52,6 menit | 4,32 menit |
Angka dari Availability Table di SRE Book. [6] Rumusnya: (1 − SLO) × periode. 0,001 × 30 × 1.440 menit = 43,2 menit.
Setiap sembilan tambahan memotong budget sepuluh kali lipat. SRE Book mengingatkan bahwa user di smartphone yang 99% andal tidak bisa membedakan layanan 99,99% dan 99,999%, dan bahwa target yang terlalu tinggi membuang kesempatan menambah fitur dan menurunkan biaya. [5]
Latihan 2 — SLI, SLO, error budget
5. Kapan tidak perlu
Mengukur selalu perlu; yang perlu dibenarkan adalah seberapa canggih alatnya.
Sinyal yang membenarkan distributed tracing: satu request melewati beberapa service (misalnya tiga atau lebih) dan Anda tidak bisa menjelaskan kenaikan p99 dari metrics dan logs saja. Monolith dengan satu database cukup dengan log terstruktur yang membawa request id, ditambah metrics empat golden signals.
Biaya dan risiko: tracing dan log bervolume besar memakan storage dan biaya ingest yang bisa melebihi biaya server aplikasinya; karena itu trace biasanya di-sampling, dan sampling bisa melewatkan request yang justru bermasalah. SLA dengan penalti adalah komitmen bisnis: jangan menjanjikan 99,99% kalau database tunggal Anda butuh maintenance bulanan.
Alternatif lebih murah: metrics dan dashboard dari platform hosting yang sudah ada, log terstruktur dengan request id, dan satu atau dua SLO untuk endpoint terpenting (misalnya checkout) sebelum mendefinisikan SLO untuk semua endpoint. SLA hanya untuk pelanggan eksternal yang memintanya; service internal cukup SLO.
Latihan lisan — Ucapkan dengan suara keras
Pasang timer dan jawab dengan suara keras, seolah sedang interview. Jangan buka jawaban contoh sebelum selesai. Soal ini juga ada di bank soal dan bisa ditarik review 0026.
"Definisikan SLI dan SLO untuk API checkout kita, lalu jelaskan bagaimana error budget dipakai." (60 detik)
Bandingkan dengan jawaban contoh dan checklist-nya
"SLI adalah ukuran yang kita ambil, misalnya persentase request checkout yang sukses dan persentase yang dijawab di bawah 500 ms, diukur di load balancer. SLO adalah targetnya: 99,9% request sukses dan 99% di bawah 500 ms per 30 hari. SLA berbeda: kontrak dengan pelanggan yang punya konsekuensi seperti refund, dan biasanya lebih longgar dari SLO internal. Error budget adalah sisa dari SLO: 99,9% per 30 hari berarti sekitar 43 menit kegagalan boleh terjadi. Selama budget masih ada, tim boleh rilis cepat; kalau habis, rilis ditahan dan fokus ke keandalan. Saya tidak memilih 99,99% tanpa alasan, karena setiap sembilan tambahan jauh lebih mahal dan user sering tidak bisa membedakannya. Untuk mengukurnya cukup empat golden signals dulu: latency, traffic, errors, saturation."
Checklist: apakah Anda menyebut…
- SLI = ukuran kuantitatif (success rate, latency percentile)?
- SLO = target untuk SLI dalam periode tertentu?
- SLA = kontrak dengan konsekuensi, beda dari SLO?
- error budget = 1 − SLO, dengan contoh angka (±43 menit per 30 hari untuk 99,9%)?
- budget habis → rilis ditahan, fokus ke keandalan?
- memilih jumlah sembilan dari kebutuhan user, bukan setinggi mungkin?
Lulus jika minimal 4 dari 6.
Berikutnya, lesson 0024: tracing menjadi wajib begitu sistem dipecah menjadi banyak service. Kapan pemecahan itu sepadan dengan biayanya?
Istilah: GLOSSARY.md (bagian "Reliabilitas & API") · Indeks: semua lesson System Design
Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "Kenapa SLO latency memakai percentile, bukan rata-rata?", "Bagaimana memilih SLO untuk service internal?"
Sumber: [1] OpenTelemetry docs: Signals · [2] OpenTelemetry docs: Traces · [3] Google SRE Book, ch. 6: Monitoring Distributed Systems · [4] Google SRE Book, ch. 4: Service Level Objectives · [5] Google SRE Book, ch. 3: Embracing Risk · [6] Google SRE Book, Appendix A: Availability Table