OTel’in Yerine Geçmek ve Gözlemlenebilirlik Platformunu Wide Events ile Genişletmek

• LogHouse, 1 yıl içinde 19PiB’den 100PB’den fazla log verisi işleyerek yaklaşık 500 trilyon satıra kadar ölçeklendi
• OpenTelemetry(OTel) veri işleme sınırları ve verimsizlik sorunları nedeniyle, temel sistemlere uygun özel bir pipeline’a (SysEx) geçildi
• Bu geçişle birlikte olay işleme hacmi 20 kat artmasına rağmen CPU kullanımı %10’un altında tutulan bir verimlilik sağlandı
• ClickHouse’un HyperDX ve ClickStack kullanıma alınmasıyla UI ve veri entegrasyonu, şema esnekliği ve güçlü bir veri keşif ortamı kuruldu
• Wide events ve yüksek kardinalite modelinin benimsenmesiyle, önceden agregasyon yapmadan tüm olayların saklanması ve analiz edilmesi mümkün hale geldi

---

Arka plan ve değişim

• ClickHouse Cloud için geliştirilen dahili loglama platformu LogHouse, 1 yıl içinde veri ölçeği 19PiB’den 100PB’nin üzerine, 37 trilyon satırdan neredeyse 500 trilyon satıra çıkan büyük bir sisteme dönüştü
• Başlangıçta tüm telemetri OpenTelemetry(OTel) üzerinden toplanıyordu, ancak büyük veri ortamlarında performans, kaynak sınırları ve veri dönüştürme sürecindeki CPU israfı ile veri kaybı sorunları belirgin hale geldi

OTel’in sınırları ve özel pipeline’a geçiş nedenleri

• OTel pipeline’ında loglar önce JSON’a dönüştürülüyor, ardından yeniden OTel formatına eşleniyor; bu sırada birden fazla dönüşüm ve marshalling tekrarlandığı için verimlilik son derece düşüyordu
• Gerçekte OTel tabanlı olarak saniyede 20 milyon satır işlemek için yaklaşık 8.000 CPU çekirdeği gerekiyordu
• Trafik ani yükseldiğinde Collector aşırı yükleniyor ve log drop yaşanıyor, yani toplanamayan veriler oluşuyordu

SysEx’in kullanıma alınması ve mimarisi

• SysEx(System Tables Exporter), ClickHouse’un system tables verilerini herhangi bir dönüşüm olmadan, özgün tipleriyle doğrudan LogHouse’a taşıyor
• Hash ring yapısıyla dağıtık scraping, zaman gecikmeli buffer ve sliding window yaklaşımıyla veri kaybını önleyip dahili SLA gereksinimlerini karşılıyor
• Go dili ve ClickHouse istemcisindeki özel yetenekler kullanılarak veri marshalling olmadan byte-to-byte aktarım yapılabiliyor
• Değişken şema yapısı için şema hash’i ve dinamik şema yönetimi uygulanıyor; Merge table engine ile birden fazla şema sürümü tek bir mantıksal görünümde birleştiriliyor
• Snapshot tabanlı bellek tablosu toplama sayesinde gelişmiş tanılama ve analiz işleri destekleniyor

Performans ve verimlilik iyileştirmeleri

• SysEx sayesinde OTel Collector saniyede 2 milyon logu 800 CPU ile işlerken, SysEx 70 CPU ile 37 milyon logu işleyebilir hale geldi
• Bu verimlilik artışıyla kaynak kullanımı ciddi biçimde azaldı, olay kaybı önlendi ve gerçek zamanlı destek ortamı sağlandı

OTel’in süregelen rolü

• OTel, standart ve vendor-neutral bir platform sunduğu için servis arızaları ya da anormal durumlarda hâlâ kritik önem taşıyor
• SysEx’in işleyemediği crash ve anormal durumlarda da log yakalama olanağı sağlıyor
• Şu anda trace seviyesinin altındaki loglar çıkarılıyor, yalnızca info seviyesi ve üzeri toplanarak kaynak kullanımı optimize ediliyor

UI, HyperDX ve ClickStack entegrasyonu

• Mevcut özel Grafana UI’dan, kademeli olarak HyperDX tabanlı ve ClickHouse-native bir UI’a geçiliyor
• HyperDX, şemadan bağımsız, Lucene sorgu desteği ve SQL desteğiyle ClickHouse’un geniş veri türleriyle tam uyumluluk sunuyor
• Farklı tablo yapıları ve özel Exporter kaynaklarından gelen veriler de UI değişikliği olmadan entegre edilebiliyor
• Grafana ise Prometheus tabanlı metrikler ve sabit dashboard’lar için kullanılmaya devam ediyor; iki çözüm birbirini tamamlıyor

Wide events ve yüksek kardinalite modelinin benimsenmesi

• Wide events, her satıra sorgu ID’si, Pod adı, sürüm bilgisi gibi çeşitli bağlamları ekleyerek, agregasyon olmadan tüm veriyi saklayan çığır açıcı bir yaklaşım sunuyor
• Bu yaklaşım, Prometheus gibi sistemlerin aksine, önceden agregasyon, label kısıtları veya kardinalite patlaması kaygısı olmadan derin analiz ve esnek sorgulama sağlıyor
• Gerekli agregasyonun veri analiz anında yapılması sayesinde, büyük veri ortamlarında hem performans hem de maliyet kontrol altında tutulabiliyor

Veri görselleştirme ve sorgu esnekliği

• ClickHouse; Plotly, Jupyter notebook gibi araçlarla güçlü entegrasyon sunduğundan farklı görselleştirme araçları serbestçe kullanılabiliyor
• Lucene tabanlı HyperDX’in hızlı keşif yeteneklerine ek olarak, karmaşık ilişki ve koşul sorguları (SQL, JOIN vb.) ile ileri düzey kök neden analizi doğrudan ClickHouse üzerinde yapılabiliyor

Farklı Wide Event tabanlı veri kaynaklarının artması

• kubenetmon: Kubernetes ağ gözlemi için açık kaynak; L3/L4 trafiği, bağlantılar ve maliyet analizi sağlıyor
• Kubernetes Event Exporter: ClickHouse sink eklenmiş bir fork kullanılıyor; büyük ölçekli küme durum değişimleri izleniyor ve tüm nesnelerin snapshot’ı için deneyler sürüyor
• Control Plane Data, RUM(Real User Monitoring), Istio Access Log gibi farklı katmanlardaki verilerle yorum kapsamı ve korelasyon analizi yetenekleri büyük ölçüde güçlendiriliyor

Operasyonel değerlendirmeler ve gelecek yönü

• SysEx, sorgu sırasında log ve metriklerde görünür olabilir; ancak bellek sınırları ve hata durumunda etkiyi en aza indiren bir yapıyla tasarlandı
• Zero-impact scraping: Tamamen decoupled bir yapı (ör. S3 tabanlı plain rewritable disk kullanımı) ile kümeye etkisini temelden ortadan kaldıran bir yöntem araştırılıyor
• OTel, servisin başlangıç ve anormal durumlarında log toplama açısından hâlâ önemli; ancak gelecekte zero-impact yaklaşımı olgunlaştıkça bağımlılığın daha da azalması bekleniyor

ClickHouse JSON tipinin evrimi ve kullanımı

• JSON tipi resmen GA oldu; alan bazlı dinamik kolon oluşturma, birden fazla tip desteği ve şema patlamasına esnek şekilde yanıt verme imkânı sunuyor
• Çok sayıda kolona sahip JSON sorgularında optimizasyon henüz kusursuz değil; bu yüzden biçime göre paralel saklama ve Map tipinin pratikliği yeniden doğrulanıyor
• HyperDX entegrasyonuyla Map ve JSON alanları otomatik çıkarılıp analiz edilebiliyor; gelecekte JSON’un daha geniş kullanımı planlanıyor

Sonuç ve kültürel değişim

• LogHouse artık performans analizinden gerçek zamanlı debugging’e kadar ClickHouse Cloud operasyonlarının temel gözlemlenebilirlik platformu haline geldi
• Maliyet düşürme başlangıç noktası olsa da, SysEx gibi özel araçlar, OTel ile uyumlu çalışma ve HyperDX tabanlı esnek UI genişlemesi sayesinde teknik ve kültürel bir dönüşüm yaşanıyor
• Büyük ölçekli ve yüksek doğruluklu Wide Event tabanlı veri modeli; mühendislik, destek ve veri analizi dahil tüm alanlarda yeni değer ve verimlilik sağlıyor
• Bundan sonra da 100PB ve 500 trilyon satır ölçeğinde edinilen deneyimle, gözlemlenebilirliğin geleceğine yön vermeye devam etmeyi hedefliyor

[GN⁺]

Hacker News görüşleri

• Açıkçası bunun övünülecek çok da büyük bir şey olduğunu düşünmüyorum. 100 PB log saklıyor olmak, hâlâ gerçekten neyin tutulması gerektiğini bulamadığınızın kanıtı. Temel bilgilerin çoğu metrikler ve yapılandırılmış event’lerle yeterince anlaşılabilir. Geri kalanı? Kimsenin okumadığı ayrıntılı trace log’lar; ancak gerçekten bir arıza çıktığında bakılıyor. Daha iyi bir yöntem? Hiçbir zaman alarm için kullanılmamış log’ları ya da 3 ay boyunca hiç sorgulanmamış log’ları otomatik silen bir “ilgiye dayalı saklama politikası” uygulamak. Bu yola gitmedikçe bu, sadece biraz sıkıştırılmış çok lüks bir dijital çöp yığını
  • Ben ise tersine, tüm veriyi toplayıp gerekmediğinde filtreleme yaklaşımını tercih ediyorum. Debug log’ları normalde gerekmez ama gerektiğinde gerçekten vazgeçilmez olur. Bazı event’ler yeniden üretilemeyecek kadar nadir olabiliyor; o noktada veriyi yeniden toplamaya başlayamazsınız. Her şey zaten kaydedilmişse sadece bulmanız yeterli olur, bence bu çok daha iyi
  • Çeşitli şirketlerde Datadog kullanırken, yenileme maliyeti fahiş çıkınca yalnızca metrikleri ve sınırlı event’leri tutup log’ları kısmamız için çok baskı gördüm. Sorun şu ki, neyin olacağını önceden bilseydik zaten çoktan düzeltirdik. Bir şey tuhaf göründüğünde gerçekte ne olduğunu anlamak için ayrıntılı log’lar çok gerekli oluyor. Ama tekrar tekrar yaşanan bir durum değilse hangi log’un önemli olduğunu önceden bilmenin bir yolu yok
  • “İlgiye dayalı saklama politikası” gerçekten harika bir fikir. Log kalıbı bazında sorgu/alarm erişim sayısını saymak bile TTL (saklama süresi) politikası oluşturmak için yeterli olabilir. Bizim ekip de bunu uyguladı; depolama maliyetini %70 azalttık ve önemli verilerin hepsini koruduk
  • Log gönderim maliyeti de bedava değil. Özellikle çökme nedenini anlamak için log’u mümkün olduğunca hızlı diske yazan dillerde bu maliyet daha da büyüyor. Bilgi çok fazla olunca gerçekten önemli korelasyonları bulmak da zorlaşıyor, çözülmüş bug’ların log’ları ise değerini hızla kaybediyor. Ben istatistiksel veriyi tercih ediyorum. İstatistiksel veri toplulaştırma açısından daha verimli ve özellikle GIL tabanlı dillerde OTEL kullanıldığında overhead aşırı olabiliyor
  • Veri zaten saklanıyorsa, sonradan filtreleme veya temizlik yapmak çözülebilecek bir sorun diye düşünüyorum. Her şeyi saklayıp gerektiğinde kullanmak, gerektiğinde elde olmamasından daha iyidir. Tabii bu, böyle büyük ölçekli bir altyapıyı işletecek kaynağınız olduğu varsayımıyla söylenebilir
• Bu aslında yalnızca Clickhouse log’ları için geçerli. Diğer log türleriyle pek ilgili değil. Tabii Clickhouse’un kendisi yine de çok hoşuma giden bir çözüm
  • Partilerde çok eğlenceli bir tip olmalısın
• Dikkat edilmesi gereken bir noktayı söyleyeyim. Servis crash loop’a girdiğinde ya da arıza nedeniyle düştüğünde, SysEx ile gerekli sistem tablolarına erişilemediği için log toplanamaz. Ama OpenTelemetry (OTel) pasif bir yaklaşım olduğu için, servis tamamen normale dönmemiş olsa bile stdout ve stderr’e çıkan log’ları toplayabilir. Böylece arıza durumunda da log toplayıp kök nedene kadar analiz yapmak mümkün
  • Benim yaptığım OTel projelerinin hepsi aktif yaklaşımdaydı. O yüzden bu, yeni bir bilgi olmaktan çok yanlış ya da eksik bir açıklama gibi geliyor
• "Wide event"in gerçekten bu kadar çok depolama alanı kaplaması gerekip gerekmediğini merak ediyorum. Observability özünde bir örnekleme problemi. Amaç, mümkün olan en az depolamayla belirli bir andaki durumu olabildiğince iyi yeniden kurabilmek. O hâlde örnek sayısını azaltabilir veya sıkıştırma verimini artırabilirsiniz. Üstelik sıkıştırma teknolojisinin de sınırına dayanmış olduğumuzu sanmıyorum. Bu kadar tekrar içeren veride mutlaka çok güçlü bir düşük dereceli (low rank) yapı vardır diye düşünüyorum. Elbette zaten inverted index ve türlü ağaç yapıları kullanılıyor ama daha deneysel, düşük dereceli tensör ayrıştırma gibi araştırma yönlerinde de umut olduğunu hissediyorum. Sektörden biri değilim; bir şeyi gözden kaçırıyor olabilirim
• ClickHouse ölçeğinde hiç çalışmadım. Bu hacimdeki log’lar gerçekten aranabilir mi? ElasticSearch’ün küçük ölçekte sorgularda iyi olduğunu biliyorum. Tarihsel log’lar için json dosyası saklamak yerine neden ClickHouse kullanasınız?
  • Bu ölçekte çalışıyorum. Kısa cevap: Evet, mümkün. Ama işleme maliyeti hayal gücünüzü aşabilir. İndeksleme, sıralama ve kümeleme stratejiniz kötüyse, bir kere "bu string’i içeren kayıt" araması yapmak bile $1~$10 tutabilir. Deneyimime göre büyük veri ölçeğinde iki ilke kritik: "mümkün olan en az veriyi, mümkün olduğunca az dokunarak işlemek" ve "mümkün olduğunca az taşımak". Serileştirme/seri açma ya da disk, ağ I/O’su bir kez bile devreye girse maliyet patlıyor. Bu yüzden OTel tarafında kolektörden bir kez daha geçirmek verimlilik ilkesine doğrudan aykırı olabilir. Ama petabayt ölçeğinde bu tür küçük optimizasyonlarla tasarruf edilen para, karmaşık serileştirme kodu yazan mühendisin maaşını fazlasıyla çıkarır
  • Neden tarihsel log’lar için json dosyaları yerine ClickHouse? Birkaç nedeni var. (1) ClickHouse gibi log veritabanları sütun bazlı sıkıştırma kullandığı için her alanı ayrı sıkıştırır ve sıradan json dosyalarından — sıkıştırılmış olsalar bile — çok daha az yer kaplar. (2) Log veritabanları sorgularda çok daha hızlıdır. 1000 kat daha hızlı olması bile mümkündür. Çünkü gerekmeyen veriyi hiç okumazlar. İlgili bağlantı. (3) 100 PB json dosyasını grep ile aramak pratikte imkânsızdır. Log veritabanları ise yalnızca depolama düğümlerini ve alanını artırarak yatay ölçeklenebilir
  • Bu bir ölçek ve maliyet meselesi. Bizim şirket de log hacmi sorununa çarptı. json’u Splunk’a doğrudan vermek yılda 6 milyon doların üzerine çıkıyor. Oysa onaylı bütçe bunun yalnızca %5~10’u. Yazıda json log işleme için 8.000 CPU gerektiği, optimizasyondan sonra ise bunun 90 CPU ile çözüldüğü söyleniyor
  • 2~3 yıl önce ClickHouse’un full-text search performansı biraz zayıftı. Hızlıydı ve ElasticSearch düzeyinde büyük ölçekleri de işleyebiliyordu ama kullanım amacına göre, önceden indeksleme yapılmamışsa toplama, gruplayama ve FTS tarafında ES’nin çok daha hızlı olduğunu düşünüyordum
• Observability aşırılığı gerçekten yeni bir din gibi hissettiriyor. Ve çok da paraları var
  • Bilinmeyen anomalilere kadar inmek istiyorsanız, açıkçası pek keskin bir alternatif yok
  • Komik olan şu: Önce sizi bu tür sorunlarla uğraşmak zorunda bırakıyorlar, sonra da bunu "aylık abonelik ödeyin, her şeyi çözelim" stratejisiyle satıyorlar
• Yazıda log saklama süresinin ne olduğu söylenmemiş. Belirli bir süreden sonra yalnızca özet/toplulaştırılmış veriyi bırakıp ham veriyi elde tutmanın gerçekten gerekli olup olmadığı şüpheli
• Clickhouse kullanıp sonra Postgres’e dönünce hep kültürel şok yaşıyorum. 20 GB dump import’unun birkaç dakika sürmesini aklım almıyor. Bunun birkaç saniyede bitmesi gerekmiyor mu?
  • Clickhouse’u her kullandığımda çok zorlanıyorum. Elbette Clickhouse’un gerekli olduğu kullanım alanları var ve Postgres her şeyi ikame edemez ama sanki Clickhouse’ta çok fazla “tehlike unsuru” var ve özel olarak sınırlı bir amaç yoksa neredeyse her açıdan Postgres daha iyi gibi geliyor
• Wide event kullanmaları için insanlara baskı yapanlar, log veri maliyetinin nasıl patladığından hiç bahsetmiyor. Geleneksel yaklaşım (metrik + trace + örnekleme tabanlı log) ile karşılaştırıldığında kesinlikle çok daha pahalı. Elbette faydaları var ama maliyet konusu hep eksik bırakılıyor
  • Doğru tasarlanmış bir wide event yapısı, geleneksel log’lara kıyasla depolama maliyetini aslında azaltabilir. Tek bir dış istek tek bir wide event olarak kaydedildiği için, sonraki debug veya analiz için gereken bilginin tamamını içerir. İlgili yazı: A practitioner's guide to wide events
• Clickhouse ya da Dynamo gibi sistemlerin temel numarasını merak ediyorum. Özünde devasa bir hash table gibi bir yapı mı bunlar?
  • Clickhouse ve benzeri büyük veritabanlarının ortak iki temel numarası var. Birincisi, veriyi diskte akıllıca yerleştirip büyük kısmını atlayarak yalnızca gerekli parçaları okuma yaklaşımı (sütun odaklı depolama, LSM tree benzeri yapılar vb.). Ayrıca depolanan verinin tamamını sıkıştırarak disk I/O’sunu da en aza indiriyorlar. İkincisi, tüm kaynakları (CPU, RAM, disk, ağ) sonuna kadar kullanacak aşırı düzeyde ayar/tuning yapmak. Örneğin Clickhouse, CPU çekirdeği başına saniyede 1 milyardan fazla satır işleyebiliyor ve çekirdek sayısıyla doğrusal biçimde ölçekleniyor