UNDER PRESSURE

Level 3 · Sistem yang Saling Bergantung

Sesi 30: Melihat Apa yang Terjadi di Dalam: Tiga Pilar Observability (Logs, Metrics, & Traces)

Bagaimana jika CPU dan RAM semua server menunjukkan warna hijau 15%, namun pengguna di seluruh dunia berteriak di media sosial karena tombol checkout mereka loading berputar selamanya tanpa ada satu pun pesan error di terminal?

Sesi 30 / 344 menit baca

1. Bayangkan Jika

Sebuah pesawat jet komersial modern terbang di ketinggian 40.000 kaki di tengah badai malam yang gelap pekat. - Monitoring Tradisional: Pilot hanya punya dua jarum analog: "Bensin masih ada" dan "Suhu mesin normal". Jika tiba-tiba kemudi pesawat bergetar aneh, pilot tidak tahu apakah sayap patah, sensor hidung beku, atau komputer navigasi eror. - Observability Penuh: Kokpit dilengkapi panel kaca digital canggih, flight recorder black box, sensor radar cuaca, dan telemetri real-time yang langsung menunjukkan: "Kabel hidrolik nomor 3 pada sayap kiri mengalami penurunan tekanan 12% akibat micro-leak di sambungan katup".

2. Mengapa Monitoring Tradisional Gagal?

Dalam arsitektur microservices terdistribusi: - Server CPU dan RAM bisa tampak sangat santai (10–20%), tetapi sistem lumpuh total karena thread starvation, connection pool exhaustion, atau lock contention. - Monitoring hanya menjawab: "Apakah sistem sedang hidup atau mati?" (Biner / Black-box). - Observability menjawab: "Mengapa sistem bertindak aneh dan di mana letak akar masalahnya di antara 50 microservices yang saling memanggil?" (Internal state inference).

3. Tiga Pilar Observability Modern

  1. Metrics (Metrik Agregat — "Ada Sesuatu yang Salah"): - Data numerik time-series yang murah disimpan dan ideal untuk dashboard visualisasi serta alerting real-time. - Metode RED (Standar Microservices):

    • Rate: Berapa request per detik yang masuk (QPS).
    • Errors: Berapa persentase request yang gagal (HTTP 5xx rate).
    • Duration: Distribusi latensi respons (p50, p95, p99 histogram).

  2. Distributed Tracing (Jejak Terdistribusi — "Di Mana Masalahnya Terjadi"): - Standar industri: OpenTelemetry (OTel) & Jaeger/Tempo. - Setiap request yang masuk ke API Gateway diberi sebuah Trace ID unik. - Trace ID ini dialirkan (propagated) melalui header HTTP/gRPC (traceparent) ke setiap hop microservice. - Menghasilkan visualisasi Waterfall Span Chart yang secara presisi membongkar waktu eksekusi:

    • Gateway: 1.200 ms
    • Auth: 10 ms
    • Cart: 15 ms
    • Payment RPC: 1.150 ms (BOTTLENECK DITEMUKAN!)
      • MySQL Query SELECT FOR UPDATE: 1.130 ms (LOCK CONTENTION!)

  3. Logs (Catatan Peristiwa Terstruktur — "Apa Penyebab Detailnya"): - Tinggalkan log teks biasa (console.log("error disini")). - Gunakan Structured JSON Logging yang mengikutsertakan trace_id, user_id, dan error_stack. - Cukup cari trace_id yang bermasalah di Grafana Loki / ElasticSearch untuk melihat baris kode exact penyebab kegagalan dalam 1 detik!

4. Alur Investigasi Insiden 60 Detik (The Golden Triad)

  1. Detik 0–10 (Alert Metric): Prometheus menembakkan alert ke Slack/PagerDuty: Payment p99 Duration > 1.000ms.
  2. Detik 11–30 (Trace Analysis): Engineer membuka Grafana Tempo / Jaeger, mengklik salah satu Trace ID pada p99 spike, dan melihat rentang Span merah di MySQL Lock.
  3. Detik 31–60 (Log Deep-Dive): Engineer mengklik link log dari Trace ID tersebut di Loki, membaca error Lock wait timeout exceeded on row id=9821, lalu mengeksekusi mitigasi rollback atau kill query.

5. Rangkuman Sementara: Di Mana Kita Sekarang

Empat sesi lagi menuju garis akhir. Sejauh ini, seluruh perjalanan SYSTEM UNDER PRESSURE sudah mencakup: - Level 0 (Sesi 1–06): Anatomi mesin tunggal, latensi CPU/RAM/Disk, antrean, dan batas hukum Amdahl. - Level 1 (Sesi 7–13): Virtualisasi, scaling horizontal, Load Balancer L4/L7, Reverse Proxy, Stateless Architecture, dan High Availability. - Level 2 (Sesi 14–21): Multi-DC Anycast, Kubernetes Pods, Database Connection Storm, PgBouncer, Read Replica, Redis Cache, Sharding, dan CQRS. - Level 3 (Sesi 22–31): Fan-out microservices, protokol antar layanan (REST/gRPC/GraphQL), service mesh, cascading failure, retry storm, message queue, rate limiting, load & chaos testing, dan tiga pilar observability. Satu sesi tersisa di level ini: sintesis membaca design doc. - Level 4 (Sesi 32–34): Belum dimulai — pipa log, Elasticsearch & Kibana, lalu Dynatrace vs jalur DIY.

6. Lensa Performance Tester

Metrik dan pengujian krusial: 1. Trace Propagation Completeness: Verifikasi bahwa 100% downstream microservices mempertahankan traceparent header tanpa ada span yang terputus. 2. Observability Overhead Under Load: Pastikan agent collector OpenTelemetry mengonsumsi <2% CPU dan <50MB RAM saat trafik 20.000 QPS. 3. MTTD & MTTR Reduction: Ukur waktu deteksi insiden (Mean Time to Detect) dan waktu pemulihan (Mean Time to Resolve) sebelum vs sesudah implementasi distributed tracing.

7. Pertanyaan untuk Ronde Berikutnya

Alat sudah lengkap: metric, trace, dan log menyala bersamaan. Tapi alat yang lengkap belum berarti timnya siap.

Pertanyaan yang tersisa bukan soal alat lagi, melainkan soal cara membaca: kamu diberi satu diagram arsitektur yang belum pernah kamu lihat, dan lima belas menit untuk menemukan di mana dia akan patah. Berapa kapasitas yang benar-benar dibutuhkan — dihitung dari angka bisnis, bukan dari tebakan? Dan pertanyaan baku apa yang harus diajukan seorang performance tester setiap kali ada design doc baru mendarat di mejanya?

Jawabannya ada di Sesi 31: Membaca Design Doc Seperti Orang Dalam — Capacity Planning & Daftar Pertanyaan Baku.