परिदृश्य (Scenario)
आप एक पॉलीग्लॉट माइक्रोसर्विस प्लेटफ़ॉर्म के स्वामी हैं। ट्रेस, मेट्रिक्स और लॉग मौजूद हैं, लेकिन प्रदर्शन में गिरावट (performance regressions) के लिए अभी भी मैन्युअल, होस्ट-दर-होस्ट प्रोफाइलिंग की आवश्यकता होती है। टीम चाहती है कि OpenTelemetry Profiles CPU, off-CPU और हीप डेटा को OTLP के माध्यम से एक Collector को भेजे और इसे ट्रेस व स्पैन के साथ सहसंबंधित करे। यह सिग्नल 2026 में Public Alpha में आया था। मूल्यांकन, पायलट, डेटा पाथ और रोलबैक योजना डिज़ाइन करें।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
- प्रोफाइल, लॉग, मेट्रिक्स और ट्रेस द्वारा उत्तर दिए जाने वाले प्रश्नों में अंतर करना।
- Alpha परिपक्वता, बैकएंड की तत्परता और भाषा-विशिष्ट संग्रह अंतरालों (collection gaps) को पहचानना।
- सैंपलिंग ओवरहेड, स्टोरेज लागत, संवेदनशील डेटा और एक्सेस को नियंत्रित करना।
- मापने योग्य पायलट गेट्स, आइसोलेशन सीमाएं और रोलबैक को परिभाषित करना।
स्पष्टीकरण हेतु प्रश्न
पुष्टि करें कि लक्षित समस्या CPU, मेमोरी, लॉक वेट या टेल लेटेंसी है; किन भाषाओं और रनटाइम्स को कवर किया जाना चाहिए; वर्तमान प्रोफाइलर्स, SLOs, सैंपलिंग बजट, रिटेंशन और अनुपालन (compliance) सीमाएं क्या हैं। पूछें कि क्या कोई बैकएंड OTLP Profiles का समर्थन करता है और क्या विफलताओं के दौरान pprof, JFR या वर्तमान APM को बनाए रखा जा सकता है।
30-सेकंड का उत्तर
मैं एक पायलट चलाऊंगा लेकिन Alpha सिग्नल को महत्वपूर्ण अलर्टिंग से बाहर रखूंगा। कुछ Linux सेवाओं का चयन करें, एक अलग Collector के माध्यम से कम आवृत्ति पर डेटा एकत्र करें, और आधार रेखा (baseline) के रूप में pprof/JFR को बनाए रखें। डायग्नोसिस में लगने वाले समय, CPU ओवरहेड, सैंपलिंग कवरेज, प्रति GB लागत, ट्रेस-सहसंबंध दर और रेडैक्शन त्रुटियों को मापें। बैकएंड, एक्सेस-कंट्रोल और रोलबैक अभ्यास सफल होने के बाद ही विस्तार करें। फॉर्मेट या Collector की विफलता में अनुरोध ट्रैफ़िक को प्रभावित किए बिना निर्यात को रोकने में सक्षम होना चाहिए।
चरण-दर-चरण तर्क
1. सिग्नल की सीमाओं को परिभाषित करें
लॉग असतत (discrete) घटनाओं का वर्णन करते हैं, मेट्रिक्स सिस्टम-स्तरीय मानों का वर्णन करते हैं, ट्रेस एक अनुरोध के पथ का वर्णन करते हैं, और प्रोफाइल बताते हैं कि कौन सा कोड संसाधनों की खपत करता है। प्रोफाइल अन्य सिग्नलों को बदलने के बजाय उनके पूरक हैं; मूल कारण विश्लेषण (root-cause analysis) को छोटा करने के लिए उन्हें संसाधन, ट्रेस या स्पैन पहचानकर्ताओं के माध्यम से सहसंबंधित करें।
2. संग्रह (Collection) डिज़ाइन करें
सैंपलिंग प्रोफाइलर निरंतर, कम ओवरहेड के लिए समय-समय पर स्टैक रिकॉर्ड करते हैं। इंस्ट्रूमेंटेशन प्रोफाइलर रनटाइम घटनाओं जैसे आवंटन (allocations), लॉक या कचरा संग्रहण (garbage collection) को रिकॉर्ड कर सकते हैं। पृथक नोड्स पर eBPF एजेंट या भाषा-मूल (language-native) टूल से शुरुआत करें, फिर Collector को OTLP निर्यात से पहले डेटा को फ़िल्टर, दर-सीमित (rate-limit), बैच और रूट करने दें।
3. लागत और गोपनीयता को नियंत्रित करें
सेवा स्तर (service tier) के आधार पर सैंपलिंग दरें और CPU बजट निर्धारित करें, 99वें-पर्सेंटाइल लेटेंसी विसंगतियों वाली सेवाओं को प्राथमिकता दें। प्रतीकों (symbols), तर्कों (arguments) और संवेदनशील पाथ डेटा को प्रतिबंधित करें; किरायेदारों (tenants) को अलग करें; और कच्चे (raw) व समेकित (aggregated) प्रोफाइल के लिए अलग-अलग रिटेंशन का उपयोग करें। ड्रॉप दर, Collector कतारों, इग्रेस बैंडविड्थ और स्टोरेज लागत की निगरानी करें।
4. Alpha जोखिम को संभालें
आधिकारिक दस्तावेज़ Profiles को Alpha के रूप में लेबल करते हैं, और घोषणा में कहा गया है कि जब तक प्रोडक्शन-रेडी बैकएंड उभर रहे हैं, तब तक इसका उपयोग महत्वपूर्ण प्रोडक्शन वर्कलोड के लिए नहीं किया जाना चाहिए। एक फीचर फ्लैग, एक स्वतंत्र संसाधन कोटा, एक पुराने टूल की बेसलाइन और केवल-कॉन्फ़िगरेशन रोलबैक का उपयोग करें। केवल मानकीकरण के लिए प्रत्येक भाषा और बैकएंड को माइग्रेट न करें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं मौजूदा प्रोफाइलर्स के तत्काल प्रतिस्थापन के बजाय प्रदर्शन-निदान के समय को कम करने के लिए अनुकूलन करूंगा। पहले चरण में दो Linux सेवाओं (एक Go और एक JVM) का चयन किया जाता है, pprof/JFR आउटपुट को बनाए रखा जाता है, और बेसलाइन निदान समय व संसाधन लागत को रिकॉर्ड किया जाता है। दूसरे चरण में कम आवृत्ति वाले CPU प्रोफाइलिंग के साथ एक अलग Collector तैनात किया जाता है; दर को केवल SLO या CPU विसंगतियों के लिए बढ़ाया जाता है। Collector परिवेश के आधार पर फ़िल्टर करता है, सीमाएं लागू करता है, फ़ील्ड्स को रिडैक्ट करता है, और OTLP को प्रोडक्शन ट्रैफ़िक से अलग कतार के माध्यम से रूट करता है। तीसरा चरण ट्रेस/स्पैन सहसंबंध को सक्षम करता है और परीक्षण करता है कि क्या एक धीमा स्पैन जिम्मेदार स्टैक तक पहुंच सकता है। गेट्स हैं: सीमित CPU ओवरहेड, पर्याप्त कवरेज, कम P95 निदान समय, स्वीकार्य मासिक लागत और शून्य संवेदनशील-फ़ील्ड लीक। चूंकि Profiles Alpha है, इसलिए वर्तमान बैकएंड और टूल बनाए रखें। यदि Collector में बैकअप हो जाता है, बैकएंड डेटा को अस्वीकार कर देता है, या एक्सेस सीमाएं विफल हो जाती हैं, तो निर्यात को अक्षम कर दें; व्यावसायिक अनुरोध कभी भी इस पथ पर निर्भर नहीं होते हैं।
सामान्य गलतियाँ
- Alpha Profiles को एक स्थिर सार्वभौमिक प्रतिस्थापन के रूप में मानना।
- सहसंबंध की व्याख्या किए बिना प्रोफाइल के साथ ट्रेस, मेट्रिक्स या लॉग को बदलना।
- लागत और संवेदनशीलता के बावजूद हर कच्चे स्टैक और प्रतीक को अनिश्चित काल तक बनाए रखना।
- प्रोफ़ाइल निर्यात के साथ एक व्यावसायिक-महत्वपूर्ण कतार साझा करना जिससे विफलताओं के कारण अनुरोधों में देरी हो।
- सैंपलिंग बजट, बैकएंड संगतता या किल स्विच के बिना "eBPF तैनात करें" कहना।
अनुवर्ती प्रश्न और उत्तर
"pprof या JFR को क्यों न बनाए रखें?"
उन्हें बेसलाइन और फ़ॉलबैक के रूप में बनाए रखें। Profiles एक सामान्य मॉडल, एक OTLP पाइपलाइन और क्रॉस-सिग्नल सहसंबंध जोड़ता है; माइग्रेशन तभी उचित है जब पायलट उन लाभों को साबित करे।
"आप ट्रेस और प्रोफाइल को कैसे सहसंबंधित करते हैं?"
प्रोफ़ाइल नमूनों पर संसाधन और उपलब्ध trace_id या span_id मेटाडेटा रिकॉर्ड करें और Collector व बैकएंड के माध्यम से फ़ील्ड्स को सुरक्षित रखें। स्वीकार करें कि प्रत्येक नमूना किसी अनुरोध से मैप नहीं हो सकता है।
"आप पायलट को कब रोकेंगे?"
जब CPU, लागत, या गोपनीयता जोखिम अपनी सीमा से अधिक हो जाए, या बैकएंड स्थिरता रोलबैक विंडो का समर्थन नहीं कर सके, तो निर्यात को अक्षम करें। मौजूदा टूल बनाए रखें और सिग्नल के परिपक्व होने के बाद पुनर्विचार करें।