Belajar Cloud Architect - Observability by Design

#Pendahuluan

Di episode 8 kita menetapkan SLO dan di episode 9 menghitung biaya — tetapi bagaimana kita tahu sistem benar-benar memenuhi janji itu? Jawabannya: observability. Namun ada kesalahpahaman yang harus diluruskan sejak awal: observability bukan "menambahkan monitoring di akhir".

Observability by design berarti telemetry — metrics, logs, traces — dipertimbangkan sebagai bagian arsitektur sejak diagram pertama. Setiap service baru harus menjawab: bagaimana cara mengukur, menelusuri, dan mendiagnosisnya? Jika jawabannya "nanti", itu bukan arsitektur — itu harapan.

#Tiga Pilar Telemetry

#Metrics

Nilai numerik pada interval waktu: latency, error rate, CPU, request count. Murah, efisien, dan ideal untuk alerting & SLO. Tapi metrics tidak memberi konteks "kenapa".

#Logs

Catatan peristiwa dengan detail: error message, request ID, payload. Kaya informasi untuk diagnosis, tapi mahal dan tidak terstruktur tanpa effort.

#Traces

Perjalanan satu request melintasi banyak service: di mana waktu terbuang? Di service mana kegagalan terjadi? Ini pembeda observability modern di arsitektur terdistribusi.

Ketiganya bukan pilihan "salah satu" — arsitektur yang baik memakai ketiganya dengan peran berbeda.

#OpenTelemetry: Standar Telemetry

OpenTelemetry (OTel) adalah standar open source untuk mengumpulkan telemetry dari aplikasi — satu API/SDK yang mengirim metrics, logs, dan traces ke berbagai backend (Prometheus, Grafana, Datadog, CloudWatch). Bagi arsitek, OTel menyelesaikan masalah klasik: vendor lock-in telemetry.

receivers:
  otlp:
    protocols:
      grpc:
      http:
exporters:
  otlp:
    endpoint: observability-prod:4317
  prometheus:
    endpoint: 0.0.0.0:9090
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      exporters: [prometheus]

Dengan pola ini, aplikasi cukup mengirim telemetry ke satu endpoint standar; backend bisa diganti tanpa mengubah kode aplikasi. Ini contoh nyata "telemetry sebagai keputusan arsitektur": pilih OTel di awal, bebas di kemudian hari.

#SLI dan SLO: Kontrak Kualitas

#Definisi

• SLI (Service Level Indicator) — pengukuran nyata: "persentase request dengan latency di bawah 500ms".
• SLO (Service Level Objective) — target: "99.9% request harus di bawah 500ms dalam 30 hari".
• SLA (Service Level Agreement) — kontrak eksternal dengan konsekuensi hukum jika dilanggar.

Alur: ukur (SLI) → targetkan (SLO) → jual ke pelanggan (SLA). SLA harus selalu lebih longgar dari SLO internal — kalian tidak boleh berjanji yang tidak bisa dijamin.

#Memilih SLI yang Benar

Pertanyaan arsitektur: SLI apa yang benar-benar mencerminkan pengalaman user? Bukan "uptime server", tapi:

Availability   : request sukses / total request
Latency        : % request dengan p50/p95/p99 di bawah target
Throughput     : request per detik yang bisa dilayani
Freshness      : data analytics seterbaru apa?

Perhatikan istilah p95, p99 — persentil. Mengukur rata-rata (average) menipu: rata-rata 200ms bisa menyembunyikan 5% request 5 detik. SLO latency wajib memakai persentil, dengan p99 sebagai standar umum untuk user experience.

#Observability Blueprint

Blueprint observability untuk arsitektur baru — pola yang bisa dipakai ulang:

Prinsip blueprint ini:

1. Semua service mengirim telemetry via OTel — satu standar, tanpa SDK vendor.
2. Korelasi di semua pilar — trace ID di log dan metric sehingga request bisa ditelusuri end-to-end.
3. SLO dashboard — setiap service menampilkan SLO aktual vs target; alert saat error budget menipis.
4. Telemetry sebagai design review item — setiap ADR (episode 3) menyertakan bagian "bagaimana ini diamati?".

#Telemetry sebagai Input Desain

Observability bukan hanya "untuk memantau setelah jalan" — ia juga menggerakkan keputusan arsitektur di masa depan:

• Data SLO menunjukkan bagian mana yang melanggar target → di situ arsitektur perlu diperbaiki (cache, scaling, pola baru).
• Trace menunjukkan bottleneck → keputusan compute/data di episode 4-5 bisa dievaluasi ulang.
• Error budget (episode 8) menentukan kapan tim berhenti rilis fitur dan fokus reliability.

Dengan kata lain, observability menutup siklus: desain → operasi → pengukuran → desain ulang. Arsitek yang mengabaikan telemetry mengoperasikan pesawat tanpa instrumen.

#Penutup

Inti yang harus dibawa pulang:

• Observability by design: setiap service harus bisa diukur, ditelusuri, dan didiagnosis sejak awal.
• Tiga pilar — metrics, logs, traces — dengan peran berbeda; gunakan ketiganya.
• OpenTelemetry menghilangkan vendor lock-in telemetry.
• SLI diukur dengan persentil; SLO ditargetkan; SLA selalu lebih longgar dari SLO.
• Telemetry menutup siklus desain → operasi → pengukuran → desain ulang.

Di episode 11 selanjutnya kita akan membahas IaC & automation architecture — Terraform/OpenTofu, policy-as-code, dan GitOps sebagai delivery model. Sampai jumpa di episode 11!