Menggantikan OTel dan Memperluas Platform Observabilitas dengan Wide Events

• LogHouse tumbuh dari memproses 19PiB menjadi lebih dari 100PB data log dalam 1 tahun, dan menskalakan hingga sekitar 500 triliun baris
• Karena keterbatasan pemrosesan data dan masalah inefisiensi pada OpenTelemetry(OTel), sistem ini beralih ke pipeline kustom (SysEx) yang disesuaikan dengan sistem inti
• Melalui perubahan ini, efisiensi tercapai dengan throughput pemrosesan event meningkat 20x sementara penggunaan CPU tetap di bawah 10%
• Dengan adopsi HyperDX dan ClickStack dari ClickHouse, dibangun integrasi UI dan data, fleksibilitas skema, serta lingkungan eksplorasi data yang kuat
• Dengan mengadopsi model wide events dan high-cardinality, kini semua event dapat disimpan dan dianalisis tanpa pra-agregasi

---

Latar belakang dan perubahan

• Platform logging internal LogHouse untuk ClickHouse Cloud telah berkembang dalam 1 tahun menjadi sistem berskala besar, dengan volume data meningkat dari 19PiB menjadi lebih dari 100PB, dan dari 37 triliun baris menjadi hampir 500 triliun baris
• Pada awalnya, semua telemetri dikumpulkan melalui OpenTelemetry(OTel), tetapi di lingkungan data berskala besar, masalah performa, keterbatasan sumber daya, serta pemborosan CPU dan kehilangan data dalam proses transformasi data menjadi sangat menonjol

Keterbatasan OTel dan alasan adopsi pipeline kustom

• Pipeline OTel sangat tidak efisien karena log diubah ke JSON, lalu dipetakan ulang ke format OTel, sehingga konversi dan marshaling berulang kali terjadi
• Dalam praktiknya, untuk memproses 20 juta baris per detik dengan basis OTel dibutuhkan sekitar 8.000 core CPU
• Saat lonjakan trafik terjadi, Collector mengalami overload dan menyebabkan log ter-drop, sehingga ada data yang gagal terkumpul

Adopsi SysEx dan arsitekturnya

• SysEx(System Tables Exporter) memindahkan data dari system tables ClickHouse langsung ke LogHouse dalam tipe aslinya tanpa transformasi
• Dengan scraping terdistribusi berbasis hash ring, buffer penundaan waktu dan metode sliding window, sistem ini mencegah kehilangan data dan memenuhi SLA internal
• Dengan Go dan fitur kustom pada klien ClickHouse, dimungkinkan transfer byte-to-byte tanpa data marshaling
• Untuk menangani skema yang dinamis, diterapkan hash skema dan manajemen skema dinamis, lalu beberapa versi skema disatukan ke dalam satu logical view melalui Merge table engine
• Mendukung pengumpulan memory table berbasis snapshot, serta pekerjaan diagnosis dan analisis yang lebih canggih

Peningkatan performa dan efisiensi

• Dengan adopsi SysEx, OTel Collector memproses 2 juta log per detik dengan 800 CPU, sedangkan SysEx dapat memproses 37 juta log dengan 70 CPU
• Peningkatan efisiensi ini secara drastis menurunkan penggunaan sumber daya, mencegah kehilangan event, dan memungkinkan lingkungan dukungan real-time

Peran OTel yang tetap berlanjut

• OTel tetap penting karena menyediakan platform standar yang vendor-netral, dan masih esensial saat terjadi gangguan layanan atau kondisi abnormal
• OTel tetap dapat menangkap log bahkan pada situasi crash atau abnormal yang tidak dapat ditangani SysEx
• Saat ini, hanya log di bawah trace level yang dihapus, dan hanya level info ke atas yang dikumpulkan untuk mengoptimalkan penggunaan sumber daya

Integrasi UI serta HyperDX dan ClickStack

• Dari UI Grafana kustom yang lama, sistem ini secara bertahap beralih ke UI ClickHouse-native berbasis HyperDX
• HyperDX menawarkan independen terhadap skema, dukungan kueri Lucene, dukungan SQL, dan kompatibilitas penuh dengan beragam tipe data ClickHouse
• Data dari berbagai struktur tabel dan sumber exporter kustom juga bisa diintegrasikan tanpa perubahan UI
• Grafana menangani metrik berbasis Prometheus dan dashboard tetap, sehingga kedua solusi digunakan secara saling melengkapi

Adopsi model Wide Events dan high-cardinality

• Wide events adalah pendekatan inovatif yang menyimpan semua data tanpa agregasi, dengan tiap baris memuat beragam konteks seperti query ID, nama Pod, dan informasi versi
• Berbeda dengan Prometheus dan sejenisnya, pendekatan ini memungkinkan analisis mendalam dan kueri fleksibel tanpa pra-agregasi, batas label, atau kekhawatiran ledakan cardinality
• Dengan melakukan agregasi yang diperlukan pada saat analisis data, sistem ini sekaligus menjaga performa dan biaya bahkan di lingkungan data skala besar

Visualisasi data dan fleksibilitas kueri

• ClickHouse terintegrasi dengan baik dengan Plotly, Jupyter notebook, dan lainnya, sehingga berbagai alat visualisasi dapat digunakan dengan bebas
• Selain eksplorasi cepat berbasis Lucene di HyperDX, analisis akar masalah tingkat lanjut melalui kueri relasi dan kondisi kompleks (SQL, JOIN, dan lain-lain) dapat langsung dilakukan di ClickHouse

Peningkatan berbagai sumber data berbasis Wide Event

• kubenetmon: open source pemantauan jaringan Kubernetes, analisis trafik L3/L4, koneksi, dan biaya
• Kubernetes Event Exporter: memanfaatkan fork dengan sink ClickHouse tambahan, melacak perubahan status klaster skala besar, dan sedang bereksperimen dengan snapshot objek penuh
• Control Plane Data, RUM(Real User Monitoring), Istio Access Log, dan data dari berbagai lapisan lain sangat memperkuat cakupan interpretasi dan kemampuan analisis korelasi

Pertimbangan operasional dan arah ke depan

• SysEx dapat terekspos ke log dan metrik selama kueri, tetapi dirancang dengan batas memori dan struktur yang meminimalkan dampak saat terjadi error
• Zero-impact scraping: sedang diteliti pendekatan yang secara fundamental menghilangkan dampak pada klaster melalui arsitektur yang sepenuhnya terlepas (misalnya memanfaatkan plain rewritable disk berbasis S3)
• OTel tetap menjadi elemen penting untuk mengamankan log pada tahap awal layanan dan kondisi abnormal, tetapi ketika pendekatan zero-impact stabil, ketergantungannya diperkirakan akan makin berkurang

Evolusi dan pemanfaatan tipe JSON di ClickHouse

• Tipe JSON kini resmi dirilis sebagai GA, memungkinkan pembuatan kolom dinamis per field, dukungan untuk berbagai tipe, dan penanganan fleksibel terhadap ledakan skema
• Karena optimasi untuk kueri JSON dengan sangat banyak kolom belum sepenuhnya matang, pendekatan seperti penyimpanan paralel berdasarkan bentuk data dan penegasan kembali kepraktisan tipe Map sedang terus disempurnakan
• Bersama HyperDX, field Map dan JSON dapat diekstrak dan dianalisis secara otomatis, dan ada rencana pemanfaatan JSON yang lebih luas ke depan

Kesimpulan dan perubahan budaya

• LogHouse kini telah menjadi platform observabilitas inti dalam operasi ClickHouse Cloud, mulai dari analisis performa hingga debugging real-time
• Penghematan biaya memang menjadi titik awal, tetapi melalui alat kustom seperti SysEx, harmoni dengan OTel, dan perluasan UI fleksibel berbasis HyperDX, tim ini sedang mengalami transformasi teknis dan kultural
• Model data berbasis Wide Event berskala besar dan berakurasi tinggi memberikan nilai dan efisiensi baru bagi engineering, support, dan analisis data
• Ke depan, berdasarkan pengalaman di skala 100PB dan 500 triliun baris, mereka berencana terus memimpin masa depan observabilitas

[GN⁺]

Opini Hacker News

• Sejujurnya, menurut saya ini bukan sesuatu yang patut dibanggakan. Menyimpan log sampai 100PB justru bukti bahwa mereka masih belum tahu apa yang benar-benar perlu dipertahankan. Sebagian besar informasi penting sebenarnya bisa dipahami cukup lewat metrik dan event terstruktur. Sisanya? Log trace detail yang tidak dibaca siapa pun, paling cuma dilihat saat insiden besar benar-benar terjadi. Cara yang lebih baik? Terapkan “kebijakan penyimpanan berbasis minat” yang otomatis menghapus log yang tak pernah dipakai untuk alarm, atau yang tak pernah muncul dalam pencarian selama 3 bulan. Kalau tidak menuju ke sana, ini cuma tumpukan sampah digital kelas premium yang sedikit lebih terkompresi
  • Saya justru lebih suka mengumpulkan semua data lalu memfilternya saat memang tidak diperlukan. Log debug biasanya memang tak dibutuhkan, tapi ketika dibutuhkan, keberadaannya benar-benar krusial. Kalau ada event yang begitu langka sampai tak bisa direproduksi, kita tak bisa kembali mengumpulkan datanya saat itu juga. Kalau semuanya sudah disimpan, tinggal dicari saja, dan menurut saya itu jauh lebih baik
  • Saya pernah sering memakai Datadog di beberapa perusahaan, dan saat biaya perpanjangan membengkak tak masuk akal, selalu ada tekanan untuk hanya menyisakan metrik dan event terbatas lalu mengurangi log. Masalahnya, kalau kita sudah tahu sebelumnya apa yang bakal rusak, pasti dari dulu sudah diperbaiki. Saat ada sesuatu yang aneh dan kita ingin tahu sebenarnya apa yang terjadi, log detail sangat dibutuhkan. Tapi kenyataannya, kalau situasinya tidak berulang, tidak ada cara untuk tahu sebelumnya log mana yang penting
  • “Kebijakan penyimpanan berbasis minat” itu ide yang sangat keren. Cukup hitung jumlah akses kueri/alarm per pola log, kita sudah bisa menyusun kebijakan TTL (masa simpan). Tim kami benar-benar menerapkan pendekatan ini dan berhasil menurunkan biaya penyimpanan 70% sambil tetap mempertahankan semua data penting
  • Biaya pengiriman log juga tidak gratis. Terutama pada bahasa yang menulis log ke disk secepat mungkin untuk mencari penyebab crash, biayanya bisa makin besar. Kalau informasinya terlalu banyak, akan makin sulit menemukan korelasi yang benar-benar penting, dan log untuk bug yang sudah selesai nilainya juga cepat turun. Saya lebih suka data statistik. Data statistik lebih efisien dalam cara agregasinya, dan khususnya di bahasa berbasis GIL, penggunaan OTEL kadang punya overhead yang berlebihan
  • Kalau datanya sudah tersimpan, penyaringan atau pembersihan setelahnya menurut saya masih bisa diatasi. Menyimpan semuanya dan memakainya saat perlu terasa lebih baik daripada kerepotan karena data yang dibutuhkan ternyata tidak ada. Tentu saja, ini hanya masuk akal kalau memang ada sumber daya untuk mengoperasikan infrastruktur sebesar itu
• Ini sebenarnya hanya berlaku untuk log Clickhouse. Untuk jenis log lain tidak terlalu relevan. Meski begitu, Clickhouse sendiri memang solusi yang sangat saya suka
  • Kayaknya tipe orang yang seru banget di pesta
• Ada satu hal yang perlu diperhatikan. Saat layanan masuk ke crash loop atau down karena gangguan, dengan SysEx kita tidak bisa mengakses tabel sistem yang dibutuhkan sehingga log tak bisa dikumpulkan. Tetapi OpenTelemetry (OTel) bersifat pasif, jadi meskipun layanan belum pulih sepenuhnya, log yang keluar lewat stdout dan stderr masih bisa diambil. Dengan begitu, log tetap bisa dikumpulkan dalam kondisi gangguan dan dianalisis sampai akar penyebabnya
  • Semua proyek OTel yang pernah saya kerjakan justru bersifat aktif. Jadi isi itu terasa bukan informasi baru, melainkan penjelasan yang keliru atau tidak lengkap
• Saya ragu “wide event” benar-benar perlu memakan ruang penyimpanan sebesar ini. Observability pada dasarnya adalah masalah sampling. Yang dibutuhkan adalah kemampuan merekonstruksi keadaan pada suatu waktu sebaik mungkin dengan ruang penyimpanan seminimal mungkin. Kita bisa mengurangi jumlah sampel atau meningkatkan efisiensi kompresi. Dan saya rasa teknologi kompresi juga belum mencapai batasnya. Data yang penuh duplikasi pasti punya struktur low rank yang sangat besar. Memang sekarang sudah ada inverted index dan berbagai macam tree, tapi saya merasa masih ada harapan pada pendekatan riset yang lebih eksperimental seperti dekomposisi tensor low rank. Saya juga bukan orang industri, jadi mungkin ada yang saya lewatkan
• Saya belum pernah mengalami skala seperti ClickHouse. Apakah log dengan volume seperti ini benar-benar bisa dicari? Setahu saya ElasticSearch masih cukup bagus kuerinya untuk skala kecil. Kenapa untuk log historis orang memilih ClickHouse alih-alih menyimpan file json?
  • Saya bekerja di skala seperti ini. Jawaban singkatnya: bisa. Tapi biaya pemrosesannya bisa di luar bayangan. Kalau strategi indexing, sorting, dan clustering berantakan, satu pencarian “record yang berisi string ini” bisa menghabiskan $1~$10. Dari pengalaman saya, pada data berskala besar prinsip yang paling penting adalah “sentuh sesedikit mungkin data, sesedikit mungkin” dan “pindahkan sesedikit mungkin”. Sekali saja ada serialisasi/deserialisasi atau disk/network IO tambahan, biayanya bisa melonjak. Karena itu, dalam kasus OTel, melewatkan data melalui collector satu kali lagi bisa bertentangan langsung dengan efisiensi. Tapi pada skala petabyte, penghematan dari optimasi kecil seperti ini bisa lebih dari cukup untuk membayar gaji engineer yang menulis kode serialisasi rumit
  • Kenapa ClickHouse dipakai untuk log historis alih-alih file json? Ada beberapa alasan. (1) DB log seperti ClickHouse memakai kompresi per kolom, jadi tiap field dikompresi terpisah dan ruang simpannya jauh lebih kecil daripada file json biasa, termasuk yang sudah dikompresi. (2) DB log jauh lebih cepat untuk kueri. Bisa 1000 kali lebih cepat atau lebih, karena data yang tidak perlu bahkan tidak dibaca sama sekali. Tautan terkait. (3) Mencari dengan grep pada 100PB file json secara praktis tidak mungkin. DB log bisa diskalakan secara horizontal cukup dengan menambah node dan kapasitas penyimpanan
  • Ini soal skala dan biaya. Perusahaan kami juga sempat menabrak masalah volume log. Kalau json dimasukkan begitu saja ke Splunk, biayanya tembus lebih dari 6 juta dolar per tahun. Sementara anggaran yang disetujui cuma 5~10% dari itu. Di artikel utama disebutkan pemrosesan log json butuh 8.000 CPU, tetapi setelah dioptimalkan cukup 90 CPU saja
  • Dua atau tiga tahun lalu, performa full text search ClickHouse masih terasa kurang. Memang cepat dan bisa menangani volume besar setara ElasticSearch, tapi tergantung use case, kalau tidak diindeks dulu, ES terasa jauh lebih cepat untuk bucket, grouping, dan FTS
• Ekstremisme observability benar-benar terasa seperti agama baru. Dan uangnya juga banyak sekali
  • Kalau mau menggali sampai anomali yang bahkan belum diketahui, memang tidak ada alternatif yang benar-benar tajam
  • Yang lucu, orang dibuat menderita oleh masalah seperti ini, lalu pada akhirnya dijual strategi “bayar langganan bulanan dan semua beres”
• Di artikel utama tidak disebutkan berapa lama retensi log disimpan. Setelah lewat periode tertentu, saya ragu masih perlu menyimpan data mentah kalau yang tersisa cukup data ringkasan/agregasi
• Setiap kali kembali ke Postgres setelah memakai Clickhouse, rasanya seperti culture shock. Sulit diterima bahwa impor dump 20GB bisa makan waktu beberapa menit. Bukannya hal seperti ini seharusnya selesai dalam hitungan detik?
  • Setiap kali memakai Clickhouse rasanya sangat menyiksa. Tentu ada use case yang memang butuh Clickhouse, dan Postgres tidak bisa menggantikan semuanya, tapi entah kenapa Clickhouse terasa punya banyak “faktor risiko”, dan kalau bukan untuk tujuan yang sangat terbatas, saya merasa Postgres lebih baik hampir di semua sisi
• Orang-orang yang mendorong penggunaan wide event tidak membicarakan ledakan biaya data untuk log. Dibanding pendekatan lama (metrik + trace + log berbasis sampel), jelas biayanya jauh lebih mahal. Memang ada manfaatnya, tapi isu biaya selalu hilang dari pembahasan
  • Struktur wide event yang dirancang dengan benar justru bisa menurunkan biaya penyimpanan dibanding log tradisional. Satu permintaan eksternal tercatat sebagai satu wide event, jadi semua informasi yang dibutuhkan untuk debugging atau analisis sesudahnya sudah terkandung di sana. Lihat tulisan terkait A practitioner's guide to wide events
• Saya penasaran apa trik inti dari sistem seperti Clickhouse atau Dynamo. Apakah pada dasarnya bentuknya semacam hash table raksasa?
  • Ada dua trik umum pada DB skala besar seperti Clickhouse. Pertama, menata data di disk dengan cerdas agar sebagian besar data bisa diabaikan dan hanya potongan yang diperlukan saja yang dibaca, misalnya lewat penyimpanan kolumnar dan keluarga LSM tree. Lalu seluruh data yang disimpan dikompresi untuk meminimalkan disk IO. Kedua, penyetelan ekstrem agar semua sumber daya—CPU, RAM, disk, jaringan—dimanfaatkan semaksimal mungkin. Misalnya, Clickhouse bisa memproses lebih dari 1 miliar baris per detik per inti CPU, dan skalanya tumbuh linear sesuai jumlah inti