Tentang Sesi Ini
Ringkasan & metadata
Sesi ini menyodorkan sebuah cetak biru (blueprint) praktis untuk membangun observability — kemampuan memantau kesehatan sistem — dalam skala besar di AWS. Saat aplikasi masih kecil, memantau server cukup dengan sekali lihat. Namun ketika sebuah marketplace melayani jutaan pengguna dengan ratusan layanan yang saling bicara, pertanyaannya berubah menjadi: "bagaimana kita tahu, dalam hitungan detik, bagian mana yang bermasalah dan mengapa?" OLX Indonesia berbagi pengalaman lapangan, dan AWS memetakan layanan-layanan yang menopangnya.
Inti sesi bukan sekadar "pasang monitoring", melainkan membangun monitoring yang bermakna: dashboard yang menjawab pertanyaan bisnis, alert yang benar-benar perlu ditindak (bukan yang bikin tim kebal karena terlalu sering berbunyi), serta SLO/SLI yang menautkan angka teknis ke janji layanan kepada pengguna. Semua itu harus tetap terkendali dari sisi biaya ketika volume telemetri membengkak di skala besar.
Kenapa penting untuk Anda? Jika tim Anda sering "tahu ada masalah dari komplain pelanggan, bukan dari dashboard", atau tenggelam dalam banjir notifikasi yang tak lagi dipedulikan (alert fatigue), sesi ini memberi peta jalan menuju pemantauan yang tenang tapi tajam.
OLX mengoperasikan jaringan marketplace jual-beli (classifieds) berskala besar — layanan identitas terkelola (hCIAM) grup OLX saja melayani sekitar 11 juta pengguna per bulan di 13 platform kawasan Eropa & Asia. Untuk observability, tim OLX India (bagian grup OLX) mendokumentasikan pendekatan tiga pilar — metrics, logs & traces: tech stack diinstrumentasi dengan New Relic sebagai platform observability all-in-one (backend & PWA) dan agen OpenTelemetry (OTEL) agar logika instrumentasi netral-vendor dan mudah berpindah platform, dipadu Amazon CloudWatch untuk pemantauan infrastruktur, dengan alerting berlapis (throughput, response time, error rate). Di sisi keamanan, studi kasus AWS untuk AWS WAF Bot Control di OLX memperlihatkan backend hCIAM yang ditopang Amazon Cognito, AWS Lambda, AWS Fargate, dan Amazon ECS — pernah menolak sekitar 250.000 permintaan bot dalam satu serangan.
Sumber: Blog teknik "Inside OLX India: Strategies for Effective Monitoring & Observability" (tech.olx.in) — data observability (New Relic, OpenTelemetry, CloudWatch, tiga pilar) berasal dari OLX India, bagian grup OLX — bukan spesifik OLX Indonesia; serta studi kasus AWS "Enhancing Security Using AWS WAF Bot Control with OLX" (aws.amazon.com) yang menyebut Cognito/Lambda/Fargate/ECS pada backend hCIAM grup OLX. Nama produk & angka milik pemiliknya; contoh penerapan lain di buku ini bersifat ilustratif.
Apa Itu & Bagaimana Bekerjanya
Apa itu observability
Monitoring menjawab "apakah sistem sehat?"; observability melangkah lebih jauh: "kalau tidak sehat, kenapa — sampai ke akarnya?" Kunci observability modern adalah tiga pilar yang saling melengkapi:
- Metrics — angka ringkas dari waktu ke waktu (jumlah permintaan, latensi, error rate, penggunaan CPU). Murah disimpan, ideal untuk grafik & alert.
- Logs — catatan peristiwa terperinci ("pada 16:03, permintaan X gagal karena Y"). Kaya konteks untuk investigasi.
- Traces — jejak perjalanan satu permintaan yang melintasi banyak layanan (checkout → pembayaran → notifikasi), menunjukkan di titik mana ia melambat atau putus.
Ketiganya harus bisa dikorelasikan: dari grafik latensi yang melonjak (metric), turun ke jejak permintaan yang lambat (trace), lalu ke log detail penyebabnya. Itulah beda "punya data" dan "bisa menjawab pertanyaan".
Layanan & pilar di AWS
Berikut layanan inti yang membentuk blueprint monitoring skala besar di AWS, dengan fungsi ringkasnya:
Layanan-layanan ini dipadukan sesuai pilar: CloudWatch & Managed Prometheus untuk metrics, CloudWatch Logs untuk logs, X-Ray untuk traces, dengan OpenTelemetry/ADOT sebagai standar pengumpulan yang netral-vendor, Managed Grafana sebagai kaca depan visualisasi, dan Alerting/SNS yang berbunyi hanya saat SLO benar-benar terancam.
Analogi yang Mudah Dicerna
Ibarat ruang kendali kota
Ibaratnya, sistem berskala besar adalah sebuah kota, dan tim operasi duduk di ruang kendali (control room) dengan dinding penuh layar. Ribuan sensor tersebar di jalan, jembatan, jaringan listrik, dan air. Operator tak perlu menyusuri kota satu per satu — cukup melihat "denyut" seluruh kota di layar dan langsung tahu persis di ruas mana yang macet atau padam.
- Sensor = agen OpenTelemetry di tiap layanan — mengirim data tanpa henti.
- Metrics = papan angka (kecepatan lalu lintas, tegangan listrik) — ringkas dan cepat dibaca.
- Logs = laporan kejadian tiap pos ("lampu simpang A mati pukul 16:03").
- Traces = melacak satu mobil dari gerbang tol sampai tujuan — di persimpangan mana ia tertahan.
- Dashboard (Grafana) = dinding layar besar yang menyatukan semuanya.
- Alert = sirene yang hanya berbunyi untuk kejadian genting — bukan setiap daun jatuh.
High-Level Architecture & Alur
High-Level Architecture (HLA)
Secara garis besar, blueprint observability skala besar mengalir seperti ini: setiap layanan aplikasi memancarkan telemetri lewat OpenTelemetry/ADOT Collector, yang lalu meneruskan tiap sinyal ke tujuan yang tepat — metrics ke CloudWatch & Managed Prometheus, logs ke CloudWatch Logs, traces ke X-Ray. Semua disatukan di Managed Grafana sebagai dashboard, dan pelanggaran SLO memicu Alerting (SNS) ke tim yang tepat.
Alur data telemetri & investigasi
Ketika latensi checkout mendadak melonjak, inilah cara ruang kendali menemukan akar masalah:
- Kumpul. Agen OpenTelemetry di tiap layanan memancarkan metrics, logs, dan traces ke Collector.
- Salurkan. Collector mengirim tiap sinyal ke penyimpanan yang tepat (CloudWatch, Prometheus, X-Ray).
- Deteksi. Alarm berbasis SLO menyala — error budget checkout hampir habis.
- Korelasi. Dari grafik latensi (metric), tim turun ke trace permintaan yang lambat.
- Akar masalah. Trace menunjuk layanan pembayaran; log detail memastikan penyebabnya.
- Tindak & belajar. Perbaikan diterapkan; dashboard & SLO diperbarui agar cepat terdeteksi lain kali.
Dari Konsep ke Operasi Nyata
Contoh nyata (konteks Indonesia)
Agar tidak berhenti di teori, berikut tiga skenario penerapan blueprint monitoring skala besar.
Pantau uptime & performa jual-beli (OLX)
Sebuah marketplace jual-beli seperti OLX Indonesia harus tahu detik ini juga apakah fitur pasang iklan, pencarian, dan chat berfungsi mulus. Metrics memantau latensi pencarian & error rate checkout; traces (X-Ray) mengurai kenapa satu permintaan lambat melintasi layanan; SLO ("99,9% pencarian < 300 ms") menjaga janji ke pengguna. Alert hanya berbunyi saat error budget menipis — sehingga tim fokus pada masalah yang benar-benar berdampak, bukan noise.
Standardisasi observability lintas ratusan layanan
Tim SRE di platform besar memakai OpenTelemetry/ADOT agar setiap tim mengirim telemetri dengan format seragam, lalu Managed Grafana menyatukan dashboard sehingga tak ada lagi "monitoring tiap tim beda-beda". Managed Prometheus menampung metrics dalam volume besar dengan biaya terkendali, dan desain alert berbasis SLO menekan alert fatigue — piket malam jadi lebih manusiawi.
Jejak yang bisa dipertanggungjawabkan
Perusahaan yang diatur ketat butuh bukti bahwa layanan memang memenuhi target keandalan. CloudWatch Logs menyimpan jejak peristiwa; dashboard SLO menjadi laporan keandalan yang bisa ditunjukkan ke manajemen atau auditor. Ketika insiden terjadi, korelasi metrics-logs-traces menghasilkan post-mortem yang akurat — bukan tebak-tebakan.
Ringkasan Visual (Geser)
Ringkasan visual
Enam kartu berikut merangkum inti sesi. Gunakan tombol atau tombol panah keyboard (← →) untuk berpindah.
Poin yang Bisa Dibawa Pulang
Poin yang bisa dibawa pulang
- Observability = tiga pilar yang terkorelasi. Metrics untuk melihat, traces untuk melacak, logs untuk memahami — dan ketiganya harus tersambung.
- Standardkan dengan OpenTelemetry/ADOT. Format seragam lintas tim memudahkan penyatuan dashboard di Grafana.
- Alert & dashboard yang bermakna. Ikat ke SLO/SLI agar notifikasi hanya muncul saat berdampak — lawan alert fatigue.
- Jaga biaya di skala besar. Pilih retensi, sampling, dan agregasi dengan sadar; volume telemetri bisa membengkak diam-diam.