ID

Kenapa observability itu penting

Saat traffic naik, error tidak selalu terlihat dari dashboard utama. Observability membantu kita menjawab tiga pertanyaan:

• Apa yang rusak?

• Di mana bottleneck terjadi?

• Seberapa besar dampaknya ke user?

Arsitektur ringkas

1. Aplikasi mengirim log terstruktur (JSON).

2. Metric dikumpulkan per service dan endpoint.

3. Trace dipakai untuk melacak latensi antar service.

4. Alert dipicu berdasarkan SLO/SLA.

Jangan mulai dari 100 metric. Mulai dari metric yang langsung berdampak ke user.

Sinyal utama yang wajib ada

1) Logging

Gunakan format konsisten:

{"level":"error","service":"api-gateway","request_id":"req_123","message":"timeout upstream","duration_ms":2140}

2) Metrics

Minimal:

• Request rate

• Error rate

• P95/P99 latency

• Saturation (CPU/memory/queue)

3) Tracing

Distribusi trace membantu tahu service mana yang memperlambat request end-to-end.

Praktik alerting yang sehat

• Alert berdasarkan gejala user-facing (mis. error rate > 2% selama 10 menit)

• Hindari alert spam dari metric yang tidak actionable

• Tambahkan runbook singkat di setiap alert

Checklist implementasi

Logging JSON aktif di semua service

Dashboard latency + error per endpoint

Alert utama terhubung ke channel on-call

Satu drill incident simulasi setiap bulan

---

Penutup: observability bukan hanya tool, tapi disiplin tim untuk menjaga kualitas layanan secara konsisten.

EN

(Write English version here)

EN

(Write English version here)