लॉगिंग बुरी तरह टूटी हुई है

• आधुनिक distributed systems में पारंपरिक logging तरीकों की ऐसी संरचनात्मक सीमाएँ हैं कि वे सच्चाई नहीं बता पाते
• logs अब भी 2005-स्टाइल single-server environment को मानकर डिज़ाइन किए गए हैं, इसलिए कई services, databases और cache से गुजरने वाले request का context खो जाता है
• साधारण string search structure, relation, correlation को नहीं समझती, जिससे समस्या की जड़ तक पहुँचना मुश्किल हो जाता है
• इसका समाधान है कि हर request के लिए सभी context वाला एक single ‘Wide Event(या Canonical Log Line)’ छोड़ा जाए
• इससे logs सिर्फ text नहीं रहते, बल्कि analyzable data asset में बदल जाते हैं

---

लॉगिंग की मूल समस्या

• मौजूदा logs monolithic server युग को ध्यान में रखकर बनाए गए थे, इसलिए वे आज की distributed service architecture को reflect नहीं करते
  • एक request कई services, DB, cache और queue से होकर गुजरता है, लेकिन logs अब भी single server के हिसाब से लिखे जाते हैं
• उदाहरण logs में एक request पर 13 lines बनती हैं, इसलिए 10,000 concurrent users पर प्रति सेकंड 130,000 lines निकलती हैं, लेकिन इनमें से अधिकतर अर्थहीन जानकारी होती है
• समस्या आने पर सबसे ज़रूरी चीज़ context होती है, लेकिन मौजूदा logs में वही नहीं होता

string search की सीमाएँ

• जब कोई user रिपोर्ट करता है कि “payment नहीं हो रहा”, तब email या user_id से logs खोजने पर भी कोई consistent structure न होने के कारण उपयोगी नतीजे मिलना मुश्किल होता है
  • एक ही user ID user-123, user_id=user-123, {"userId":"user-123"} जैसी दर्जनों अलग forms में रिकॉर्ड हो सकती है
• services के बीच log format अलग-अलग होने से related events को trace करना असंभव हो जाता है
• मूल समस्या यह है कि logs को write के लिए डिज़ाइन किया गया है, query के लिए optimize नहीं किया गया

मुख्य अवधारणाओं की परिभाषा

• Structured Logging: strings की जगह key-value (JSON) format में रिकॉर्ड करने का तरीका
• Cardinality: किसी field के unique values की संख्या; उदाहरण के लिए user_id बहुत high होता है
• Dimensionality: किसी log event में fields की संख्या; जितनी अधिक होगी, analysis की संभावना उतनी अधिक होगी
• Wide Event / Canonical Log Line: प्रति request एक context-rich single log event
• अधिकांश logging systems high-cardinality data को cost कारणों से सीमित करते हैं, जबकि वास्तव में debugging के लिए वही सबसे उपयोगी होता है

OpenTelemetry की सीमाएँ

• OpenTelemetry(OTel) एक protocol और SDKs का set है, जो सिर्फ data collection और transport का standard देता है
• लेकिन OTel यह काम नहीं करता
  1. क्या log करना है, यह तय नहीं करता
  2. business context (जैसे subscription tier, cart amount आदि) अपने आप नहीं जोड़ता
  3. developer की logging mindset नहीं बदलता
• एक ही library इस्तेमाल करने पर भी, जानबूझकर context जोड़कर की गई instrumentation और साधारण instrumentation के debugging experience में बहुत बड़ा फर्क होता है
• OTel सिर्फ plumbing है; उसमें क्या बहाना है, यह developer को तय करना होता है

Wide Event / Canonical Log Line तरीका

• पारंपरिक “code क्या कर रहा है” वाली logging से हटकर, “request के साथ क्या हुआ” यह रिकॉर्ड करना चाहिए
• हर request के लिए service स्तर पर एक व्यापक event बनाया जाए
  • इसमें request, user, payment, error, environment आदि के 50 से अधिक fields शामिल हो सकते हैं
• उदाहरण JSON में user_id, subscription_tier, service_version, error_code जैसे debugging के लिए ज़रूरी सभी context शामिल होते हैं
• इससे एक ही search में “premium users की payment failure का कारण” जैसी चीज़ों का तुरंत analysis संभव हो जाता है

Wide Event की query में उपयोगिता

• Wide Event को साधारण text search की तरह नहीं, बल्कि structured data query की तरह handle किया जाता है
• high-cardinality और high-dimensional data के आधार पर real-time analysis स्तर की debugging संभव होती है
• उदाहरण: “पिछले 1 घंटे में premium users की payment failure rate को error code के हिसाब से aggregate करो” जैसी query तुरंत चलाई जा सकती है

implementation pattern

• पूरे request lifecycle के दौरान event तैयार किया जाए, और अंत में सिर्फ एक बार output किया जाए
  • middleware में request_id, timestamp, method, path जैसे base fields initialize करें
  • handler में user, cart, payment, error जानकारी को धीरे-धीरे जोड़ें
• आखिर में logger.info(event) से एक single JSON event रिकॉर्ड करें

sampling से cost control

• प्रति request 50 से अधिक fields रिकॉर्ड करने पर cost तेज़ी से बढ़ सकती है, इसलिए sampling ज़रूरी है
• साधारण random sampling में errors छूट जाने का जोखिम रहता है
• Tail Sampling strategy का सुझाव
  1. errors (जैसे 500) हमेशा store करें
  2. slow requests (p99 से ऊपर) हमेशा store करें
  3. VIP users या specific flag sessions हमेशा store करें
  4. बाकी में सिर्फ 1~5% को random sample करें
• इससे cost reduction और critical events preservation दोनों साथ हासिल किए जा सकते हैं

आम गलतफहमियाँ

• Structured Logging ≠ Wide Event: सिर्फ JSON format काफी नहीं है, context ही असली चीज़ है
• OpenTelemetry का उपयोग ≠ complete observability: यह सिर्फ collection को standardize करता है, क्या रिकॉर्ड करना है यह developer पर निर्भर है
• यह Tracing जैसा नहीं है: tracing services के बीच flow दिखाता है, जबकि Wide Event service के अंदर का context देता है
• logs debugging के लिए, metrics dashboard के लिए जैसी विभाजन रेखा अनावश्यक है — Wide Event दोनों काम कर सकता है
• high-cardinality data महँगा होता है वाली सोच पुरानी हो चुकी है; ClickHouse, BigQuery जैसे modern DBs इसे efficiently handle कर सकते हैं

Wide Event अपनाने का असर

• debugging archaeology से analytics में बदल जाती है
• “user payment failure” खोजने के लिए 50 services के logs पर grep चलाने के बजाय,
  “premium users की payment failure rate को error code के हिसाब से देखो” जैसे single-query based analysis पर शिफ्ट हो जाता है
• नतीजतन logs झूठ बोलने वाले tool से, सच बताने वाले data asset में बदल जाते हैं