Menggantikan OTel dan Memperluas Platform Observability dengan Wide Events

• LogHouse internal ClickHouse tumbuh dalam satu tahun dari 19PiB dan sekitar 40 triliun baris menjadi penyimpanan log tak terkompresi lebih dari 100PB dan hampir 500 triliun baris
• Jalur ingest yang sebelumnya berpusat pada OpenTelemetry berpindah-pindah antara JSON, format OTel, dan format ClickHouse Native, sehingga meningkatkan biaya CPU dan risiko log terbuang
• Dengan SysEx(System Tables Exporter), ClickHouse melakukan penyalinan tingkat byte dari system table ke LogHouse dan memproses 37M logs/s dengan 70 core CPU
• OTel tetap berguna untuk log kegagalan berbasis stdout·stderr dan format standar netral vendor, tetapi telemetri inti ClickHouse beralih ke SysEx dan wide events
• Setelah mengadopsi HyperDX, ClickHouse menggabungkan UI native ClickHouse, pencarian sintaks Lucene, analisis SQL, dan eksplorasi tanpa bergantung pada skema, sehingga menggantikan sebagian peran UI kustom berbasis Grafana

---

LogHouse tumbuh menjadi skala 100PB dan 500 triliun baris

• LogHouse adalah platform logging internal yang dibuat untuk monitoring ClickHouse Cloud, dan sebelumnya juga berperan menggantikan biaya Datadog yang terus membesar
• Setahun lalu LogHouse memproses 19PiB data tak terkompresi dan 37 triliun baris; kini menyimpan lebih dari 100PB data tak terkompresi dan hampir 500 triliun baris
• Komposisi utama data yang tersimpan saat ini adalah sebagai berikut
  • SysEx: 93.6PB, 431 triliun baris
  • OTel: 14.5PB, 16.7 triliun baris
• Sebelumnya semua telemetri melewati OpenTelemetry, tetapi kini sebagian besar data masuk dari SysEx, exporter khusus yang dibuat ClickHouse

Keterbatasan pipeline OpenTelemetry

• OpenTelemetry cocok sebagai pipeline standar awal untuk mengirim semua log Pod di lingkungan Kubernetes ke ClickHouse
• Log teks stdout dari ClickHouse saja tidak cukup untuk analisis operasional; analisis nyata membutuhkan log terstruktur, metrik, detail eksekusi, disk I/O, dan status pekerjaan latar belakang dari tabel system
• Jalur log OTel lama melewati beberapa tahap konversi
  • Instance ClickHouse pelanggan menulis log ke stdout dalam JSON
  • kubelet menyimpan log di /var/log/…
  • OTel collector membaca log dari disk, mem-parse JSON, lalu mengubahnya menjadi representasi di memori
  • collector mengubahnya lagi ke format log OTel
  • ClickHouse Go client mengonversinya kembali ke format ClickHouse Native lalu memasukkannya ke LogHouse
• Pipeline OTel nyata juga mencakup edge collector, transport OTLP, gateway collector, dan pemrosesan tambahan, sehingga tiap tahap menambah overhead, latensi, dan kompleksitas
• Seiring skala membesar, dua masalah menjadi menonjol
  • Tipe ClickHouse Native melewati JSON dan format OTel, membuang CPU dan menurunkan fidelity data
  • OTel agent pada node Kubernetes terbentur batas CPU dan memori, lalu menjatuhkan baris log saat trafik melonjak
• Diperkirakan perlu sekitar 8.000 core CPU di seluruh agent dan collector untuk memproses 20M rows/s tanpa kehilangan data berbasis OTel

SysEx: collector khusus untuk transfer ClickHouse-to-ClickHouse

• ClickHouse membuat System Tables Exporter(SysEx) untuk mengirim data langsung dari system table ClickHouse di Pod pelanggan ke tabel LogHouse
• SysEx melakukan penyalinan tingkat byte antara sumber dan tujuan, mempertahankan tipe ClickHouse Native, dan menghapus konversi perantara
• Struktur ini memudahkan engineer mengubah query yang digunakan untuk debugging live instance menjadi query data historis seluruh fleet di LogHouse
  • Skema tabelnya sama, hanya ditambahkan kolom enrichment seperti nama Pod dan versi ClickHouse
• Arsitekturnya terdiri dari pool SysEx scraper dan hash ring
  • hash ring menetapkan Pod pelanggan ke replica scraper tertentu untuk membagi beban
  • scraper menjalankan SELECT pada system table Pod sumber dan melakukan streaming data ke LogHouse
  • scraper mengoordinasikan penerusan byte antara sumber dan tujuan tanpa deserialisasi
• Untuk menghindari terlewatnya flush buffer system table, SysEx menggunakan sliding time window, biasanya melakukan query 5 menit di belakang real-time
• Karena perilaku default Go ClickHouse client mengonversi data ke Go native type, ClickHouse mengontribusikan kemampuan untuk melewati marshalling internal ke clickhouse-go
• Karena SysEx memakai model berbasis pull, ia tidak membutuhkan buffering berat seperti OTel, dan jika LogHouse sementara tidak tersedia atau telemetri sumber melonjak, SysEx dapat melakukan backfill dengan men-scrape ulang window historis

Skema dinamis dan snapshot status

• SysEx mengharuskan skema sumber dan target cocok, tetapi skema system table ClickHouse sering berubah karena penambahan metrik dan kolom baru
• Untuk menanganinya, saat bertemu system table, SysEx memeriksa dan melakukan hash pada skema, lalu mengecek apakah LogHouse memiliki tabel dengan skema yang sama
  • Jika ada, data dimasukkan ke tabel yang sudah ada
  • Jika tidak, SysEx membuat versi skema baru seperti text_log_6
• Saat query, ClickHouse menggunakan Merge table engine untuk menggabungkan beberapa iterasi skema menjadi satu view logis
• Merge table engine memungkinkan query tetap berjalan tanpa pengelolaan manual saat skema berubah, dengan memilih hanya kolom yang kompatibel atau membatasi query ke tabel yang memiliki kolom yang diminta
• ClickHouse juga secara berkala menangkap system table in-memory seperti system.processes sebagai snapshot dan menyimpannya di LogHouse
• Snapshot ini digunakan untuk menganalisis status cluster, skema tabel, dan konfigurasi cluster pada titik waktu tertentu secara historis

Analisis seluruh fleet dan angka efisiensi

• Berkat SysEx, Advanced Dashboard queries yang digunakan pelanggan untuk memonitor instance ClickHouse individual dapat dijalankan sekaligus di seluruh fleet instance pelanggan
• Dalam analisis rilis, query diagnostik dijalankan sebelum dan sesudah deployment untuk memeriksa pola performa query, tren penggunaan resource, dan perubahan tingkat error secara real-time pada skala fleet
• Dashboard dukungan mengorelasikan Advanced Dashboard queries dengan log jaringan, event Kubernetes, serta event data plane dan control plane dalam antarmuka yang sama
• Perbandingan efisiensi berdasarkan LogHouse adalah sebagai berikut
  • OTel Collectors: mengirim 2M logs/s dengan lebih dari 800 core CPU
  • LogHouse Scrapers(SysEx): mengirim 37M logs/s dengan 70 core CPU
• SysEx meningkatkan volume event 20 kali pada sumber data paling penting, sambil menurunkan footprint CPU menjadi kurang dari 10% dari sebelumnya dan membuat event tidak lagi dijatuhkan di edge

Area yang masih membutuhkan OpenTelemetry

• OpenTelemetry tetap menjadi pilihan default ClickStack karena menyediakan format netral vendor yang terstandardisasi dan pengalaman onboarding untuk pengguna baru
• SysEx sangat terikat dengan internal ClickHouse dan memakai struktur berbasis pull yang men-query live system table, sehingga tidak dapat men-scrape data jika layanan sedang crash loop atau down
• OpenTelemetry secara pasif menangkap log yang di-emit ke stdout dan stderr, sehingga dapat mengumpulkan log saat terjadi kegagalan meskipun layanan tidak sepenuhnya healthy
• ClickHouse tetap menjalankan OpenTelemetry di semua layanan ClickHouse, tetapi mengubah cakupan pengumpulan
  • Sebelumnya semua log hingga trace-level di-ingest
  • Kini hanya log info-level ke atas yang dikumpulkan
• Setelah perubahan ini, OTel collector dan gateway berjalan dengan resource jauh lebih kecil, dan dipertahankan sebagai pipeline yang lebih kecil pada skala 2M log lines/s seperti disebutkan di atas

HyperDX dan pengalaman eksplorasi native ClickHouse

• UI pertama LogHouse adalah pengalaman observability kustom yang dibangun di atas Grafana, tetapi seiring bertambahnya SysEx dan telemetri wide-column, dibutuhkan UI yang lebih terintegrasi mendalam dengan ClickHouse
• HyperDX adalah UI native ClickHouse yang mendukung eksplorasi log dan trace, korelasi, serta analisis berskala besar
• Data dapat di-query dengan sintaks Lucene sehingga eksplorasi menjadi lebih sederhana, sementara SQL tetap dapat digunakan untuk analisis event yang kompleks
• Pendekatan tanpa bergantung skema di HyperDX v2.0 tidak mengharuskan satu struktur tabel log tetap
  • Menangani format data pipeline OpenTelemetry yang terstandardisasi tetapi berubah-ubah
  • Menangani tabel wide-column khusus dari SysEx dan custom exporter lain tanpa pengetahuan skema sebelumnya atau grok pattern yang rumit
• Grafana juga masih memiliki peran di LogHouse
  • Aplikasi internal berbasis Grafana meminta namespace, mengetahui lokasi data per layanan, lalu merutekan query ke instance ClickHouse yang sesuai
  • Dashboard dan alert lama berbasis metrik Prometheus masih tetap berada di Grafana
  • Metrik tingkat tinggi seperti kube_state_metrics cocok untuk alerting meskipun tidak cocok untuk deep investigation

Wide events dan observability berkardinalitas tinggi

• Penerapan SysEx menggeser pengumpulan yang berpusat pada log stdout ke model yang berpusat pada wide events berbasis system table dan data berkardinalitas tinggi
• ClickHouse menyebutnya sebagai gabungan LogHouse dan ClickStack, bukan Observability 2.0
• Model ini menyimpan telemetri berkardinalitas tinggi dari berbagai sumber di warehouse pusat, bukan menggunakan model tiga pilar tradisional
• Tiap row memuat konteks kaya seperti query identifier, nama Pod, metadata versi, dan detail jaringan, tanpa melakukan pra-agregasi atau membuang dimension demi menyesuaikan batas metric store
• Data disimpan apa adanya saat ingest tanpa diringkas, lalu agregasi ditunda hingga query time
• Perbedaannya dengan Prometheus adalah semua data point disimpan
  • Field seperti insertDuration tidak dipra-agregasi, melainkan setiap nilai dipertahankan bersama dimension terkait
  • Jika semua timeseries dari seluruh kombinasi label disimpan di Prometheus, terjadi ledakan kardinalitas
  • Pra-agregasi histogram mengendalikan penggunaan resource, tetapi membuat pertanyaan seperti spike tertentu berasal dari insert instance, tabel, dan time window mana menjadi sulit dijawab
• Elasticsearch juga mendorong wide events dan struktur dokumen fleksibel, tetapi desain columnar ClickHouse memungkinkan data event berkardinalitas tinggi dan bervolume besar disimpan serta di-query secara efisien pada skala besar

Alat data science dan analisis SQL

• Beberapa karakteristik dapat divisualisasikan dari satu wide event, dan dari titik tertentu pada chart pengguna dapat kembali ke raw log
• Karena ClickHouse menyediakan integrasi visualisasi data dan language client, alat berbasis SQL seperti Plotly, Jupyter notebook, Hex, Bokeh, dan Evidence dapat digunakan
• Pencarian sintaks Lucene di HyperDX cocok untuk lookup dan filtering cepat, tetapi pertanyaan kompleks membutuhkan SQL
• ClickHouse SQL dapat mengekspresikan join, operasi berbasis waktu, dan transformasi
  • Contohnya mencocokkan event Killing dan event Created dari container yang sama di Kubernetes event stream dengan ASOF JOIN untuk menghitung waktu dari terminasi hingga restart
  • Query contoh memproses 17.78M rows dan 581.49MB, memakan waktu 0.099 detik, dengan peak memory 272.88MiB
• Metrik yang dibutuhkan dapat diturunkan saat query time di wide events warehouse, tanpa harus membuat dan men-deploy component terlebih dahulu

Sumber data yang ditambahkan ke LogHouse

• LogHouse menambahkan lebih banyak data sink berbasis wide event atas permintaan tim engineering dan support
• kubenetmon: alat open-source untuk monitoring jaringan Kubernetes, menggunakan Linux conntrack untuk menangkap L3/L4 connection data serta jumlah byte dan packet
  • Menyediakan forensics, atribusi workload dan Pod, serta metering pelacakan biaya seperti cross-region egress
  • Proyek: https://github.com/ClickHouse/kubenetmon
• Kubernetes Event Exporter: mem-fork exporter populer dan menambahkan ClickHouse native sink untuk menganalisis event Kubernetes pada skala besar
  • fork: ClickHouse/kubernetes-event-exporter
  • Ke depannya sedang dijalankan rencana untuk meng-ingest bukan hanya event, tetapi seluruh Kubernetes object model ke LogHouse, serta menyimpan snapshot pada setiap titik perubahan
• Control Plane Data: mengumpulkan data operasional dari divisi Control Plane yang belum di-onboard ke LogHouse
• Real User Monitoring(RUM): proyek yang sedang berjalan, mengirim frontend performance metric dari browser pengguna melalui public gateway ke pipeline OTel
• Istio Access Log: meng-ingest HTTP-level traffic data dari Istio service mesh untuk menangkap pola request dan response, latensi, serta routing decision
  • Dikombinasikan dengan system.query_log dan network flow kubenetmon untuk menganalisis silang SQL query, HTTP request, dan packet flow

Langkah berikutnya: zero-impact scraping dan JSON

• Query scrape SysEx dibatasi dengan strict memory limit, tetapi pelanggan dapat merasa khawatir saat melihatnya di log dan metrik
• ClickHouse sedang mengeksplorasi zero-impact scraping yang tidak menjalankan query pada live system
  • Arah yang menjanjikan adalah memanfaatkan plain rewritable disk di S3 yang sudah digunakan ClickHouse untuk menulis service log
  • Jika worker pool SysEx me-mount langsung log table berbasis disk, query terhadap instance ClickHouse yang sedang berjalan dapat dilewati
• Jika pendekatan ini berhasil, keunggulan saat ini seperti native format, high fidelity, dan konversi minimal dapat dipertahankan sambil mengurangi persepsi dampak operasional
• Tipe JSON ClickHouse mencapai GA di 25.3, membuat kolom bertipe sesuai secara dinamis saat field baru muncul, serta menangani field dengan beberapa tipe dan schema explosion
• LogHouse sedang mengevaluasi seberapa cocok JSON untuk pola akses observability skala besar
  • Mencari string di seluruh JSON blob dapat memindai ribuan kolom
  • Ada workaround dengan menyimpan raw string JSON bersama data terstruktur
  • Sebagian besar log dan resource attribute berukuran kecil dan stabil, sehingga Map type juga masih cocok
  • HyperDX otomatis mengubah akses map menjadi fungsi JSONExtract