ClickStack – ClickHouse ve HyperDX ile oluşturulmuş açık kaynaklı Datadog alternatifi

 (clickhouse.com)
4 puan yazan GN⁺ 2025-06-07 | 1 yorum | WhatsApp'ta paylaş
  • ClickStack, ClickHouse ve HyperDX tabanlı açık kaynaklı bir gözlemlenebilirlik platformudur (Observability); logları, metrikleri, izleri ve oturum tekrarını tek bir yerde bütünleşik olarak işler
  • Log ve iz arama ile görselleştirme işlemlerini ClickHouse kümesi üzerinde kolay ve hızlı biçimde destekler; ek çalışma gerektirmeden her türlü şemaya uygulanabilir
  • Sezgisel arama, olay tabanlı uyarılar ve pano özellikleri sunarak mühendislerin sorunları hızla tespit edip müdahale etmesini sağlar
  • OpenTelemetry standardını varsayılan olarak destekler ve çeşitli diller ile platformlar için SDK entegrasyonları sunar
  • Mevcut ticari çözümlere kıyasla daha ucuz ve kurulumu daha basittir; birden fazla gözlemlenebilirlik aracı arasında zahmetle geçiş yapmadan tüm süreci tek bir platformda yürütür

Başlıca özellikler

  • Loglar, metrikler, oturum tekrarı ve izler için korelasyon analizi ile arama işlemleri tek bir yerde yapılabilir
  • ClickHouse’un mevcut şemasını olduğu gibi kullanır ve şemadan bağımsız bir yapı sunar
  • Hızlı arama performansı ve görselleştirme optimizasyonu sayesinde büyük hacimli veriler için de uygundur
  • Tam metin ve özellik araması desteklenir; SQL kullanımı isteğe bağlıdır
  • Olay değişim eğilimlerini analiz etme, kolay uyarı ayarlama ve pano oluşturma mümkündür
  • Native JSON string sorguları desteği sunar
  • Gerçek zamanlı log ve iz tail özellikleriyle en güncel olaylar görülebilir
  • OpenTelemetry entegrasyonu ve APM (performans izleme) ortamı desteği sağlar

Dağıtım ve başlangıç yöntemi

  • ClickStack paketi; ClickHouse, HyperDX, OpenTelemetry Collector ve MongoDB’yi içerecek şekilde birleşik olarak dağıtılabilir
  • HyperDX arayüzüne tarayıcı üzerinden erişilebilir
  • ClickHouse Cloud ortamıyla da entegre olabilir ve farklı ortamlara kolayca dağıtılabilir

Uygulama enstrümantasyonu ve entegrasyon

HyperDX ile log, metrik, iz ve oturum tekrarı verilerini toplamak için uygulamanın telemetri verilerini HyperDX’e göndermesi gerekir

  • SDK ve entegrasyon seçenekleri sunar: Tarayıcı, Node.js, Python gibi çeşitli dil ve ortamlar için SDK’lerle kolayca entegre edilebilir
  • OpenTelemetry standardı desteği: Kubernetes, JavaScript, Python, Java, Go, Ruby, PHP, .NET, Elixir, Rust gibi birçok dil ve runtime ile uyumludur
  • OpenTelemetry toplayıcısına varsayılan olarak http://localhost:4318 adresinden bağlanılabilir

Katkı yöntemleri

  • PR gönderme, issue açma, belgeleri iyileştirme, açık issue’lara oy verme ve yeni kullanım senaryoları paylaşma gibi çeşitli topluluk katkıları memnuniyetle karşılanır

Geliştirme motivasyonu ve felsefesi

HyperDX geliştiricilerinin hedefi, tüm mühendislerin üretim ortamı telemetrisini kullanarak sorunları hızlıca çözebilmesini sağlamaktır

Mevcut başlıca sorunlar:

  • Üretim gözlemlenebilirlik araçları pahalıdır ve veri ölçeği arttıkça maliyet de yükselir
  • Kurulum ve kullanım zorluğu yüksektir; SRE ve uzman desteği gerekir
  • Loglar, oturum tekrarı, APM gibi özellikler birbirinden ayrıdır, bu da bilgi ilişkilendirmesini zahmetli hale getirir

Bu sınırlamaları aşmak için ClickStack ve HyperDX açık kaynak olarak sunulmaktadır

  • HyperDX, ClickHouse tarafından satın alındı

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-07
Hacker News görüşleri

  • Neden zaten var olan Grafana yerine özel bir frontend yapıldığı merak ediliyor.

  • DataDog fiyatları pahalı olduğu için HyperDX’in gerçekten çok cazip göründüğü belirtiliyor. Yorum sahibi, işlettiği LogLayer’ın(https://loglayer.dev) TypeScript için yapılandırılmış bir logger olduğunu, farklı logger türlerine ve bulut servislerine (DataDog vb.) log gönderebildiğini söylüyor. HyperDX entegrasyonu geliştirdiklerini ve yakında yayımlayacaklarını paylaşıyor. HyperDX ile LogLayer entegrasyonuna dair doküman bağlantısını kendi sitesindeki "integrations" bölümüne eklemek istediğini belirtiyor ve ilgili PR bağlantısını paylaşıyor(https://github.com/hyperdxio/hyperdx-js/pull/184).

    • VictoriaLogs’a log gönderebilme desteğinin de eklenmesi isteniyor; çeşitli veri ingestion protokollerinin dokümantasyon bağlantısıyla birlikte öneriliyor(https://docs.victoriametrics.com/victorialogs/data-ingestion/).
    • LogLayer ile HyperDX entegrasyonunun etkileyici göründüğü ve bizzat inceleneceği yönünde olumlu geri bildirim veriliyor.

  • HyperDX’in gerçek production ortamında kullanıldığı, ClickHouse entegrasyonu ve maliyet verimliliğinden çok memnun kalındığı söyleniyor. HyperDX’ten ClickStack’e geçiş için hazırlık gerekip gerekmediği soruluyor.

    • Production kullanıcılarından gelen geri bildirimlerin her zaman heyecan verici olduğu belirtiliyor. HyperDX’in kesinlikle ortadan kalkmayacağı ve pazarlama sayfasında hâlâ stack’in çekirdeği olarak vurgulandığı açıklanıyor. İleride HyperDX v2 ve ClickStack desenine daha çok odaklanacaklarını, ancak HyperDX’in son kullanıcı deneyimine odaklanmayı sürdüreceğini söylüyorlar. ClickStack’in amacının, ClickHouse tabanlı çekirdeğin esnekliğini ve performansını daha fazla kullanmak olduğu ekleniyor. Hem açık kaynakta hem de bulutta geçişin sorunsuz olması için mühendisliğe odaklandıkları paylaşılıyor. Ayrıca son dönemde Wi‑Fi bağlantısının kararsız olması nedeniyle yanıtın geciktiği de not düşülüyor.

  • OTel’in trace ve logging tarafı iyi bulunurken, OTel metrics özelliğinin fazla karmaşık tasarlandığı düşünülüyor. ClickStack’in statsd verisini (özellikle Datadog’un tag genişletmeleriyle birlikte) ingest edip edemeyeceği, trace/log/metric için birleşik servis tagging ve ilişkilendirme desteği olup olmadığı, UI’da ilgili veriler arasında bağlantı kurma işlevi bulunup bulunmadığı, Elixir SDK’nın neden hyperdx kütüphanesini kullandığı ve Notebooks özelliğinin roadmap’te olup olmadığı soruluyor.

    • Bunun iyi bir soru olduğu belirtiliyor ve OTel metrics standardının neden bu kadar çeşitlendiğine dair empati kuruluyor. OTel collector’ın statsd gibi farklı formatları toplayıp doğrudan ClickHouse’a yazabildiği için statsd kullanımının mümkün olduğu açıklanıyor(statsdreceiver doküman bağlantısı). Log ve trace’lerin trace/span id ve resource attributes ile ilişkilendirilebildiği, k8s workload’larında metric tarafında da ilişkilendirme sağlandığı belirtiliyor. Metric correlation için exemplars desteğinin henüz olmadığı ama planlandığı ekleniyor. Elixir SDK’nın, kullanıcı ortamlarına uygun destek verme yaklaşımıyla seçildiği; kütüphanenin bağımsız şekilde geliştiği ve ileride resmî OTel SDK’ya geçmenin değerlendirildiği söyleniyor. Deno için OTel integration’ını hızlıca devreye aldıkları bir örnek de paylaşılıyor. Notebooks’un yakında deneysel olarak yayımlanacağı ve çeşitli workflow’ları etkinleştireceği belirtiliyor; daha fazla kullanıcı geri bildirimi istedikleri de ifade ediliyor.
    • OTel metrics’in neden karmaşık geldiği soruluyor ve statsd ya da DD agent gibi mevcut metric pipeline’larını kolayca değiştirmek zorunda olmamanın bir avantaj olduğu belirtiliyor.

  • Signoz gibi ClickHouse tabanlı olup açık kaynak ve bulut sürümü sunmasının HyperDX’e benzediği söyleniyor; farkların ne olduğu merak ediliyor. UI’ın da benzer göründüğü gözlemi paylaşılıyor.

    • Signoz ile doğrudan karşılaştırmaya dair daha fazla şey duymak istendiği ekleniyor.

  • Kibana’nın yerine geçecek yeni bir logging çözümü arandığı ve ClickHouse deneyimi iyi olduğu için HyperDX’in UI’ına ilgi duyulduğu belirtiliyor. Mevcut log pipeline’ının Kubernetes üzerinde Vector olduğu, Vector’ın OTel sink’i (beta) desteklediği ve verilerin JSON olduğu ortamda log göndermenin en iyi yolunun ne olacağı soruluyor. TB ölçeğinde, yüksek performanslı trafik ortamı olduğu özellikle vurgulanıyor.

    • ClickHouse’un büyük hacimler ve yüksek throughput için çok uygun olduğu, Vector’dan doğrudan ClickHouse’a yazmanın kullanıldığı örnekler bulunduğu belirtiliyor (ör. Anthropic sunumu). Gerçekten deneyip görüş paylaşılırsa yardımcı olmaktan memnun olacakları söyleniyor.
    • Veri aktarım formatını otel olarak standartlaştırmanın gelecek açısından stratejik olarak iyi bir seçim olduğu görüşü paylaşılıyor; iki ayrı kaygının azalmış gibi hissettirdiği ekleniyor.

  • Signoz ile HyperDX’in (veya ClickHouse’un) farkının ne olduğu soruluyor; her ikisinin de YC çıkışlı olduğu ve ClickHouse kullandığı gözlemi yapılıyor.

    • Aşağıda da belirtildiği gibi en büyük farkın, bunun ClickHouse ekibi tarafından resmî olarak geliştirilen 1st-party bir ürün olması olduğu söyleniyor. Neredeyse tüm ClickHouse instance’larında esnek şekilde çalışabildiği ve özel schema’ları da desteklediği belirtiliyor. Bunun yüksek performans tuning’i ya da belirli büyük ölçekli ortamlar (ör. Anthropic) için önemli olduğu vurgulanıyor. Zaten ClickHouse verisi olanlar için benimsemenin çok kolay olduğu söyleniyor. otelin zorunlu tutulmadığı; Vector, Cribl, S3, özel script’ler gibi yolların da native desteklendiği ifade ediliyor. Telemetry wrangling özellikleri (yüksek kardinaliteli event delta’ları, ML tabanlı otomatik log/span kümeleme vb.) sayesinde veri keşfinin kolaylaştığı belirtiliyor. Session replay ile tıklamalardan altyapı metric’lerine kadar geniş kapsamlı birleşik destek sunulduğu ekleniyor. Dahili ClickHouse Cloud izleme sisteminde 100PB+ ölçekte çalıştırıldığı ve belirli kullanıcı sorunlarını uçtan uca incelemeye yetecek esneklik sağladığı söyleniyor. Felsefi olarak, klasik "3 pillars" (logs/metrics/traces) ayrımından ziyade, birleşik/merkezî bir ipucu keşif aracı yapmanın gerçek dünyadaki debugging için daha uygun olduğuna inandıkları paylaşılıyor.
    • Buradaki “You” ifadesinin ClickHouse’u kastettiği netleştiriliyor.

  • Kayıt olduktan sonra UI’da "Was this search result helpful?" widget’ının arama yapmadan önce bile görünmesinin UX’i kafa karıştırıcı hale getirdiği söyleniyor. Hide düğmesine basınca geri bildirim düğmesine dönmesi, sonra tekrar geri bildirim denince eski hâline gelmesi gibi bir bug bulunduğu belirtiliyor. Genel olarak fontların monospace olduğu, yazıların küçük kaldığı ve koyu arka plan üzerinde kalın beyaz ile parlak yeşilin uyumunun kötü olduğu değerlendiriliyor. Sistem fontuna geçilse bile büyük iyileşme olmadığı, daha geleneksel bir UI stilinin tercih edilmesi gerektiği söyleniyor. Okuması zor tasarımın kullanma isteğini azalttığı yönünde geri bildirim veriliyor.

  • ClickHouse’un bu stack’teki tek stateful bileşen olup olmadığı soruluyor. Rust tabanlı OTEL collector olan Rotel’e(https://github.com/streamfold/rotel) uyumluluk da merak ediliyor. Datadog’un, kendi geliştirdiği ve performansı daha iyi olan bir OTel collector alternatifi olduğu belirtiliyor.

    • Rotel’in lambda gibi hafif ortamlarda OTel entegrasyonu için uygun göründüğü söyleniyor. HyperDX’in OTel ingest endpoint’inin zaten standart olduğu için doğrudan uyumlu olmasının beklendiği ifade ediliyor. Rotel geliştiricileriyle de iletişim kurulduğu ve ClickHouse desteğinin yakın zamanda eklenmesiyle genel hikâyenin daha da güçlendiği vurgulanıyor.