वितरित अनुरेखण: हमने यह सब गलत किया

टिप्पणी। अनुवाद।: इस सामग्री के लेखक सिंडी श्रीधरन हैं, जो imgix के एक इंजीनियर हैं, जो एपीआई विकास और विशेष रूप से माइक्रोसर्विस परीक्षण में विशेषज्ञ हैं। इस सामग्री में, वह वितरित ट्रेसिंग के क्षेत्र में वर्तमान समस्याओं के बारे में अपनी विस्तृत दृष्टि साझा करती है, जहां, उनकी राय में, गंभीर समस्याओं को हल करने के लिए वास्तव में प्रभावी उपकरणों की कमी है।

[चित्रण से लिया गया है अन्य सामग्री वितरित अनुरेखण के बारे में।]

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

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

हालाँकि, अगर हम कल्पना करें कि ये सभी समस्याएं हल हो गई हैं, तो इस बात की बहुत अधिक संभावना है कि कुछ भी महत्वपूर्ण बदलाव नहीं आएगा अंतिम उपयोगकर्ता अनुभव. ट्रेसिंग अभी भी सबसे आम डिबगिंग परिदृश्यों में व्यावहारिक उपयोग की नहीं हो सकती है - भले ही इसे तैनात किया गया हो।

इतना अलग निशान

वितरित ट्रेसिंग में कई अलग-अलग घटक शामिल हैं:

• अनुप्रयोगों और मिडलवेयर को नियंत्रण उपकरणों से लैस करना;
• वितरित संदर्भ स्थानांतरण;
• निशानों का संग्रह;
• भंडारण का पता लगाएं;
• उनका निष्कर्षण और विज़ुअलाइज़ेशन।

वितरित ट्रेसिंग के बारे में बहुत सी बातें इसे एक प्रकार के यूनरी ऑपरेशन के रूप में मानती हैं जिसका एकमात्र उद्देश्य सिस्टम का पूरी तरह से निदान करने में मदद करना है। यह काफी हद तक इस कारण है कि वितरित ट्रेसिंग के बारे में विचार ऐतिहासिक रूप से कैसे बने हैं। में वेबदैनिकी डाक, जब जिपकिन स्रोत खोले गए थे, तब इसका उल्लेख किया गया था यह [ज़िपकिन] ट्विटर को तेज़ बनाता है. ट्रेसिंग के लिए पहली व्यावसायिक पेशकश को भी इस रूप में प्रचारित किया गया था एपीएम उपकरण.

टिप्पणी। अनुवाद।: आगे के पाठ को समझने में आसान बनाने के लिए, आइए इसके अनुसार दो बुनियादी शब्दों को परिभाषित करें ओपनट्रेसिंग प्रोजेक्ट दस्तावेज़ीकरण:

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

ट्रेस में अविश्वसनीय रूप से मूल्यवान डेटा होता है जो उत्पादन परीक्षण, आपदा पुनर्प्राप्ति परीक्षण, त्रुटि इंजेक्शन परीक्षण इत्यादि जैसे कार्यों में सहायता कर सकता है। वास्तव में, कुछ कंपनियां पहले से ही समान उद्देश्यों के लिए ट्रेसिंग का उपयोग करती हैं। आइये शुरू करते हैं सार्वभौमिक संदर्भ स्थानांतरण स्टोरेज सिस्टम में स्पैन को स्थानांतरित करने के अलावा इसके अन्य उपयोग भी हैं:

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

ऊपर सूचीबद्ध कोई भी विकल्प पूरी तरह से परिदृश्य पर लागू नहीं होता है डिबगिंग, जिसके दौरान इंजीनियर ट्रेस को देखकर समस्या का समाधान करने का प्रयास करता है।

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

मैंने अब तक जितने भी ट्रेसिंग सिस्टम देखे हैं, उनमें समस्या यह है कि परिणामी विज़ुअलाइज़ेशन (ट्रेसव्यू) यह लगभग पूरी तरह से ट्रेस जनरेशन प्रक्रिया की विशेषताओं को दर्शाता है। यहां तक ​​कि जब वैकल्पिक विज़ुअलाइज़ेशन प्रस्तावित होते हैं: हीटमैप, सेवा टोपोलॉजी, विलंबता हिस्टोग्राम, तब भी वे अंततः नीचे आते हैं ट्रेसव्यू.

अतीत में मैं शिकायत की यूआई/यूएक्स ट्रेसिंग में अधिकांश "नवाचार" यहीं तक सीमित प्रतीत होते हैं पर मोड़ ट्रेस में अतिरिक्त मेटाडेटा, उनमें उच्च कार्डिनैलिटी के साथ जानकारी निवेश करना (उच्च-कार्डिनैलिटी) या विशिष्ट स्पैन में ड्रिल डाउन करने या क्वेरीज़ चलाने की क्षमता प्रदान करना अंतर- और इंट्रा-ट्रेस. इस प्रकार ट्रेसव्यू प्राथमिक विज़ुअलाइज़ेशन उपकरण बना हुआ है। जब तक यह स्थिति जारी रहती है, वितरित ट्रेसिंग (सबसे अच्छा) मेट्रिक्स, लॉग और स्टैक ट्रेस के बाद डिबगिंग टूल के रूप में चौथा स्थान लेगी, और सबसे बुरी स्थिति में यह पैसे और समय की बर्बादी साबित होगी।

ट्रेसव्यू के साथ समस्या

भाग्य ट्रेसव्यू - वितरित प्रणाली के सभी घटकों में एक अनुरोध के संचलन की पूरी तस्वीर प्रदान करें जिससे यह संबंधित है। कुछ अधिक उन्नत ट्रेसिंग प्रणालियाँ आपको अलग-अलग स्पैन में गहराई तक जाने और समय के साथ ब्रेकडाउन देखने की अनुमति देती हैं अंदर एक प्रक्रिया (जब स्पैन में कार्यात्मक सीमाएँ होती हैं)।

माइक्रोसर्विसेज आर्किटेक्चर का मूल आधार यह विचार है कि संगठनात्मक संरचना कंपनी की जरूरतों के साथ बढ़ती है। माइक्रोसर्विसेज के समर्थकों का तर्क है कि विभिन्न व्यावसायिक कार्यों को व्यक्तिगत सेवाओं में वितरित करने से छोटी, स्वायत्त विकास टीमों को ऐसी सेवाओं के पूरे जीवनचक्र को नियंत्रित करने की अनुमति मिलती है, जिससे उन्हें स्वतंत्र रूप से उन सेवाओं का निर्माण, परीक्षण और तैनाती करने की क्षमता मिलती है। हालाँकि, इस वितरण का नुकसान यह जानकारी का नुकसान है कि प्रत्येक सेवा दूसरों के साथ कैसे इंटरैक्ट करती है। ऐसी स्थितियों में, वितरित अनुरेखण एक अपरिहार्य उपकरण होने का दावा करता है डिबगिंग सेवाओं के बीच जटिल अंतःक्रिया.

आप यदि सच आश्चर्यजनक रूप से जटिल वितरित प्रणाली, तो एक भी व्यक्ति इसे अपने दिमाग में नहीं रख पाता है полную चित्र। वास्तव में, इस धारणा के आधार पर एक उपकरण विकसित करना कि यह संभव भी है, एक विरोधी पैटर्न (एक अप्रभावी और अनुत्पादक दृष्टिकोण) है। आदर्श रूप से, डिबगिंग के लिए एक ऐसे टूल की आवश्यकता होती है जो मदद करे अपना खोज क्षेत्र सीमित करें, ताकि इंजीनियर विचाराधीन समस्या परिदृश्य के लिए प्रासंगिक आयामों (सेवाओं/उपयोगकर्ताओं/होस्टों, आदि) के सबसेट पर ध्यान केंद्रित कर सकें। किसी विफलता का कारण निर्धारित करते समय, इंजीनियरों को यह समझने की आवश्यकता नहीं होती है कि विफलता के दौरान क्या हुआ था सभी सेवाएँ एक साथ, क्योंकि ऐसी आवश्यकता माइक्रोसर्विस आर्किटेक्चर के विचार के विपरीत होगी।

हालाँकि, ट्रेसव्यू है यानी यह। हां, कुछ ट्रेसिंग सिस्टम संपीड़ित ट्रेसव्यू की पेशकश करते हैं जब ट्रेस में स्पैन की संख्या इतनी बड़ी होती है कि उन्हें एक विज़ुअलाइज़ेशन में प्रदर्शित नहीं किया जा सकता है। हालाँकि, इस तरह के छीने गए विज़ुअलाइज़ेशन में भी बड़ी मात्रा में जानकारी मौजूद होने के कारण, इंजीनियर अभी भी ऐसा नहीं कर पा रहे हैं करने के लिए मजबूर इसे "छानें", मैन्युअल रूप से चयन को सेवाओं के एक सेट तक सीमित करें जो समस्याओं का स्रोत हैं। दुर्भाग्य से, इस क्षेत्र में मशीनें इंसानों की तुलना में बहुत तेज़ हैं, त्रुटियों की संभावना कम है, और उनके परिणाम अधिक दोहराए जा सकते हैं।

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

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

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

स्पैन बहुत निचले स्तर के हैं

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

इसके अलावा, मैं निम्नलिखित पर जोर देने की स्वतंत्रता लूंगा: आदर्श रूप से, हमें इसकी आवश्यकता नहीं है पूरा चित्र अनुरोध जीवनचक्र के दौरान हुआ, जिसे आधुनिक ट्रेसिंग टूल द्वारा दर्शाया गया है। इसके बजाय, कुछ प्रकार के उच्च-स्तरीय अमूर्तन की आवश्यकता होती है जिसमें किस चीज़ के बारे में जानकारी होती है गड़बड़ हो गया (बैकट्रेस के समान), कुछ संदर्भ के साथ। मैं पूरे ट्रेस को देखने के बजाय उसे देखना पसंद करता हूं часть, जहां कुछ दिलचस्प या असामान्य घटित होता है। वर्तमान में, खोज मैन्युअल रूप से की जाती है: इंजीनियर ट्रेस प्राप्त करता है और किसी दिलचस्प चीज़ की खोज में स्वतंत्र रूप से स्पैन का विश्लेषण करता है। संदिग्ध गतिविधि का पता लगाने की उम्मीद में अलग-अलग निशानों में स्पैन को घूरने वाले लोगों का दृष्टिकोण बिल्कुल भी स्केल नहीं करता है (खासकर जब उन्हें अलग-अलग स्पैन में एन्कोड किए गए सभी मेटाडेटा को समझना होता है, जैसे कि स्पैन आईडी, आरपीसी विधि का नाम, स्पैन अवधि) 'ए, लॉग, टैग, आदि)।

ट्रेसव्यू के विकल्प

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

मैं विज़ुअल डिज़ाइनर या यूएक्स विशेषज्ञ नहीं हूं, लेकिन अगले भाग में मैं कुछ विचार साझा करना चाहता हूं कि ये विज़ुअलाइज़ेशन कैसा दिख सकता है।

विशिष्ट सेवाओं पर ध्यान दें

ऐसे समय में जब उद्योग विचारों के इर्द-गिर्द संगठित हो रहा है एसएलओ (सेवा स्तर उद्देश्य) और एसएलआई (सेवा स्तर संकेतक), यह उचित प्रतीत होता है कि व्यक्तिगत टीमों को यह सुनिश्चित करने को प्राथमिकता देनी चाहिए कि उनकी सेवाएँ इन लक्ष्यों के साथ संरेखित हों। यह इस प्रकार है कि सेवा उन्मुख ऐसी टीमों के लिए विज़ुअलाइज़ेशन सबसे उपयुक्त है।

निशान, विशेष रूप से नमूने के बिना, एक वितरित प्रणाली के प्रत्येक घटक के बारे में जानकारी का खजाना हैं। यह जानकारी एक चालाक प्रोसेसर को दी जा सकती है जो उपयोगकर्ताओं को आपूर्ति करेगा सेवा उन्मुख निष्कर्ष। उन्हें पहले से पहचाना जा सकता है - उपयोगकर्ता द्वारा निशानों को देखने से पहले भी:

1. विलंबता वितरण आरेख केवल अत्यधिक प्रमुख अनुरोधों के लिए (बाहरी अनुरोध);
2. उन मामलों के लिए विलंब वितरण के आरेख जब सेवा एसएलओ लक्ष्य प्राप्त नहीं होते हैं;
3. प्रश्नों में सबसे अधिक "आम", "दिलचस्प" और "अजीब" टैग होते हैं दोहराए जाते हैं;
4. ऐसे मामलों के लिए विलंबता टूटना जहां पर निर्भर करता है सेवाएँ अपने SLO लक्ष्य प्राप्त नहीं करतीं;
5. विभिन्न डाउनस्ट्रीम सेवाओं के लिए विलंबता टूटना।

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

इससे सवाल उठता है: विभिन्न टीमों द्वारा नियंत्रित विविध सेवाओं के बीच जटिल बातचीत के बारे में क्या? यही है ना ट्रेसव्यू ऐसी स्थिति को उजागर करने के लिए सबसे उपयुक्त उपकरण नहीं माना जाता है?

मोबाइल डेवलपर्स, स्टेटलेस सेवाओं के मालिक, प्रबंधित स्टेटफुल सेवाओं (जैसे डेटाबेस) के मालिक और प्लेटफ़ॉर्म मालिकों की किसी और चीज़ में रुचि हो सकती है प्रस्तुति वितरित प्रणाली; ट्रेसव्यू इन मौलिक रूप से भिन्न आवश्यकताओं के लिए यह अत्यधिक सामान्य समाधान है। यहां तक ​​कि एक बहुत ही जटिल माइक्रोसर्विस आर्किटेक्चर में भी, सेवा मालिकों को दो या तीन से अधिक अपस्ट्रीम और डाउनस्ट्रीम सेवाओं के गहन ज्ञान की आवश्यकता नहीं होती है। मूलतः, अधिकांश परिदृश्यों में, उपयोगकर्ताओं को केवल संबंधित प्रश्नों के उत्तर देने की आवश्यकता होती है सेवाओं का सीमित सेट.

यह जांचने के लिए सेवाओं के एक छोटे उपसमूह को आवर्धक कांच के माध्यम से देखने जैसा है। इससे उपयोगकर्ता को इन सेवाओं और उनकी तत्काल निर्भरता के बीच जटिल इंटरैक्शन के संबंध में अधिक महत्वपूर्ण प्रश्न पूछने की अनुमति मिलेगी। यह सेवा जगत में बैकट्रेस के समान है, जहां इंजीनियर जानता है कि गलत है, और आसपास की सेवाओं में क्या हो रहा है, इसकी भी कुछ समझ होनी चाहिए क्यों.

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

टोपोलॉजी का निर्माण

यदि उपयोगकर्ता को पता हो तो सेवा-विशिष्ट दृश्य अविश्वसनीय रूप से उपयोगी हो सकते हैं कौन कोई सेवा या सेवाओं का समूह विलंबता बढ़ाने या त्रुटियाँ उत्पन्न करने के लिए ज़िम्मेदार है। हालाँकि, एक जटिल प्रणाली में, विफलता के दौरान आपत्तिजनक सेवा की पहचान करना एक गैर-मामूली कार्य हो सकता है, खासकर यदि सेवाओं से कोई त्रुटि संदेश रिपोर्ट नहीं किया गया हो।

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

चलिए एक उदाहरण लेते हैं. आइए एक काल्पनिक समाचार साइट की कल्पना करें। होम पेज सेवा (मुखपृष्ठ) Redis के साथ, अनुशंसा सेवा के साथ, विज्ञापन सेवा और वीडियो सेवा के साथ डेटा का आदान-प्रदान करता है। वीडियो सेवा S3 से वीडियो और DynamoDB से मेटाडेटा लेती है। अनुशंसा सेवा DynamoDB से मेटाडेटा प्राप्त करती है, Redis और MySQL से डेटा लोड करती है, और काफ्का को संदेश लिखती है। विज्ञापन सेवा MySQL से डेटा प्राप्त करती है और काफ्का को संदेश लिखती है।

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

एक काल्पनिक समाचार साइट का सेवा आरेख

नीचे दिया गया चित्र बेहतर अनुकूल होगा. सेवा में कोई समस्या है (वीडियो) ठीक मध्य में दर्शाया गया है। उपयोगकर्ता इसे तुरंत नोटिस करता है। इस विज़ुअलाइज़ेशन से, यह स्पष्ट हो जाता है कि S3 प्रतिक्रिया समय में वृद्धि के कारण वीडियो सेवा असामान्य रूप से काम कर रही है, जो मुख्य पृष्ठ के हिस्से की लोडिंग गति को प्रभावित करती है।

गतिशील टोपोलॉजी केवल "रोचक" सेवाएँ प्रदर्शित करती है

गतिशील रूप से उत्पन्न टोपोलॉजी स्थिर सेवा मानचित्रों की तुलना में अधिक कुशल हो सकती है, विशेष रूप से लोचदार, ऑटो-स्केलिंग बुनियादी ढांचे में। सेवा टोपोलॉजी की तुलना और अंतर करने की क्षमता उपयोगकर्ता को अधिक प्रासंगिक प्रश्न पूछने की अनुमति देती है। सिस्टम के बारे में अधिक सटीक प्रश्नों से सिस्टम कैसे काम करता है इसकी बेहतर समझ होने की अधिक संभावना है।

तुलनात्मक प्रदर्शन

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

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

निष्कर्ष

मैं ट्रेसिंग की उपयोगिता पर सवाल नहीं उठाता। मेरा ईमानदारी से मानना ​​है कि डेटा एकत्र करने की कोई अन्य विधि इतनी समृद्ध, कारणपूर्ण और प्रासंगिक नहीं है जितनी कि एक ट्रेस में निहित है। हालाँकि, मेरा यह भी मानना ​​है कि सभी ट्रेसिंग समाधान इस डेटा का उपयोग बेहद अकुशलता से करते हैं। जब तक ट्रेसिंग उपकरण ट्रेसव्यू प्रतिनिधित्व पर अटके रहेंगे, तब तक वे ट्रेस में मौजूद डेटा से निकाली जा सकने वाली मूल्यवान जानकारी का अधिकतम लाभ उठाने की अपनी क्षमता में सीमित रहेंगे। इसके अलावा, एक पूरी तरह से अमित्र और सहज दृश्य इंटरफ़ेस विकसित होने का जोखिम है जो एप्लिकेशन में त्रुटियों का निवारण करने की उपयोगकर्ता की क्षमता को गंभीर रूप से सीमित कर देगा।

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

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

हमें अच्छी अमूर्तता और लेयरिंग क्षमताओं की आवश्यकता है (विशेषकर यूआई में)। वे जो परिकल्पना-संचालित डिबगिंग प्रक्रिया में अच्छी तरह से फिट होंगे जहां आप पुनरावृत्त रूप से प्रश्न पूछ सकते हैं और परिकल्पनाओं का परीक्षण कर सकते हैं। वे सभी अवलोकन संबंधी समस्याओं को स्वचालित रूप से हल नहीं करेंगे, लेकिन वे उपयोगकर्ताओं को अपने अंतर्ज्ञान को तेज करने और बेहतर प्रश्न तैयार करने में मदद करेंगे। मैं विज़ुअलाइज़ेशन के लिए अधिक विचारशील और नवीन दृष्टिकोण का आह्वान करता हूं। यहां क्षितिज का विस्तार करने की वास्तविक संभावना है।

अनुवादक से पी.एस

हमारे ब्लॉग पर भी पढ़ें:

• «Kubernetes पॉड्स में डिबगिंग के लिए kubectl-debug प्लगइन";
• «माइक्रोसर्विसेज: आकार मायने रखता है, भले ही आपके पास कुबेरनेट्स हो";
• «निगरानी और कुबेरनेट्स (समीक्षा और वीडियो रिपोर्ट)'.

स्रोत: www.habr.com