Prompt और Scope
बैकएंड और विश्वसनीयता टीमों द्वारा सेवाओं के बीच एक अनुरोध या एसिंक्रोनस वर्कफ़्लो को ट्रैक करने के लिए उपयोग किए जाने वाले एक मल्टी-टेनेंट डिस्ट्रीब्यूटेड ट्रेसिंग प्लेटफॉर्म को डिज़ाइन करें। इंटरव्यू के अनुमान हैं प्रति सेकंड 500,000 नए रूट वर्कफ़्लो, औसतन प्रति वर्कफ़्लो 15 स्पैन, और स्टोरेज कम्प्रेशन से पहले प्रति एन्कोडेड स्पैन 700 बाइट्स। एक रखे गए ट्रेस को p99 पर 30 सेकंड के भीतर सर्च योग्य बन जाना चाहिए। टेनेंट और ट्रेस ID द्वारा सटीक लुकअप p99 पर 2 सेकंड के भीतर पूरा होना चाहिए; सर्विस, ऑपरेशन, एरर, अवधि और टाइम विंडो द्वारा सामान्य सर्च p95 पर 3 सेकंड के भीतर पूरी होनी चाहिए। इंस्ट्रूमेंटेशन को केंद्रीय प्लेटफ़ॉर्म के लिए सिंक्रोनस रूप से प्रतीक्षा नहीं करनी चाहिए, और एक उपलब्धता क्षेत्र (availability zone) के बंद होने से अनुप्रयोगों को टेलीमेट्री उत्सर्जित करने से नहीं रोकना चाहिए।
प्लेटफ़ॉर्म स्पैन बनाता या प्राप्त करता है, समर्थित ट्रांसपोर्ट्स पर W3C ट्रेस कॉन्टेक्स्ट को प्रोपेगेट करता है, देर से या आउट-ऑफ़-ऑर्डर आने वाले स्पैन को असेंबल करता है, स्पष्ट बजट के तहत पूरे ट्रेस का सैंपल लेता है, ट्रेस विवरण संग्रहीत करता है, और रखे गए ट्रेस से प्राप्त डिपेंडेंसी ग्राफ़ का समर्थन करता है। प्रत्येक भाषा का SDK, एक पूर्ण APM UI, लॉग स्टोरेज, मीट्रिक स्टोरेज और विसंगति का पता लगाना (anomaly detection) स्कोप से बाहर हैं। लॉग और मीट्रिक्स ट्रेस ID या उदाहरण (exemplars) ले जा सकते हैं, लेकिन वे अलग सिस्टम बने रहते हैं।
तीन स्वतंत्र 2026 इंटरव्यू-तैयारी पृष्ठ डिस्ट्रीब्यूटेड ट्रेसिंग को एक सिस्टम-डिज़ाइन अभ्यास के रूप में प्रस्तुत करते हैं जिसमें स्पैन, कॉन्टेक्स्ट प्रोपेगेशन, ट्रेस असेंबली, सैंपलिंग और क्वेरी स्टोरेज शामिल हैं। यह किसी कंपनी के संदर्भ को साबित किए बिना वर्तमान प्रतिनिधित्व स्थापित करता है, इसलिए लेख कोई संदर्भ नहीं बनाता है। तकनीकी मॉडल W3C Trace Context अनुशंसा, OpenTelemetry विनिर्देश और Collector कार्यान्वयन, और Google के Dapper पेपर से आता है।
Interviewer क्या मूल्यांकन कर रहा है
पहला संकेत यह है कि क्या उम्मीदवार प्रोसेस सीमाओं के पार कार्य-कारण (causality) को संरक्षित करता है। एक trace_id पर्याप्त नहीं है। प्रत्येक ऑपरेशन को एक span_id, पैरेंट संबंध या स्पष्ट लिंक, समय, स्थिति, संसाधन पहचान और सावधानीपूर्वक सीमित एट्रिब्यूट्स की आवश्यकता होती है। W3C प्रारूप traceparent में इंटरऑपरेबल और tracestate में वैकल्पिक वेंडर स्थिति को परिभाषित करता है; यह किसी अविश्वसनीय आने वाले ट्रेस ID को प्राधिकरण क्रेडेंशियल (authorization credential) नहीं बनाता है। एक मजबूत उत्तर आने वाले कॉन्टेक्स्ट को मान्य करता है, इनजेशन पर टेनेंट्स को अलग करता है, और विश्वास सीमाओं पर व्यवहार को परिभाषित करता है।
दूसरा संकेत एक ईमानदार सैंपलिंग मॉडल है। हेड सैंपलिंग पूरे ट्रेस के ज्ञात होने से पहले निर्णय लेती है और SDK, नेटवर्क और इनजेस्ट कार्य को कम कर सकती है। यह बाद की हर त्रुटि को बनाए रखने का वादा नहीं कर सकता। टेल सैंपलिंग अधिकांश स्पैन देखने के बाद एक ट्रेस का चयन कर सकती है, लेकिन इसे पहले उन स्पैन को प्राप्त करना और होल्ड करना होगा। यह डाउनस्ट्रीम स्टोरेज को कम करता है, अपस्ट्रीम संग्रह लागत को नहीं। यदि 2% हेड सैंपलर ने पहले ही एक ट्रेस को छोड़ दिया है, तो बाद का कोई भी टेल सैंपलर उसके एरर स्पैन को पुनर्प्राप्त नहीं कर सकता है।
तीसरा संकेत एक सामान्य इवेंट पाइपलाइन के बजाय ट्रेस असेंबली है। स्पैन डुप्लिकेट, विलंबित और अव्यवस्थित (unordered) होते हैं; एसिंक्रोनस फ़ैन-आउट या बैच कार्य एक साफ पेड़ (tree) के बजाय एक निर्देशित चक्रीय ग्राफ (directed acyclic graph) बना सकता है। एक टेल सैंपलर को एक ही निर्णय स्वामी (decision owner) के लिए रूट किए गए एक ट्रेस के लिए सभी स्पैन, एक सीमित पूर्णता नियम, मेमोरी सुरक्षा और स्पष्ट देर से आने वाले स्पैन व्यवहार की आवश्यकता होती है। यह स्टेटफुल सीमा तय करती है कि डिज़ाइन उपयोगी साक्ष्य उत्पन्न करता है या मूक सैंपलिंग पूर्वाग्रह (silent sampling bias)।
अंतिम संकेत संचालन क्षमता (operability) है। एक अच्छा उत्तर कच्चे और रखे गए वॉल्यूम को मापता है, मनमाने एट्रिब्यूट इंडेक्स को सीमित करता है, शोर करने वाले टेनेंट्स को अलग करता है, अनुपलब्ध प्रोपेगेशन और छोड़े गए स्पैन को मापता है, और टेलीमेट्री पथ को एप्लिकेशन निर्भरता बनने से रोकता है। "स्पैन को डेटाबेस में लिखें" पर समाप्त होने वाला आरेख लागत, शुद्धता और विफलता के सवालों को अनुत्तरित छोड़ देता है।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
- किन वर्कफ़्लो के लिए टेल निर्णयों की आवश्यकता होती है? पूर्ण टेल सैंपलिंग के लिए सभी उम्मीदवार स्पैन की केंद्रीय प्राप्ति की आवश्यकता होती है। यह डिज़ाइन सामान्य ट्रैफ़िक के लिए स्रोत हेड सैंपलिंग का उपयोग करता है और महत्वपूर्ण मार्गों के एक नियंत्रित सेट को टेल पूल में 100% पर भेजता है। यदि प्रत्येक मार्ग को एरर-जागरूक प्रतिधारण (error-aware retention) की आवश्यकता है, तो संपूर्ण कच्ची स्ट्रीम को केंद्रीय नेटवर्क और स्थिति बजट में फिट होना चाहिए।
- "पूर्ण ट्रेस" का क्या अर्थ है? कतारों और अलग किए गए कार्यों में कोई सार्वभौमिक अंत मार्कर नहीं है। सिंक्रोनस अनुरोधों के लिए, एक समाप्त रूट स्पैन और एक ग्रेस अंतराल उपयोगी है। लंबे समय तक चलने वाले वर्कफ़्लो को एक लंबी नीति या स्पष्ट वर्कफ़्लो पूर्णता की आवश्यकता होती है। प्लेटफ़ॉर्म को निश्चितता का दावा करने के बजाय अभी भी एक
incompleteफ़्लैग प्रकाशित करना चाहिए। - कौन से सर्च संविदात्मक (contractual) हैं? सटीक ट्रेस-ID लुकअप और सर्विस, ऑपरेशन, स्थिति, अवधि बकेट और समय पर सीमित फ़िल्टर दायरे में हैं। प्रत्येक एट्रिब्यूट पर मनमाना पूर्ण-पाठ विधेय (full-text predicates) इंडेक्स लागत को गुणा करेगा और उच्च-कार्डिनैलिटी दुरुपयोग पैदा करेगा, इसलिए गैर-अनुमति प्राप्त एट्रिब्यूट्स केवल एक ट्रेस प्राप्त होने के बाद ही उपलब्ध रहते हैं।
- डेटा कितने समय तक रखा जाता है? मानी गई नीति अनुक्रमित हॉट डेटा के सात दिन और संपीड़ित ऑब्जेक्ट डेटा के अन्य 23 दिन है। लंबा हॉट प्रतिधारण स्टोरेज और इंडेक्स आकार को बदलता है; कानूनी विलोपन नियम यह भी निर्धारित करते हैं कि ऑब्जेक्ट कुंजियाँ और एन्क्रिप्शन डोमेन टेनेंट-विशिष्ट होने चाहिए या नहीं।
- क्या क्रॉस-टेनेंट ट्रेस की अनुमति है? डिफ़ॉल्ट रूप से नहीं है। गेटवे प्रमाणित क्रेडेंशियल्स को एक टेनेंट से जोड़ते हैं और स्पैन में आपूर्ति किए गए किसी भी टेनेंट फ़ील्ड को अधिलेखित (overwrite) करते हैं। स्वीकृत क्रॉस-डोमेन वर्कफ़्लो स्पष्ट लिंक या अलग से अधिकृत सहसंबंध का उपयोग करते हैं, कभी भी क्लाइंट-चयनित टेनेंट पहचानकर्ता का नहीं।
- एसिंक्रोनस कार्य-कारण का प्रतिनिधित्व कैसे किया जाना चाहिए? एक एकल पैरेंट एक कारणात्मक पूर्ववर्ती के लिए काम करता है। बैच उपभोक्ता और फ़ैन-इन कई उत्पादकों पर निर्भर हो सकते हैं, इसलिए उन्हें स्पैन लिंक की आवश्यकता होती है। एक पैरेंट को बाध्य करने से जानकारी खो जाती है; कई पैरेंट के तहत एक स्पैन की प्रतिलिपि बनाने से ट्रेस अकाउंटिंग दूषित हो जाती है।
- अधिभार (overload) के दौरान एप्लिकेशन क्या खो सकता है? व्यावसायिक ट्रैफ़िक जारी रहना चाहिए। एक सीमित स्थानीय कतार मेमोरी और डिस्क बजट समाप्त होने के बाद टेलीमेट्री को छोड़ सकती है, लेकिन नुकसान को सेवा, टेनेंट, कारण और सैंपलिंग वर्ग द्वारा गिना जाता है। यदि शून्य टेलीमेट्री हानि की आवश्यकता है, तो ट्रेसिंग एक व्यावसायिक-पथ निर्भरता बन जाती है और उपलब्धता अनुबंध को बदलना होगा।
30-सेकंड उत्तर रूपरेखा
"मैं कॉन्टेक्स्ट प्रोपेगेशन, संग्रह, ट्रेस निर्णय और क्वेरी स्टोरेज को अलग करूंगा। इंस्ट्रूमेंटेड लाइब्रेरी स्पैन बनाती हैं और मान्य W3C कॉन्टेक्स्ट को प्रोपेगेट करती हैं। एक स्थानीय एजेंट उन्हें एसिंक्रोनस रूप से बैच करता है और एक सीमित स्पूल का उपयोग करता है, इसलिए केंद्रीय प्लेटफ़ॉर्म अनुरोध पथ को कभी ब्लॉक नहीं करता है। रीजनल गेटवे टेनेंट को प्रमाणित करते हैं, स्कीमा और कोटा लागू करते हैं, और ट्रेस ID द्वारा विभाजित एक टिकाऊ स्ट्रीम में स्पैन जोड़ते हैं।
"साधारण मार्ग अपस्ट्रीम लागत को कम करने के लिए सुसंगत हेड सैंपलिंग का उपयोग करते हैं। महत्वपूर्ण मार्ग एक पूर्ण टेल पूल में प्रवेश करते हैं; एक ट्रेस के लिए सभी स्पैन एक असेंबलर तक पहुंचते हैं, जो रूट प्लस ग्रेस विंडो की प्रतीक्षा करता है, त्रुटि, विलंबता और बेसलाइन बजट लागू करता है, और रिकॉर्ड करता है कि क्या ट्रेस अधूरा है। रखे गए ट्रेस विहित विवरण के लिए एक ऑब्जेक्ट स्टोर में और ट्रेस-ID और सीमित फ़िल्टर के लिए एक अनुमति-सूचीबद्ध हॉट इंडेक्स में जाते हैं। मैं प्री-सैंपलिंग स्थिति और रखे गए स्टोरेज दोनों का आकार तय करूंगा, पहले कम प्राथमिकता वाले सामान्य ट्रेस को छोड़कर डिग्रेड करूंगा, और कैनरी ट्रेस के साथ प्रोपेगेशन, देर से स्पैन, पक्षपाती सैंपलिंग, टेनेंट अलगाव और ज़ोन रिकवरी को सत्यापित करूंगा।"
चरण-दर-चरण गहन विश्लेषण
चरण 1: स्पैन अनुबंध और क्वेरी API परिभाषित करें।
एक स्पैन रिकॉर्ड में कम से कम निम्नलिखित शामिल हैं:
Span {
tenant_id, trace_id, span_id, parent_span_id?, links[],
service, operation, kind, start_time, end_time, status,
resource_attributes, span_attributes, events[],
observed_at, schema_version, trace_flags, tracestate?
}गेटवे प्रमाणीकरण से tenant_id प्राप्त करता है। यह पहचानकर्ता की लंबाई और प्रारूपों को मान्य करता है, बड़े आकार के रिकॉर्ड को अस्वीकार करता है, स्वीकृत सिमेंटिक फ़ील्ड को सामान्य करता है, और एट्रिब्यूट गणना, मान लंबाई, ईवेंट गणना, लिंक गणना और कुल बाइट्स को सीमित करता है। यह ईवेंट समय और observed_at दोनों को संग्रहीत करता है: सर्विस घड़ियां एक समयरेखा प्रस्तुत करने में मदद करती हैं, जबकि कलेक्टर समय देरी और घड़ी-तिरछा (clock-skew) समस्याओं को उजागर करता है। SDK को एक स्थानीय स्पैन की अवधि को एक मोनोटोनिक घड़ी के साथ मापना चाहिए, भले ही क्रॉस-होस्ट ऑर्डरिंग के लिए अभी भी वास्तविक समय (wall time) और कारणात्मक किनारों की आवश्यकता होती है।
मुख्य क्वेरी अनुबंध हैं:
GetTrace(tenant_id, trace_id)
SearchTraces(tenant_id, start, end, service?, operation?, status?,
min_duration?, max_duration?, cursor?, limit?)GetTrace स्पैन, लिंक, सैंपलिंग नीति और संस्करण, first_observed_at, last_observed_at और पूर्णता चेतावनियाँ लौटाता है। SearchTraces को एक सीमित समय सीमा की आवश्यकता होती है और यह एक असीमित ऑफ़सेट के बजाय एक कर्सर लौटाता है। विवरण पुनर्प्राप्ति और द्वितीयक खोज अलग-अलग एक्सेस पथ हैं; एक विस्तृत ट्रेस रिकॉर्ड को प्रत्येक द्वितीयक इंडेक्स में डुप्लिकेट नहीं किया जाना चाहिए।
चरण 2: कॉन्टेक्स्ट को विश्वास में बदले बिना प्रोपेगेट करें।
HTTP के लिए, SDK W3C traceparent को निकालता और इंजेक्ट करता है, जिसमें संस्करण, ट्रेस ID, पैरेंट ID और फ़्लैग होते हैं; tracestate वैकल्पिक वेंडर-विशिष्ट स्थिति रखता है। संदेश उत्पादक संदेश मेटाडेटा में समान प्रोपेगेशन फ़ील्ड डालते हैं। ट्रेस में शामिल होने से पहले रिसीवर प्रारूप को मान्य करते हैं। अमान्य कॉन्टेक्स्ट एक मौजूदा कुंजी स्थान को दूषित करने के बजाय एक नया ट्रेस शुरू करता है और एक प्रोपेगेशन त्रुटि काउंटर बढ़ाता है।
इंटरनेट-सामना करने वाले या क्रॉस-टेनेंट सीमा पर, सेवा जानबूझकर एक नया ट्रेस शुरू कर सकती है और एक अनुमोदित अपस्ट्रीम संदर्भ में एक लिंक संलग्न कर सकती है। यह किसी बाहरी कॉलर को आंतरिक पैरेंट या सैंपलिंग नियंत्रण चुनने दिए बिना सहसंबंध को संरक्षित करता है। बैगेज एक अलग प्रोपेगेटेड कुंजी-मान तंत्र है। इसे अनुमति-सूचीबद्ध, आकार-सीमित और रहस्यों या व्यक्तिगत डेटा से रहित होना चाहिए क्योंकि यह प्रत्येक डाउनस्ट्रीम हॉप तक फैलता है।
पहले सामान्य HTTP, RPC, डेटाबेस और कतार लाइब्रेरीज़ को ऑटो-इंस्ट्रूमेंट करें। डैपर ने प्रदर्शित किया कि कैसे सामान्य लाइब्रेरी इंस्ट्रूमेंटेशन कम एप्लिकेशन प्रयास के साथ कवरेज में सुधार करता है। कस्टम स्पैन व्यावसायिक सीमाओं के लिए उपयोगी रहते हैं, लेकिन प्लेटफ़ॉर्म उन सेवाओं और मार्गों को मापता है जिनमें अपेक्षित सर्वर या क्लाइंट स्पैन की कमी होती है। ट्रेस गुणवत्ता केवल इंस्ट्रूमेंटेशन और बनाए रखे गए नमूनों जितनी ही पूर्ण होती है।
चरण 3: एप्लिकेशन अनुरोध पथ से संग्रह को बाहर रखें।
समाप्त स्पैन एक इन-प्रोसेस बाउंडेड बफ़र में प्रवेश करते हैं और एक नोड एजेंट या साइडकार में संपीड़ित बैचों में फ़्लश किए जाते हैं। एजेंट के पास संक्षिप्त कलेक्टर आउटेज, जिटर के साथ घातीय पुनः प्रयास (exponential retry with jitter), और प्रति-प्राथमिकता कतारों के लिए एक सीमित डिस्क स्पूल है। एप्लिकेशन द्वारा अपनी प्रतिक्रिया समाप्त करने से पहले यह केंद्रीय पावती के लिए सिंक्रोनस रूप से कभी प्रतीक्षा नहीं करता है। एक बार स्थानीय बजट समाप्त हो जाने के बाद, यह पहले कम प्राथमिकता वाली सामान्य टेलीमेट्री को छोड़ देता है और वास्तव में क्या खो गया था इसका वर्णन करने वाले काउंटर निर्यात करता है।
रीजनल स्टेटलेस गेटवे एजेंट को प्रमाणित करते हैं, टेनेंट को बांधते हैं, बाइट और स्पैन कोटा लागू करते हैं, स्कीमा को मान्य करते हैं, और स्वीकृत बैचों को एक प्रतिकृति टिकाऊ स्ट्रीम में जोड़ते हैं। पावती का अर्थ है कि रीजनल स्ट्रीम ने बैच को स्थायी रूप से स्वीकार कर लिया है, यह नहीं कि सर्च में यह पहले से मौजूद है। उपभोक्ता (tenant_id, trace_id, span_id) प्लस एक रिकॉर्ड संस्करण द्वारा इडेम्पोटेंट हैं; डुप्लिकेट डिलीवरी अवलोकन मेटाडेटा को अपडेट करती है लेकिन स्पैन को डुप्लिकेट नहीं करती है।
स्ट्रीम (tenant_id, trace_id) के एक स्थिर हैश द्वारा विभाजित होती है। यह वैश्विक स्पैन ऑर्डर की आवश्यकता के बिना एक ट्रेस को एक आदेशित निर्णय स्वामी देता है। बड़े पैमाने पर टेल सैंपलिंग के लिए, पहली कलेक्टर परत ट्रेस ID द्वारा दूसरी स्टेटफुल परत में लोड-बैलेंस कर सकती है। OpenTelemetry Collector समान इनवेरिएंट का दस्तावेजीकरण करता है: एक ट्रेस के लिए सभी स्पैन एक ही टेल-सैंपलिंग इंस्टेंस तक पहुंचने चाहिए।
चरण 4: प्रत्येक क्षमता सीमा को पुनर्गणना योग्य बनाएं।
सैंपलिंग से पहले, वर्कलोड उत्पन्न करता है:
500,000 workflows/s × 15 spans/workflow = 7,500,000 spans/s
7,500,000 spans/s × 700 bytes/span = 5.25 GB/s
5.25 GB/s × 86,400 s = 453.6 TB/day rawये वर्कलोड धारणाएं हैं, मापे गए कम्प्रेशन के दावे नहीं। एक प्लेटफ़ॉर्म जो सभी कच्चे स्पैन को एक केंद्रीय टेल सैंपलर को भेजता है, उसे प्रतिकृति, प्रोटोकॉल ओवरहेड, पुनः प्रयास, तिरछापन और फ़ेलओवर हेडरूम के लिए लेखांकन से पहले 5.25 GB/s इनजेस्ट पथ का प्रावधान करना होगा।
मान लें कि साधारण मार्ग 90% स्पैन उत्पन्न करते हैं और 2% सुसंगत हेड सैंपलिंग का उपयोग करते हैं। महत्वपूर्ण मार्ग 10% उत्पन्न करते हैं और 100% पर टेल पूल में प्रवेश करते हैं:
ordinary: 7.5M × 90% × 2% = 135,000 spans/s
tail pool input: 7.5M × 10% = 750,000 spans/s
collector input: 885,000 spans/s × 700 bytes = 619.5 MB/sयदि टेल नीति अपने उम्मीदवार स्पैन का औसतन 10% बरकरार रखती है, तो हॉट स्टोरेज कम्प्रेशन, प्रतिकृति, इंडेक्स और ऑब्जेक्ट मेटाडेटा से पहले 135,000 + 75,000 = 210,000 spans/s, या 147 MB/s और 12.7008 TB/दिन प्राप्त करता है। सात कच्चे-समतुल्य हॉट दिन 88.9056 TB हैं। उत्पादन एट्रिब्यूट वितरण के साथ बेंचमार्क कम्प्रेशन और नोड गणना निर्धारित करते हैं; अंकगणित केवल निचली सीमा स्थापित करता है और दिखाता है कि कौन सी सैंपलिंग सीमा किस लागत का भुगतान करती है।
चरण 5: टेल सैंपलिंग को निर्णायक स्टेटफुल अड़चन मानें।
असेंबलर टेनेंट और ट्रेस ID द्वारा कुंजीबद्ध आंशिक स्थिति संग्रहीत करता है: अद्वितीय स्पैन, सबसे प्रारंभिक शुरुआत, नवीनतम अंत, रूट-समाप्त स्थिति, त्रुटि स्थिति, वर्तमान अवधि, बाइट गणना, और अंतिम आगमन। एक सिंक्रोनस ट्रेस अपने रूट समाप्त होने और ग्रेस अंतराल बीतने के बाद निर्णय के लिए योग्य हो जाता है। यह अधिकतम आयु, स्पैन गणना या बाइट गणना पर निर्णय लेने के लिए भी बाध्य है। लंबे वर्कफ़्लो एक अलग नीति का उपयोग करते हैं; अन्यथा एक ट्रेस अनिश्चित काल के लिए मेमोरी को पिन कर सकता है।
निर्णय आदेश स्पष्ट महत्वपूर्ण प्रवाह, त्रुटियों और उच्च-विलंबता ट्रेस के लिए क्षमता सुरक्षित रखता है, फिर प्रति-सेवा और प्रति-टेनेंट बजट के भीतर एक सुसंगत संभाव्य बेसलाइन का उपयोग करता है। एक वैश्विक "प्रत्येक त्रुटि को रखें" नियम किसी घटना के दौरान एक सीमित नीति नहीं है, जब त्रुटियां 100% तक पहुंच सकती हैं। टोकन बकेट और हार्ड बाइट सीमाएं प्रत्येक वर्ग को सीमित करती हैं; कमी की प्रतिक्रिया एक दृश्यमान डिग्रेटेड नीति है, न कि आउट-ऑफ-मेमोरी क्रैश।
सैंपलर देर से आने वाले स्पैन के लिए एक निर्णय कैश रिकॉर्ड करता है। एक रखे गए ट्रेस के लिए एक देर से आने वाले स्पैन को जोड़ा जाता है और ट्रेस को अपडेटेड चिह्नित किया जाता है। एक छोड़े गए ट्रेस के लिए देर से आने वाले स्पैन को लगातार त्याग दिया जाता है। कैश समाप्त होने के बाद आने वाले स्पैन को अनाथ (orphaned) के रूप में गिना जाता है; इसे भ्रामक एक-स्पैन ट्रेस नहीं बनाना चाहिए। प्रत्येक संग्रहीत ट्रेस complete, decision_reason और देर से स्पैन काउंटरों को वहन करता है। ग्रेस अंतराल बढ़ाने से पूर्णता में सुधार होता है लेकिन मेमोरी, निर्णय विलंबता और सैंपलर विफलता के संपर्क में आने वाले ट्रेस की संख्या बढ़ जाती है।
महत्वपूर्ण जाल एक हाइब्रिड पाइपलाइन है। टेल लॉजिक केवल उन ट्रेसों में से चुन सकता है जो उस तक पहुंचे हैं। यदि 2% हेड सैंपलर ने डाउनस्ट्रीम त्रुटि होने से पहले एक सामान्य ट्रेस को हटा दिया, तो टेल चरण इसे पुनर्प्राप्त नहीं कर सकता है। इसलिए, गारंटीकृत त्रुटि-जागरूक निर्णयों की आवश्यकता वाले मार्गों को अपस्ट्रीम ड्रॉपिंग निर्णय के बिना टेल पूल में प्रवेश करना चाहिए, या एक अलग ट्रिगर का उपयोग करना चाहिए और यह स्वीकार करना चाहिए कि यह अतीत का पुनर्निर्माण नहीं करेगा।
चरण 6: कैनोनिकल विवरण को सीमित इंडेक्स से अलग स्टोर करें।
रखे गए स्पैन को टेनेंट और समय द्वारा विभाजित अपरिवर्तनीय, संपीड़ित ऑब्जेक्ट्स में कॉम्पैक्ट किया जाता है, जिसमें प्रत्येक ट्रेस संशोधन के लिए एक मेनिफेस्ट होता है। ट्रेस-ID निर्देशिका (tenant_id, trace_id) को ऑब्जेक्ट स्थानों और नवीनतम संशोधन में मैप करती है। यह पथ सटीक लुकअप प्रदान करता है। हाल की ट्रेस ऑब्जेक्ट्स को कैश किया जा सकता है, लेकिन ऑब्जेक्ट लेयर व्युत्पन्न इंडेक्स के लिए पुनर्निर्माण स्रोत है।
हॉट सर्च इंडेक्स प्रति ट्रेस एक सारांश पंक्ति संग्रहीत करता है: टेनेंट, ट्रेस ID, रूट सेवा और ऑपरेशन, स्टार्ट बकेट, अवधि, स्थिति, चयनित सेवा सेट या फ़िंगरप्रिंट, सैंपलिंग कारण, पूर्णता और ऑब्जेक्ट पॉइंटर। केवल अनुमति-सूचीबद्ध फ़ील्ड को द्वितीयक इंडेक्स प्राप्त होते हैं। मनमाने यूजर ID, SQL टेक्स्ट, URL और बैगेज मान संरक्षित विवरण में रहते हैं या हटा दिए जाते हैं; उन्हें डिफ़ॉल्ट रूप से अनुक्रमित करने से असीमित कार्डिनैलिटी, गोपनीयता का जोखिम और राइट प्रवर्धन (write amplification) बनता है।
सर्विस डिपेंडेंसी और लेटेंसी दृश्य रखे गए ट्रेस पर स्ट्रीमिंग समुच्चय हैं और उन्हें सैंपल किए गए अनुमानों के रूप में लेबल किया जाना चाहिए। संभावना ज्ञात होने पर सैंपलिंग भार कुछ निष्पक्ष गणना अनुमानों का समर्थन कर सकते हैं, लेकिन त्रुटि- और विलंबता-पक्षपाती टेल नमूने स्वचालित रूप से ट्रैफ़िक अनुपात का प्रतिनिधित्व नहीं करते हैं। मीट्रिक्स सटीक बेड़े-स्तर की दरों के लिए स्रोत बने रहते हैं; ट्रेस व्यक्तिगत कारणात्मक पथों की व्याख्या करते हैं।
चरण 7: टेनेंट्स को अलग करें और विफलता व्यवहार को परिभाषित करें।
गेटवे प्रति-टेनेंट बाइट्स प्रति सेकंड, स्पैन प्रति सेकंड, समवर्ती आंशिक ट्रेस, क्वेरी समवर्ती और बनाए रखे गए बाइट्स को लागू करते हैं। विभाजन कुंजियों में टेनेंट पहचान शामिल है, एन्क्रिप्शन नीतियां विनियमित टेनेंट्स को अलग कर सकती हैं, और किसी भी इंडेक्स लुकअप से पहले क्वेरी प्राधिकरण की जांच की जाती है। एक विशाल ट्रेस या उच्च-कार्डिनैलिटी एट्रिब्यूट वाला एक टेनेंट दूसरे टेनेंट की सैंपलर स्थिति को बाहर (evict) नहीं करना चाहिए।
यदि कोई गेटवे या उपलब्धता क्षेत्र विफल हो जाता है, तो एजेंट दूसरे रीजनल एंडपॉइंट का पुनः प्रयास करते हैं और अपने सीमित स्पूल का उपयोग करते हैं। यदि टिकाऊ स्ट्रीम धीमी है, तो प्रवेश नियंत्रण सामान्य सैंपलिंग को कम करता है और स्टेटफुल असेंबली से पहले अतिरिक्त बाइट्स को अस्वीकार करता है। यदि कोई असेंबलर बंद हो जाता है, तो स्ट्रीम इसके विभाजन को फिर से चलाती है; चेकपॉइंट रिकवरी को गति देते हैं, जबकि इडेम्पोटेंट स्पैन कुंजियाँ डुप्लिकेट को अवशोषित करती हैं। इंडेक्स आउटेज के दौरान, विहित ऑब्जेक्ट आते रहते हैं और एक इंडेक्स बैकलॉग बढ़ता है। हाल ही में लिखी गई सटीक क्वेरीज़ गलत नॉट-फाउंड लौटाने के बजाय "स्वीकृत, अनुक्रमण" रिपोर्ट कर सकती हैं।
यदि टेल पूल ओवरलोड हो जाता है, तो उत्तरोत्तर संभाव्य बेसलाइन को कम करें, बड़े ट्रेस को कैप करें, और फिर प्रभावित मार्गों के लिए एक नियतात्मक हेड नीति पर वापस जाएं। कंट्रोल-प्लेन कैनरी ट्रेस और कुछ सीमित त्रुटि क्षमता को सुरक्षित रखें। टेनेंट, सर्विस, ज़ोन और नीति द्वारा स्वीकृत, छोड़े गए, पुनः प्रयास किए गए, बहुत जल्दी निकाले गए, देर से, अनाथ और अनुक्रमित स्पैन की निगरानी करें।
चरण 8: केवल थ्रूपुट ही नहीं, बल्कि सच्चाई को सत्यापित करें।
प्रोपेगेशन परीक्षण मान्य, अनुपलब्ध, विकृत और भविष्य के संस्करण के हेडर को कवर करते हैं; क्रॉस-टेनेंट और इंटरनेट सीमाएं; बैगेज सीमाएं; कतारें; पुनः प्रयास; फ़ैन-आउट; फ़ैन-इन; और बैच लिंक। असेंबली परीक्षण डुप्लिकेट, आउट-ऑफ़-ऑर्डर, लापता-पैरेंट, देर से, बड़े आकार और कभी न समाप्त होने वाले ट्रेस को इंजेक्ट करते हैं। सैंपलिंग परीक्षण पूरे ट्रेस की स्थिरता, बजट की सीमा, नियतात्मक संभावना निर्णयों, त्रुटि और विलंबता नीतियों, और इस तथ्य को साबित करते हैं कि अपस्ट्रीम हेड ड्रॉप्स अप्राप्य रहते हैं।
लोड परीक्षण उत्पादन के आकार के ट्रेस आकार और टेनेंट तिरछापन को बनाए रखते हैं। वे SDK ओवरहेड, एजेंट हानि, गेटवे प्रवेश, स्ट्रीम अंतराल, सक्रिय ट्रेस मेमोरी, निर्णय विलंबता, रखे गए बाइट्स, इंडेक्स अंतराल, ट्रेस लुकअप और फ़िल्टर किए गए सर्च को मापते हैं। दोष परीक्षण एक ज़ोन को हटाते हैं, एक हॉट विभाजन के दौरान एक असेंबलर को पुनरारंभ करते हैं, ऑब्जेक्ट स्टोरेज को रोकते हैं, एक टेनेंट कोटा समाप्त करते हैं, और विहित ऑब्जेक्ट से हॉट इंडेक्स का पुनर्निर्माण करते हैं।
प्रत्येक क्षेत्र के माध्यम से एक ज्ञात ग्राफ के साथ लगातार सिंथेटिक कैनरी वर्कफ़्लो उत्सर्जित करें। यदि अपेक्षित स्पैन गायब हो जाते हैं, पितृत्व बदल जाता है, सर्च की ताजगी 30 सेकंड का उल्लंघन करती है, या ट्रेस-ID लुकअप अपने SLO का उल्लंघन करता है, तो अलर्ट करें। एक स्वस्थ कलेक्टर प्रक्रिया यह साबित नहीं करती है कि ट्रेस पूर्ण या खोजने योग्य हैं।
मजबूत नमूना उत्तर
"मैं पहले यह बताऊंगा कि एक ट्रेस स्पैन का एक कारणात्मक ग्राफ है, न कि लॉग लाइनों का एक बैग। प्रत्येक स्पैन में एक टेनेंट-बाउंड ट्रेस ID, स्पैन ID, पैरेंट या लिंक, समय, स्थिति, संसाधन, सीमित एट्रिब्यूट्स, ईवेंट और देखा गया समय होता है। सेवाएं HTTP या संदेश मेटाडेटा पर मान्य W3C संदर्भ को प्रोपेगेट करती हैं। एक अविश्वसनीय सीमा पर मैं एक नया आंतरिक ट्रेस शुरू करूंगा और इसे लिंक करूंगा, क्योंकि ट्रेस संदर्भ सहसंबंध डेटा है, प्राधिकरण नहीं।
"स्पैन एक सीमित इन-प्रोसेस बफ़र और स्थानीय एजेंट के माध्यम से अनुरोध पथ छोड़ देते हैं। एजेंट व्यावसायिक ट्रैफ़िक को अवरुद्ध करने के बजाय मापे गए कम प्राथमिकता वाले डेटा को बैच करता है, संपीड़ित करता है, डिस्क पर संक्षिप्त रूप से स्पूल करता है, और छोड़ देता है। रीजनल गेटवे टेनेंट्स को प्रमाणित करते हैं, स्कीमा और कोटा लागू करते हैं, और एक प्रतिकृति स्ट्रीम में लिखते हैं। टेनेंट और ट्रेस ID द्वारा विभाजन प्रत्येक ट्रेस को एक असेंबलर को भेजता है और स्पैन ID द्वारा पुनः प्रयास को इडेम्पोटेंट बनाता है।
"कच्चा वर्कलोड 7.5 मिलियन स्पैन प्रति सेकंड और 5.25 GB/s है। मैं गलती से वह सब एक टेल सैंपलर को नहीं भेजूंगा। साधारण मार्ग 2% सुसंगत हेड सैंपलिंग का उपयोग करते हैं। नियंत्रित 10% महत्वपूर्ण-मार्ग पूल 100% पर टेल सैंपलिंग में प्रवेश करता है, इसलिए कलेक्टर इनपुट 885,000 स्पैन/सेकंड, या 619.5 MB/s है। यदि टेल पूल 10% रखता है, तो स्टोरेज को इंडेक्स और प्रतियों से पहले कच्चा 210,000 स्पैन/सेकंड, लगभग 12.7 TB/दिन मिलता है। वे सीमाएं बेंचमार्क इनपुट हैं, वादा किए गए कम्प्रेशन परिणाम नहीं।
"असेंबलर कठिन हिस्सा है। यह आंशिक ट्रेस रखता है, एक पूर्ण रूट प्लस एक ग्रेस विंडो की प्रतीक्षा करता है, और आयु, स्पैन और बाइट सीमाओं पर निर्णय लागू करता है। यह महत्वपूर्ण, त्रुटि और धीमी ट्रेस के लिए सीमित क्षमता सुरक्षित रखता है, फिर एक सुसंगत बेसलाइन के साथ प्रति-सेवा बजट भरता है। यह देर से आने वाले स्पैन के लिए निर्णयों को कैश करता है और अपूर्ण ट्रेस को लेबल करता है। 2% अपस्ट्रीम हेड ड्रॉप को बाद में पुनर्प्राप्त नहीं किया जा सकता है, इसलिए किसी भी मार्ग को वास्तव में त्रुटि-जागरूक प्रतिधारण की आवश्यकता होती है, उसे अनसैंपल किए गए टेल पूल में प्रवेश करना होगा।
"रखा गया ट्रेस विवरण ट्रेस-ID निर्देशिका के साथ संपीड़ित ऑब्जेक्ट स्टोरेज में जाता है। एक अलग हॉट इंडेक्स एक ट्रेस सारांश और केवल अनुमति-सूचीबद्ध सेवा, ऑपरेशन, स्थिति, अवधि और समय फ़ील्ड संग्रहीत करता है। यह कार्डिनैलिटी को नियंत्रित करता है और इंडेक्स को फिर से बनाने की अनुमति देता है। विफलताओं के दौरान, एजेंट सीमित स्पूल का उपयोग करते हैं, स्ट्रीम विभाजन फिर से चलते हैं, यदि सर्च बंद है तो ऑब्जेक्ट लिखना जारी रहता है, और ओवरलोड संरक्षित वर्गों से पहले सामान्य बेसलाइन को छोड़ देता है। मैं संदर्भ सीमाओं, डुप्लिकेट और देर से स्पैन, सैंपलिंग पूर्वाग्रह और सीमाओं, शोर-टेनेंट अलगाव, ज़ोन हानि, पुनर्निर्माण और एंड-टू-एंड कैनरी ट्रेस को सत्यापित करूंगा।"
सामान्य गलतियाँ
- कहना "2% सैंपल लें, फिर टेल में हर त्रुटि को रखें" → पहला चरण पहले ही 98% उम्मीदवार ट्रेस को मिटा चुका है, जिसमें बाद की त्रुटियां भी शामिल हैं → सुरक्षित मार्गों को अनसैंपल करके टेल पूल में भेजें या गारंटी को कमजोर करें।
- ट्रेस ID के बिना कलेक्टर्स में स्पैन को हैश करना → एक टेल सैंपलर केवल टुकड़े देखता है और एक पक्षपाती निर्णय लेता है →
(tenant, trace_id)के लिए प्रत्येक स्पैन को उसी निर्णय स्वामी को रूट करें। - एक पूर्ण ट्रेस के लिए हमेशा के लिए प्रतीक्षा करना → एसिंक्रोनस कार्य में कोई सार्वभौमिक अंत मार्कर नहीं होता है, इसलिए स्थिति बिना किसी सीमा के बढ़ती है → रूट-प्लस-ग्रेस, अधिकतम आयु/आकार, स्पष्ट वर्कफ़्लो नीतियों और एक अपूर्ण फ़्लैग का उपयोग करें।
traceparentको पहचान या प्राधिकरण के रूप में मानना → एक बाहरी कॉलर सहसंबंध फ़ील्ड चुन सकता है → टेनेंट को स्वतंत्र रूप से प्रमाणित करें और विश्वास सीमाओं पर एक नया लिंक किया गया ट्रेस शुरू करें।- बैगेज या मनमाने एट्रिब्यूट्स को प्रत्येक इंडेक्स में डालना → कार्डिनैलिटी, राइट प्रवर्धन और संवेदनशील डेटा का जोखिम असीमित हो जाता है → अनुक्रमित फ़ील्ड को अनुमति-सूचीबद्ध करें और प्रोपेगेट किए गए मानों को सीमित या संशोधित करें।
- केंद्रीय कलेक्टर को सिंक्रोनस रूप से स्पैन भेजना → टेलीमेट्री विफलता एप्लिकेशन विलंबता या उपलब्धता जोखिम को बढ़ाती है → सीमित स्थानीय कतारों के माध्यम से एसिंक्रोनस रूप से बैच करें और मापे गए नुकसान को उजागर करें।
- प्रत्येक स्पैन को संग्रहीत करना लेकिन ट्रेस सारांश को छोड़ देना → सेवा, अवधि और त्रुटि खोजें विशाल विवरण डेटा को स्कैन करती हैं → विहित विवरण प्लस प्रति ट्रेस एक सीमित, पुनर्निर्माण योग्य सारांश पंक्ति रखें।
- एक पक्षपाती टेल नमूने को एक सटीक ट्रैफ़िक वितरण कहना → त्रुटि और विलंबता नियम जानबूझकर असामान्य ट्रेस का अधिक प्रतिनिधित्व करते हैं → सैंपलिंग मेटाडेटा प्रकाशित करें और सटीक समग्र दरों के लिए मीट्रिक्स का उपयोग करें।
- केवल कलेक्टर अपटाइम का परीक्षण करना → संदर्भ टूटना, अनुपलब्ध स्पैन और इंडेक्स अंतराल अदृश्य रह सकते हैं → ज्ञात-ग्राफ़ कैनरी चलाएं और पूर्णता, सैंपलिंग, ताजगी और क्वेरी SLO का दावा करें।
अनुवर्ती प्रश्न और उत्तर
अनुवर्ती 1: उत्पाद को अब समान केंद्रीय इनजेस्ट बजट रखते हुए प्रत्येक त्रुटि ट्रेस की आवश्यकता है। क्या बदलता है?
दोनों आवश्यकताएं परस्पर विरोधी हो सकती हैं। डाउनस्ट्रीम स्पैन निष्पादित होने के बाद ही अक्सर एक त्रुटि ज्ञात होती है, इसलिए एक स्रोत हेड सैंपलर प्रतिधारण की गारंटी नहीं दे सकता है। अधिकतम कच्चे स्पैन दर और केंद्रीय टेल क्षमता को मापें। यदि बजट सभी उम्मीदवार मार्गों को प्राप्त नहीं कर सकता है, तो गारंटी को एक सीमित महत्वपूर्ण-मार्ग सेट तक सीमित करें, क्षमता बढ़ाएं, या एप्लिकेशन त्रुटि ट्रिगर जोड़ें जो भविष्य की उच्च-दर सैंपलिंग शुरू करते हैं जबकि यह स्वीकार करते हैं कि पिछले छोड़े गए स्पैन का पुनर्निर्माण नहीं किया जा सकता है। "हमेशा त्रुटियां" में एक बाइट कैप भी होना चाहिए क्योंकि एक घटना लगभग सभी ट्रैफ़िक को त्रुटियों में बदल सकती है।
अनुवर्ती 2: एक संदेश 10 उत्पादक ट्रेस से ईवेंट्स का उपभोग करता है। उपभोक्ता स्पैन को किस पैरेंट का उपयोग करना चाहिए?
कोई भी एकल पैरेंट दस स्वतंत्र कारणों का प्रतिनिधित्व नहीं करता है। उपयुक्त वर्कफ़्लो में एक उपभोक्ता या बैच-प्रोसेसिंग स्पैन बनाएं और लिंक-गणना सीमा के अधीन दस निर्माता संदर्भों में लिंक संलग्न करें। यदि बैच में ही एक डिलीवरी संदर्भ है, तो वह पैरेंट हो सकता है जबकि व्यक्तिगत इनपुट लिंक बने रहते हैं। क्वेरी और विज़ुअलाइज़ेशन कोड को DAG का समर्थन करना चाहिए और ट्रंकेटेड-लिंक मेटाडेटा दिखाना चाहिए; उपभोक्ता स्पैन को दस पेड़ों में कॉपी करने से अवधि और स्टोरेज विकृत हो जाती है।
अनुवर्ती 3: टेल सैंपलर अपनी निर्णय विंडो से पहले आंशिक ट्रेस को बाहर निकाल रहा है। आप इसे कैसे डिबग करेंगे?
सक्रिय ट्रेस गणना और बाइट्स, ट्रेस-आकार वितरण, आगमन में देरी, हॉट पार्टीशन, निर्णय आयु, प्रारंभिक-निष्कासन काउंटर और प्रति-टेनेंट तिरछापन की तुलना करें। प्रतीक्षा विंडो बढ़ाने से मेमोरी दबाव खराब हो सकता है। पहले बड़े आकार के ट्रेस को कैप करें, शोर करने वाले टेनेंट्स को अलग करें, ट्रेस समानता को तोड़े बिना पार्टीशन को विभाजित करें, और सामान्य बेसलाइन को कम करें। फिर क्षमता जोड़ें या देखे गए देर से स्पैन मान के आधार पर विंडो को छोटा करें। यह मापने के लिए एक शैडो नीति चलाएं कि प्रस्तावित परिवर्तन कैसे बनाए रखी गई त्रुटियों, धीमे ट्रेस और पूर्णता को बदलता है।
अनुवर्ती 4: सर्च दो घंटे के लिए बंद है, लेकिन इनजेशन और ऑब्जेक्ट स्टोरेज स्वस्थ हैं। API क्या लौटाता है?
विहित ट्रेस ऑब्जेक्ट्स और टिकाऊ इंडेक्स-परिवर्तन बैकलॉग लिखना जारी रखें। यदि वह पथ उपलब्ध रहता है तो GetTrace ट्रेस-ID निर्देशिका का उपयोग कर सकता है; द्वितीयक सर्च बासी as_of डेटा या एक स्पष्ट अस्थायी-अनुपलब्ध स्थिति की रिपोर्ट करती है। इसे यह रिपोर्ट नहीं करना चाहिए कि एक नया स्वीकृत ट्रेस केवल इसलिए मौजूद नहीं है क्योंकि इसका सारांश अनुक्रमित नहीं है। रिकवरी के बाद, इडेम्पोटेंट रूप से फिर से चलाएं, गणना और अंतराल की तुलना करें, और यदि बैकलॉग दूषित है तो ऑब्जेक्ट्स से इंडेक्स का पुनर्निर्माण करें।
अनुवर्ती 5: आप कैसे साबित करते हैं कि सैंपलिंग ने एक कम-मात्रा वाली सेवा को पूरी तरह से नहीं छिपाया है?
शेष वैश्विक बजट को साझा करने से पहले प्रति-सेवा या प्रति-ऑपरेशन न्यूनतम बेसलाइन बजट बनाए रखें। प्रत्येक रखे गए ट्रेस के साथ संभावना और निर्णय कारण को ट्रैक करें, और ट्रैफ़िक वाली लेकिन कोई बनाए रखा ट्रेस नहीं वाली सेवाओं पर अलर्ट करें। सिंथेटिक कैनरी संभावना से स्वतंत्र पूर्ण पथ को सत्यापित करते हैं। मीट्रिक अनुरोध गणना के साथ ट्रेस-व्युत्पन्न कवरेज की तुलना करें; यदि कोई सेवा अनुरोध प्राप्त करती है लेकिन कोई स्पैन नहीं देती है, तो अनुपलब्ध इंस्ट्रूमेंटेशन, प्रोपेगेशन विफलता, कोटा ड्रॉप, हेड निर्णय, टेल निर्णय और इंडेक्स हानि में अंतर करें।