प्रॉम्प्ट और उपयोग के मामले
एक HTTP अनुरोध एसिंक्रोनस प्रोसेसिंग के लिए एक संदेश प्रकाशित करता है। आप पुनः प्रयासों (retries), बैचों और टेनेंट्स में ट्रेस संदर्भ को सुरक्षित रूप से कैसे प्रचारित करते हैं? यह प्रॉम्प्ट बैकएंड, ऑब्जर्वेबिलिटी और मैसेजिंग इंटरव्यू के लिए उपयुक्त है। इसका लक्ष्य अनुरोध संदर्भ को स्थायी प्राधिकरण (authorization) या व्यावसायिक डेटा के रूप में माने बिना निष्पादन सीमाओं के पार कारण-संबंधी सहसंबंध (causal correlation) स्थापित करना है।
साक्षात्कारकर्ता क्या मूल्यांकन करते हैं
- क्या आप
traceparent, वैकल्पिकtracestate, और प्रोपेगेटर्स की सीमाओं को समझते हैं। - क्या प्रोड्यूसर, संदेश-प्रोसेसिंग, और पुनः प्रयास (retry) स्पैन के बीच स्पष्ट मूल (parent) संबंध हैं।
- क्या आप बैच वाले संदेशों, विलंबित उपभोग (delayed consumption), डेड लेटर्स, सैंपलिंग और समाप्ति (expiry) को संभालते हैं।
- क्या आप संवेदनशील बैगेज, क्रॉस-टेनेंट डेटा, और जाली विश्वास संकेतों (forged trust signals) को फैलने से रोकते हैं।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
ट्रांसपोर्ट, संदेश स्थायित्व (durability), बैचिंग और पुनः प्रयास व्यवहार की पुष्टि करें, और यह भी कि क्या उपभोक्ता सेवाओं या ट्रस्ट डोमेन को पार करते हैं। स्पष्ट करें कि क्या वांछित संबंध किसी एक व्यावसायिक ऑपरेशन, एक संदेश या किसी बैच के लिए है। सैंपलिंग, डेटा प्रतिधारण (retention), टेनेंट अलगाव (isolation), और क्या बाहरी प्रोड्यूसर संदर्भ इंजेक्ट कर सकते हैं, इसके बारे में पूछें। अंत में, डेड-लेटर हैंडलिंग को परिभाषित करें और क्या मैन्युअल रीप्ले एक नई ट्रेस शाखा बनाता है।
30-सेकंड उत्तर फ्रेमवर्क
“एंट्री सर्विस प्रोपेगेशन हेडर को निकालती और सत्यापित करती है, फिर संदेश प्रकाशित करते समय न्यूनतम ट्रेस संदर्भ इंजेक्ट करती है। उपभोक्ता इसे निकालता है, एक स्वतंत्र उपभोक्ता स्पैन बनाता है, और पुनः प्रयासों, बैचों और डेड लेटर्स को स्पष्ट रूप से दर्शाता है। ट्रस्ट डोमेन के पार मैं केवल नियंत्रित फ़ील्ड स्वीकार करता हूँ और संवेदनशील बैगेज को हटा देता हूँ; प्लेटफ़ॉर्म नीति सैंपलिंग और समाप्ति को नियंत्रित करती है, जबकि रीप्ले मूल से जुड़े एक नए ट्रेस आईडी का उपयोग करता है।”
चरण-दर-चरण विस्तृत उत्तर
- सीमाएँ परिभाषित करें: HTTP इनग्रेस, संदेश प्रकाशन, ट्रांसपोर्ट और उपभोग को स्पष्ट इंजेक्ट और एक्सट्रैक्ट मालिकों के साथ अलग निष्पादन इकाइयों के रूप में मॉडल करें।
- वाहक (carrier) चुनें: संदेश हेडर या नियंत्रित मेटाडेटा में मानक प्रोपेगेशन प्रारूप रखें; कभी भी पूरे अनुरोध, पहचान टोकन या मनमाने बैगेज को टिकाऊ संदेशों में कॉपी न करें।
- स्पैन मॉडल करें: प्रकाशक (publisher) एक प्रोड्यूसर स्पैन बनाता है और उपभोक्ता एक उपभोक्ता स्पैन बनाता है; बैचों के लिए, यह नाटक करने के बजाय कि बैच एक ही अनुरोध है, संदेश लिंक रिकॉर्ड करें।
- पुनः प्रयास और डेड लेटर्स संभालें: मूल ईवेंट लिंक को सुरक्षित रखते हुए प्रत्येक प्रयास को उसका अपना स्पैन और प्रयास विशेषता (attempt attribute) दें; डेड-लेटर हैंडलिंग और रीप्ले एक नई शाखा बनाते हैं।
- सुरक्षा नियंत्रित करें: क्रॉस-डोमेन इंजेक्शन को प्रतिबंधित करें, उपयोगकर्ता-नियंत्रित फ़ील्ड को सैनिटाइज़ करें, टेनेंट लेबल को अलग करें, और सैंपलिंग, प्रतिधारण और संदर्भ आकार को सीमित करें।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं मानक संदर्भ, व्यावसायिक सहसंबंध और सुरक्षा सीमाओं को अलग रखूँगा। HTTP प्रवेश बिंदु केवल सही प्रारूप वाले प्रोपेगेशन हेडर निकालता है, संस्करण और लंबाई को सत्यापित करता है, और एक सर्वर स्पैन बनाता है। प्रकाशित करते समय, प्रोड्यूसर स्पैन संदेश मेटाडेटा में न्यूनतम ट्रेस संदर्भ इंजेक्ट करता है, जबकि एक अपरिवर्तनीय व्यावसायिक ईवेंट आईडी अलग से संग्रहीत की जाती है क्योंकि दोनों के उद्देश्य अलग-अलग होते हैं। उपभोक्ता मेटाडेटा निकालता है और एक उपभोक्ता स्पैन बनाता है; प्रत्येक डाउनस्ट्रीम ऑपरेशन को अपना चाइल्ड स्पैन मिलता है। किसी बैच को पहले संदेश के तहत एक पैरेंट के रूप में बाध्य नहीं किया जाता है: मैं एक बैच स्पैन और सीमित संदेश लिंक रिकॉर्ड करता हूँ। प्रत्येक पुनः प्रयास ईवेंट आईडी को बनाए रखते हुए एक प्रयास और बैकऑफ़ विशेषता जोड़ता है। एक बार जब कोई संदेश डेड-लेटर कतार में प्रवेश करता है, तो मैन्युअल रीप्ले मूल से जुड़ा एक नया ट्रेस बनाता है ताकि नया निष्पादन इतिहास के रूप में प्रस्तुत न हो सके। किसी अन्य टेनेंट या बाहरी प्रोड्यूसर के बैगेज को डिफ़ॉल्ट रूप से हटा दिया जाता है; केवल प्लेटफ़ॉर्म-अनुमोदित कम-संवेदनशीलता वाले फ़ील्ड ही सीमा पार करते हैं। मैं परीक्षणों और उत्पादन मेट्रिक्स के साथ संदर्भ आकार, निष्कर्षण विफलताओं, संदेश-से-उपभोक्ता सहसंबंध, पुनः प्रयास दृश्यता, और क्रॉस-टेनेंट रिसाव को मान्य करूँगा।
सामान्य गलतियाँ
- किसी ट्रेस आईडी को प्रमाणीकरण क्रेडेंशियल या व्यावसायिक निष्क्रियता (idempotency) कुंजी के रूप में मानना।
- किसी टिकाऊ संदेश में पूरे HTTP हेडर, उपयोगकर्ता इनपुट या टोकन को बनाए रखना।
- बैच उपभोग और सभी पुनः प्रयासों को एक ही स्पैन के तहत रखना, जिससे समय विकृत हो जाए।
- डेड-लेटर रीप्ले के दौरान पुराने ट्रेस का पुन: उपयोग करना, जिससे नया प्रयास छिप जाए।
- ट्रस्ट डोमेन, सैंपलिंग, प्रतिधारण और आकार शासन के बिना केवल SDK कॉल पर चर्चा करना।
अनुवर्ती प्रश्न और उत्तर
यदि किसी संदेश का दस बार पुनः प्रयास किया जाता है, तो कितने स्पैन होने चाहिए?
प्रत्येक वास्तविक प्रोसेसिंग प्रयास के लिए एक अलग स्पैन बनाएं और इसे प्रयास संख्या, ईवेंट आईडी और मूल प्रोड्यूसर ऑपरेशन के साथ लिंक करें। यह दस निष्पादनों को एक के रूप में रिपोर्ट किए बिना प्रति-प्रयास लेटेंसी को उजागर करता है।
आप किसी बैच के लिए पैरेंट कैसे चुनते हैं?
बैच के लिए एक उपभोक्ता स्पैन बनाएं, फिर उन संदेशों के लिए सीमित लिंक या चाइल्ड स्पैन का उपयोग करें जिन्हें विश्लेषण की आवश्यकता है। पहले संदेश को मनमाने ढंग से बैच पैरेंट के रूप में न चुनें; जब सैंपलिंग सीमित हो तो बैच-स्तरीय सांख्यिकी और सहसंबंध आईडी बनाए रखें।
क्या कोई बाहरी ग्राहक tracestate इंजेक्ट कर सकता है?
प्रोटोकॉल-अनुरूप फ़ील्ड को केवल अविश्वसनीय इनपुट के रूप में स्वीकार करें। ट्रस्ट सीमा के पार, लंबाई, कुंजियों और फ़ॉरवर्डिंग को सीमित करें, संवेदनशील या उच्च-कार्डिनैलिटी वाले फ़ील्ड हटाएं, और उन्हें प्रमाणीकरण के लिए कभी उपयोग न करें।
मैन्युअल डेड-लेटर रीप्ले कैसे ट्रेस करने योग्य बना रहता है?
रीप्ले के लिए एक नया ट्रेस और निष्पादन स्पैन बनाएं, जिसमें मूल संदेश आईडी, ऑपरेटर, कारण और रीप्ले बैच रिकॉर्ड हो। अपरिवर्तनीय मूल विफलता को सुरक्षित रखते हुए एक नियंत्रित संबंध के माध्यम से पुराने और नए ट्रेस को लिंक करें।