प्रॉम्प्ट और संदर्भ
एक सर्विस OpenTelemetry को अपना रही है और टीम userid, requestid और पूर्ण URLs को मेट्रिक एट्रिब्यूट्स के रूप में जोड़ना चाहती है। एक कार्डिनैलिटी बजट डिज़ाइन करें, बताएं कि क्या रखा जाता है, सीमा तक पहुँचने पर क्या होता है, और आप यह कैसे साबित करते हैं कि अलर्ट उपयोगी बने रहते हैं।
OpenTelemetry मेट्रिक्स एट्रिब्यूट संयोजनों से टाइम सीरीज़ बनाते हैं। SDK कार्डिनैलिटी सीमा एक संग्रह चक्र के दौरान किसी मेट्रिक के लिए ट्रैक किए जाने वाले मेट्रिक पॉइंट्स पर एक निश्चित सीमा (hard limit) होती है। हाई-कार्डिनैलिटी फ़ील्ड मेमोरी, एक्सपोर्ट, स्टोरेज और क्वेरी की लागत को कई गुना बढ़ा देते हैं, इसलिए बजट को लागत और डायग्नोस्टिक वैल्यू दोनों की रक्षा करनी चाहिए।
इंटरव्यूअर क्या जांच रहा है
इंटरव्यूअर यह परख रहा है कि क्या आप मेट्रिक, लॉग और ट्रेस डाइमेंशन्स को अलग-अलग रखते हैं, सिंगल-फ़ील्ड काउंट के बजाय संयोजनों को समझते हैं, हार्ड लिमिट और डिग्रेडेशन डिज़ाइन करते हैं, और सर्विस ग्राफ़, अलर्ट, सैंपलिंग और गोपनीयता प्रतिबंधों को व्यावहारिक बनाते हैं।
स्पष्टीकरण के लिए प्रश्न
मेट्रिक का उद्देश्य, क्वेरी विंडो, अलर्ट लेटेंसी, टेनेंट संख्या, एंडपॉइंट संख्या, संग्रह अंतराल, बैकएंड डेटा रिटेंशन और बजट की पुष्टि करें। पूछें कि क्या ट्रेस या लॉग कोरिलेशन फ़ील्ड पहले से मौजूद हैं, कौन से पहचान फ़ील्ड गोपनीयता के प्रति संवेदनशील हैं, और क्या सीमा को नए मानों, पुराने मानों या एग्रीगेट सटीकता को प्राथमिकता देनी चाहिए।
30-सेकंड का उत्तर
“मैं मेट्रिक्स में सभी संदर्भ डालने के बजाय मेट्रिक उद्देश्य के अनुसार अनुमत डाइमेंशन्स को परिभाषित करूँगा। service, region, रूट टेम्प्लेट और स्टेटस क्लास जैसे स्थिर, लो-कार्डिनैलिटी फ़ील्ड्स को रखूँगा जो समूहीकृत अलर्ट का समर्थन करते हैं; userid, requestid और रॉ URLs को ट्रेस या लॉग में रखूँगा। प्रति मेट्रिक एक कार्डिनैलिटी सीमा, लागत अलर्ट और सैचुरेशन सिग्नल सेट करूँगा, जिसमें एक स्पष्ट एग्रीगेशन या ड्रॉप नीति होगी। अंत में, अलर्ट रिकॉल, फ़ाल्स पॉज़िटिव, क्वेरी लागत और गोपनीयता को मापने के लिए ऐतिहासिक ट्रैफ़िक को फिर से चलाऊँगा (replay)।”
गहन उत्तर
चरण 1: मेट्रिक प्रश्न को परिभाषित करें
प्रश्न लिखें: क्या एरर रेट बढ़ रहा है, कौन सा रूट प्रभावित है, किस क्षेत्र का प्रदर्शन गिरा है, या किसी एक यूज़र रिक्वेस्ट में क्या हुआ? शुरुआती मामले मेट्रिक्स के लिए उपयुक्त हैं; अंतिम मामला ट्रेस या लॉग से संबंधित है।
चरण 2: संयोजन कार्डिनैलिटी का अनुमान लगाएं
कार्डिनैलिटी एट्रिब्यूट संयोजनों का अद्वितीय सेट है, न कि प्रत्येक फ़ील्ड में मानों का योग। service, region, रूट टेम्प्लेट, स्टेटस, मेथड और टेनेंट टियर के गुणनफल का अनुमान लगाएं, फिर वास्तविक वितरण, लॉन्ग टेल और बर्स्ट के आधार पर इसे सही करें।
चरण 3: फ़ील्ड्स को स्तरित (Layer) करें
स्थिर एग्रीगेटेबल फ़ील्ड्स को बनाए रखें; यूज़र्स, रिक्वेस्ट्स और पूर्ण URLs को ट्रेस या लॉग में डालें। हाई-कार्डिनैलिटी टेनेंट आइडेंटिफायर्स के लिए, बकेटिंग, हैशिंग या सैंपलिंग का उपयोग केवल तभी करें जब एक्सेस कंट्रोल और जांच की ज़रूरतें पूरी होती रहें। रॉ पाथ पैरामीटर्स से कभी भी असीमित सीरीज़ न बनाएं।
चरण 4: SDK और बैकएंड बजट कॉन्फ़िगर करें
केवल अंत में डेटा काटने के बजाय SDK, Collector, टाइम-सीरीज़ बैकएंड और क्वेरी लेयर में बजट सेट करें। OpenTelemetry मेट्रिक कार्डिनैलिटी सीमा एक हार्ड कैप है, और बनाए रखे गए एट्रिब्यूट सेट को कार्यान्वयन और अलर्ट में अवलोकनीय (observable) होना चाहिए।
चरण 5: सीमा व्यवहार को परिभाषित करें
निर्दिष्ट करें कि कौन से संयोजन बचते हैं, क्या ओवरफ़्लो बकेट का उपयोग किया जाता है, क्या नए सेट छोड़ दिए जाते हैं, और निर्णय को कैसे गिना जाता है। नीति स्थिर और समझाने योग्य होनी चाहिए, जिसमें एक सैचुरेशन सिग्नल हो; बिना सूचना के डेटा का नुकसान (silent loss) स्वीकार्य नहीं है।
चरण 6: सही सिग्नल में कोरिलेशन रखें
रिक्वेस्ट के लिए traceid, रॉ URL या userid के लिए लॉग, और मेट्रिक से सैंपल पर जाने के लिए एक्सेम्पलर्स (exemplars) या लिंक्स का उपयोग करें। मेट्रिक्स ट्रेंड और अलर्ट प्रदान करते हैं; वे प्रति-रिक्वेस्ट डायग्नोसिस की जगह नहीं लेते हैं।
चरण 7: सर्विस ग्राफ़ और लागत का बजट बनाएं
सर्विस ग्राफ़ और ऑटो-इंस्ट्रूमेंटेशन कई मेट्रिक फ़ैमिलीज़ बना सकते हैं। एजेस, क्लाइंट्स, सर्वर्स और एरर स्टेट्स के लिए अलग-अलग बजट सेट करें, और एक्सपोर्ट फ़्रीक्वेंसी, रिटेंशन और हाई-कार्डिनैलिटी एट्रिब्यूट्स को नियंत्रित करें। केवल कुल लागत देखने के बजाय लागत रिपोर्ट को संबंधित सर्विसेज़ और मेट्रिक्स से जोड़ें।
चरण 8: अलर्ट गुणवत्ता और गोपनीयता को मान्य करें
बजट के साथ और उसके बिना रिकॉल, फ़ाल्स पॉज़िटिव, लेटेंसी और क्वेरी लागत की तुलना करने के लिए ट्रैफ़िक को फिर से चलाएं और विफलताएं इंजेक्ट करें। रेडैक्शन, एक्सेस कंट्रोल, डिलीशन रिक्वेस्ट और टेनेंट आइसोलेशन की जांच करें, और सैचुरेशन, कॉन्फ़िगरेशन परिवर्तन और डेटा हानि को ट्रेस करने योग्य बनाएं।
मॉडल उत्तर
मैं ट्रेंड अलर्टिंग को सिंगल-रिक्वेस्ट जांच से अलग रखूँगा। Service, region, रूट टेम्प्लेट, मेथड और स्टेटस क्लास आमतौर पर स्थिर, लो-कार्डिनैलिटी मेट्रिक एट्रिब्यूट्स होते हैं; userid, requestid और पैरामीटरयुक्त URLs ट्रेस, लॉग और एक्सेम्पलर्स में आते हैं। मैं एट्रिब्यूट संयोजनों के गुणनफल का अनुमान लगाऊंगा और लॉन्ग-टेल ट्रैफ़िक के साथ इसे सही करूँगा, फिर SDK, Collector और बैकएंड में कार्डिनैलिटी और लागत बजट कॉन्फ़िगर करूँगा। सीमा पर, चुपचाप विफल होने के बजाय एक स्पष्ट ओवरफ़्लो या ड्रॉप नीति का उपयोग करूँगा और सैचुरेशन रिकॉर्ड करूँगा। कलेक्शन और रिटेंशन को नियंत्रित करते हुए, सर्विस-ग्राफ़ एजेस, क्लाइंट्स और एरर स्टेट्स का स्वतंत्र रूप से बजट बनाऊंगा। लॉन्च से पहले, ट्रैफ़िक को फिर से चलाऊंगा और हाई-कार्डिनैलिटी और विफलता मामलों को इंजेक्ट करूँगा, जिससे अलर्ट रिकॉल, फ़ाल्स पॉज़िटिव, क्वेरी लागत, गोपनीयता और टेनेंट आइसोलेशन की तुलना की जा सके।
सामान्य गलतियाँ
प्रत्येक फ़ील्ड को स्वतंत्र रूप से गिनना
सीरीज़ संयोजनों से बनती हैं। कई मध्यम-कार्डिनैलिटी फ़ील्ड्स आपस में गुणा होकर बहुत बड़ा रूप ले सकते हैं, इसलिए संयोजनों, लॉन्ग टेल और बर्स्ट का अनुमान लगाएं।
हर मेट्रिक में user_id डालना
यूज़र-स्तरीय जांच ट्रेस और लॉग का हिस्सा है। मेट्रिक्स में आइडेंटिटी डाइमेंशन्स जोड़ने से लागत, गोपनीयता जोखिम और क्वेरी में अनावश्यक रुकावट बढ़ती है।
सीमा पर बिना सूचना डेटा छोड़ना (Silent drop)
चुपचाप डेटा खो जाने से अलर्ट स्वस्थ दिखाई देते हैं। सैचुरेशन, रिटेंशन नियम और कॉन्फ़िगरेशन वर्ज़न रिकॉर्ड करें, फिर डिग्रेडेड डायग्नोसिस का परीक्षण करें।
फॉलो-अप प्रश्न और उत्तर
रूट टेम्प्लेट पूर्ण URLs से किस प्रकार भिन्न होने चाहिए?
मेट्रिक्स नॉर्मलाइज़्ड रूट टेम्प्लेट्स का उपयोग करते हैं ताकि पाथ पैरामीटर्स नई सीरीज़ न बनाएं। पूर्ण URLs प्राइवेसी रेडैक्शन के साथ नियंत्रित लॉग या ट्रेस में जाते हैं।
क्या सीमा को पुराने या नए एट्रिब्यूट सेट्स को सुरक्षित रखना चाहिए?
यह अलर्ट और एग्रीगेटर पर निर्भर करता है, लेकिन नियम निश्चित, समझाने योग्य और अवलोकनीय होना चाहिए। ओवरफ़्लो की गणना करें ताकि इंस्टेंसेस असंगत रूप से व्यवहार न करें।
आप मेट्रिक्स, ट्रेस और लॉग को कैसे सहसंबंधित (correlate) करते हैं?
सैंपल्स को लिंक करने के लिए traceid, spanid या एक्सेम्पलर्स का उपयोग करें। मेट्रिक्स में स्थिर डाइमेंशन्स रखें, लॉग और ट्रेस में रिक्वेस्ट संदर्भ रखें, और नेविगेट करते समय एक्सेस बाउंड्री लागू करें।
सर्विस ग्राफ़ को अपने बजट की आवश्यकता क्यों होती है?
स्वचालित रूप से उत्पन्न एजेस, क्लाइंट्स और एरर डाइमेंशन्स सीरीज़ को कई गुना बढ़ा देते हैं। एज प्रकार, संग्रह आवृत्ति और रिटेंशन के आधार पर बजट को विभाजित करें ताकि ग्राफ़ व्यावसायिक मेट्रिक्स को प्रभावित न करे।
आप कैसे साबित करते हैं कि बजट विफलताओं को छिपा नहीं रहा है?
वास्तविक ट्रैफ़िक को फिर से चलाएं और हाई-कार्डिनैलिटी, एरर स्पाइक्स और टेनेंट लॉन्ग टेल को इंजेक्ट करें। सैचुरेशन घटनाओं पर नज़र रखते हुए बजट से पहले और बाद में रिकॉल, फ़ाल्स पॉज़िटिव, लेटेंसी और क्वेरी परिणामों की तुलना करें।
आपको मेट्रिक्स के बजाय लॉग कब जोड़ने चाहिए?
जब प्रश्न के लिए किसी एक रिक्वेस्ट, रॉ इनपुट या यूज़र संदर्भ की आवश्यकता हो, तो नियंत्रित लॉग या ट्रेस का उपयोग करें। मेट्रिक्स में केवल एग्रीगेट किए जा सकने वाले ट्रेंड्स और अलर्ट डाइमेंशन्स होने चाहिए।