Logging Itu Berantakan

• Dalam sistem terdistribusi modern, pendekatan logging lama memiliki keterbatasan struktural sehingga gagal menyampaikan kebenaran
• Log masih dirancang dengan asumsi lingkungan server tunggal ala 2005, sehingga kehilangan konteks permintaan yang melewati banyak layanan, database, dan cache
• Pencarian string sederhana tidak memahami struktur, relasi, dan korelasi, sehingga menyulitkan penemuan akar masalah
• Solusinya adalah menyimpan satu ‘Wide Event (atau Canonical Log Line)’ yang memuat seluruh konteks untuk setiap permintaan
• Dengan ini, log berubah dari sekadar teks menjadi aset data yang bisa dianalisis

---

Masalah mendasar dalam logging

• Log lama dibuat dengan asumsi era server monolitik, sehingga tidak mencerminkan arsitektur layanan terdistribusi modern
  • Satu permintaan bisa melewati banyak layanan, DB, cache, dan queue, tetapi log masih dicatat berdasarkan perspektif satu server
• Dalam contoh log, satu permintaan menghasilkan 13 baris, sehingga dengan 10.000 pengguna serentak, muncul 130.000 baris per detik, namun sebagian besar tidak bermakna
• Saat masalah terjadi, yang dibutuhkan adalah konteks, tetapi log saat ini tidak memilikinya

Batas pencarian string

• Ketika pengguna melaporkan “pembayaran tidak berhasil”, mencari log berdasarkan email atau user_id pun sulit memberi hasil yang berguna karena tidak ada struktur yang konsisten
  • ID pengguna yang sama bisa dicatat dalam puluhan bentuk seperti user-123, user_id=user-123, {"userId":"user-123"}
• Format log antarlayanan berbeda-beda sehingga pelacakan event yang saling terkait menjadi mustahil
• Masalah intinya adalah log dirancang berfokus pada penulisan (write), bukan dioptimalkan untuk query

Definisi konsep inti

• Structured Logging: cara mencatat dalam bentuk key-value (JSON) alih-alih string
• Cardinality: jumlah nilai unik dalam sebuah field; misalnya user_id sangat tinggi
• Dimensionality: jumlah field dalam sebuah event log; makin banyak, makin besar peluang analisis
• Wide Event / Canonical Log Line: satu event log tunggal yang kaya konteks per permintaan
• Sebagian besar sistem logging membatasi data berkardinalitas tinggi karena masalah biaya, padahal justru itulah yang paling berguna untuk debugging

Batasan OpenTelemetry

• OpenTelemetry (OTel) adalah sekumpulan protokol dan SDK yang hanya menyediakan standar untuk pengumpulan dan pengiriman data
• Namun OTel tidak melakukan hal-hal berikut
  1. Tidak menentukan apa yang harus dicatat ke log
  2. Tidak otomatis menambahkan konteks bisnis seperti tingkat langganan atau nilai keranjang belanja
  3. Tidak mengubah cara berpikir developer tentang logging
• Bahkan dengan library yang sama, pengalaman debugging akan sangat berbeda antara instrumentasi yang sengaja menambahkan konteks dan instrumentasi yang sekadar dasar
• OTel hanyalah sarana pengangkutan (plumbing); apa yang dialirkan tetap harus diputuskan developer

Pendekatan Wide Event / Canonical Log Line

• Logging harus keluar dari pendekatan berpusat pada “apa yang dilakukan kode” dan mulai mencatat “apa yang terjadi pada permintaan”
• Untuk setiap permintaan, buat satu event yang luas di tingkat layanan
  • Dapat mencakup lebih dari 50 field seperti permintaan, pengguna, pembayaran, error, dan environment
• Contoh JSON mencakup seluruh konteks debugging seperti user_id, subscription_tier, service_version, dan error_code
• Dengan ini, satu pencarian saja cukup untuk analisis langsung, misalnya menemukan penyebab kegagalan pembayaran pada pengguna premium

Pemanfaatan query pada Wide Event

• Wide Event diperlakukan sebagai query data terstruktur, bukan pencarian teks sederhana
• Debugging setingkat analisis real-time dimungkinkan dengan data berdimensi tinggi dan berkardinalitas tinggi
• Contoh: query seperti “agregasikan tingkat kegagalan pembayaran pengguna premium selama 1 jam terakhir berdasarkan kode error” bisa dijalankan seketika

Pola implementasi

• Bangun event sepanjang seluruh siklus hidup permintaan, lalu keluarkan sekali saja di akhir
  • Di middleware, inisialisasi field dasar seperti request_id, timestamp, method, dan path
  • Di handler, tambahkan secara bertahap informasi pengguna, keranjang, pembayaran, dan error
• Pada akhirnya, catat satu event JSON tunggal dengan logger.info(event)

Mengendalikan biaya dengan sampling

• Jika mencatat lebih dari 50 field per permintaan, biaya bisa melonjak sehingga diperlukan sampling
• Sampling acak sederhana berisiko melewatkan error
• Strategi Tail Sampling yang diusulkan
  1. Error (seperti 500) selalu disimpan
  2. Permintaan lambat (di atas p99) selalu disimpan
  3. Pengguna VIP atau sesi dengan flag tertentu selalu disimpan
  4. Sisanya hanya diambil sampel acak 1–5%
• Dengan ini, penghematan biaya dan pelestarian event penting bisa dicapai sekaligus

Meluruskan kesalahpahaman umum

• Structured Logging ≠ Wide Event: format JSON saja tidak cukup; konteks adalah inti utamanya
• Menggunakan OpenTelemetry ≠ observability lengkap: yang distandarkan hanya pengumpulan; apa yang dicatat tetap tanggung jawab developer
• Tidak sama dengan tracing: tracing menunjukkan alur antarservice, sedangkan Wide Event memberi konteks di dalam service
• Pemisahan bahwa log untuk debugging dan metrics untuk dashboard tidak lagi perlu — Wide Event memenuhi kedua kebutuhan itu
• Anggapan bahwa data berkardinalitas tinggi itu mahal sudah usang; database modern seperti ClickHouse dan BigQuery dapat menanganinya secara efisien

Dampak penerapan Wide Event

• Debugging berubah dari ekskavasi (archaeology) menjadi analitik (analytics)
• Dari pendekatan grep pada log 50 service untuk mencari “kegagalan pembayaran pengguna”,
  menjadi analisis berbasis satu query seperti “lihat tingkat kegagalan pembayaran pengguna premium menurut kode error”
• Hasil akhirnya, log berubah dari alat yang mengatakan kebohongan menjadi aset data yang mengatakan kebenaran