प्रतिनिधि इंटरव्यू विषय

System Design: ट्रेस कोरिलेशन के साथ OpenTelemetry लॉग पाइपलाइन कैसे बनाएं?

सिस्टम डिज़ाइनकठिन
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

ट्रेस कोरिलेशन का समर्थन करने वाली एक OpenTelemetry लॉग पाइपलाइन डिज़ाइन करें। डेटा मॉडल, बैकप्रेशर, टेनेंट आइसोलेशन और रिकवरी को समझाएं।

प्रॉम्प्ट और दायरा

एक इंटरव्यूअर पूछ सकता है: “ट्रेस कोरिलेशन का समर्थन करने वाली एक OpenTelemetry लॉग पाइपलाइन डिज़ाइन करें। डेटा मॉडल, बैकप्रेशर, टेनेंट आइसोलेशन और रिकवरी को समझाएं।”

संकेत यह है कि क्या आप एप्लिकेशन इवेंट्स को गवर्न की गई टेलीमेट्री में बदल सकते हैं या नहीं। OpenTelemetry Logs Data Model Timestamp, TraceId, SpanId, SeverityNumber, Body, Resource, और Attributes को अलग करता है; OTLP लॉग्स को एजेंट्स, Collectors, और बैकएंड्स के माध्यम से हॉप-बाय-हॉप आगे बढ़ने की अनुमति देता है। चुनौती सिमेंटिक्स, क्षमता और सुरक्षा सीमाओं को बनाए रखने की है, न कि केवल एक साधारण Kafka लाइन खींचने की।

इंटरव्यूअर क्या जांच रहा है

  • क्या आप Resource, Attributes, Body, और Trace Context की जिम्मेदारियों को अलग करते हैं।
  • क्या आप एप्लिकेशन्स, एजेंट्स, Collectors, कतारों (queues) और बैकएंड्स के बीच एक विश्वसनीय पाथ डिज़ाइन कर सकते हैं।
  • क्या आप बर्स्ट बैकप्रेशर, बैचिंग, पुनः प्रयास (retries), प्राथमिकता-आधारित ड्रॉप्स और डिस्क बफरिंग को संभालते हैं।
  • क्या आप क्रॉस-टेनेंट एक्सपोज़र को रोकते हैं और सीक्रेट्स तथा पर्सनल डेटा को रिडैक्ट करते हैं।
  • क्या आप डुप्लिकेट्स, ऑर्डरिंग, सैंपलिंग, और TraceId न होने पर क्वेरी अनुभव की व्याख्या करते हैं।

स्पष्टीकरण के लिए प्रश्न

  • क्या स्रोत SDKs, मौजूदा फ़ाइलें, कंटेनर stdout, या इनका मिश्रण हैं?
  • टेनेंट संख्या, थ्रूपुट, रिटेंशन, और क्वेरी-लेटेंसी के लक्ष्य क्या हैं?
  • क्या एप्लिकेशन लगातार TraceId इंजेक्ट करता है, और क्या इसके न होने पर कोरिलेशन की (correlation key) की अनुमति है?
  • किन फ़ील्ड्स में पर्सनल डेटा, सीक्रेट्स, या बिज़नेस-सेंसिटिव कंटेंट शामिल हैं, और रिडेक्शन कहाँ होना चाहिए?
  • बैकएंड विफलता के दौरान, किन स्तरों को ड्रॉप किया जा सकता है और रिकवरी के बाद कितने रिप्ले की आवश्यकता है?

30-सेकंड का उत्तर

आप कह सकते हैं:

मैं एप्लिकेशन या फ़ाइल रिसीवर्स से एक लोकल Collector, फिर एक कतार और बैकएंड तक एक लेयर्ड पाथ का उपयोग करूँगा। प्रत्येक रिकॉर्ड समय, गंभीरता (severity), Body, Resource, और Attributes को बनाए रखता है, और संदर्भ मौजूद होने पर TraceId और SpanId शामिल करता है। Collectors बैच, रेट-लिमिट, रिडैक्ट और रूट करते हैं; एक कतार और डिस्क बफर बैकएंड जिटर को अवशोषित करते हैं। टेनेंट पहचान विश्वसनीय Resource एट्रिब्यूट्स और ऑथराइजेशन इंडेक्स में दर्ज होती है। लोड सर्ज के दौरान, पहले debug को ड्रॉप या सैंपल करें, फिर रीप्रयासों, डुप्लिकेट्स और रिकवरी रीड्स को प्रबंधित करें।

चरण-दर-चरण तर्क

एक रिकॉर्ड अनुबंध परिभाषित करें

एक असंरचित लाइन को एकमात्र अनुबंध न बनाएं। एक लॉजिकल रिकॉर्ड इस तरह दिख सकता है:

json
{
  "timestamp": "2026-08-01T10:00:00Z",
  "traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
  "spanId": "00f067aa0ba902b7",
  "severityNumber": 17,
  "severityText": "ERROR",
  "body": {"message": "payment declined", "code": "CARD_DECLINED"},
  "resource": {"service.name": "checkout", "tenant.id": "t-7"},
  "attributes": {"region": "us-east-1"}
}

Resource उत्सर्जक इकाई (emitting entity) का वर्णन करता है, Attributes किसी इवेंट की घटना का वर्णन करते हैं, और Body संरचित कंटेंट को सुरक्षित रखता है। डिस्प्ले के लिए मूल SeverityText को बनाए रखते हुए SeverityNumber के साथ गंभीरता की तुलना करें।

कलेक्शन और ट्रांसपोर्ट डिज़ाइन करें

एक SDK या फ़ाइल रिसीवर रिकॉर्ड्स को OTLP में बदलता है। एक नोड एजेंट बैच करता है और शुरुआती सीमाएं लागू करता है; एक Collector पार्स करता है, Resource डेटा को समृद्ध करता है, रिडैक्ट करता है, रूट करता है और निर्यात करता है। OTLP इंटरमीडिएट Collectors का समर्थन करता है, इसलिए लंबे पाथ्स के लिए स्पष्ट टाइमआउट्स, ऑथेंटिकेशन और कम्प्रेशन की आवश्यकता होती है। कतार वैकल्पिक है, लेकिन बैकएंड थ्रूपुट अस्थिर होने पर यह ड्यूरेबल बफरिंग और प्रति-टेनेंट कोटा सीमा प्रदान कर सकती है।

बैकप्रेशर और डेटा वर्गों को संभालें

प्रति-टेनेंट और प्रति-सर्विस दर, बैच, मेमोरी और डिस्क सीमाएं निर्धारित करें। जब बैकएंड धीमा हो जाता है, तो एरर, ऑडिट और सुरक्षा इवेंट्स को संरक्षित करते हुए कम प्राथमिकता वाले एक्सपोर्ट्स को रोकें; debug को सैंपल या ड्रॉप करें। पुनः प्रयास तूफानों (retry storms) से बचने के लिए रीप्रयासों को एक्सपोनेंशियल बैकऑफ़ और अधिकतम रिटेंशन समय की आवश्यकता होती है। रिप्ले के लिए विफल बैच श्रेणियों को रिकॉर्ड करें और डुप्लिकेट्स को कम करने के लिए इडेम्पोटेंसी या बैकएंड डिडुप्लीकेशन का उपयोग करें।

सुरक्षित करें, अलग करें और क्वेरीज़ को सहसंबंधित करें

एज या Collector पर ही सीक्रेट्स, टोकन्स और पर्सनल डेटा को हटा दें। एक विश्वसनीय Resource स्रोत से टेनेंट पहचान इंजेक्ट करें; मनमाने क्लाइंट ओवरराइड्स को स्वीकार न करें। टेनेंट और समय के अनुसार इंडेक्स को विभाजित करें, जिसमें वैकल्पिक TraceId और SpanId कोरिलेशन इंडेक्स हों। बिना TraceId वाले लॉग्स सर्विस, समय और रिक्वेस्ट आइडेंटिफ़ायर द्वारा क्वेरी करने योग्य बने रहते हैं; कभी भी कोई काल्पनिक TraceId न बनाएं।

मॉडल उच्च-गुणवत्ता वाला उत्तर

मैं इस डिज़ाइन को रिकॉर्ड अनुबंध, कलेक्शन, बफरिंग, प्रोसेसिंग और क्वेरी लेयर्स में विभाजित करूँगा। रिकॉर्ड्स समय, गंभीरता, Body, Resource, और Attributes के लिए OpenTelemetry Logs Data Model का पालन करते हैं, और एप्लिकेशन में संदर्भ होने पर TraceId और SpanId जोड़ते हैं। एक SDK या filelog रिसीवर नोड Collector को भेजता है; Collector बैच बनाता है, रिडैक्ट करता है, टेनेंट कोटा लागू करता है, और आवश्यकता पड़ने पर प्रति-टेनेंट ड्यूरेबल कतार के साथ OTLP पर रूट करता है। बैकएंड जिटर को मेमोरी और डिस्क बफ़र्स द्वारा अवशोषित किया जाता है; जब बजट पार हो जाता है, तो ड्रॉप रेट और सबसे पुराने रिकॉर्ड की आयु को मापते हुए debug, info, error, और audit के क्रम में ड्रॉप करें। क्वेरी इंडेक्स टेनेंट- और समय-आइसोलेटेड होते हैं, और TraceId कोरिलेशन संदर्भ को गढ़े बिना जांच को तेज़ करता है। रिकवरी बैच रेंज, बैकऑफ़ और इडेम्पोटेंट डिडुप्लीकेशन का उपयोग करती है; ऑडिट और सुरक्षा लॉग्स की अलग-अलग रिटेंशन और एक्सेस नीतियां होती हैं।

सामान्य गलतियाँ

  • हर फ़ील्ड को Body में डालना और Resource, Attributes, और Trace Context के सिमेंटिक्स को खो देना।
  • बिना किसी एजेंट, Collector, कतार या डिस्क बफर के केवल एक एप्लिकेशन-टू-बैकएंड लाइन खींचना।
  • बैकएंड विफलता के दौरान तब तक लगातार रीप्रयास करना जब तक कि मेमोरी समाप्त न हो जाए और आउटेज कैस्केड न हो जाए।
  • क्लाइंट्स को सीधे टेनेंट एट्रिब्यूट्स सबमिट करने देना और क्रॉस-टेनेंट इंडेक्स को दूषित करना।
  • ऐसे लॉग्स के लिए रैंडम ट्रेस आईडी जनरेट करना जिनमें संदर्भ की कमी है और जांच को भटकाना।
  • प्रायोरिटी ड्रॉप्स, रिडेक्शन, डुप्लिकेट और रिकवरी मेट्रिक्स के बिना केवल थ्रूपुट पर चर्चा करना।

फॉलो-अप प्रश्न और उत्तर

1. जब TraceId अनुपस्थित हो तो आप क्या करते हैं?

मूल लॉग को बनाए रखें और संदर्भ को अनुपस्थित (missing) के रूप में चिह्नित करें। कोरिलेशन के लिए सत्यापन योग्य सर्विस, समय और रिक्वेस्ट आइडेंटिफ़ायर का उपयोग करें। केवल तभी TraceId भरें जब एप्लिकेशन या विश्वसनीय प्रॉक्सी इसे प्रदान करे; कभी भी इसे स्वयं न गढ़ें।

2. आप सीक्रेट लीकेज को कैसे रोकते हैं?

SDK, एजेंट या Collector में शुरुआत में ही फ़ील्ड नियम और पैटर्न रिडेक्शन लागू करें, स्पष्ट सीक्रेट फॉर्मेट्स को अस्वीकार करें, और टेनेंट-स्तरीय बैकएंड एक्सेस लागू करें। किसी भी सैंपल्ड रॉ रिटेंशन के लिए सख्त आइसोलेशन और ऑडिट की आवश्यकता होती है।

3. लॉग्स को ड्रॉप करना कब स्वीकार्य है?

पहले बिज़नेस वर्गों को परिभाषित करें: सुरक्षा, ऑडिट और गंभीर एरर्स आमतौर पर संरक्षित किए जाते हैं; debug और उच्च-कार्डिनैलिटी वाले डायग्नोस्टिक फ़ील्ड्स को सैंपल किया जा सकता है। प्रत्येक ड्रॉप के लिए कारण, टेनेंट, समय सीमा और संख्या रिकॉर्ड करें ताकि क्षमता के दबाव को समझाया जा सके और अलर्ट किया जा सके।

सार्वजनिक स्रोत

संबंधित प्रश्न

संबंधित इंटरव्यू टूल

सिस्टम डिज़ाइन उत्तर के लिए हल करें का उपयोग करें

पहले आवश्यकताओं को स्पष्ट करें, फिर स्केल, आर्किटेक्चर, कंपोनेंट चयन और ट्रेड-ऑफ की ओर बढ़ें।

टूल देखें