OTel’i değiştirip Wide Events ile gözlemlenebilirlik platformunu ölçeklendirmek

• ClickHouse’un dahili LogHouse’u 1 yıl içinde 19PiB ve yaklaşık 40 trilyon satırdan, sıkıştırılmamış 100PB üzeri log ve neredeyse 500 trilyon satır saklayan bir ölçeğe büyüdü
• Mevcut OpenTelemetry merkezli toplama yolu JSON, OTel formatı ve ClickHouse Native formatı arasında gidip gelerek CPU maliyetini ve log düşürme riskini artırıyordu
• ClickHouse, SysEx (System Tables Exporter) ile sistem tablolarını LogHouse’a bayt düzeyinde kopyalayarak 37M logs/s akışını 70 CPU çekirdeğiyle işliyor
• OTel, stdout·stderr tabanlı hata logları ve satıcıdan bağımsız standart format için hâlâ yararlı; ancak temel ClickHouse telemetrisi SysEx ve wide events merkezli yapıya geçiyor
• HyperDX’in devreye alınmasından sonra ClickHouse native UI, Lucene söz dizimiyle arama, SQL analizi ve şemadan bağımsız keşif birleştirilerek Grafana tabanlı özel UI’ın bazı rolleri değiştiriliyor

---

LogHouse 100PB ve 500 trilyon satır ölçeğine büyüdü

• LogHouse, ClickHouse Cloud izleme için oluşturulmuş dahili bir loglama platformu; daha önce artan Datadog maliyetlerinin yerini alma rolü de vardı
• 1 yıl önce 19PiB sıkıştırılmamış veri ve 37 trilyon satır işliyordu; bugün 100PB üzeri sıkıştırılmamış veri ve neredeyse 500 trilyon satır saklıyor
• Mevcut saklanan verinin başlıca bileşenleri şöyle
  • SysEx: 93.6PB, 431 trilyon satır
  • OTel: 14.5PB, 16.7 trilyon satır
• Daha önce tüm telemetri OpenTelemetry’den geçiyordu; şimdi ise verinin büyük kısmı ClickHouse’un geliştirdiği amaca özel exporter olan SysEx’ten geliyor

OpenTelemetry pipeline’ının sınırları

• OpenTelemetry, Kubernetes ortamındaki tüm Pod loglarını ClickHouse’a gönderen ilk standart pipeline olarak uygundu
• ClickHouse’un yalnızca stdout metin logları operasyonel analiz için yeterli değildi; gerçek analiz için system tablolarındaki yapılandırılmış loglar, metrikler, yürütme ayrıntıları, disk I/O ve arka plan iş durumları gerekiyordu
• Mevcut OTel log yolu birden çok dönüşüm aşamasından geçiyordu
  • Müşteri ClickHouse instance’ı logları JSON olarak stdout’a yazıyordu
  • kubelet logları /var/log/… altına kaydediyordu
  • OTel collector diskteki logları okuyup JSON’ı parse ederek bellek içi temsile dönüştürüyordu
  • collector bunu yeniden OTel log formatına dönüştürüyordu
  • ClickHouse Go client, LogHouse’a eklemek için yeniden ClickHouse Native formatına dönüştürüyordu
• Gerçek OTel pipeline’ında edge collector, OTLP aktarımı, gateway collector ve ek işleme de yer alıyor; her aşama overhead, gecikme ve karmaşıklığı artırıyor
• Ölçek büyüdükçe iki sorun öne çıktı
  • ClickHouse Native tipleri JSON ve OTel formatlarından geçerken CPU boşa harcanıyor ve veri doğruluğu düşüyordu
  • Kubernetes node’larındaki OTel agent’ı CPU ve bellek limitlerine takılıyor, trafik artışlarında log satırlarını düşürüyordu
• OTel tabanlı olarak 20M rows/s akışını kayıpsız işlemek için agent ve collector genelinde yaklaşık 8.000 CPU çekirdeği gerekeceği tahmin ediliyor

SysEx: ClickHouse-to-ClickHouse aktarımına özel toplayıcı

• ClickHouse, müşteri Pod’larındaki ClickHouse sistem tablolarından LogHouse tablolarına veriyi doğrudan aktarmak için System Tables Exporter(SysEx) geliştirdi
• SysEx, kaynak ve hedef arasında bayt düzeyinde kopyalama yaparak ClickHouse Native tiplerini koruyor ve ara dönüşümleri ortadan kaldırıyor
• Bu yapı sayesinde mühendislerin live instance debug için kullandığı sorgular, LogHouse’taki tüm fleet geçmiş verisine yönelik sorgulara kolayca dönüştürülebiliyor
  • Tablo şeması aynı kalıyor; yalnızca Pod adı ve ClickHouse sürümü gibi enrichment kolonları ekleniyor
• Mimari, SysEx scraper havuzu ve hash ring yapısından oluşuyor
  • hash ring, müşteri Pod’larını belirli bir scraper replica’ya atayarak yükü dağıtıyor
  • scraper, kaynak Pod’un system table’ında SELECT çalıştırıyor ve veriyi LogHouse’a stream ediyor
  • scraper, deserialize etmeden kaynak ile hedef arasındaki bayt aktarımını koordine ediyor
• Sistem tablolarındaki buffer flush atlamalarını önlemek için SysEx kayan zaman penceresi kullanıyor ve genellikle gerçek zamandan 5 dakika geriden sorguluyor
• Go ClickHouse client’ın varsayılan davranışı veriyi Go native type’a dönüştürdüğü için ClickHouse, dahili marshalling’i atlayan bir özelliği clickhouse-go’ya katkı olarak ekledi
• SysEx pull tabanlı bir model olduğundan OTel gibi ağır buffering gerektirmiyor; LogHouse geçici olarak kullanılamaz olsa veya kaynak telemetri aniden artsa bile geçmiş window yeniden scrape edilerek backfill yapılabiliyor

Dinamik şema ve durum snapshot’ları

• SysEx’te kaynak ve hedef şemaların eşleşmesi gerekiyor; ancak ClickHouse system table şeması yeni metrik ve kolon eklemeleriyle sık sık değişiyor
• Bunu ele almak için SysEx bir system table ile karşılaştığında şemayı inceliyor ve hash’liyor, ardından LogHouse’ta aynı şemaya sahip tablo olup olmadığını kontrol ediyor
  • Varsa mevcut tabloya insert ediyor
  • Yoksa text_log_6 gibi yeni bir şema sürümü oluşturuyor
• Sorgu anında ClickHouse’un Merge table engine yapısı kullanılarak birden çok şema yinelemesi tek bir mantıksal view altında birleştiriliyor
• Merge table engine yalnızca uyumlu kolonları seçebiliyor veya sorguyu istenen kolona sahip tablolarla sınırlayabiliyor; böylece şema değişimlerinde manuel yönetim olmadan sorgulama yapılabiliyor
• ClickHouse, system.processes gibi bellek içi system table’ları da periyodik olarak snapshot şeklinde yakalayıp LogHouse’ta saklıyor
• Bu snapshot’lar belirli bir andaki cluster durumunu, tablo şemasını ve cluster yapılandırmasını geçmişe dönük analiz etmek için kullanılıyor

Tüm fleet analizi ve verimlilik rakamları

• SysEx sayesinde müşterilerin tekil ClickHouse instance’larını izlemek için kullandığı Advanced Dashboard queries, tüm müşteri instance fleet’i üzerinde aynı anda çalıştırılabiliyor
• Release analizinde dağıtım öncesi ve sonrası tanı sorguları çalıştırılarak sorgu performans pattern’leri, kaynak kullanım trendleri ve hata oranı değişimleri fleet ölçeğinde gerçek zamanlı görülebiliyor
• Destek dashboard’u, Advanced Dashboard sorgularıyla birlikte ağ loglarını, Kubernetes event’lerini, data plane ve control plane event’lerini aynı arayüzde korele analiz ediyor
• LogHouse bazlı verimlilik karşılaştırması şöyle
  • OTel Collectors: 800’den fazla CPU çekirdeğiyle 2M logs/s aktarım
  • LogHouse Scrapers(SysEx): 70 CPU çekirdeğiyle 37M logs/s aktarım
• SysEx, en önemli veri kaynağında event hacmini 20 kat artırırken CPU footprint’ini öncekinin %10’unun altına düşürdü ve edge’de event düşürülmesini engelledi

OpenTelemetry’nin hâlâ gerekli olduğu alanlar

• OpenTelemetry, standartlaştırılmış satıcıdan bağımsız format ve yeni kullanıcı onboarding deneyimi sunduğu için ClickStack’in varsayılan seçeneği olarak kalıyor
• SysEx, ClickHouse internals ile sıkı bağlı ve live system table sorgulayan pull tabanlı bir yapı olduğundan, servis crash loop içindeyse veya down durumdaysa veri scrape edemiyor
• OpenTelemetry, stdout ve stderr’e emit edilen logları pasif olarak yakaladığı için servis tamamen healthy olmasa bile arıza sırasındaki logları toplayabiliyor
• ClickHouse, tüm ClickHouse servislerinde OpenTelemetry’yi çalıştırmaya devam ediyor; ancak toplama kapsamını değiştiriyor
  • Daha önce trace-level loglara kadar her şey ingest ediliyordu
  • Şu anda yalnızca info-level ve üzeri toplanıyor
• Bu değişiklikten sonra OTel collector ve gateway çok daha az kaynakla çalışıyor ve yukarıda belirtilen 2M log lines/s ölçeğindeki daha küçük pipeline olarak korunuyor

HyperDX ve ClickHouse native keşif deneyimi

• LogHouse’un ilk UI’ı Grafana üzerinde oluşturulmuş özel bir gözlemlenebilirlik deneyimiydi; ancak SysEx ve wide-column telemetri arttıkça ClickHouse’a daha derin entegre bir UI ihtiyacı doğdu
• HyperDX, log ve trace keşfi, korelasyon analizi ve büyük ölçekli analiz için ClickHouse native UI sağlıyor
• Lucene söz dizimiyle sorgulama yapılabildiğinden veri keşfi basitleşiyor; karmaşık event analizi için SQL kullanılmaya devam edilebiliyor
• HyperDX v2.0’ın şemadan bağımsız yaklaşımı, tek bir sabit log tablosu yapısı gerektirmiyor
  • OpenTelemetry pipeline’ındaki standartlaştırılmış ama değişen veri formatını işliyor
  • SysEx ve diğer custom exporter’ların specialized wide-column table’larını da önceden şema bilgisi veya karmaşık grok pattern olmadan işliyor
• Grafana’nın LogHouse içinde hâlâ rolü var
  • Dahili Grafana tabanlı uygulama, namespace belirtmeyi sağlayarak servis bazlı verinin nerede olduğunu biliyor ve sorguları uygun ClickHouse instance’ına yönlendiriyor
  • Prometheus metrik tabanlı mevcut dashboard ve alert’ler hâlâ Grafana’da kalıyor
  • kube_state_metrics gibi üst seviye metrikler deep investigation için uygun olmasa da alerting için uygun

Wide events ve yüksek kardinaliteli gözlemlenebilirlik

• SysEx’in devreye alınması, stdout log merkezli toplamadan system table tabanlı wide events ve yüksek kardinaliteli veri merkezli modele geçişi sağladı
• ClickHouse bunu Observability 2.0 yerine LogHouse ile ClickStack’in birleşimi olarak adlandırıyor
• Bu model, geleneksel üç sütun modelinin yerine merkezi warehouse’ta birden çok kaynaktan yüksek kardinaliteli telemetri saklıyor
• Her row; query identifier, Pod adı, version metadata, network detail gibi zengin context içeriyor ve metric store sınırlarına uymak için dimension’lar önceden aggregate edilmiyor veya atılmıyor
• Ingest anında özetlemek yerine ham haliyle saklanıyor; aggregation query time’a erteleniyor
• Prometheus ile farkı, tüm data point’lerin saklanması
  • insertDuration gibi alanlar önceden aggregate edilmeden her değer ilgili dimension’larla birlikte korunuyor
  • Prometheus’ta tüm label kombinasyonlarının timeseries olarak saklanması kardinalite patlamasına yol açıyor
  • histogram ön aggregation’ı kaynak kullanımını kontrol etse de belirli bir spike’ın hangi instance, table, time window içindeki insert olduğunu sormayı zorlaştırıyor
• Elasticsearch de wide events ve esnek document yapısını teşvik etmişti; ancak ClickHouse’un columnar design’ı yüksek kardinaliteli ve yüksek hacimli event verisini büyük ölçekte verimli biçimde saklamayı ve sorgulamayı sağlıyor

Veri bilimi araçları ve SQL analizi

• Tek bir wide event içinden birden fazla özellik görselleştirilebiliyor ve grafikteki belirli bir noktadan raw log’a geri dönülebiliyor
• ClickHouse veri görselleştirme entegrasyonları ve dil client’ları sunduğu için Plotly, Jupyter notebook, Hex, Bokeh, Evidence gibi SQL tabanlı araçlar kullanılabiliyor
• HyperDX’in Lucene söz dizimiyle araması hızlı lookup ve filtreleme için uygun; ancak karmaşık sorular SQL gerektiriyor
• ClickHouse SQL join, zaman tabanlı işlemler ve dönüşümleri ifade edebiliyor
  • Örnek, Kubernetes event stream’inde aynı container’ın Killing event’i ile Created event’ini ASOF JOIN ile eşleyerek kapatmadan yeniden başlatmaya kadar geçen süreyi hesaplıyor
  • Örnek sorgu 17.78M row ve 581.49MB işledi, 0.099 saniye sürdü ve peak memory 272.88MiB oldu
• Gerekli metrikler önceden component olarak oluşturulup dağıtılmadan, wide events warehouse’ta query time’da türetilebiliyor

LogHouse’a eklenen veri kaynakları

• LogHouse, mühendislik ve destek ekiplerinin talepleri doğrultusunda daha fazla wide event tabanlı data sink ekledi
• kubenetmon: Kubernetes networking izleme için açık kaynak bir araç; Linux conntrack kullanarak L3/L4 connection data ile byte ve packet count yakalıyor
  • forensics, workload/pod attribution, cross-region egress gibi maliyet takibi metering’i sağlıyor
  • Proje: https://github.com/ClickHouse/kubenetmon
• Kubernetes Event Exporter: Popüler exporter fork’lanıp ClickHouse native sink eklenerek Kubernetes API event’leri büyük ölçekte analiz ediliyor
  • fork: ClickHouse/kubernetes-event-exporter
  • İleriye dönük olarak yalnızca event’leri değil, tüm Kubernetes object model’ini LogHouse’a ingest etme ve her değişim anının snapshot’ını saklama planı yürütülüyor
• Control Plane Data: LogHouse’a henüz onboarding yapılmamış Control Plane bölümünün operasyonel verileri toplanıyor
• Real User Monitoring(RUM): Devam eden bir proje; kullanıcı tarayıcılarındaki frontend performance metric’leri public gateway üzerinden OTel pipeline’ına gönderiliyor
• Istio Access Log: Istio service mesh’in HTTP-level traffic data’sını ingest ederek request/response pattern’lerini, latency’yi ve routing decision’ları yakalıyor
  • system.query_log, kubenetmon network flow ile birleştirilerek SQL query, HTTP request ve packet flow çapraz analiz ediliyor

Sonraki adım: zero-impact scraping ve JSON

• SysEx scrape query’leri strict memory limit ile sınırlandırılmış olsa da müşteriler bunu log ve metriklerde gördüğünde endişe oluşabilir
• ClickHouse, live system üzerinde sorgu çalıştırmayan zero-impact scraping yaklaşımını araştırıyor
  • ClickHouse’un service log’u zaten yazdığı S3’teki plain rewritable disk’i kullanma yönü umut verici
  • SysEx worker pool disk tabanlı log table’ı doğrudan mount ederse çalışan ClickHouse instance’ını sorgulamayı bypass edebilir
• Bu yaklaşım başarılı olursa native format, high fidelity ve minimum dönüşüm gibi mevcut avantajlar korunurken operasyonel etki algısı da azaltılabilir
• ClickHouse’un JSON tipi 25.3’te GA seviyesine ulaştı; yeni alanlar ortaya çıktığında uygun tipte kolonları dinamik olarak oluşturuyor ve çok tipli alanları ile schema explosion’ı da işliyor
• LogHouse, JSON’ın büyük ölçekli gözlemlenebilirlik erişim pattern’lerine ne kadar uyduğunu değerlendiriyor
  • JSON blob’un tamamında string aramak binlerce kolonun taranmasına yol açabilir
  • Yapılandırılmış veriyle birlikte raw string JSON saklama şeklinde bir workaround var
  • Çoğu log ve resource attribute küçük ve kararlı olduğundan Map type hâlâ uygun
  • HyperDX, map access’i otomatik olarak JSONExtract fonksiyonuna dönüştürüyor