ClickStack – Alternatif Datadog open source yang dibangun dengan ClickHouse dan HyperDX

 (clickhouse.com)
4 poin oleh GN⁺ 2025-06-07 | 1 komentar | Bagikan ke WhatsApp
  • ClickStack adalah platform observability open source berbasis ClickHouse dan HyperDX, yang menangani log, metrik, trace, dan session replay secara terintegrasi di satu tempat
  • Mendukung pencarian dan visualisasi log serta trace dengan mudah dan cepat di atas klaster ClickHouse, dan dapat diterapkan ke skema apa pun tanpa pekerjaan tambahan
  • Menyediakan pencarian yang intuitif, alert berbasis event, dan fitur dashboard sehingga engineer dapat dengan cepat memahami masalah dan meresponsnya
  • Mendukung standar OpenTelemetry secara bawaan serta menyediakan integrasi SDK untuk beragam bahasa dan platform
  • Dibandingkan solusi komersial yang sudah ada, lebih murah dan mudah dikonfigurasi, serta memungkinkan seluruh alur kerja ditangani dalam satu platform tanpa perlu bolak-balik antar berbagai alat observability

Fitur utama

  • Analisis korelasi dan pencarian untuk log, metrik, session replay, dan trace dapat dilakukan di satu tempat
  • Memanfaatkan skema ClickHouse yang sudah ada apa adanya, dengan struktur yang tidak terikat pada skema
  • Cocok untuk data berukuran besar berkat kecepatan pencarian yang tinggi dan optimasi visualisasi
  • Mendukung full-text search dan pencarian atribut, sementara penggunaan SQL bersifat opsional
  • Memungkinkan analisis tren perubahan event serta pembuatan alert yang mudah dan dashboard
  • Mendukung kueri string JSON native
  • Dapat memeriksa event terbaru melalui fitur tail log dan trace secara real-time
  • Mendukung integrasi OpenTelemetry dan lingkungan APM (pemantauan performa)

Deployment dan cara memulai

  • Paket ClickStack dapat di-deploy secara terintegrasi dengan menyertakan ClickHouse, HyperDX, OpenTelemetry Collector, dan MongoDB
  • UI HyperDX dapat diakses melalui browser
  • Dapat dihubungkan dengan lingkungan ClickHouse Cloud, dan mudah di-deploy ke berbagai lingkungan

Instrumentasi aplikasi dan integrasi

Untuk mengumpulkan data log, metrik, trace, dan session replay dengan HyperDX, aplikasi perlu mengirim data telemetry ke HyperDX

  • Menyediakan opsi SDK dan integrasi: tersedia SDK untuk berbagai bahasa/lingkungan seperti browser, Node.js, Python, dan lainnya sehingga mudah diintegrasikan
  • Mendukung standar OpenTelemetry: kompatibel dengan berbagai bahasa dan runtime seperti Kubernetes, JavaScript, Python, Java, Go, Ruby, PHP, .NET, Elixir, Rust, dan lainnya
  • Collector OpenTelemetry secara default dapat dihubungkan di alamat http://localhost:4318

Cara berkontribusi

  • Kontribusi komunitas disambut dalam berbagai bentuk seperti mengirim PR, mendaftarkan issue, memperbaiki dokumentasi, memberikan vote pada issue terbuka, dan menyediakan use case baru

Motivasi pengembangan dan filosofi

Tujuan tim pengembang HyperDX adalah membantu semua engineer memanfaatkan telemetry di lingkungan produksi agar dapat menyelesaikan masalah dengan cepat

Masalah utama yang ada saat ini:

  • Alat observability untuk produksi mahal dan biayanya meningkat seiring skala data
  • Konfigurasi dan penggunaannya sulit, sehingga membutuhkan SRE dan tenaga ahli
  • Setiap fungsi seperti log, session replay, dan APM terpisah-pisah, sehingga keterkaitan informasi menjadi merepotkan

Untuk mengatasi keterbatasan ini, ClickStack dan HyperDX disediakan sebagai open source

  • HyperDX telah diakuisisi oleh ClickHouse

Bacaan terkait

1 komentar

 
GN⁺ 2025-06-07
Komentar Hacker News

  • Penasaran kenapa membuat frontend kustom alih-alih memakai Grafana yang sudah ada

  • Berbagi bahwa harga DataDog mahal sehingga HyperDX terasa sangat menarik; LogLayer miliknya (https://loglayer.dev) adalah structured logger untuk TypeScript yang mendukung pengiriman log ke berbagai logger dan layanan cloud (termasuk DataDog), dan ia berencana merilis integrasi untuk HyperDX dalam waktu dekat; juga menyampaikan harapan untuk menambahkan tautan dokumentasi cara menghubungkan HyperDX dan LogLayer ke bagian "integrations" di situsnya; membagikan PR terkait (https://github.com/hyperdxio/hyperdx-js/pull/184)

    • Permintaan agar fitur pengiriman log ke VictoriaLogs juga ditambahkan, disertai usulan dengan tautan dokumentasi berbagai protokol ingest data (https://docs.victoriametrics.com/victorialogs/data-ingestion/)
    • Umpan balik positif bahwa integrasi LogLayer dan HyperDX terlihat keren sehingga ingin dicek langsung

  • Sedang memakai HyperDX di produksi nyata dan sangat puas dengan integrasinya dengan ClickHouse serta efisiensi biayanya; penasaran apakah perlu bersiap bermigrasi dari HyperDX ke ClickStack

    • Menyampaikan kegembiraan karena selalu antusias mendengar masukan dari pengguna produksi; menjelaskan bahwa HyperDX sama sekali tidak akan hilang dan di halaman marketing juga tetap ditekankan sebagai inti dari stack ini; ke depan mereka akan lebih fokus pada pola HyperDX v2 dan ClickStack, tetapi HyperDX sendiri akan tetap berfokus pada pengalaman pengguna akhir; tambahan penjelasan bahwa tujuan ClickStack adalah memanfaatkan lebih banyak fleksibilitas dan performa dari core berbasis ClickHouse; membagikan bahwa tim sedang fokus pada engineering agar perubahan bisa berjalan mulus baik di open source maupun cloud; sebagai tambahan, menyebut akhir-akhir ini Wi-Fi sedang tidak stabil sehingga balasannya terlambat

  • Berbagi pendapat bahwa trace dan logging di OTel cukup bagus, tetapi fitur metrics OTel terasa dirancang terlalu rumit; bertanya apakah ClickStack bisa meng-ingest data statsd (terutama termasuk ekstensi tagging milik Datadog), apakah ada service tagging terpadu dan fitur pengaitan antara trace/log/metric, apakah UI punya fitur penautan data terkait, penasaran kenapa SDK Elixir memakai library hyperdx, dan apakah fitur Notebooks ada di roadmap

    • Menanggapi bahwa itu pertanyaan bagus, sambil sepakat bahwa salah satu alasan standar metrics OTel menjadi sangat beragam sekaligus agak disayangkan; menjelaskan bahwa OTel collector bisa mengumpulkan berbagai format seperti statsd dan menulis langsung ke ClickHouse sehingga statsd dapat digunakan (tautan dokumen statsdreceiver); log/trace bisa dikaitkan dengan trace/span id dan resource attributes, dan pada workload k8s korelasi hingga metrics juga sudah disediakan; menyebut bahwa correlation metrics dengan fitur exemplars belum didukung tetapi direncanakan ke depan; SDK Elixir dipilih agar dukungan bisa menyesuaikan lingkungan pengguna, library tersebut berkembang secara independen dan masih dipertimbangkan apakah nantinya akan beralih ke SDK OTel resmi; membagikan contoh bahwa integrasi OTel untuk Deno pernah diadopsi sendiri dengan cepat; Notebooks akan segera dirilis dalam status eksperimental untuk mengaktifkan berbagai workflow, dan menyampaikan minat pada lebih banyak masukan pengguna
    • Bertanya kenapa OTel metrics terasa rumit, sambil menjelaskan keuntungan bahwa pipeline metrics yang sudah ada seperti statsd atau DD agent tidak harus diganti dengan mudah

  • Berpendapat bahwa HyperDX tampak mirip dengan Signoz karena sama-sama berbasis ClickHouse dan menyediakan versi open source serta cloud; penasaran apa perbedaannya, dan mengamati bahwa UI-nya juga mirip

    • Menambahkan rasa penasaran karena ingin mendengar perbandingan langsung dengan Signoz

  • Sedang mencari solusi logging baru untuk menggantikan Kibana, dan karena pengalaman dengan ClickHouse bagus jadi tertarik dengan UI HyperDX; saat ini pipeline log yang dipakai adalah Vector di atas Kubernetes, dan karena Vector mendukung OTel sink (beta), ia sedang memikirkan cara terbaik mengirim log ketika datanya berupa JSON; menekankan bahwa lingkungannya memiliki trafik besar berukuran TB dan performa tinggi

    • Menyebut bahwa ClickHouse memang kuat untuk pemrosesan skala besar dan throughput tinggi, serta menyinggung contoh penggunaan direct write ke ClickHouse dari Vector (misalnya presentasi Anthropic); mengajak untuk mencobanya dan memberi masukan agar bisa dibantu
    • Berpendapat bahwa menstandarkan format pengiriman data ke otel adalah pilihan strategis yang baik untuk masa depan, dan merasa dua kekhawatiran sekaligus berkurang

  • Penasaran apa perbedaan Signoz dengan HyperDX (atau ClickHouse), mengamati bahwa keduanya sama-sama berasal dari YC dan memanfaatkan ClickHouse

    • Menjelaskan bahwa seperti disebut di bawah, pembeda terbesar adalah ini merupakan produk 1st-party yang resmi dikembangkan oleh tim ClickHouse; bisa berjalan fleksibel di hampir semua instance ClickHouse dan juga mendukung schema kustom, yang penting untuk tuning performa tinggi atau lingkungan skala besar tertentu (misalnya Anthropic); jika sudah punya data di ClickHouse, adopsinya juga sangat mudah; tidak memaksakan otel secara mutlak dan secara native juga mendukung Vector, Cribl, S3, script kustom, dan lainnya; juga memiliki fitur telemetry wrangling (delta event berkardinalitas tinggi, clustering log/span otomatis berbasis ML, dll.) sehingga eksplorasi data menjadi lebih mudah; lewat fitur session replay, integrasi menyeluruh didukung mulai dari klik hingga metrics infrastruktur; dioperasikan pada skala 100PB+ di monitoring internal ClickHouse Cloud dan cukup fleksibel untuk menelusuri isu pengguna tertentu secara end-to-end; secara filosofis mereka percaya bahwa alih-alih memisahkan "3 pillars" umum (logs/metrics/traces), membuat alat eksplorasi petunjuk yang terpadu/terpusat lebih cocok untuk debugging di dunia nyata
    • Memperjelas bahwa “You” merujuk ke ClickHouse

  • Berbagi pengalaman bahwa setelah mendaftar, widget "Was this search result helpful?" sudah muncul di UI bahkan sebelum melakukan pencarian sehingga UX terasa membingungkan; menemukan bug bahwa saat menekan tombol Hide, tombol feedback menghilang lalu ketika feedback ditekan lagi kembali seperti semula; menilai secara keseluruhan font yang dipakai monospace dan ukurannya kecil, lalu putih tebal dan hijau terang kurang serasi dengan latar gelap; bahkan setelah mengganti ke font sistem, tidak banyak membaik, sehingga menyarankan gaya UI yang lebih tradisional; memberi masukan bahwa desain yang sulit dibaca membuatnya ragu untuk menggunakan produk ini

  • Penasaran apakah ClickHouse adalah satu-satunya elemen stateful di stack ini; tertarik pada kompatibilitas dengan Rotel, OTel collector berbasis Rust (https://github.com/streamfold/rotel); menyebut bahwa Datadog punya pengganti OTel collector buatan sendiri dengan performa yang lebih baik

    • Menilai Rotel cocok untuk integrasi OTel di lingkungan ringan seperti lambda, dan karena endpoint ingest OTel milik HyperDX sudah standar, kemungkinan akan langsung kompatibel; juga menyebut telah berkomunikasi dengan para pengembang Rotel, dan menekankan bahwa dukungan ClickHouse yang baru ditambahkan belakangan membuat keseluruhan ceritanya jadi makin solid