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

• LogHouse ने सिर्फ 1 साल में 19PiB से बढ़कर 100PB+ log data को प्रोसेस किया और लगभग 500 trillion rows तक स्केल किया
• OpenTelemetry(OTel) की data processing सीमाओं और inefficiency के कारण, core systems के लिए उपयुक्त custom pipeline (SysEx) पर स्विच किया गया
• इस बदलाव के बाद event throughput 20 गुना बढ़ने पर भी CPU utilization 10% से नीचे बनाए रखने वाली efficiency हासिल हुई
• ClickHouse के HyperDX और ClickStack अपनाने से UI और data integration, schema flexibility, और powerful data exploration environment तैयार हुआ
• Wide events और high-cardinality model अपनाने से, बिना pre-aggregation के सभी events को store और analyze करना संभव हुआ

---

पृष्ठभूमि और बदलाव

• ClickHouse Cloud के लिए internal logging platform LogHouse सिर्फ 1 साल में 19PiB से 100PB+ data scale, और 37 trillion rows से लगभग 500 trillion rows तक बढ़कर एक बड़े सिस्टम के रूप में विकसित हुआ
• शुरुआत में सभी telemetry को OpenTelemetry(OTel) के जरिए collect किया गया, लेकिन large-scale data environment में performance, resource limits, और data transformation process के दौरान CPU waste और data loss की समस्याएं स्पष्ट हो गईं

OTel की सीमाएं और custom pipeline अपनाने का कारण

• OTel pipeline में logs पहले JSON में बदले जाते थे, फिर OTel format में remap किए जाते थे, और कई बार conversion व marshaling दोहराए जाते थे, जिससे efficiency बेहद कम हो जाती थी
• वास्तव में OTel-based setup में प्रति सेकंड 20 million rows प्रोसेस करने के लिए लगभग 8,000 CPU cores की जरूरत पड़ती थी
• traffic spike के दौरान Collector overload हो जाता था और logs drop होने लगते थे, जिससे uncollected data पैदा होता था

SysEx अपनाना और इसकी संरचना

• SysEx(System Tables Exporter) ClickHouse की system tables से data को उसके मूल type में, बिना conversion के, सीधे LogHouse तक पहुंचाता है
• hash ring structure के जरिए distributed scraping, time-delay buffer और sliding window approach के माध्यम से data miss होने से बचाव, और internal SLA को पूरा करना संभव हुआ
• Go language और ClickHouse client की custom capabilities का उपयोग करके data marshaling के बिना byte-to-byte transfer संभव हुआ
• schema variability को संभालने के लिए schema hash और dynamic schema management लागू किया गया, और Merge table engine के जरिए कई schema versions को एक logical view में जोड़ा गया
• snapshot-based memory table collection के जरिए advanced diagnostics और analysis workflows को support किया गया

performance और efficiency में सुधार

• SysEx अपनाने के बाद जहां OTel Collector 800 CPU के साथ प्रति सेकंड 2 million logs प्रोसेस करता है, वहीं SysEx 70 CPU में 37 million logs प्रोसेस कर सकता है
• इस efficiency gain से resource usage में भारी कमी, event loss की रोकथाम, और real-time support environment संभव हुआ

OTel की लगातार भूमिका

• OTel अब भी standard, vendor-neutral platform उपलब्ध कराता है और service outage या abnormal state में जरूरी बना रहता है
• crash या abnormal situations, जिन्हें SysEx handle नहीं कर पाता, उनमें भी log capture संभव है
• फिलहाल trace level से नीचे के logs हटाकर, सिर्फ info level और उससे ऊपर के logs collect किए जा रहे हैं ताकि resources optimize किए जा सकें

UI और HyperDX, ClickStack integration

• मौजूदा custom Grafana UI से धीरे-धीरे HyperDX आधारित ClickHouse-native UI की ओर migration किया जा रहा है
• HyperDX, schema-independent, Lucene query support और SQL support जैसी सुविधाओं के साथ ClickHouse के व्यापक data types के साथ पूरी compatibility देता है
• अलग-अलग table structures और custom Exporter sources से आने वाला data भी UI बदले बिना integrate किया जा सकता है
• Grafana अभी भी Prometheus-based metrics और fixed dashboards संभालता है, यानी दोनों solutions एक-दूसरे को complement करते हैं

Wide Events और high-cardinality model को अपनाना

• Wide events एक ऐसा नया तरीका है जिसमें हर row में query ID, Pod name, version info जैसे अनेक context शामिल होते हैं, जिससे बिना aggregation के सारा data store किया जा सकता है
• यह approach Prometheus आदि से अलग है, क्योंकि इसमें pre-aggregation, label limits, या cardinality explosion की चिंता के बिना deep analysis और flexible queries संभव हैं
• analysis के समय जरूरी aggregation करके, large-scale data environment में performance और cost दोनों को संतुलित किया जाता है

data visualization और query flexibility

• ClickHouse की Plotly, Jupyter notebook आदि के साथ integration बहुत अच्छी है, इसलिए कई visualization tools को आसानी से इस्तेमाल किया जा सकता है
• Lucene-based HyperDX की fast exploration के अलावा, complex relationship और conditional queries (SQL, JOIN आदि) के जरिए advanced root-cause analysis सीधे ClickHouse में किया जा सकता है

Wide Event आधारित data sources का विस्तार

• kubenetmon: Kubernetes network monitoring open source, L3/L4 traffic, connection, और cost analysis
• Kubernetes Event Exporter: ClickHouse sink जोड़े गए fork का उपयोग, large-scale cluster state changes को track करना, और full object snapshot पर experiment जारी
• Control Plane Data, RUM(Real User Monitoring), Istio Access Log जैसे कई layers के data के जरिए interpretation scope और correlation analysis क्षमता में बड़ा विस्तार हुआ

operational considerations और आगे की दिशा

• SysEx query के दौरान logs और metrics में exposed हो सकता है, लेकिन इसे memory limits और error impact minimization को ध्यान में रखकर design किया गया है
• Zero-impact scraping: पूरी तरह decoupled structure (जैसे S3-based plain rewritable disk का उपयोग) के जरिए cluster पर पड़ने वाले प्रभाव को मूल रूप से खत्म करने के तरीकों पर काम चल रहा है
• OTel शुरुआती service stage और abnormal states में log capture के लिए अब भी महत्वपूर्ण है, लेकिन zero-impact approach स्थिर होने पर इसकी dependency और कम होने की संभावना है

ClickHouse JSON type का विकास और उपयोग

• JSON type आधिकारिक GA के रूप में जारी हो चुका है, जिससे field-wise dynamic column creation, multiple type support, और schema explosion को flexible तरीके से handle करना संभव हुआ
• बड़ी संख्या में columns वाले JSON queries के लिए optimization अभी पूरी तरह perfect नहीं है, इसलिए shape-based parallel storage और Map type की practical utility जैसी approaches को और बेहतर बनाया जा रहा है
• HyperDX integration के साथ Map और JSON fields की automatic extraction और analysis संभव है, और भविष्य में JSON का और व्यापक उपयोग करने की योजना है

निष्कर्ष और सांस्कृतिक बदलाव

• LogHouse अब performance analysis से लेकर real-time debugging तक ClickHouse Cloud operations का core observability platform बन चुका है
• cost reduction इस पहल की शुरुआत थी, लेकिन SysEx जैसे custom tools, OTel के साथ संतुलित उपयोग, और HyperDX आधारित flexible UI expansion के जरिए एक technical और cultural transformation देखने को मिला है
• large-scale, high-accuracy Wide Event आधारित data model engineering, support, और data analysis के सभी क्षेत्रों में नई value और efficiency दे रहा है
• आगे भी 100PB और 500 trillion rows scale पर मिले अनुभव के आधार पर observability के भविष्य का नेतृत्व जारी रखने की योजना है

[GN⁺]

Hacker News टिप्पणियाँ

• सच कहूँ तो मुझे नहीं लगता कि यह कोई बहुत बड़ी शेख़ी की बात है। 100PB लॉग स्टोर करना इस बात का सबूत है कि आपने अभी तक यह नहीं समझा कि वास्तव में क्या बचाकर रखना चाहिए। ज़्यादातर मुख्य जानकारी metrics और structured events से ही समझी जा सकती है। बाकी क्या? बेहद डिटेल्ड trace logs, जिन्हें कोई पढ़ता ही नहीं, और सच में बड़ी गड़बड़ी होने पर ही देखा जाता है। इससे बेहतर तरीका? ऐसी ‘interest-based retention policy’ लाना, जिसमें वे लॉग अपने-आप हट जाएँ जो कभी alerts में इस्तेमाल नहीं हुए, या 3 महीनों तक search में नहीं आए। जब तक इस दिशा में नहीं जाते, तब तक यह बस एक बहुत महँगा डिजिटल कचरे का ढेर है, जिसे थोड़ा compress कर दिया गया है
  • मैं उल्टा हर डेटा इकट्ठा करके, ज़रूरत न होने पर बाद में filter करने वाला तरीका पसंद करता हूँ। Debug logs आम दिनों में काम नहीं आते, लेकिन जब ज़रूरत पड़ती है तब वे सच में अनिवार्य होते हैं। अगर कोई event इतना दुर्लभ हो कि दोबारा reproduce ही न हो सके, तो उस समय डेटा फिर से इकट्ठा नहीं किया जा सकता। अगर सब कुछ पहले से store है, तो बस ढूँढना पड़ता है, इसलिए मुझे वह ज़्यादा बेहतर लगता है
  • कई कंपनियों में Datadog इस्तेमाल करते हुए मैंने यह बहुत देखा है कि renew करने की लागत बेहिसाब आते ही metrics और सीमित events रखो, logs घटाओ — ऐसा दबाव आता है। समस्या यह है कि अगर पहले से पता होता कि क्या होने वाला है, तो उसे पहले ही ठीक कर दिया जाता। जब कुछ अजीब होता है और पता लगाना होता है कि आखिर हुआ क्या, तब detailed logs बहुत ज़रूरी होते हैं। लेकिन हक़ीक़त यह है कि अगर कोई चीज़ बार-बार न हो, तो पहले से यह जानने का कोई तरीका नहीं कि कौन-से logs महत्वपूर्ण होंगे
  • ‘interest-based retention policy’ वाकई शानदार आइडिया है। सिर्फ log patterns के हिसाब से query/alert access count गिनकर भी TTL (retention period) policy बनाई जा सकती है। हमारी टीम ने भी वास्तव में यह तरीका अपनाया और storage cost 70% घटा दी, जबकि महत्वपूर्ण डेटा पूरा रखा
  • लॉग ingest cost भी मुफ़्त नहीं है। खासकर उन languages में, जो crash का कारण समझने के लिए जितनी जल्दी हो सके disk पर logs लिखती हैं, वहाँ लागत और बढ़ जाती है। जानकारी बहुत ज़्यादा हो तो सच में महत्वपूर्ण correlations ढूँढना भी मुश्किल हो जाता है, और fix हो चुके bugs के logs की value जल्दी गिर जाती है। मैं statistical data को पसंद करता हूँ। Statistical data aggregation के हिसाब से efficient होता है, और खासकर GIL-आधारित languages में OTEL का इस्तेमाल करते समय overhead कभी-कभी बहुत ज़्यादा हो सकता है
  • अगर डेटा पहले से stored है, तो बाद में filter या cleanup करना संभव है। मुझे लगता है कि सब कुछ store करके ज़रूरत पड़ने पर इस्तेमाल करना, ज़रूरत के समय डेटा न होने से बेहतर है। बेशक, यह तभी संभव है जब आपके पास ऐसी large-scale infrastructure चलाने के resources हों
• यह असल में सिर्फ Clickhouse logs पर लागू होने वाली बात है। दूसरे तरह के logs से इसका बहुत संबंध नहीं है। हाँ, Clickhouse खुद एक बहुत पसंद आने वाला solution है
  • लगता है आप पार्टियों में बहुत मज़ेदार इंसान होंगे
• एक सावधानी की बात बताना चाहूँगा। जब service crash loop में फँसी हो या outage के कारण down हो, तब SysEx से ज़रूरी system tables तक पहुँचना संभव नहीं होता, इसलिए logs collect नहीं किए जा सकते। लेकिन OpenTelemetry(OTel) passive तरीका है, इसलिए service पूरी तरह normal न हुई हो तब भी stdout, stderr से निकलने वाले logs को कैप्चर किया जा सकता है। इस तरह failure state में भी logs इकट्ठा करके root cause तक analyze किया जा सकता है
  • मैंने जिन OTel projects पर काम किया है, वे सब active तरीके वाले थे। इसलिए ऊपर की बात मुझे नई जानकारी कम और गलत या अधूरी व्याख्या ज़्यादा लगती है
• मुझे शक है कि 'wide event' सच में इतना storage space लेना चाहिए या नहीं। Observability मूल रूप से sampling की समस्या है। अगर न्यूनतम storage में किसी खास समय की state को यथासंभव अच्छी तरह reconstruct किया जा सके, तो वही काफ़ी है। Sample count घटाया जा सकता है या compression efficiency बढ़ाई जा सकती है। और मुझे नहीं लगता कि compression technology अभी अपनी सीमा तक पहुँच चुकी है। इतने duplicate data में ज़रूर बहुत मज़बूत low-rank structure होगा। बेशक inverted index और तरह-तरह के trees पहले से इस्तेमाल हो रहे हैं, लेकिन मुझे लगता है कि low-rank tensor decomposition जैसी और experimental research methods में भी उम्मीद है। मैं खुद industry का व्यक्ति नहीं हूँ, इसलिए संभव है कि मैं कुछ छोड़ रहा हूँ
• ClickHouse जैसी scale का अनुभव मुझे नहीं है। क्या इस मात्रा के logs सच में searchable होते हैं? मेरी समझ से ElasticSearch छोटे scale पर queries अच्छी तरह संभाल लेता है। Historical logs के लिए json files store करने के बजाय ClickHouse इस्तेमाल करने की वजह क्या है?
  • मैं इसी scale पर काम कर रहा हूँ। निष्कर्ष पहले बता दूँ: हाँ, संभव है। लेकिन processing cost कल्पना से परे हो सकती है। अगर indexing, sorting, clustering strategy खराब हो, तो सिर्फ "इस string वाला record" एक बार खोजने में भी $1~$10 लग सकते हैं। मेरे अनुभव में, बड़े डेटा पर हमेशा "जितना कम डेटा हो सके, उतना ही कम छूना" और "जितना कम हो सके, उतना कम move करना" — ये सिद्धांत महत्वपूर्ण हैं। Serialization/deserialization या disk, network IO एक बार भी अतिरिक्त हो जाए, तो लागत बहुत बढ़ जाती है। ऐसे में OTel के लिए एक और collector hop जोड़ना efficiency के ख़िलाफ़ जा सकता है। लेकिन petabyte scale पर ऐसी छोटी optimizations से बचा पैसा, complex serialization code लिखने वाले engineer की salary से भी ज़्यादा हो सकता है
  • ClickHouse को json files की जगह historical logs के लिए क्यों इस्तेमाल करें? वजहें कई हैं। (1) ClickHouse जैसे log DB column-wise compression करते हैं, यानी हर field को अलग compress करते हैं, इसलिए सामान्य json files (compressed files सहित) की तुलना में बहुत कम storage लेते हैं। (2) Log DB की query speed बहुत तेज़ होती है। 1000 गुना तक तेज़ होना संभव है। क्योंकि बेकार डेटा को पढ़ा ही नहीं जाता। संबंधित लिंक. (3) 100PB json files को grep से खोजना व्यवहारिक रूप से असंभव है। Log DB ऐसी संरचना देते हैं जिसमें storage nodes और storage capacity बढ़ाकर horizontal scale करना संभव होता है
  • यह scale और cost की समस्या है। हमारी कंपनी भी log volume की समस्या से टकराई। अगर json को सीधा Splunk में डालें, तो सालाना लागत 6 million dollars से ऊपर जाती है। लेकिन approved budget उसका सिर्फ 5~10% है। लेख में कहा गया कि json logs को process करने के लिए 8,000 CPUs चाहिए थे, लेकिन optimization के बाद वही काम सिर्फ 90 CPUs से हो जाता है
  • 2~3 साल पहले तक ClickHouse में full-text search performance कुछ कमज़ोर लगती थी। वह तेज़ है और ElasticSearch-स्तर की बड़ी processing भी कर सकता है, लेकिन use case पर निर्भर करता है कि अगर पहले से indexing न हो, तो bundling, grouping, FTS में ES कहीं ज़्यादा तेज़ महसूस हो सकता है
• observability extremism सच में किसी नए धर्म जैसा लगता है। और उसके पास पैसा भी बहुत है
  • अनजान anomalies तक गहराई से जाने के लिए, फिलहाल कोई खास तेज़तर्रार विकल्प भी नहीं है
  • मज़ेदार बात यह है कि पहले ऐसे systems बनाते हैं जिनसे आप इन समस्याओं में फँसें, फिर अंत में "मासिक subscription दे दो, सब हल" वाली strategy बेचते हैं — यही विडंबना है
• लेख में log retention period कितना है, इसका ज़िक्र नहीं था। एक निश्चित अवधि के बाद सिर्फ summary/aggregated data रखकर raw data को बनाए रखने की ज़रूरत पर सवाल उठता है
• Clickhouse इस्तेमाल करने के बाद Postgres पर लौटना हमेशा cultural shock जैसा लगता है। 20GB dump import करने में कई मिनट लगते हैं — यह बात समझ नहीं आती। क्या यह कुछ seconds में नहीं होना चाहिए?
  • हर बार Clickhouse इस्तेमाल करते हुए बहुत थकान होती है। मानता हूँ कि Clickhouse के अपने ज़रूरी use cases हैं, और Postgres हर चीज़ replace नहीं कर सकता, लेकिन फिर भी Clickhouse में ‘risk factors’ बहुत लगते हैं, और विशेष रूप से सीमित उद्देश्यों को छोड़ दें तो लगभग हर पहलू में Postgres बेहतर महसूस होता है
• जिन लोगों पर wide events इस्तेमाल करने का दबाव डाला जाता है, वे log-data cost explosion की बात नहीं करते। पारंपरिक तरीके (metrics + traces + sampled logs) की तुलना में यह निश्चित रूप से बहुत महँगा पड़ता है। फ़ायदे ज़रूर हैं, लेकिन लागत की बात हमेशा गायब रहती है
  • अगर wide event structure सही तरह design किया जाए, तो वह पारंपरिक logs की तुलना में storage cost घटा भी सकता है। क्योंकि एक external request एक ही wide event के रूप में रह जाती है, इसलिए बाद की debugging या analysis के लिए ज़रूरी सारी जानकारी उसी में होती है। संबंधित लेख देखें A practitioner's guide to wide events
• मुझे Clickhouse या Dynamo जैसे systems की core trick जानने की जिज्ञासा है। क्या वे मूल रूप से किसी बहुत बड़े hash table जैसी संरचना हैं?
  • Clickhouse जैसे बड़े DB में दो आम tricks होती हैं। पहली, disk पर data को समझदारी से इस तरह रखना कि ज़्यादातर data को नज़रअंदाज़ करके सिर्फ ज़रूरी chunks पढ़े जाएँ (जैसे column-oriented storage और LSM-tree जैसी विधियाँ)। और stored data को compress करके disk IO भी न्यूनतम रखा जाए। दूसरी, सभी resources (CPU, RAM, disk, network) का अधिकतम उपयोग कराने के लिए बहुत aggressive tuning। उदाहरण के लिए Clickhouse एक CPU core पर प्रति second 1 billion से अधिक rows process कर सकता है, और cores की संख्या के अनुसार linearly scale भी होता है