Observability #

Dalam sistem modern (microservices, cloud-native, distributed systems), observability bukan lagi sekadar “nice to have”, tapi kebutuhan dasar. Tanpa observability yang baik, tim akan buta ketika terjadi latency spike, error misterius, atau penurunan performa yang hanya terjadi di kondisi tertentu.

Artikel ini akan membahas:

• Apa itu observability (dan bedanya dengan monitoring)
• Pilar utama observability
• Bagan gambaran besar observability (big picture)
• Best practices implementasi observability di dunia nyata

Apa itu Observability? #

Observability adalah kemampuan sebuah sistem untuk memahami kondisi internalnya hanya dari output yang dihasilkan (logs, metrics, traces).

Tujuan utamanya bukan sekadar tahu ada masalah, tapi:

• Kenapa masalah terjadi?
• Di komponen mana?
• Dalam kondisi apa?

Singkatnya: Monitoring tells you something is wrong. Observability tells you why.

Monitoring vs Observability (Perbedaan Penting) #

Monitoring adalah subset dari observability.

Tiga Pilar Utama Observability #

1️⃣ Metrics #

Data numerik teragregasi yang diukur secara periodik.

Contoh:

• Request per second (RPS)
• Error rate
• CPU / Memory usage
• Latency p95 / p99

Karakteristik:

• Cepat dan murah
• Cocok untuk alerting
• Kurang detail untuk root cause

2️⃣ Logs #

Catatan peristiwa (event) yang terjadi di sistem.

Contoh:

• Error stack trace
• Business event (user checkout, payment failed)
• Debug informasi

Karakteristik:

• Sangat detail
• Mahal jika berlebihan
• Sulit dikorelasikan tanpa struktur

3️⃣ Traces #

Jejak perjalanan sebuah request dari awal sampai akhir.

Contoh:

• Request masuk API Gateway
• Lanjut ke Auth Service
• Query ke Database
• Call ke external service

Karakteristik:

• Kunci untuk distributed systems
• Menunjukkan bottleneck antar service
• Perlu instrumentation yang konsisten

Bagan Gambaran Besar Observability #

┌──────────┐
│   User   │
└────┬─────┘
     │ HTTP / gRPC Request
     ▼
┌──────────────┐
│ API Gateway  │
│ Metrics      │──┐
│ Logs         │  │
│ Traces       │  │
└────┬─────────┘  │
     ▼            │
┌──────────────┐  │
│ Microservice │  │
│ A            │  │
│ (Metrics,    │  │
│ Logs, Trace) │  │
└────┬─────────┘  │
     ▼            │
┌──────────────┐  │
│ Database     │  │
│ / Cache      │  │
│ (Metrics)    │  │
└──────────────┘  │
                  ▼
        ┌──────────────────────┐
        │ Observability Stack  │
        │ - Metrics Store      │
        │ - Log Aggregator     │
        │ - Trace Backend      │
        │ - Visualization      │
        │ - Alerting           │
        └──────────────────────┘

Inti dari bagan ini:

• Semua komponen menghasilkan telemetry
• Telemetry dikumpulkan terpusat
• Data dikorelasikan untuk debugging

OpenTelemetry: Standar De-Facto #

Saat ini, OpenTelemetry (OTel) adalah standar industri untuk observability.

OTel menyediakan:

• API & SDK untuk metrics, logs, traces
• Vendor-neutral (tidak lock-in)
• Dukungan lintas bahasa (Go, Java, Python, dll)

Best practice: Instrument aplikasi sekali, ganti backend observability kapan pun.

Best Practices Observability #

1️⃣ Mulai dari Pertanyaan, Bukan Tools #

Jangan langsung pasang tools.

Mulai dari pertanyaan:

• Apa yang paling sering bikin sistem gagal?
• SLA apa yang paling kritikal?
• User journey mana yang paling penting?

2️⃣ Gunakan RED & USE Method #

RED (untuk service):

• Rate
• Errors
• Duration

USE (untuk resource):

• Utilization
• Saturation
• Errors

Ini membantu menentukan metrics yang benar-benar penting.

3️⃣ Structured Logging (Wajib) #

❌ Buruk:

"error occurred"

✅ Baik:

{
  "level": "error",
  "service": "payment",
  "order_id": "123",
  "error": "timeout"
}

Log harus:

• Structured (JSON)
• Konsisten antar service
• Mudah dikorelasikan

4️⃣ Correlation ID di Mana-mana #

Setiap request harus punya:

• trace_id
• request_id

Dan dibawa ke:

• Logs
• Metrics labels
• Traces

Tanpa correlation ID, observability hanya jadi kumpulan data terpisah.

5️⃣ Sampling Trace Secara Bijak #

Tracing 100% request mahal.

Strategi umum:

• Sample 1–5% request normal
• Sample 100% request error
• Dynamic sampling saat incident

6️⃣ Alert Berdasarkan SLO, Bukan CPU #

❌ Alert:

CPU > 80%

✅ Alert:

Error rate > SLO Latency p95 > threshold

Alert harus:

• Actionable
• User-impact driven
• Minim false positive

7️⃣ Observability ≠ Debug Mode #

Produksi bukan tempat debug log berlebihan.

Prinsip:

• Logs: event penting
• Metrics: health & trend
• Traces: investigasi

Jika semua jadi logs → mahal dan tidak berguna.

Anti-Pattern Observability #

🚫 Terlalu banyak metrics tanpa makna 🚫 Log tidak terstruktur 🚫 Trace tanpa context bisnis 🚫 Alert noisy tapi tidak actionable 🚫 Tool-centric, bukan problem-centric

Penutup #

Observability bukan soal tool apa yang dipakai, tapi cara berpikir tentang sistem.

Dengan observability yang baik:

• Incident lebih cepat ditangani
• Root cause lebih jelas
• Sistem lebih predictable
• Tim lebih tenang 😄

Jika monitoring adalah alarm, maka observability adalah CCTV + rekaman lengkap.