प्रॉम्प्ट और दायरा
एक बहुभाषी (multilingual) माइक्रोसर्विस प्लेटफ़ॉर्म OpenTracing APIs, वेंडर shims और OpenTelemetry SDKs का उपयोग करता है। मार्च 2026 से, OpenTelemetry विनिर्देश (specification) में नए इम्प्लीमेंटेशन्स के लिए OpenTracing कम्पैटिबिलिटी प्रदान करना अनिवार्य नहीं रह गया है, जबकि ट्रांज़िशन के दौरान मौजूदा shims की आवश्यकता बनी हुई है। एक ऐसा माइग्रेशन डिज़ाइन करें जो ट्रेसेस को सुरक्षित रखे, लागत को नियंत्रित करे और किसी एकल सर्विस को रोलबैक करने की अनुमति दे।
इंटरव्यूअर क्या जांच रहा है
इंटरव्यूअर यह परख रहा है कि क्या आप API, डेटा-सेमेंटिक और बैकएंड-प्रोटोकॉल कम्पैटिबिलिटी को अलग-अलग समझते हैं; ट्रेस और स्पैन एट्रिब्यूट मैपिंग, कॉन्टेक्स्ट प्रोपेगेशन, सैंपलिंग निरंतरता, डुअल-राइट लागत और वेंडर लॉक-इन को कैसे संभालते हैं। एक मजबूत उत्तर केवल डिपेंडेंसीज बदलने के बजाय माइग्रेशन का क्रम, स्वीकृति मेट्रिक्स और विफलता अलगाव (failure isolation) प्रदान करता है।
पहले स्पष्ट करने योग्य प्रश्न
- कौन सी भाषाएं और फ्रेमवर्क OpenTracing का उपयोग करते हैं, और क्या shims ने इसके सेमेंटिक्स को बदल दिया है?
- क्या बैकएंड OTLP स्वीकार करता है, और क्या ऐतिहासिक डेटा और क्वेरी डायमेंशन्स स्थिर रहने चाहिए?
- क्या प्राथमिकता शून्य डेटा हानि, कम ओवरहेड, एकीकृत सेमेंटिक्स या वेंडर प्रतिस्थापन क्षमता है?
- क्या अस्थायी डुअल राइटिंग की अनुमति है, और सैंपलिंग तथा प्रति-सर्विस लागत सीमाएं क्या हैं?
30-सेकंड का उत्तर
“मैं माइग्रेशन को API, सेमेंटिक्स, ट्रांसपोर्ट और ऑपरेशन्स में विभाजित करूँगा। सबसे पहले नई OpenTracing डिपेंडेंसीज को फ्रीज़ करूँगा और shims, प्रोपेगेशन फॉर्मेट्स तथा प्रमुख एट्रिब्यूट्स की सूची तैयार करूँगा। एक सर्विस में, shim को कम्पैटिबिलिटी एंट्री पॉइंट के रूप में बनाए रखते हुए नेटिव OpenTelemetry जोड़ूँगा, फिर एक ही कॉन्टेक्स्ट और सैंपलिंग निर्णय के साथ उनकी तुलना करूँगा। ट्रेस निरंतरता, एरर रेट, एट्रिब्यूट कवरेज, लेटेंसी और लागत द्वारा निर्धारित सीमाओं को पूरा करने के बाद, भाषा और डिपेंडेंसी टोपोलॉजी के आधार पर इसका विस्तार करूँगा। किसी विफलता की स्थिति में साझा Collector प्लेटफ़ॉर्म के बजाय केवल संबंधित सर्विस के एंट्री या एक्सपोर्ट रूट को रोलबैक किया जाएगा।”
चरण-दर-चरण समाधान
1. कॉल्स और सेमेंटिक्स की सूची बनाएं
सर्विस, भाषा, OpenTracing पैकेज, shim वर्ज़न, प्रोपेगेशन फॉर्मेट और एक्सपोर्ट पाथ की एक विस्तृत सूची बनाएं। कस्टम टैग्स, लॉग्स, बैगेज और स्पैन नामों को चिह्नित करें, फिर प्रत्येक को OpenTelemetry एट्रिब्यूट्स, इवेंट्स, लिंक्स और बैगेज में मैप करें। सबसे अधिक कस्टमाइज़ किए गए ट्रेसर के बजाय स्पष्ट सीमाओं वाली स्टेटलेस सर्विसेज से शुरुआत करें।
2. कम्पैटिबिलिटी सीमा को परिभाषित करें
एप्लिकेशन कोड को नेटिव OpenTelemetry ट्रेसर्स की ओर ले जाएं। उन लाइब्रेरीज़ के लिए shim बनाए रखें जिन्हें अभी बदला नहीं जा सकता, लेकिन नए shim फीचर्स को फ्रीज़ कर दें। इनग्रेस (ingress), एसिंक्रोनस क्यू, RPC और बैच सीमाओं पर कॉन्टेक्स्ट प्रोपेगेशन सुसंगत रहना चाहिए; समान API नाम समतुल्य सैंपलिंग या पैरेंट संबंधों को साबित नहीं करते हैं।
3. नियंत्रित डुअल राइटिंग लागू करें
बिजनेस कोड में दो स्पैन सेट उत्पन्न करने के बजाय SDK या Collector एक्सपोर्ट सीमा पर नियंत्रित रूटिंग को प्राथमिकता दें। यदि डुअल राइटिंग आवश्यक है, तो प्रति-सर्विस सैंपलिंग कैप्स, क्यू सीमाएं, पुनः प्रयास (retries) और ड्रॉप मेट्रिक्स सेट करें, जिससे “बिजनेस स्पैन नहीं बना” और “एक्सपोर्ट विफल रहा” के बीच अंतर स्पष्ट हो सके। डुअल-राइट विंडो के लिए एक स्पष्ट निकास शर्त (exit condition) निर्धारित करें।
4. बैकएंड को क्वेरी योग्य बनाए रखें
माइग्रेशन के दौरान सर्विस, ऑपरेशन, स्टेटस और महत्वपूर्ण बिजनेस एट्रिब्यूट्स के नामों को फ्रीज़ रखें। पुराने और नए दोनों पाथ्स के माध्यम से समान अनुरोध सेट भेजें और ट्रेस काउंट, पैरेंट-चाइल्ड संबंध, एरर स्टेटस, लेटेंसी पर्सेंटाइल और एक्सेम्पलर्स (exemplars) की तुलना करें। यदि बैकएंड क्वेरी सेमेंटिक्स बदलते हैं, तो डिफ़ॉल्ट व्यू बदलने से पहले एक एडेप्टर या दो डैशबोर्ड वर्ज़न प्रदान करें।
5. लागत सुरक्षा के साथ कैनरी रोलआउट
भाषा, टीम या डिपेंडेंसी ट्री के आधार पर बैचों में माइग्रेट करें। एंड-टू-एंड ट्रेस निरंतरता, स्पैन हानि, Collector क्यू, CPU और मेमोरी, डेटा इग्रेस (egress) और प्रति मिलियन स्पैन लागत को ट्रैक करें। जब कोई सीमा विफल हो जाती है, तो पहले से माइग्रेट की गई सर्विसेज और कच्चे साक्ष्यों को सुरक्षित रखते हुए नई सर्विसेज को जोड़ना बंद करें।
6. लाइफसाइकिल नियंत्रण के साथ रोलबैक करें
प्रत्येक सर्विस के लिए एक ट्रेसर इनिशियलाइज़ेशन स्विच, डिपेंडेंसी वर्ज़न और कॉन्फ़िगरेशन स्नैपशॉट बनाए रखें। साझा Collector संसाधनों को हटाने के बजाय उस विशिष्ट सर्विस के एंट्री या एक्सपोर्ट रूट को बदलकर रोलबैक करें। shim को हटाने से पहले, सत्यापित करें कि कोई भी डाउनस्ट्रीम लाइब्रेरी अभी भी ग्लोबल ट्रेसर के माध्यम से कॉन्टेक्स्ट प्राप्त नहीं कर रही है, और एक निश्चित समय तक कम्पैटिबिलिटी मॉनिटरिंग जारी रखें।
मॉडल उत्तर
मैं नए OpenTracing कम्पैटिबिलिटी कार्य को फ्रीज़ करूँगा और कॉल्स, सेमेंटिक्स, प्रोपेगेशन और एक्सपोर्ट्स की सूची बनाऊँगा। नेटिव OpenTelemetry APIs को सर्विस-दर-सर्विस लागू किया जाएगा; अपरिवर्तनीय लाइब्रेरीज़ shims के माध्यम से चलती रहेंगी, जिनमें कॉन्ट्रैक्ट टेस्ट्स द्वारा Context, सैंपलिंग और एट्रिब्यूट मैपिंग को स्थिर रखा जाएगा। डुअल राइटिंग को SDK या एक्सपोर्ट सीमा पर सीमित किया जाएगा, जिसमें निरंतरता, एट्रिब्यूट कवरेज, Collector क्यू, लेटेंसी और लागत के मेट्रिक्स शामिल होंगे। भाषा और डिपेंडेंसी टोपोलॉजी के आधार पर कैनरी डिप्लॉयमेंट किया जाएगा। विफलता पर, कॉन्फ़िगरेशन, इवेंट्स और तुलनात्मक डेटा को सुरक्षित रखते हुए किसी एकल सर्विस के नए रूट को डिसेबल करके उसके पुराने एक्सपोर्ट को रीस्टोर किया जाएगा; shims को केवल तभी हटाया जाएगा जब सभी सर्विसेज स्थिर हो जाएं।
सामान्य गलतियाँ
- केवल इम्पोर्ट्स को बदलना → पैरेंट, बैगेज या एट्रिब्यूट सेमेंटिक्स बदल जाते हैं → प्रोपेगेशन और सेमेंटिक कॉन्ट्रैक्ट्स का परीक्षण करें।
- प्रत्येक बिजनेस कॉल में डुअल राइटिंग करना → स्पैन वॉल्यूम और लागत अत्यधिक बढ़ जाती है → SDK या एक्सपोर्ट सीमा पर रूटिंग को केंद्रीकृत और सीमित करें।
- केवल Collector की सफलता की निगरानी करना → एप्लिकेशन पहले ही स्पैन खो चुका होता है → क्रिएशन, कतारबद्धता (queueing), एक्सपोर्ट और बैकएंड मेट्रिक्स को अलग करें।
- सभी सर्विसेज को एक साथ माइग्रेट करना → प्रभाव का दायरा (blast radius) बहुत बड़ा हो जाता है → भाषा और डिपेंडेंसी टोपोलॉजी के आधार पर कैनरी का उपयोग करें।
- shims को तुरंत हटाना → एक असंशोधित लाइब्रेरी शुरू होने में विफल हो जाती है → नई डिपेंडेंसीज को फ्रीज़ करें और सत्यापित करें कि सभी संदर्भ समाप्त हो चुके हैं।
फॉलो-अप प्रश्न और उत्तर
सभी टीमों को एक साथ स्विच करने की आवश्यकता क्यों नहीं है?
साझा लाइब्रेरीज़, रिलीज़ शेड्यूल और भाषा SDKs अलग-अलग होते हैं, इसलिए एक साथ किया गया बदलाव विफलता के बड़े दायरे (blast radius) का कारण बनता है। लेयर्ड कम्पैटिबिलिटी सर्विसेज को चालू रखती है जबकि नेटिव APIs नए कार्यों का मुख्य केंद्र बन जाते हैं।
आप कैसे साबित करेंगे कि ट्रेसेस का नुकसान नहीं हुआ?
दोहराए जा सकने वाले अनुरोधों में एक स्थिर पहचानकर्ता (identifier) इंजेक्ट करें, इनग्रेस, सर्विस-टू-सर्विस प्रोपेगेशन, Collector प्राप्ति और बैकएंड क्वेरी काउंट की तुलना करें, फिर पैरेंट लिंक्स, स्टेटस और प्रमुख एट्रिब्यूट्स की सैंपल-जांच करें।
क्या डुअल राइटिंग से सैंपलिंग बदल सकती है?
हाँ। दो ट्रेसर्स में स्वतंत्र रूप से सैंपलिंग करने से ट्रेस टूट सकता है या लागत दोगुनी हो सकती है। साझा कॉन्टेक्स्ट में सैंपलिंग का निर्णय लें और दोनों रूट्स को उस निर्णय को इनहेरिट करने दें।
कम्पैटिबिलिटी लेयर को कब हटाया जा सकता है?
जब डिपेंडेंसी स्कैन में कोई OpenTracing एंट्री पॉइंट न मिले, कॉन्ट्रैक्ट टेस्ट प्रोपेगेशन और सेमेंटिक्स को कवर कर लें, कैनरी मेट्रिक्स अपनी शर्तों को पूरा करें और रिटेंशन विंडो के दौरान कोई रोलबैक न हो। इसके बाद shim को हटाएं और एक ऑडिट रिकॉर्ड सुरक्षित रखें।