सिस्टम डिज़ाइन इंटरव्यू: आप बहु-भाषी OpenTelemetry को डिक्लेरेटिव कॉन्फ़िगरेशन में कैसे माइग्रेट करेंगे?

प्रॉम्प्ट और लागू संदर्भ

आपकी कंपनी Java, Go, JavaScript और PHP सेवाएँ चलाती है। वर्तमान में वे पर्यावरण चर और भाषा-विशिष्ट SDK स्टार्टअप फ़्लैग पर निर्भर हैं। प्लेटफ़ॉर्म टीम OTEL_CONFIG_FILE द्वारा चयनित OpenTelemetry डिक्लेरेटिव कॉन्फ़िगरेशन फ़ाइलों को अपनाना चाहती है, जिससे रिसोर्स एट्रिब्यूट्स, सैंपलिंग, एक्सपोर्टर्स और प्रोसेसर्स को धीरे-धीरे मानकीकृत किया जा सके। माइग्रेशन, संगतता, सत्यापन और रोलबैक योजना डिज़ाइन करें।

मार्च 2026 में OpenTelemetry ने डिक्लेरेटिव कॉन्फ़िगरेशन JSON स्कीमा, फ़ाइल YAML निरूपण, इन-मेमरी मॉडल, प्लगइन-कंपोनेंट तंत्र, पार्स/क्रिएट ऑपरेशन्स और OTEL_CONFIG_FILE के स्थिर भागों की घोषणा की; हालाँकि भाषा कार्यान्वयन में अभी भी परिपक्वता का अंतर है। यह इंटरव्यू YAML को याद रखने का नहीं, बल्कि क्रॉस-वर्ज़न कॉन्फ़िगरेशन गवर्नेंस का परीक्षण करता है।

इंटरव्यूअर क्या मूल्यांकन करता है

क्या आप एक स्थिर विनिर्देश (specification) और प्रत्येक भाषा में समान रूप से स्थिर कार्यान्वयन के बीच अंतर करते हैं।
क्या आप स्कीमा, SDK वर्ज़न, एक्सपोर्टर एंडपॉइंट्स और अनुमतियों के लिए एक संगतता मैट्रिक्स (compatibility matrix) परिभाषित कर सकते हैं।
क्या आप पुराने पर्यावरण चरों और नई फ़ाइलों को अंतर्निहित ओवरराइड या डुप्लिकेट एक्सपोर्टर्स बनाने से रोक सकते हैं।
क्या आप ट्रेसेस को खोए बिना, उच्च-कार्डिनैलिटी डेटा बनाए बिना, या लागत बढ़ाए बिना माइग्रेशन की पूर्णता साबित कर सकते हैं।

एक मजबूत उत्तर कॉन्फ़िगरेशन को लिंटिंग, सिंथेटिक परीक्षण, कैनरी, तुलना और त्वरित रोलबैक के साथ एक वर्ज़न वाले आर्टिफ़ैक्ट के रूप में मानता है। एक कमजोर उत्तर केवल यह कहता है कि "सब कुछ YAML में डाल दें।"

उत्तर देने से पहले स्पष्टीकरण प्रश्न

कौन सी भाषाएँ लक्षित फ़ील्ड्स का समर्थन करती हैं, और किन भाषाओं को पर्यावरण चर बनाए रखने की आवश्यकता है? यह माइग्रेशन बैच तय करता है।
क्या फ़ाइल इमेज में बेक की गई है, वॉल्यूम के रूप में माउंट की गई है, या रनटाइम पर डाउनलोड की गई है? स्रोत से साइनिंग, अनुमतियाँ और रोलबैक गति बदल जाती है।
क्या एप्लिकेशन कोड मौजूदा पर्यावरण चरों को पढ़ता है? यदि हाँ, तो प्राथमिकता (precedence) और डिप्रिकेशन विंडो तय होने तक उन्हें हटाना असुरक्षित है।
क्या माइग्रेशन के दौरान अस्थायी ड्यूल राइटिंग (दोहरा लेखन) की अनुमति है? इसमें अधिक लागत आती है लेकिन तुलनात्मक प्रमाण मिलते हैं।

30-सेकंड उत्तर ढांचा

"मैं प्रत्येक भाषा की कार्यान्वयन स्थिति और कॉन्फ़िगरेशन स्रोतों की सूची बनाऊंगा, फिर एक वर्ज़न न्यूनतम स्कीमा और संगतता मैट्रिक्स परिभाषित करूंगा। एक जनरेटर भाषा-तटस्थ YAML रेंडर करेगा, जबकि CI स्कीमा, अनुमतियों, एंडपॉइंट्स और कार्डिनैलिटी की जांच करेगा; असमर्थित भाषाएँ पुराने पर्यावरण-चर पथ को बनाए रखेंगी। मैं बिना व्यावसायिक ट्रैफ़िक वाली सिंथेटिक सेवा के साथ सत्यापन करूंगा, फिर भाषा और जोखिम के आधार पर कैनरी रिलीज़ करूंगा, जिसमें भेजे गए, छोड़े गए, सैंपल किए गए, लेटेंसी और लागत मेट्रिक्स की तुलना की जाएगी। प्रत्येक आर्टिफ़ैक्ट में एक वर्ज़न और रोलबैक पॉइंटर होगा। यदि पार्सिंग विफल हो जाती है, तो लॉन्चर बिना किसी टेलीमेट्री के चुपचाप शुरू होने के बजाय पिछले आर्टिफ़ैक्ट या पुराने फ़्लैग को बनाए रखेगा।"

चरण-दर-चरण विस्तृत उत्तर

1. क्षमता मैट्रिक्स और सीमा का निर्माण करें

कॉन्फ़िगरेशन को रिसोर्स, सैंपलिंग, रिसीवर्स, प्रोसेसर्स, एक्सपोर्टर्स और प्लगइन कंपोनेंट्स में विभाजित करें। प्रत्येक भाषा के लिए SDK वर्ज़न, समर्थित फ़ील्ड्स, डिफ़ॉल्ट्स, पर्यावरण-चर मैपिंग और अज्ञात-फ़ील्ड व्यवहार रिकॉर्ड करें। एक स्थिर डेटा मॉडल और पार्स/क्रिएट तंत्र का अर्थ यह नहीं है कि सभी भाषाओं के कार्यान्वयन समान रूप से परिपक्व हैं।

2. एक स्रोत और प्राथमिकता परिभाषित करें

डिक्लेरेटिव फ़ाइल को नई सेवाओं के लिए प्राथमिक स्रोत बनाएं, जबकि लेगेसी सेवाएँ पर्यावरण चरों को बनाए रखें। माइग्रेशन के दौरान प्राथमिकता को स्पष्ट रूप से परिभाषित करें: एक स्पष्ट फ़ाइल फ़ील्ड प्लेटफ़ॉर्म-जनरेटेड डिफ़ॉल्ट को ओवरराइड करती है; एक असमर्थित फ़ील्ड को चुपचाप अनदेखा करने के बजाय एडेप्टर द्वारा अस्वीकार या चिह्नित किया जाता है। ऑडिट के लिए प्रभावी कॉन्फ़िगरेशन का एक रेडैक्टेड (संपादित) स्नैपशॉट उत्सर्जित करें।

text

repo template -> rendered config -> schema validation -> signed artifact
       |                                       |
   env defaults --------------------------> runtime loader

प्रत्येक सेवा को अपना स्वयं का YAML जोड़ने की अनुमति न दें। प्लेटफ़ॉर्म टेम्प्लेट सामान्य सेटिंग्स का स्वामित्व रखते हैं; एक सेवा केवल एक छोटे, समीक्षित ओवरराइड की घोषणा कर सकती है।

3. आर्टिफ़ैक्ट और रिलीज़ पथ डिज़ाइन करें

आर्टिफ़ैक्ट को एक वर्ज़न, लक्षित भाषा, SDK रेंज, एक्सपोर्टर एंडपॉइंट, सीक्रेट संदर्भ और संगतता घोषणा की आवश्यकता होती है। CI स्कीमा को मान्य करता है, फिर इसे लोड करने और एक्सपोर्टर कनेक्शन स्थापित करने के लिए एक न्यूनतम सेवा शुरू करता है। प्रोडक्शन एक अपरिवर्तनीय (immutable) डाइजेस्ट और हस्ताक्षर का उपयोग करता है; रोलबैक पहले से सत्यापित डाइजेस्ट पर स्विच करता है।

4. पुराने चरों और डुप्लिकेट एक्सपोर्टर्स को संभालें

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

5. सिंथेटिक टेलीमेट्री के साथ सेमेंटिक्स सत्यापित करें

प्रत्येक भाषा के लिए निश्चित ट्रेस, मीट्रिक और लॉग नमूने उत्पन्न करें। सर्विस नाम, रिसोर्स एट्रिब्यूट्स, स्पैन नाम, सैंपलिंग, बैच आकार और एक्सपोर्टर लक्ष्य की जाँच करें। केवल "प्रक्रिया शुरू हो गई" पर न रुकें; कलेक्टर या बैकएंड में इनपुट और आउटपुट काउंट, लेटेंसी, अस्वीकृति कारणों और उच्च-कार्डिनैलिटी लेबल की तुलना करें।

6. बैचों में कैनरी करें और रोकने की शर्तें परिभाषित करें

पहले एक व्यावसायिक प्रवाह, एक भाषा और कम ट्रैफ़िक वाले इंस्टेंसेस चुनें, और पुराने वर्ज़न का नियंत्रण समूह बनाए रखें। पार्स त्रुटियों, टेलीमेट्री हानि, एक्सपोर्ट विफलताओं, CPU/RSS, बैकएंड राइट लागत, या व्यावसायिक p99 रिग्रेशन पर रोलआउट रोकें। यदि किसी भाषा का कार्यान्वयन अधूरा है, तो दिखावटी एकरूपता को बाध्य करने के बजाय पुराने पथ को बनाए रखें और अंतर (gap) को दर्ज करें।

7. रोलबैक करें और दीर्घकालिक गवर्नेंस बनाए रखें

लॉन्चर को तीन स्थितियों का समर्थन करना चाहिए: नई फ़ाइल, पुराने चर, और स्पष्ट रूप से अक्षम टेलीमेट्री। एक पार्स विफलता को "खाली लेकिन सफल" SDK नहीं बनना चाहिए; पिछले हस्ताक्षरित आर्टिफ़ैक्ट या पुराने चरों पर फ़ॉलबैक करें और अलर्ट भेजें। प्रत्येक SDK अपग्रेड पर मैट्रिक्स को फिर से चलाएं और पर्यावरण चरों को धीरे-धीरे समाप्त करें।

उच्च-गुणवत्ता वाला नमूना उत्तर

मैं भाषा और SDK क्षमता मैट्रिक्स से शुरुआत करूंगा, जिसमें स्थिर डिक्लेरेटिव स्कीमा को कार्यान्वयन परिपक्वता से अलग रखा जाएगा। प्लेटफ़ॉर्म वर्ज़न वाले टेम्प्लेट और छोटे सेवा-स्तरीय ओवरराइड प्रदान करेगा। रेंडरिंग के बाद, CI स्कीमा, अनुमतियों, एंडपॉइंट्स, कार्डिनैलिटी और न्यूनतम स्टार्टअप की जांच करेगा, जिससे एक हस्ताक्षरित अपरिवर्तनीय आर्टिफ़ैक्ट तैयार होगा। माइग्रेशन के दौरान, पुराने पर्यावरण चर एक स्पष्ट फ़ॉलबैक बने रहेंगे और प्रभावी कॉन्फ़िगरेशन दर्ज किया जाएगा ताकि फ़ाइल और चर सेटिंग्स डुप्लिकेट एक्सपोर्टर्स न बनाएं। मैं चारों भाषाओं के लिए निश्चित टेलीमेट्री नमूनों को मान्य करूंगा, फिर भाषा और व्यावसायिक जोखिम के आधार पर कैनरी रिलीज़ करूंगा। रोकने की शर्तों में पार्स विफलताएं, ड्रॉप दर, एक्सपोर्ट विफलताएं, संसाधन ओवरहेड और लागत रिग्रेशन शामिल हैं। फ़ाइल विफलता पर लॉन्चर पिछले आर्टिफ़ैक्ट या पुराने चरों पर वापस आ जाता है, कभी भी बिना टेलीमेट्री वाले इंस्टेंस पर चुपचाप शुरू नहीं होता; SDK अपग्रेड मैट्रिक्स को फिर से चलाते हैं और डिप्रिकेशन को आगे बढ़ाते हैं।

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

गलती → सभी भाषाओं को माइग्रेट करना क्योंकि स्कीमा स्थिर है → स्थिर विनिर्देश का अर्थ प्रत्येक कार्यान्वयन में पूर्ण फ़ील्ड होना नहीं है; समाधान: भाषा और SDK क्षमता मैट्रिक्स बनाए रखें।
गलती → बिना प्राथमिकता के फ़ाइलों और चरों की अनुमति देना → एक्सपोर्टर्स या सैंपलर दो बार इंस्टेंटिएट हो सकते हैं; समाधान: प्राथमिकता घोषित करें और एक रेडैक्टेड प्रभावी स्नैपशॉट उत्सर्जित करें।
गलती → केवल यह जांचना कि प्रक्रिया शुरू होती है → स्पैन छूट सकते हैं, कार्डिनैलिटी बढ़ सकती है, या डेटा गलत एंडपॉइंट पर पहुँच सकता है; समाधान: निश्चित सिंथेटिक टेलीमेट्री के साथ काउंट और लागत की तुलना करें।
गलती → पार्स विफलता के बाद चुपचाप खाली कॉन्फ़िगरेशन का उपयोग करना → आउटेज के समय ऑब्ज़र्वेबिलिटी का अंधा बिंदु (blind spot) बन जाता है; समाधान: हस्ताक्षरित पिछले आर्टिफ़ैक्ट या पुराने चरों पर फ़ॉलबैक करें और अलर्ट दें।

फॉलो-अप प्रश्न और उत्तर

क्या होगा यदि किसी भाषा में आवश्यक एक्सपोर्टर फ़ील्ड का अभाव हो?

एकरूपता के लिए बाध्य न करें। उस सेवा को पुराने-चर पथ पर रखें, फ़ील्ड अंतर और जोखिम दर्ज करें, और यदि आवश्यक हो तो केवल एक ऑडिट किए गए एडेप्टर के माध्यम से माइग्रेट करें। परिणाम को पूर्ण स्कीमा समर्थित दिखाने के बजाय आंशिक रूप से संगत के रूप में लेबल करें।

आप टीमों को प्लेटफ़ॉर्म सैंपलिंग नीति को ओवरराइड करने से कैसे रोकते हैं?

ओवरराइड करने योग्य फ़ील्ड्स को अनुमति सूची (allowlist) में रखें, रेंडरिंग के बाद नीति जांच चलाएं, और प्रभावी सारांश तथा परिवर्तन स्वामी को रिकॉर्ड करें। प्लेटफ़ॉर्म को महंगे एक्सपोर्टर्स, संवेदनशील एंडपॉइंट्स और सैंपलिंग सीमाओं को लागू करना चाहिए।

क्या होगा यदि कॉन्फ़िगरेशन सफलतापूर्वक लोड हो जाता है लेकिन बैकएंड लागत दोगुनी हो जाती है?

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