OTel को बदलकर Wide Events के साथ observability platform का विस्तार

 (clickhouse.com)
1 पॉइंट द्वारा GN⁺ 2025-06-23 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • ClickHouse का आंतरिक LogHouse सिर्फ 1 साल में 19PiB·लगभग 40 खरब rows से बढ़कर 100PB से अधिक uncompressed logs और लगभग 500 खरब rows स्टोर करने वाले स्तर तक पहुँच गया
  • मौजूदा OpenTelemetry-केंद्रित collection path में JSON, OTel format और ClickHouse Native format के बीच बार-बार रूपांतरण होने से CPU cost बढ़ी और log drop का जोखिम भी बढ़ा
  • ClickHouse ने SysEx(System Tables Exporter) के जरिए system tables को LogHouse में byte-level copy के रूप में भेजकर 70 CPU cores पर 37M logs/s प्रोसेस किए
  • OTel अब भी stdout·stderr आधारित failure logs और vendor-neutral standard format के लिए उपयोगी है, लेकिन मुख्य ClickHouse telemetry अब SysEx और wide events पर शिफ्ट हो रही है
  • HyperDX अपनाने के बाद ClickHouse native UI, Lucene syntax search, SQL analysis और schema-independent exploration को मिलाकर Grafana-आधारित custom UI की कुछ भूमिकाएँ बदली जा रही हैं

LogHouse 100PB और 500 खरब rows तक बढ़ा

  • LogHouse, ClickHouse Cloud monitoring के लिए बनाया गया एक आंतरिक logging platform है, और पहले इसका एक उद्देश्य बढ़ती Datadog लागत का विकल्प बनना भी था
  • 1 साल पहले यह 19PiB uncompressed data और 37 खरब rows संभाल रहा था, जबकि अब यह 100PB से अधिक uncompressed data और लगभग 500 खरब rows स्टोर करता है
  • वर्तमान stored data की मुख्य संरचना इस प्रकार है
    • SysEx: 93.6PB, 431 खरब rows
    • OTel: 14.5PB, 16.7 खरब rows
  • पहले सारी telemetry OpenTelemetry से होकर गुजरती थी, लेकिन अब ज्यादातर data ClickHouse द्वारा बनाए गए purpose-built exporter SysEx से आता है

OpenTelemetry pipeline की सीमाएँ

  • OpenTelemetry, Kubernetes environment में सभी Pod logs को ClickHouse तक भेजने के लिए प्रारंभिक standard pipeline के रूप में उपयुक्त था
  • सिर्फ ClickHouse के stdout text logs operational analysis के लिए पर्याप्त नहीं थे; वास्तविक analysis के लिए system tables के structured logs, metrics, execution details, disk I/O और background job state की जरूरत थी
  • पुराना OTel log path कई transformation stages से गुजरता था
    • customer ClickHouse instance logs को JSON के रूप में stdout पर लिखता था
    • kubelet /var/log/… में logs स्टोर करता था
    • OTel collector disk से logs पढ़कर JSON parse करता था और उसे memory representation में बदलता था
    • collector उसे फिर OTel log format में बदलता था
    • ClickHouse Go client उसे दोबारा ClickHouse Native format में बदलकर LogHouse में insert करता था
  • वास्तविक OTel pipeline में edge collector, OTLP transport, gateway collector और अतिरिक्त processing भी शामिल थे, जिससे हर stage पर overhead·latency·complexity बढ़ती थी
  • scale बढ़ने पर दो समस्याएँ खास तौर पर सामने आईं
    • ClickHouse Native types, JSON और OTel format से गुजरते हुए CPU बर्बाद करते थे और data fidelity भी घटती थी
    • Kubernetes nodes पर OTel agent CPU·memory limits से टकराकर traffic spike के समय log lines drop करता था
  • अनुमान था कि OTel आधारित तरीके से 20M rows/s बिना loss संभालने के लिए agents और collectors में कुल लगभग 8,000 CPU cores चाहिए होते

SysEx: ClickHouse-to-ClickHouse transfer के लिए विशेष collector

  • ClickHouse ने System Tables Exporter(SysEx) बनाया, जो customer Pods के ClickHouse system tables से data सीधे LogHouse tables तक भेजता है
  • SysEx source और destination के बीच byte-level copy करता है, जिससे ClickHouse Native types सुरक्षित रहते हैं और बीच के transformation हट जाते हैं
  • इस संरचना की वजह से engineers live instance debugging में इस्तेमाल होने वाली queries को आसानी से LogHouse के पूरे fleet के historical data पर चलने वाली queries में बदल सकते हैं
    • table schema समान रहता है, और सिर्फ Pod name·ClickHouse version जैसे enrichment columns जोड़े जाते हैं
  • architecture, SysEx scraper pool और hash ring से बनी है
    • hash ring customer Pods को किसी खास scraper replica को assign करके load distribute करती है
    • scraper source Pod की system table पर SELECT चलाकर data को LogHouse तक stream करता है
    • scraper, बिना deserialization के source और destination के बीच bytes transfer का समन्वय करता है
  • system tables में buffer flush छूट न जाए, इसके लिए SysEx sliding time window का उपयोग करता है और आम तौर पर real time से 5 मिनट पीछे query करता है
  • Go ClickHouse client का default behavior data को Go native types में बदलता है, इसलिए ClickHouse ने internal marshalling bypass करने की सुविधा clickhouse-go में contribute की
  • SysEx pull-based model होने की वजह से OTel जैसी भारी buffering नहीं मांगता, और अगर LogHouse अस्थायी रूप से उपलब्ध न हो या source telemetry अचानक बढ़ जाए तो पुरानी window को दोबारा scrape करके backfill किया जा सकता है

Dynamic schema और state snapshots

  • SysEx में source और target schema का मेल होना चाहिए, लेकिन ClickHouse system table schema नए metrics और columns जुड़ने से अक्सर बदलती रहती है
  • इसे संभालने के लिए SysEx किसी system table को देखते ही schema inspect और hash करता है, फिर LogHouse में वही schema वाली table मौजूद है या नहीं यह जांचता है
    • अगर है, तो existing table में insert करता है
    • अगर नहीं, तो text_log_6 जैसी नई schema version बनाता है
  • query के समय ClickHouse का Merge table engine इस्तेमाल करके कई schema revisions को एक logical view में जोड़ा जाता है
  • Merge table engine compatible columns ही चुन सकता है या query को उन tables तक सीमित कर सकता है जिनमें requested columns मौजूद हों, जिससे schema changes के बावजूद बिना manual management के query की जा सकती है
  • ClickHouse, system.processes जैसी in-memory system tables के periodic snapshots भी लेकर LogHouse में स्टोर करता है
  • इन snapshots का उपयोग किसी खास समय पर cluster state, table schema और cluster settings का historical analysis करने में होता है

पूरे fleet का analysis और efficiency metrics

  • SysEx की वजह से वे Advanced Dashboard queries जो ग्राहक individual ClickHouse instances की monitoring के लिए इस्तेमाल करते हैं, अब पूरे customer instance fleet पर एक साथ चलाई जा सकती हैं
  • release analysis में deployment से पहले और बाद diagnostic queries चलाकर query performance patterns, resource usage trends और error rate changes को fleet scale पर real time में देखा जाता है
  • support dashboards, Advanced Dashboard queries के साथ network logs, Kubernetes events और data plane·control plane events को एक ही interface में correlate करते हैं
  • LogHouse के आधार पर efficiency comparison इस प्रकार है
    • OTel Collectors: 800 से अधिक CPU cores के साथ 2M logs/s transfer
    • LogHouse Scrapers(SysEx): 70 CPU cores के साथ 37M logs/s transfer
  • SysEx ने सबसे महत्वपूर्ण data source में event volume को 20 गुना बढ़ाया, जबकि CPU footprint को पहले के 10% से भी कम कर दिया, और edge पर events drop होना बंद हो गया

वे क्षेत्र जहाँ OpenTelemetry अब भी जरूरी है

  • OpenTelemetry standardized vendor-neutral format और नए users के लिए onboarding experience देता है, इसलिए ClickStack के लिए यह default option बना हुआ है
  • SysEx, ClickHouse internals से काफ़ी tightly coupled है और live system tables को query करने वाला pull-based design है; इसलिए अगर service crash loop में हो या down हो, तो data scrape नहीं किया जा सकता
  • OpenTelemetry stdout और stderr पर emit हुए logs को passive तरीके से capture करता है, इसलिए service पूरी तरह healthy न होने पर भी failure के दौरान logs collect किए जा सकते हैं
  • ClickHouse सभी ClickHouse services पर OpenTelemetry चलाता रहेगा, लेकिन collection scope बदल दिया गया है
    • पहले trace-level logs तक सब ingest किए जाते थे
    • अब सिर्फ info-level या उससे ऊपर के logs collect किए जाते हैं
  • इस बदलाव के बाद OTel collector और gateway बहुत कम resources पर चलते हैं, और पहले बताए गए 2M log lines/s वाले छोटे pipeline आकार में बने रहते हैं

HyperDX और ClickHouse native exploration experience

  • LogHouse का पहला UI, Grafana पर बना custom observability experience था, लेकिन SysEx और wide-column telemetry बढ़ने के साथ ClickHouse में अधिक गहराई से integrated UI की जरूरत हुई
  • HyperDX, ClickHouse native UI के रूप में logs·traces exploration, correlation analysis और large-scale analysis को support करता है
  • Lucene syntax से query की जा सकती है, जिससे data exploration आसान हो जाती है, और complex event analysis के लिए SQL का उपयोग जारी रखा जा सकता है
  • HyperDX v2.0 का schema-independent approach किसी एक fixed log table structure की मांग नहीं करता
    • यह OpenTelemetry pipeline के standardized लेकिन बदलते रहने वाले data formats को संभालता है
    • यह SysEx और दूसरे custom exporters की specialized wide-column tables को भी बिना पहले से schema knowledge या complex grok patterns के संभालता है
  • Grafana की भी अब भी LogHouse में भूमिका है
    • internal Grafana-based app namespace specify करवाता है ताकि service-specific data location पता रहे और query को सही ClickHouse instance तक route किया जा सके
    • Prometheus metrics पर आधारित legacy dashboards और alerts अब भी Grafana में मौजूद हैं
    • kube_state_metrics जैसे high-level metrics deep investigation के लिए हमेशा उपयुक्त न हों, लेकिन alerting के लिए उपयोगी हैं

Wide events और high-cardinality observability

  • SysEx के आने से stdout log-केंद्रित collection से system table आधारित wide events और high-cardinality data-केंद्रित model की ओर बदलाव हुआ
  • ClickHouse इसे Observability 2.0 कहने के बजाय LogHouse और ClickStack के संयोजन के रूप में देखता है
  • इस model में पारंपरिक three pillars approach की जगह केंद्रीय warehouse में कई sources की high-cardinality telemetry स्टोर की जाती है
  • हर row में query identifier, Pod name, version metadata, network detail जैसी समृद्ध context होती है, और metric store limits के हिसाब से dimensions को पहले से aggregate या drop नहीं किया जाता
  • ingest के समय summary नहीं बनाई जाती; raw data उसी रूप में रखा जाता है और aggregation को query time तक टाला जाता है
  • Prometheus से अंतर यह है कि यहाँ हर data point स्टोर किया जाता है
    • insertDuration जैसे fields को pre-aggregate नहीं किया जाता, बल्कि हर value को उससे जुड़े dimensions के साथ सुरक्षित रखा जाता है
    • Prometheus में सभी label combinations की timeseries स्टोर करने पर cardinality explosion हो सकता है
    • histogram pre-aggregation resources को नियंत्रित करती है, लेकिन इससे यह पूछना मुश्किल हो जाता है कि कोई खास spike किस instance, table या time window के insert से जुड़ा था
  • Elasticsearch ने भी wide events और flexible document structure को बढ़ावा दिया था, लेकिन ClickHouse का columnar design high-cardinality·high-volume event data को बड़े पैमाने पर कुशलता से store और query करने देता है

Data science tools और SQL analysis

  • एक wide event से कई characteristics को visualize किया जा सकता है, और chart के किसी खास point से raw log तक वापस जाया जा सकता है
  • ClickHouse data visualization integrations और language clients देता है, इसलिए Plotly, Jupyter notebook, Hex, Bokeh, Evidence जैसे SQL-based tools इस्तेमाल किए जा सकते हैं
  • HyperDX की Lucene syntax search तेज lookup और filtering के लिए अच्छी है, लेकिन complex सवालों के लिए SQL जरूरी है
  • ClickHouse SQL join, time-based operations और transformations व्यक्त कर सकता है
    • उदाहरण के तौर पर, Kubernetes event stream में उसी container के Killing event और Created event को ASOF JOIN से मिलाकर termination के बाद restart तक लगा समय निकाला जाता है
    • example query ने 17.78M rows और 581.49MB process किए, 0.099 सेकंड लिए, और peak memory 272.88MiB रही
  • जिन metrics की जरूरत है उन्हें पहले से component बनाकर deploy करने के बजाय, उन्हें wide events warehouse से query time पर derive किया जा सकता है

LogHouse में जोड़े गए अतिरिक्त data sources

  • engineering और support team की मांग के अनुसार LogHouse में wide event-आधारित और अधिक data sinks जोड़े गए
  • kubenetmon: Kubernetes networking monitoring के लिए open source tool, जो Linux conntrack का उपयोग करके L3/L4 connection data और byte·packet count capture करता है
  • Kubernetes Event Exporter: लोकप्रिय exporter को fork करके उसमें ClickHouse native sink जोड़ा गया, ताकि Kubernetes API events का बड़े पैमाने पर analysis किया जा सके
    • fork: ClickHouse/kubernetes-event-exporter
    • आगे सिर्फ events ही नहीं बल्कि पूरे Kubernetes object model को LogHouse में ingest करने और हर बदलाव के समय snapshots स्टोर करने की योजना भी चल रही है
  • Control Plane Data: Control Plane विभाग का operational data collect किया जा रहा है, जो अभी तक LogHouse में onboard नहीं हुआ था
  • Real User Monitoring(RUM): चल रहा project, जिसमें user browser के frontend performance metrics को public gateway के जरिए OTel pipeline में भेजा जाता है
  • Istio Access Log: Istio service mesh के HTTP-level traffic data को ingest करके request·response patterns, latency और routing decisions capture किए जाते हैं
    • इसे system.query_log, kubenetmon network flow के साथ जोड़कर SQL query, HTTP request और packet flow का cross-analysis किया जाता है

अगला चरण: zero-impact scraping और JSON

  • SysEx scrape queries पर strict memory limit लगी होती है, लेकिन जब ग्राहक इसे logs और metrics में देखते हैं तो चिंता हो सकती है
  • ClickHouse ऐसा zero-impact scraping खोज रहा है जिसमें live system पर query चलानी न पड़े
    • एक संभावनाशील दिशा यह है कि S3 के plain rewritable disk का उपयोग किया जाए, जहाँ ClickHouse पहले से service logs लिखता है
    • अगर SysEx worker pool disk-based log tables को सीधे mount कर सके, तो running ClickHouse instances पर query चलाने से बचा जा सकता है
  • अगर यह तरीका सफल रहा, तो native format, high fidelity और minimal transformation जैसे मौजूदा फायदे बने रहेंगे, साथ ही operational impact की धारणा भी घटेगी
  • ClickHouse का JSON type 25.3 में GA तक पहुँच गया, और नए field आने पर उपयुक्त type वाले columns dynamic रूप से बना सकता है, साथ ही multi-type fields और schema explosion को भी संभालता है
  • LogHouse यह आकलन कर रहा है कि JSON बड़े पैमाने की observability access patterns के लिए कितना उपयुक्त है
    • अगर पूरे JSON blob में string खोजी जाए, तो हजारों columns scan हो सकते हैं
    • structured data के साथ raw string JSON स्टोर करने वाला workaround मौजूद है
    • अधिकांश log·resource attributes छोटे और स्थिर होते हैं, इसलिए Map type अब भी उपयुक्त है
    • HyperDX map access को अपने आप JSONExtract function में बदल देता है

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.