डेटा और ऑब्जर्वेबिलिटी इंटरव्यू: बैच के लिए OpenTelemetry Span Links का उपयोग क्यों करें?

प्रॉम्प्ट और संदर्भ

एक वर्कर कतार (queue) से 100 इवेंट्स कंज्यूम करता है और एग्रीगेशन के बाद एक डाउनस्ट्रीम API कॉल करता है। प्रत्येक इवेंट एक अलग Trace से संबंधित हो सकता है, और वर्कर को शेड्यूलर या रीप्ले द्वारा भी ट्रिगर किया जा सकता है। ट्रेस को इस तरह मॉडल करें कि प्रत्येक सोर्स खोजने योग्य बना रहे, बिना यह दिखावा किए कि असंबंधित अनुरोध एक ही पैरेंट-चाइल्ड ट्री बनाते हैं।

OpenTelemetry Spans को ऐसे ऑपरेशन्स के रूप में वर्णित करता है जो एक ट्री बना सकते हैं और प्रत्येक Span में शून्य या अधिक Links रखने की अनुमति देता है। इसका अवलोकन कई इनकमिंग Spans द्वारा शुरू की गई बैच प्रोसेसिंग को Links के एक विशिष्ट उपयोग के मामले (use case) के रूप में नामित करता है।

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

उम्मीदवार को यह पता होना चाहिए कि parent एक वर्तमान संदर्भ (context) है जबकि एक Link बिना पैरेंटेज के संबंधित कार्य-कारण संबंध का प्रतिनिधित्व करता है। उन्हें लिंक काउंट, सैंपलिंग और उच्च-कार्डिनैलिटी वाले एट्रिब्यूट्स को नियंत्रित करना चाहिए, साथ ही उपयोगी मेट्रिक्स और लॉग सहसंबंध (correlation) को बनाए रखना चाहिए।

पहले पूछे जाने वाले स्पष्टीकरण प्रश्न

क्या एक बैच में कई टेनेंट्स (tenants), सुरक्षा स्तर या व्यावसायिक प्रकार शामिल हो सकते हैं?
क्या डाउनस्ट्रीम कॉल एक एग्रीगेटेड ऑपरेशन है, या यह प्रति-इवेंट रह सकता है?
क्या लक्ष्य प्रति-इवेंट जवाबदेही, लेटेंसी विश्लेषण, या बैच थ्रूपुट है?
क्या सैंपलिंग का निर्णय इनग्रेस (ingress) पर लिया जाता है, या वर्कर चयनित सोर्स संदर्भों को बनाए रख सकता है?
क्या Link एट्रिब्यूट्स में इवेंट ID, टेनेंट ID, या संवेदनशील फ़ील्ड शामिल हो सकते हैं?

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

"बैच-प्रोसेसिंग Span वर्कर या शेड्यूलर संदर्भ को अपने parent के रूप में उपयोग करता है। 100 इनकमिंग SpanContexts Links बन जाते हैं क्योंकि उन्होंने एक पैरेंट-चाइल्ड चेन बनाए बिना संयुक्त रूप से एक बैच ऑपरेशन का कारण बना। मैं केवल आवश्यक लो-कार्डिनैलिटी एट्रिब्यूट्स रखता हूँ, एक लिंक सीमा लागू करता हूँ, और ट्रंकेशन की गणना करता हूँ। बैच मेट्रिक्स आकार, कतार प्रतीक्षा, प्रोसेसिंग, डाउनस्ट्रीम लेटेंसी, विफलताएं और रीट्राई को कवर करते हैं; लॉग बैच ID और इवेंट हैश के साथ सहसंबद्ध होते हैं। संवेदनशील टेनेंट फ़ील्ड को फ़िल्टर किया जाता है, और विफल या रीप्ले किए गए बैचों में एक सैंपलिंग सुरक्षा पथ होता है।"

चरण-दर-चरण गहन विश्लेषण

चरण 1: parent को Link से अलग करें

एक parent बताता है कि वर्तमान ऑपरेशन किस एकल Span को जारी रखता है, जिससे एक Trace ट्री बनता है और उसका TraceId इनहेरिट होता है। एक Link उसी या किसी अन्य Trace से संबंधित एक SpanContext रिकॉर्ड करता है। जब किसी बैच में सोर्स समकक्ष (peers) होते हैं, तो पहले इवेंट को parent के रूप में चुनना एक गलत ट्री बनाता है।

text

Batch-processing Span
  parent: worker / scheduler context
  links: event-1 SpanContext ... event-100 SpanContext

चरण 2: सीमा के पार SpanContext को सुरक्षित रखें

मैसेज हेडर से TraceContext निकालें, इसके प्रारूप और सैंपलिंग फ़्लैग को मान्य करें, और एक Link बनाएं। संपूर्ण मैसेज, यूजर इनपुट, या रॉ टोकन को Link एट्रिब्यूट्स में न डालें। किसी गुम संदर्भ के लिए, TraceId का आविष्कार करने के बजाय "कोई सोर्स संदर्भ नहीं" की गणना करें।

चरण 3: लिंक का आकार और लागत सीमित करें

एक सौ लिंक केवल उदाहरण सीमा है; प्रोडक्शन बैच बड़े हो सकते हैं। SDK लिंक काउंट सीमा या एप्लिकेशन कैप कॉन्फ़िगर करें, प्रतिनिधि त्रुटि, रीट्राई, रीप्ले, या प्राथमिकता-टेनेंट सोर्स को बनाए रखें, और ड्रॉप किए गए लिंक काउंट को रिकॉर्ड करें। ट्रंकेशन बैच मेट्रिक्स और लॉग में दृश्यमान होना चाहिए।

चरण 4: बैच Span लाइफ़साइकिल को परिभाषित करें

Span बैच प्रतीक्षा, डीसीरियलाइज़ेशन, एग्रीगेशन, डाउनस्ट्रीम कॉल और कमिट को कवर करता है। फेज़ इवेंट्स या मेट्रिक्स जोड़ें। प्रत्येक निर्मित Span सफलता, विफलता, रद्दीकरण (cancellation), या आंशिक कमिट पर समाप्त होना चाहिए। एकल धीमा इवेंट बैच की फेज़ सीमाओं को छिपाना नहीं चाहिए।

चरण 5: सैंपलिंग और विफलताओं को निदान योग्य बनाएं

इनग्रेस सैंपलिंग सोर्स Traces को छोड़ सकती है, इसलिए वर्कर को विफलताओं, रीट्राई, डेड लेटर्स और मैनुअल रीप्ले के लिए एक सुरक्षा नीति की आवश्यकता होती है। Span निर्माण के समय मौजूद Links सैंपलिंग को प्रभावित कर सकते हैं; बाद में जोड़े गए Links ऐसा नहीं कर सकते। उस क्रम और फ़ॉलबैक को स्पष्ट करें।

चरण 6: ट्रेस, मेट्रिक्स और लॉग को अलग-अलग कार्य सौंपें

ट्रेस एक बैच के कार्य-कारण संबंध की व्याख्या करते हैं। मेट्रिक्स बैच आकार, कतार प्रतीक्षा, प्रोसेसिंग लेटेंसी, सफलता/विफलता और ट्रंकेशन ले जाते हैं। लॉग एक नियंत्रित नमूने का पता लगाने के लिए बैच ID, इवेंट हैश और रीप्ले ID का उपयोग करते हैं। इवेंट ID का उपयोग अनबाउंड मेट्रिक लेबल के रूप में न करें।

चरण 7: टेनेंट्स और गोपनीयता को अलग करें

मल्टी-टेनेंट बैचों के लिए, Links और लॉग में अपरिवर्तनीय हैश या आंतरिक संदर्भों का उपयोग करें, और निर्यात करने से पहले एट्रिब्यूट्स को फ़िल्टर करें। यदि सुरक्षा स्तरों को मिश्रित नहीं किया जा सकता है, तो बैच को टेनेंट या अनुमति के अनुसार विभाजित करें ताकि कम-विशेषाधिकार वाला पाठक किसी अन्य टेनेंट के संदर्भ को पार न कर सके।

चरण 8: प्रश्नों और विफलताओं को सत्यापित करें

एकल सोर्स, मिश्रित Traces, अनुपलब्ध संदर्भ, लिंक ओवरफ़्लो, सैंपलिंग हानि, डाउनस्ट्रीम रीट्राई, आंशिक विफलता, डेड लेटर और रीप्ले का परीक्षण करें। सत्यापित करें कि एक बैच Span बनाए रखे गए सोर्स Traces पर जाता है और मेट्रिक्स ट्रंकेटेड या अनसैंपल्ड बैचों की पहचान करते हैं।

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

"बैच Span वर्कर या शेड्यूलर को parent के रूप में उपयोग करता है, और प्रत्येक मैसेज SpanContext एक Link है। यह इस तथ्य को सुरक्षित रखता है कि 100 इवेंट्स ने पैरेंट-चाइल्ड ट्री का आविष्कार किए बिना संयुक्त रूप से एक डाउनस्ट्रीम कॉल का कारण बना। मैं लिंक्स को सीमित करता हूँ और ड्रॉप्स की गणना करता हूँ, टेनेंट और संवेदनशील एट्रिब्यूट्स को फ़िल्टर करता हूँ, और बैच आकार, कतार प्रतीक्षा, डाउनस्ट्रीम लेटेंसी, विफलताओं और रीट्राई के लिए मेट्रिक्स का उपयोग करता हूँ। लॉग बैच और रीप्ले IDs के साथ सहसंबद्ध होते हैं, और विफल बैचों को सैंपलिंग सुरक्षा प्राप्त होती है। परीक्षणों में अनुपलब्ध संदर्भ, मिश्रित Traces, ओवरफ़्लो और रीप्ले शामिल हैं।"

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

पहले मैसेज को parent के रूप में चुनना → गलत कार्य-कारण संबंध → एक सामान्य वर्कर parent और सोर्स के लिए Links का उपयोग करें।
पूरे मैसेज को Link में डालना → गोपनीयता और लागत का नुकसान → केवल आवश्यक सैनिटाइज़्ड लो-कार्डिनैलिटी फ़ील्ड ही रखें।
बिना किसी सीमा के Links जोड़ना → अनबाउंड Span और निर्यात लागत → कैप लगाएं और ट्रंकेशन को मापें।
केवल सफलता पर Span को समाप्त करना → विफलताएं और रद्दीकरण Spans को खुला छोड़ देते हैं → finally या स्कोप में समाप्त करें।
इवेंट ID को मेट्रिक लेबल के रूप में उपयोग करना → कार्डिनैलिटी विस्फोट → विवरण लॉग या ट्रेस में रखें।
यह मान लेना कि देर से जोड़े गए Links हमेशा सैंपलिंग को प्रभावित करते हैं → महत्वपूर्ण सोर्स गायब हो जाते हैं → Span निर्माण से पहले सैंपलिंग संदर्भ तैयार करें।

फॉलो-अप प्रश्न और मजबूत प्रतिक्रियाएं

फॉलो-अप 1: क्या एक-मैसेज वाले बैच को Link की आवश्यकता होती है?

यह उस मैसेज संदर्भ को parent के रूप में उपयोग कर सकता है। यदि वर्कर का एक स्वतंत्र लाइफ़टाइम है, तो एक वर्कर parent और एक Link भी मान्य है; इस आधार पर चुनें कि क्या बैच एक प्रत्यक्ष चाइल्ड ऑपरेशन है।

फॉलो-अप 2: क्या Links विभिन्न Traces को मर्ज करते हैं?

नहीं। वे संबद्धता व्यक्त करते हैं और प्रत्येक TraceId को सुरक्षित रखते हैं। क्वेरी सिस्टम को Link से सोर्स Trace तक नेविगेशन प्रदान करना चाहिए।

फॉलो-अप 3: कौन से सोर्स ट्रंकेशन से बचते हैं?

त्रुटियों, रीट्राई, रीप्ले, प्राथमिकता वाले टेनेंट्स, या नियतात्मक (deterministic) नमूनों को प्राथमिकता दें; कुल और ड्रॉप की गई संख्या को रिकॉर्ड करें। चुपचाप पहले N को रखने से पूर्वाग्रह आता है।

फॉलो-अप 4: आप एक विफल बैच का निदान कैसे करते हैं?

विफलता और डेड-लेटर रीप्ले को स्वतंत्र बैच/रीप्ले IDs दें, नियंत्रित त्रुटि-सोर्स Links या सारांश बनाए रखें, और मेट्रिक्स में विफलता का प्रकार डालें।

फॉलो-अप 5: क्या एक Link में tenant.id हो सकता है?

केवल एक्सेस, कार्डिनैलिटी और प्राइवेसी की समीक्षा के बाद। क्रॉस-टेनेंट निर्यात आमतौर पर इसे हैश या हटा देता है, और इसे उच्च-मात्रा वाला मेट्रिक लेबल नहीं बनना चाहिए।