प्रॉम्प्ट और संदर्भ
टीमें अलग-अलग लॉगिंग लाइब्रेरी और एजेंटों का उपयोग करती हैं, जिनमें लेवल्स TRACE और DEBUG से लेकर CRITICAL तक होते हैं। बताएं कि उन्हें OpenTelemetry SeverityNumber और SeverityText में कैसे मैप किया जाए, सोर्स की जानकारी कैसे सुरक्षित रखी जाए, और एक्सेप्शन, सैंपलिंग, क्वेरीज़ तथा वर्शन माइग्रेशन को कैसे संभाला जाए।
इंटरव्यूअर क्या टेस्ट कर रहा है
- मानकीकृत SeverityNumber, सोर्स SeverityText और लॉग बॉडी में अंतर करना।
- यह समझना कि संख्यात्मक रेंज सेवेरिटी को व्यक्त करती हैं और समान नाम वाले लेवल्स का सभी सिस्टम्स में एक समान अर्थ होना आवश्यक नहीं है।
- एक्सेप्शन इवेंट्स, रिसोर्स एट्रिब्यूट्स, ट्रेस/स्पैन कोरिलेशन और कलेक्टर ट्रांसफ़ॉर्मेशन को संयोजित करना।
- अज्ञात लेवल्स, सैंपलिंग बायस, क्वेरी कम्पैटिबिलिटी, अलर्ट थ्रेशोल्ड और रिप्ले वैलिडेशन को ध्यान में रखना।
पूछने के लिए स्पष्टीकरण प्रश्न
- प्रत्येक सोर्स के लेवल का क्या अर्थ है, यह किस संख्यात्मक रेंज का उपयोग करता है, और क्या यह कस्टम लेवल्स को परिभाषित करता है?
- क्या मूल लेवल स्ट्रिंग, लॉगिंग लाइब्रेरी और वर्शन को बनाए रखा जाना चाहिए? डाउनस्ट्रीम क्वेरीज़ किन फ़ील्ड्स का उपयोग करती हैं?
- क्या कोई एक्सेप्शन एक अलग इवेंट है या सामान्य बॉडी टेक्स्ट, और क्या इसे किसी ट्रेस, स्पैन या रिक्वेस्ट ID से लिंक होना चाहिए?
- क्या मैपिंग से अलर्ट, सैंपलिंग, स्टोरेज कॉस्ट या रिटेंशन कंप्लायंस में बदलाव आएगा? ऐतिहासिक लॉग्स को कैसे रिप्ले किया जाएगा?
एक 30-सेकंड का उत्तर
मैं प्रत्येक सोर्स के लिए एक सेमेंटिक डिक्शनरी बनाऊंगा, फिर मूल SeverityText और सोर्स मेटाडेटा को बनाए रखते हुए अर्थों को OpenTelemetry SeverityNumber रेंज में मैप करूंगा। एक्सेप्शन मानक एक्सेप्शन सेमेंटिक्स और ट्रेस/स्पैन कोरिलेशन का उपयोग करते हैं; स्टैक ट्रेस को लेवल फ़ील्ड में नहीं ठूंसना चाहिए। कलेक्टर रिकॉर्ड्स को ट्रांसफ़ॉर्म और वैलिडेट करता है, जबकि अज्ञात लेवल्स एक अवलोकनीय (observable) फ़ॉलबैक पाथ का पालन करते हैं। रोलआउट से पहले, मैं सभी इतिहास को चुपचाप पुनर्परिभाषित करने के बजाय अलर्ट थ्रेशोल्ड, सैंपलिंग, क्वेरीज़ और कॉस्ट की जांच करने के लिए प्रतिनिधि और विफलता नमूनों (failure samples) को रिप्ले करूंगा।
चरण-दर-चरण गहन विश्लेषण
1. मानक फ़ील्ड्स को परिभाषित करें
OpenTelemetry Logs Data Model SeverityNumber और SeverityText को अलग करता है। Number मॉडल के भीतर तुलना का समर्थन करता है; Text प्रोड्यूसर के मूल या डिस्प्ले नाम को सुरक्षित रखता है। Body, एट्रिब्यूट्स, रिसोर्सेज़ और टाइमस्टैम्प अन्य सेमेंटिक्स ले जाते हैं। मैपिंग टेबल को कन्वर्जन कोड में सब कुछ छिपाने के बजाय सोर्स, मूल लेवल, टारगेट रेंज और तर्क (rationale) को रिकॉर्ड करना चाहिए।
2. सोर्सेज़ को सेमेंटिक रेंज में मैप करें
WARN, ERROR या FATAL अलग-अलग फ्रेमवर्क में अलग-अलग ऑपरेशनल एक्शन ट्रिगर कर सकते हैं। अर्थ के आधार पर एक रेंज में मैप करें, एक असत्यापित लेवल को अनडिफ़ाइंड या लो-कॉन्फ़िडेंस के रूप में बनाए रखें, और मूल वैल्यू को SeverityText या एक नियंत्रित एट्रिब्यूट में रखें। जब तक प्रत्येक सोर्स के दस्तावेज़ और नमूनों का सत्यापन न हो जाए, तब तक सिस्टम्स के बीच रॉ नंबरों की तुलना न करें।
3. एक्सेप्शन और कोरिलेशन को संभालें
OpenTelemetry एक्सेप्शन सेमेंटिक्स एक्सेप्शन प्रकार, मैसेज और स्टैक ट्रेस के लिए फ़ील्ड्स की अनुशंसा करते हैं, जिसमें सेवेरिटी इस आधार पर चुनी जाती है कि क्या एक्सेप्शन एप्लिकेशन विफलता का कारण बनता है। लॉग्स में trace ID, span ID, सर्विस और डिप्लॉयमेंट वर्शन होना चाहिए ताकि क्वेरीज़ एक ही रिक्वेस्ट के रिकॉर्ड्स में अंतर कर सकें। स्टैक ट्रेस डायग्नोस्टिक डेटा हैं और इनके लिए अन्य लॉग्स की तरह ही संवेदनशील डेटा और रिटेंशन नियंत्रण की आवश्यकता होती है।
4. इंजेस्टशन, अलर्ट और माइग्रेशन को वैलिडेट करें
Collector या किसी एज एजेंट में मैपिंग, फ़ील्ड वैलिडेशन और कम्पैटिबिलिटी कन्वर्जन निष्पादित करें, अमान्य वैल्यूज़ और ड्रॉप कारणों को रिकॉर्ड करें। अलर्ट थ्रेशोल्ड, सैंपलिंग, क्वेरी परिणामों और स्टोरेज कॉस्ट को सत्यापित करने के लिए ऐतिहासिक नमूनों और सिंथेटिक विफलताओं को रिप्ले करें। अपग्रेड के दौरान, एक मैपिंग वर्शन और सोर्स फ़ील्ड्स बनाए रखें ताकि कंज्यूमर्स अलर्ट के अर्थ को चुपचाप बदलने के बजाय वर्शन के अनुसार इतिहास की व्याख्या कर सकें।
मॉडल उत्तर
मैं Java, Python, Nginx और अन्य सोर्सेज़ के लिए प्रलेखित सेमेंटिक मैपिंग बनाऊंगा, जो OpenTelemetry SeverityNumber को लक्षित करेगी, जबकि मूल नामों को SeverityText और नियंत्रित एट्रिब्यूट्स में बनाए रखेगी। नंबरों की तुलना केवल उसी मॉडल के भीतर की जाती है; अज्ञात या कस्टम लेवल्स अलर्ट के साथ एक लो-कॉन्फ़िडेंस पाथ का पालन करते हैं। एक्सेप्शन OpenTelemetry एक्सेप्शन फ़ील्ड्स का उपयोग करते हैं और ट्रेस/स्पैन और सर्विस वर्शन से लिंक होते हैं। Collector ट्रांसफ़ॉर्मेशन, वैलिडेशन और मेट्रिक्स को संभालता है। अलर्ट, सैंपलिंग, क्वेरीज़ और कॉस्ट का परीक्षण करने के लिए ऐतिहासिक और विफलता नमूनों को रिप्ले किया जाता है। ऑडिटेबिलिटी के लिए मैपिंग वर्शन और सोर्स फ़ील्ड्स उपलब्ध रहते हैं।
सामान्य गलतियाँ
- सेमेंटिक्स की जांच किए बिना प्रत्येक सोर्स के ERROR, WARN या FATAL को वन-टू-वन मैप करना।
- केवल SeverityNumber रखना और मूल लेवल तथा सोर्स वर्शन को छोड़ देना।
- एक्सेप्शन डेटा को बॉडी में डालना जिससे स्टैक ट्रेस को क्वेरी करना कठिन या बनाए रखना असुरक्षित हो जाता है।
- ट्रेस/स्पैन कोरिलेशन को छोड़ देना और रिक्वेस्ट-लेवल संदर्भ खो देना।
- विफल मैपिंग को चुपचाप ड्रॉप कर देना या बिना मेट्रिक्स या अलर्ट के उन्हें जबरन INFO में बदलना।
- मैपिंग परिवर्तन के बाद बिना वर्शन या रिप्ले रिकॉर्ड के ऐतिहासिक अलर्ट्स की पुनर्गणना करना।
फॉलो-अप प्रश्न और उत्तर
एक अज्ञात लेवल को किस नंबर का उपयोग करना चाहिए?
जबरन ERROR करने के बजाय मूल टेक्स्ट को बनाए रखें और इसे अज्ञात या लो-कॉन्फ़िडेंस के रूप में चिह्नित करें। यदि व्यावसायिक क्रम (ordering) आवश्यक है, तो एक प्रलेखित डिफ़ॉल्ट रेंज परिभाषित करें, मैपिंग वर्शन रिकॉर्ड करें, अज्ञात अनुपात की निगरानी करें और सोर्स सेमेंटिक्स को ठीक करें।
क्या सैंपलिंग सेवेरिटी डिस्ट्रीब्यूशन को बदल सकती है?
हाँ। गंभीर रिकॉर्ड्स और एक्सेप्शन इवेंट्स को प्राथमिकता दें, सैंपलिंग निर्णय और इनपुट हर (denominator) को रिकॉर्ड करें, और सैंपलिंग से पहले और बाद के वितरण की तुलना करें। उस संदर्भ के बिना सैंपल की गई संख्या को वास्तविक एरर रेट के रूप में प्रस्तुत नहीं किया जाना चाहिए।
आप पुरानी क्वेरीज़ को कम्पैटिबल कैसे रखते हैं?
कन्वर्जन लेयर में सोर्स फ़ील्ड्स और पुराने उपनामों (aliases) को अस्थायी रूप से बनाए रखें, और वर्शन किए गए व्यूज़ या क्वेरी फ़ंक्शन्स को प्रदर्शित करें। माइग्रेशन के दौरान, अलर्ट्स और रिपोर्ट्स को तब तक डुअल-राइट या रिप्ले करें जब तक कि अंतर समझ में न आ जाएं, फिर पुराने फ़ील्ड्स को हटा दें।