प्रॉम्प्ट और दायरा
कॉन्टेक्स्ट प्रोपेगेशन किसी रिक्वेस्ट को सर्विस सीमाओं के पार समझने योग्य बना सकता है, लेकिन हर डाउनस्ट्रीम सर्विस प्रोपेगेट किए गए मानों को प्राप्त और लॉग कर सकती है। OpenTelemetry बैगेज (Baggage) को ट्रेस कॉन्टेक्स्ट के निकट स्थित नाम/मान (name/value) कॉन्टेक्स्ट के रूप में दस्तावेज़ित करता है और सुरक्षा प्रभावों के बारे में चेतावनी देता है। मूल कौशल डिस्ट्रीब्यूटेड-बाउंड्री डिज़ाइन है, इसलिए यह एक system-design प्रश्न है।
इंटरव्यूअर्स क्या आंकते हैं
मजबूत उत्तर ट्रेस कॉन्टेक्स्ट को एप्लिकेशन मेटाडेटा से अलग करते हैं, फ़ील्ड्स के लिए एक अनुमति सूची (allowlist) और स्वामित्व (ownership) परिभाषित करते हैं, और संवेदनशील मानों को अविश्वसनीय सीमाओं को पार करने से रोकते हैं। वे हेडर साइज़, विहित एन्कोडिंग (canonical encoding), सैंपलिंग, पुनः प्रयास (retries), एसिंक्रोनस संदेशों, और कॉन्टेक्स्ट विकृत या गायब होने पर क्या होता है, इसे कवर करते हैं। वे ऐसे मेट्रिक्स भी शामिल करते हैं जो साबित करते हैं कि प्रोपेगेशन इसे अनियंत्रित डेटा चैनल में बदले बिना उपयोगी है।
पहले स्पष्ट करने योग्य प्रश्न
- कौन से प्रोटोकॉल कॉन्टेक्स्ट ले जाते हैं: HTTP, gRPC, कतारें (queues), या शेड्यूल्ड जॉब्स?
- कौन से फ़ील्ड डायग्नोस्टिक हैं, कौन से व्यवहार को प्रभावित करते हैं, और प्रत्येक फ़ील्ड का स्वामी कौन है?
- टेनेंट्स, क्षेत्रों (regions) और थर्ड-पार्टी सेवाओं के बीच क्या ट्रस्ट बाउंड्रीज़ मौजूद हैं?
- क्या मान लॉग्स, मेट्रिक्स लेबल्स, या केवल ट्रेसेस में अनुमत हैं?
- अधिकतम हेडर साइज़, लेटेंसी और उपलब्धता बजट क्या हैं?
- क्या विकृत (malformed) कॉन्टेक्स्ट को अस्वीकार (reject) किया जाना चाहिए, हटा दिया (stripped) जाना चाहिए, या एक नए रूट के साथ बदला जाना चाहिए?
30-सेकंड उत्तर फ्रेमवर्क
"मैं अलग ट्रेस कॉन्टेक्स्ट और स्वीकृत बिज़नेस फ़ील्ड्स के साथ एक छोटा वर्ज़न युक्त एनवलप (envelope) परिभाषित करूँगा। प्रत्येक सीमा पर, एक पॉलिसी लाइब्रेरी नामों, साइज़, एन्कोडिंग, टेनेंट स्कोप और गंतव्य ट्रस्ट को मान्य करती है; यह अस्वीकृत मानों को हटा देती है या अस्वीकार कर देती है और कभी भी सीक्रेट्स को आगे नहीं भेजती है। प्रोपेगेशन को सिंक्रोनस और एसिंक्रोनस दोनों किनारों के लिए काम करना चाहिए, जिसमें सीमित हेडर्स और स्पष्ट मिसिंग-कॉन्टेक्स्ट व्यवहार हो। मैं एक्सट्रैक्शन विफलताओं, ट्रंकेशन, प्रोपेगेशन कवरेज, क्रॉस-टेनेंट उल्लंघनों और ट्रेस जॉइन दर (trace join rate) को मापूँगा।"
चरण-दर-चरण उत्तर
चरण 1: कॉन्टेक्स्ट अनुबंध (contract) परिभाषित करें
स्वामी, प्रकार, अधिकतम लंबाई, संवेदनशीलता, प्रतिधारण (retention) और अनुमत गंतव्यों के साथ फ़ील्ड्स की एक रजिस्ट्री बनाएं। ट्रेस पहचानकर्ताओं को ट्रेसिंग प्रोटोकॉल में रखें और केवल स्वीकृत बिज़नेस मेटाडेटा को एक अलग बैगेज-जैसे कैरियर में रखें। एनवलप को वर्ज़न करें ताकि उपभोक्ता अज्ञात महत्वपूर्ण फ़ील्ड्स को अस्वीकार कर सकें।
चरण 2: सीमा नीति (boundary policy) लागू करें
एक साझा मिडलवेयर या साइडकार पॉलिसी का उपयोग करें जो कैरियर को पार्स करती है, एन्कोडिंग और साइज़ को मान्य करती है, टेनेंट और ट्रस्ट ज़ोन की जाँच करती है, और एक सैनिटाइज़्ड कैरियर उत्सर्जित करती है। मनमाने इनबाउंड हेडर्स को आउटबाउंड रिक्वेस्ट्स में कभी कॉपी न करें। जब तक कोई स्पष्ट नीति अग्रेषण की अनुमति न दे, थर्ड-पार्टी और क्रॉस-टेनेंट कॉल्स को नए ट्रस्ट रूट्स के रूप में मानें।
चरण 3: ट्रांसपोर्ट और पुनः प्रयासों (retries) को संभालें
HTTP, gRPC मेटाडेटा और संदेश विशेषताओं के लिए समतुल्य कैरियर्स को परिभाषित करें। केवल एक एसिंक्रोनस जॉब को सहसंबंधित करने के लिए आवश्यक फ़ील्ड्स को ही सुरक्षित रखें; कतारों में सीक्रेट्स को सीरियलाइज़ न करें। पुनः प्रयासों पर, मूल ट्रेस संबंध को बनाए रखें और बिना पुन: सत्यापन के डुप्लिकेट या पुराने बिज़नेस निर्णयों पर भरोसा किए जाने से रोकें।
चरण 4: विफलता व्यवहार डिज़ाइन करें
एंडपॉइंट जोखिम के अनुसार विकृत या बड़े आकार के कॉन्टेक्स्ट को हटा दिया जाना चाहिए या अस्वीकार कर दिया जाना चाहिए, जबकि सुरक्षित होने पर रिक्वेस्ट स्वयं एक नए स्थानीय ट्रेस रूट के साथ ऑब्जर्वेबल बनी रहती है। कारण-कोडित (reason-coded) काउंटर्स को प्रदर्शित करें, रॉ वैल्यूज़ को नहीं। ऑपरेटरों के लिए पॉलिसी वर्ज़न और प्रवर्तन परिणाम को दृश्यमान बनाएं।
चरण 5: संचालन करें और मूल्य सिद्ध करें
ट्रेस जॉइन दर, एक्सट्रैक्शन और इंजेक्शन विफलताएं, जोड़े गए बाइट्स, ट्रंकेशन, पॉलिसी रिजेक्ट्स, क्रॉस-बाउंड्री उल्लंघन और कतार सीरियलाइज़ेशन त्रुटियों को ट्रैक करें। सुरक्षित रूप से सैंपल लें और असीमित उच्च-कार्डिनैलिटी मेट्रिक लेबलों से बचें। प्रत्येक समर्थित प्रोटोकॉल के लिए अनुबंध परीक्षण जोड़ें और अस्वीकृति लागू करने से पहले एक कैनरी पॉलिसी रोलआउट करें।
मॉडल उत्तर
"मैं प्रोपेगेट किए गए कॉन्टेक्स्ट को एक अविश्वसनीय डेटा चैनल मानूँगा। एक वर्ज़न युक्त रजिस्ट्री यह परिभाषित करती है कि कौन से डायग्नोस्टिक और बिज़नेस फ़ील्ड्स जा सकते हैं, उनकी संवेदनशीलता और साइज़ क्या है। मिडलवेयर प्रत्येक हॉप को मान्य और सैनिटाइज़ करता है, जिसमें थर्ड-पार्टी और क्रॉस-टेनेंट कॉल्स के लिए सख्त नियम होते हैं; सीक्रेट्स कभी भी कैरियर्स या कतारों में प्रवेश नहीं करते हैं। ट्रेस कॉन्टेक्स्ट बिज़नेस बैगेज से अलग रहता है। मैं HTTP, gRPC और एसिंक्रोनस एट्रिब्यूट्स का समर्थन करूँगा, स्ट्रिपिंग बनाम रिजेक्शन को परिभाषित करूँगा, और जॉइन रेट, पॉलिसी विफलताओं, बाइट्स और उल्लंघनों को मापूँगा। एक कैनरी रोलआउट और कारण-कोडित मेट्रिक्स हमें ऑब्जर्वेबिलिटी खोए बिना पॉलिसी को कड़ा करने की अनुमति देते हैं।"
सामान्य गलतियाँ
- हर इनबाउंड हेडर को आगे भेजना → अविश्वसनीय डेटा सीमाओं को पार करता है → अनुमति सूची (allowlist) और सैनिटाइज़र का उपयोग करें।
- बैगेज में टोकन या PII डालना → डाउनस्ट्रीम लॉग्स और सेवाएँ उन्हें उजागर कर सकती हैं → संवेदनशील डेटा को बाहर रखें।
- बैगेज को मेट्रिक लेबल्स के रूप में उपयोग करना → कार्डिनैलिटी और लागत अत्यधिक बढ़ जाती है → सीमित कारण कोड और आयाम रिकॉर्ड करें।
- कतारों और पुनः प्रयासों को अनदेखा करना → एसिंक्रोनस कार्य पुराने कॉन्टेक्स्ट को खो देता है या उस पर भरोसा करता है → ट्रांसपोर्ट-विशिष्ट अनुबंध परिभाषित करें और पुन: सत्यापित करें।
- प्रत्येक विकृत रिक्वेस्ट को अस्वीकार करना → ऑब्जर्वेबिलिटी और उपलब्धता प्रभावित होती है → एंडपॉइंट जोखिम के आधार पर स्ट्रिपिंग या रिजेक्शन चुनें।
- कोई साइज़ बजट न होना → हेडर्स प्रॉक्सी विफलता का कारण बनते हैं → प्रत्येक फ़ील्ड और कुल कैरियर की सीमा तय करें।
अनुवर्ती प्रश्न (Follow-up questions)
अनुवर्ती 1: क्या टेनेंट आईडी को प्रोपेगेट किया जाना चाहिए?
केवल तभी जब गंतव्य उस टेनेंट के लिए अधिकृत हो और मान को प्रमाणित पहचान के विरुद्ध मान्य किया गया हो। यह अपने आप में एक प्राधिकारी (authority) नहीं बनना चाहिए।
अनुवर्ती 2: ट्रेस कॉन्टेक्स्ट और बैगेज में क्या अंतर है?
ट्रेस कॉन्टेक्स्ट स्पैन (spans) और प्रोपेगेशन स्थिति को जोड़ता है। बैगेज एप्लिकेशन-परिभाषित नाम/मान डेटा ले जाता है और इसलिए इसके लिए सख्त संवेदनशीलता, स्वामित्व और गंतव्य नीति की आवश्यकता होती है।
अनुवर्ती 3: आप हेडर की वृद्धि को कैसे रोकते हैं?
प्रति-फ़ील्ड और कुल बजट निर्धारित करें, कारण-कोडित मेट्रिक्स के साथ अस्वीकार या ट्रंकेट करें, और बड़ा कॉन्टेक्स्ट अपरिहार्य होने पर सर्वर-साइड स्थिति के सीमित संदर्भ को प्राथमिकता दें।
अनुवर्ती 4: अविश्वसनीय सीमा पर क्या होता है?
गैर-स्वीकृत फ़ील्ड्स को हटा दें, केवल नीति द्वारा अनुमत ट्रेस जानकारी बनाएं या जारी रखें, और संवेदनशील मान को रिकॉर्ड किए बिना पॉलिसी निर्णय को लॉग करें।