वितरित ट्रेस: ​​हमने सब कुछ गलत किया

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


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

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

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

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

ऐसा अलग ट्रेस

वितरित अनुरेखण में कई असमान घटक शामिल हैं:

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

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

लगभग। ट्रांस। : आगे के पाठ को बेहतर ढंग से समझने के लिए, हम OpenTracing प्रोजेक्ट के प्रलेखन के अनुसार दो मूल शब्दों को परिभाषित करते हैं:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

टोपोलॉजी बिल्डिंग

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

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

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

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


काल्पनिक समाचार साइट सेवा योजना

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


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

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

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

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

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

निष्कर्ष

मैं खुद ट्रेस की उपयोगिता पर सवाल नहीं उठाता। मुझे पूरा विश्वास है कि ट्रेस में निहित के रूप में समृद्ध, आकस्मिक और प्रासंगिक डेटा एकत्र करने का कोई अन्य तरीका नहीं है। , . , traceview-, , , trace'. , , .

, , . , , . , production , , , , .

, , , , , . , , , trace' span'.

( UI). , , . , . . .

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

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

• « kubectl-debug pod' Kubernetes »;
• « : , Kubernetes »;
• « Kubernetes ( ) ».