वितरित ट्रेसिंग: आम्ही हे सर्व चुकीचे केले

नोंद. अनुवाद: या सामग्रीचे लेखक सिंडी श्रीधरन आहेत, imgix मधील एक अभियंता जी API विकास आणि विशेषतः मायक्रोसर्व्हिस चाचणीमध्ये माहिर आहे. या सामग्रीमध्ये, ती वितरित ट्रेसिंगच्या क्षेत्रातील वर्तमान समस्यांबद्दलची तिची तपशीलवार दृष्टी सामायिक करते, जिथे तिच्या मते, दाबलेल्या समस्यांचे निराकरण करण्यासाठी खरोखर प्रभावी साधनांचा अभाव आहे.

[चित्रातून घेतले आहे इतर साहित्य वितरित ट्रेसिंगबद्दल.]

असा विश्वास आहे वितरित ट्रेसिंग अंमलात आणणे कठीण आणि त्यावर परतावा सर्वोत्तम संशयास्पद. ट्रेसिंग समस्याप्रधान असण्याची अनेक कारणे आहेत, बहुतेकदा प्रत्येक विनंतीसह योग्य शीर्षलेख प्रसारित करण्यासाठी प्रत्येक सिस्टम घटक कॉन्फिगर करण्यात गुंतलेल्या श्रमांचा उल्लेख केला जातो. ही समस्या अस्तित्वात असली तरी ती कोणत्याही प्रकारे दुरावण्यासारखी नाही. तसे, हे स्पष्ट करत नाही की विकसकांना ट्रेसिंग का आवडत नाही (जरी ते आधीपासूनच कार्यरत आहे).

वितरित ट्रेसिंगचे मुख्य आव्हान म्हणजे डेटा गोळा करणे, परिणाम वितरित करण्यासाठी आणि सादर करण्यासाठी स्वरूपांचे मानकीकरण करणे किंवा नमुना केव्हा, कुठे आणि कसा बनवायचा हे ठरवणे. मी कल्पना करण्याचा प्रयत्न करत नाही क्षुल्लक या "आकलनक्षमतेच्या समस्या" किंबहुना अतिशय महत्त्वाच्या तांत्रिक आहेत आणि (जर आपण खरोखर मुक्त स्रोताचा विचार केला तर) मानके आणि प्रोटोकॉल) राजकीय आव्हाने ज्यावर मात करणे आवश्यक आहे जेणेकरून या समस्यांचे निराकरण केले जाऊ शकते.

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

असा वेगळा ट्रेस

वितरित ट्रेसिंगमध्ये अनेक भिन्न घटक समाविष्ट आहेत:

• नियंत्रण साधनांसह अनुप्रयोग आणि मिडलवेअर सुसज्ज करणे;
• वितरित संदर्भ हस्तांतरण;
• ट्रेस संग्रह;
• ट्रेस स्टोरेज;
• त्यांचे निष्कर्षण आणि व्हिज्युअलायझेशन.

डिस्ट्रिब्युटेड ट्रेसिंगबद्दल बरीच चर्चा याला एक प्रकारची युनरी ऑपरेशन मानते ज्याचा एकमेव उद्देश सिस्टमचे पूर्णपणे निदान करण्यात मदत करणे हा आहे. हे मुख्यत्वे ऐतिहासिकदृष्ट्या वितरित ट्रेसिंगबद्दलच्या कल्पना कशा तयार केल्या गेल्यामुळे आहे. IN ब्लॉग नोंदी, जेव्हा झिपकिनचे स्त्रोत उघडले तेव्हा केले, असा उल्लेख होता हे [झिपकिन] ट्विटरला वेगवान बनवते. ट्रेसिंगसाठी पहिल्या व्यावसायिक ऑफरचा देखील प्रचार केला गेला APM साधने.

नोंद. अनुवाद: पुढील मजकूर समजण्यास सुलभ करण्यासाठी, त्यानुसार दोन मूलभूत संज्ञा परिभाषित करूया OpenTracing प्रकल्प दस्तऐवजीकरण:

• कालावधी - वितरित ट्रेसिंगचा मूलभूत घटक. हे नाव, प्रारंभ आणि समाप्ती वेळ, टॅग, लॉग आणि संदर्भासह विशिष्ट कार्यप्रवाहाचे वर्णन आहे (उदाहरणार्थ, डेटाबेस क्वेरी).
• स्पॅनमध्ये सामान्यत: इतर स्पॅनचे दुवे असतात, ज्यामुळे एकाधिक स्पॅन एकत्र केले जाऊ शकतात ट्रेस - वितरीत प्रणालीद्वारे विनंतीच्या जीवनाचे व्हिज्युअलायझेशन.

ट्रेसमध्ये आश्चर्यकारकपणे मौल्यवान डेटा असतो जो उत्पादन चाचणी, आपत्ती पुनर्प्राप्ती चाचणी, त्रुटी इंजेक्शन चाचणी इत्यादीसारख्या कार्यांमध्ये मदत करू शकतो. खरं तर, काही कंपन्या आधीच तत्सम हेतूंसाठी ट्रेसिंग वापरतात. चला सुरुवात करूया सार्वत्रिक संदर्भ हस्तांतरण स्टोरेज सिस्टीममध्ये फक्त स्पॅन हलवण्याव्यतिरिक्त इतर उपयोग आहेत:

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

वर सूचीबद्ध केलेला कोणताही पर्याय संपूर्णपणे परिस्थितीवर लागू होत नाही डीबग, ज्या दरम्यान अभियंता ट्रेस पाहून समस्या सोडवण्याचा प्रयत्न करतात.

जेव्हा ते येत अद्याप डीबगिंग स्क्रिप्टपर्यंत पोहोचते, प्राथमिक इंटरफेस आकृतीच राहते ट्रेसव्ह्यू (जरी काही त्याला म्हणतात "गँट चार्ट" किंवा "धबधबा आकृती"). अंतर्गत ट्रेसव्ह्यू я म्हणजे सर्व स्पॅन आणि सोबतचा मेटाडेटा जो एकत्रितपणे ट्रेस बनवतो. प्रत्येक ओपन सोर्स ट्रेसिंग सिस्टम, तसेच प्रत्येक व्यावसायिक ट्रेसिंग सोल्यूशन ऑफर करते ट्रेसव्ह्यू ट्रेसचे व्हिज्युअलायझिंग, तपशील आणि फिल्टरिंगसाठी वापरकर्ता इंटरफेस.

मी आतापर्यंत पाहिलेल्या सर्व ट्रेसिंग सिस्टममधील समस्या म्हणजे परिणामी व्हिज्युअलायझेशन (ट्रेसव्ह्यू) जवळजवळ पूर्णपणे ट्रेस निर्मिती प्रक्रियेची वैशिष्ट्ये प्रतिबिंबित करते. जरी पर्यायी व्हिज्युअलायझेशन प्रस्तावित केले जातात: हीटमॅप, सर्व्हिस टोपोलॉजी, लेटन्सी हिस्टोग्राम, तरीही ते शेवटी खाली येतात ट्रेसव्ह्यू.

भूतकाळात आय तक्रार केली बहुतेक UI/UX ट्रेसिंग "नवीन शोध" इतकेच मर्यादित असल्याचे दिसते चालू करत आहे ट्रेसमध्ये अतिरिक्त मेटाडेटा, उच्च कार्डिनॅलिटीसह माहितीमध्ये गुंतवणूक करणे (उच्च-कार्डिनॅलिटी) किंवा विशिष्ट स्पॅनमध्ये ड्रिल डाउन करण्याची किंवा क्वेरी चालवण्याची क्षमता प्रदान करते इंटर- आणि इंट्रा-ट्रेस... ज्यात ट्रेसव्ह्यू प्राथमिक व्हिज्युअलायझेशन साधन राहते. जोपर्यंत ही स्थिती चालू राहते तोपर्यंत, मेट्रिक्स, लॉग आणि स्टॅक ट्रेस नंतर वितरित ट्रेसिंग (सर्वोत्तम) डीबगिंग साधन म्हणून चौथे स्थान घेईल आणि सर्वात वाईट म्हणजे ते पैसे आणि वेळेचा अपव्यय ठरेल.

ट्रेसव्ह्यूसह समस्या

गंतव्य ट्रेसव्ह्यू — वितरित प्रणालीच्या सर्व घटकांमध्ये एकाच विनंतीच्या हालचालीचे संपूर्ण चित्र प्रदान करा ज्याशी ते संबंधित आहे. काही अधिक प्रगत ट्रेसिंग सिस्टम तुम्हाला वैयक्तिक स्पॅनमध्ये ड्रिल डाउन करण्याची आणि कालांतराने ब्रेकडाउन पाहण्याची परवानगी देतात आत एक प्रक्रिया (जेव्हा स्पॅन्सच्या कार्यात्मक सीमा असतात).

मायक्रोसर्व्हिसेस आर्किटेक्चरचा मूळ आधार ही कल्पना आहे की संस्थात्मक संरचना कंपनीच्या गरजेनुसार वाढते. मायक्रोसर्व्हिसेसचे समर्थक असा युक्तिवाद करतात की वैयक्तिक सेवांमध्ये विविध व्यावसायिक कार्ये वितरीत केल्याने लहान, स्वायत्त विकास संघांना अशा सेवांचे संपूर्ण जीवनचक्र नियंत्रित करण्याची परवानगी मिळते, ज्यामुळे त्यांना त्या सेवा स्वतंत्रपणे तयार करण्याची, चाचणी करण्याची आणि तैनात करण्याची क्षमता मिळते. तथापि, या वितरणाचा तोटा म्हणजे प्रत्येक सेवा इतरांशी कसा संवाद साधते याविषयी माहिती गमावणे. अशा परिस्थितीत, वितरित ट्रेसिंग हे एक अपरिहार्य साधन असल्याचा दावा करतात डीबग सेवांमधील जटिल परस्परसंवाद.

आपण खरोखर आश्चर्यकारकपणे जटिल वितरण प्रणाली, मग एकही व्यक्ती त्याच्या डोक्यात ठेवू शकत नाही पूर्ण चित्र किंबहुना, हे अगदी शक्य आहे या गृहीतकावर आधारित साधन विकसित करणे हे एक विरोधी नमुना (एक अप्रभावी आणि अनुत्पादक दृष्टीकोन) आहे. तद्वतच, डीबगिंगला मदत करणारे साधन आवश्यक आहे तुमचा शोध क्षेत्र अरुंद करा, जेणेकरून अभियंते विचारात घेतलेल्या समस्या परिस्थितीशी संबंधित परिमाणांच्या उपसंचावर (सेवा/वापरकर्ते/होस्ट इ.) लक्ष केंद्रित करू शकतात. बिघाडाचे कारण ठरवताना, अभियंत्यांना दरम्यान काय झाले हे समजून घेणे आवश्यक नाही सर्व सेवा एकाच वेळी, कारण अशी आवश्यकता मायक्रोसर्व्हिस आर्किटेक्चरच्या अगदी कल्पनेला विरोध करेल.

तथापि, ट्रेसव्ह्यू आहे म्हणजे या. होय, जेव्हा ट्रेसमधील स्पॅनची संख्या इतकी मोठी असते की ते एका व्हिज्युअलायझेशनमध्ये प्रदर्शित केले जाऊ शकत नाहीत तेव्हा काही ट्रेसिंग सिस्टम कॉम्प्रेस्ड ट्रेसव्ह्यू देतात. तथापि, अशा स्ट्रिप-डाउन व्हिज्युअलायझेशनमध्येही मोठ्या प्रमाणात माहिती समाविष्ट असल्यामुळे, अभियंते अजूनही सक्ती समस्यांचे स्त्रोत असलेल्या सेवांच्या संचापर्यंत निवड व्यक्तिचलितपणे संकुचित करून ते "चाळणे". दुर्दैवाने, या क्षेत्रात, मशीन मानवांपेक्षा खूप वेगवान आहेत, त्रुटींना कमी प्रवण आहेत आणि त्यांचे परिणाम अधिक पुनरावृत्ती करण्यायोग्य आहेत.

ट्रेसव्ह्यू चुकीचे आहे असे मला वाटते दुसरे कारण म्हणजे ते गृहीतक-चालित डीबगिंगसाठी चांगले नाही. त्याच्या केंद्रस्थानी, डीबगिंग आहे पुनरावृत्ती एका गृहीतकापासून सुरू होणारी प्रक्रिया, त्यानंतर विविध वेक्टर्स, निष्कर्ष/सामान्यीकरण आणि गृहीतकेच्या सत्यतेचे पुढील मूल्यमापन, विविध निरीक्षणे आणि सिस्टीममधून मिळालेल्या तथ्यांची पडताळणी.

संधी जलद आणि स्वस्त गृहीतके तपासणे आणि त्यानुसार मानसिक मॉडेल सुधारणे कोनशिला डीबगिंग कोणतेही डीबगिंग साधन असावे परस्परसंवादी आणि शोध जागा अरुंद करा किंवा, खोट्या लीडच्या बाबतीत, वापरकर्त्याला मागे जाण्याची आणि सिस्टमच्या वेगळ्या क्षेत्रावर लक्ष केंद्रित करण्याची परवानगी द्या. परिपूर्ण साधन हे करेल सक्रियपणे, ताबडतोब वापरकर्त्याचे लक्ष संभाव्य समस्या क्षेत्राकडे वेधून घेते.

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

स्पॅन खूप खालच्या पातळीवर आहेत

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

शिवाय, मी खालील गोष्टी सांगण्याचे स्वातंत्र्य घेईन: आदर्शपणे, आम्हाला गरज नाही पूर्ण चित्र विनंती लाइफसायकल दरम्यान उद्भवली, जी आधुनिक ट्रेसिंग साधनांद्वारे दर्शविली जाते. त्याऐवजी, उच्च-स्तरीय अमूर्ततेचा काही प्रकार आवश्यक आहे ज्यामध्ये कशाची माहिती आहे चूक झाली (बॅकट्रेस सारखे), काही संदर्भांसह. संपूर्ण ट्रेस पाहण्याऐवजी, मी ते पाहणे पसंत करतो चा भाग, जिथे काहीतरी मनोरंजक किंवा असामान्य घडते. सध्या, शोध स्वहस्ते चालविला जातो: अभियंता ट्रेस प्राप्त करतो आणि स्वारस्यपूर्ण काहीतरी शोधण्यासाठी स्वतंत्रपणे स्पॅनचे विश्लेषण करतो. संशयास्पद क्रियाकलाप शोधण्याच्या आशेने वैयक्तिक ट्रेसमध्ये स्पॅन्सकडे पाहण्याचा दृष्टीकोन अजिबात मोजला जात नाही (विशेषत: जेव्हा त्यांना स्पॅन आयडी, RPC पद्धतीचे नाव, कालावधी कालावधी यासारख्या वेगवेगळ्या स्पॅनमध्ये एन्कोड केलेला सर्व मेटाडेटा समजून घ्यावा लागतो. 'a, logs, tags, इ.)

ट्रेसव्यूसाठी पर्याय

ट्रेस परिणाम सर्वात उपयुक्त असतात जेव्हा ते अशा प्रकारे दृश्यमान केले जाऊ शकतात जे सिस्टमच्या परस्पर जोडलेल्या भागांमध्ये काय घडत आहे याबद्दल गैर-क्षुल्लक अंतर्दृष्टी प्रदान करते. हे होईपर्यंत, डीबगिंग प्रक्रिया मोठ्या प्रमाणात राहते जड आणि योग्य परस्परसंबंध लक्षात घेण्याच्या, सिस्टमचे योग्य भाग तपासण्याच्या किंवा कोडेचे तुकडे एकत्र ठेवण्याच्या वापरकर्त्याच्या क्षमतेवर अवलंबून असते - उलट वाद्य, वापरकर्त्याला या गृहीतके तयार करण्यात मदत करणे.

मी व्हिज्युअल डिझायनर किंवा UX तज्ञ नाही, परंतु पुढील भागात मला हे व्हिज्युअलायझेशन कसे दिसतील याबद्दल काही कल्पना सामायिक करायच्या आहेत.

विशिष्ट सेवांवर लक्ष केंद्रित करा

अशा वेळी जेव्हा उद्योग कल्पनांभोवती एकत्रित होत आहे SLO (सेवा स्तर उद्दिष्टे) आणि SLI (सेवा स्तर निर्देशक), हे वाजवी दिसते की वैयक्तिक संघांनी त्यांच्या सेवा या उद्दिष्टांशी संरेखित असल्याची खात्री करून प्राधान्य दिले पाहिजे. ते त्याचे पालन करते सेवाभिमुख अशा संघांसाठी व्हिज्युअलायझेशन सर्वात योग्य आहे.

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

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

यापैकी काही प्रश्नांची उत्तरे अंगभूत मेट्रिक्सद्वारे दिली जात नाहीत, ज्यामुळे वापरकर्त्यांना स्पॅनची छाननी करण्यास भाग पाडले जाते. परिणामी, आमच्याकडे अत्यंत वापरकर्ता-विरोधी यंत्रणा आहे.

यामुळे प्रश्न निर्माण होतो: विविध संघांद्वारे नियंत्रित विविध सेवांमधील जटिल परस्परसंवादाचे काय? आहे ना ट्रेसव्ह्यू अशी परिस्थिती हायलाइट करण्यासाठी सर्वात योग्य साधन मानले जात नाही?

मोबाइल डेव्हलपर, स्टेटलेस सेवांचे मालक, व्यवस्थापित स्टेटफुल सेवांचे मालक (जसे की डेटाबेस) आणि प्लॅटफॉर्म मालकांना आणखी कशात तरी रस असू शकतो. सादरीकरण वितरण प्रणाली; ट्रेसव्ह्यू या मूलभूतपणे भिन्न गरजांसाठी खूप सामान्य उपाय आहे. अगदी क्लिष्ट मायक्रोसर्व्हिस आर्किटेक्चरमध्येही, सेवा मालकांना दोन किंवा तीनपेक्षा जास्त अपस्ट्रीम आणि डाउनस्ट्रीम सेवांचे सखोल ज्ञान आवश्यक नसते. मूलत:, बर्याच परिस्थितींमध्ये, वापरकर्त्यांना फक्त संबंधित प्रश्नांची उत्तरे देण्याची आवश्यकता असते सेवांचा मर्यादित संच.

हे छाननीच्या फायद्यासाठी भिंगाद्वारे सेवांचा एक छोटासा उपसंच पाहण्यासारखे आहे. हे वापरकर्त्याला या सेवा आणि त्यांच्या तात्काळ अवलंबित्वांमधील गुंतागुंतीच्या परस्परसंवादांबद्दल अधिक महत्त्वाचे प्रश्न विचारण्यास अनुमती देईल. हे सेवा जगतातील बॅकट्रेससारखेच आहे, जिथे अभियंता जाणतो की चुकीचे आहे, आणि समजण्यासाठी आसपासच्या सेवांमध्ये काय चालले आहे याची काही समज आहे का.

मी प्रचार करत असलेला दृष्टीकोन टॉप-डाउन, ट्रेसव्ह्यू-आधारित दृष्टिकोनाच्या अगदी विरुद्ध आहे, जेथे विश्लेषण संपूर्ण ट्रेससह सुरू होते आणि नंतर हळूहळू वैयक्तिक स्पॅनवर कार्य करते. याउलट, घटनेच्या संभाव्य कारणाच्या जवळ असलेल्या लहान क्षेत्राचे विश्लेषण करून तळ-अप दृष्टिकोन सुरू होतो आणि नंतर आवश्यकतेनुसार शोध जागा विस्तृत करतो (सेवांच्या विस्तृत श्रेणीचे विश्लेषण करण्यासाठी इतर संघ आणण्याच्या संभाव्यतेसह). प्रारंभिक गृहीतके त्वरीत तपासण्यासाठी दुसरा दृष्टीकोन अधिक योग्य आहे. एकदा ठोस परिणाम प्राप्त झाल्यानंतर, अधिक लक्ष्यित आणि तपशीलवार विश्लेषणाकडे जाणे शक्य होईल.

टोपोलॉजी तयार करणे

वापरकर्त्याला माहित असल्यास सेवा-विशिष्ट दृश्ये आश्चर्यकारकपणे उपयुक्त असू शकतात कोणत्या एक सेवा किंवा सेवांचा समूह विलंब वाढवण्यासाठी किंवा त्रुटी निर्माण करण्यासाठी जबाबदार आहे. तथापि, एका जटिल प्रणालीमध्ये, अपयशाच्या वेळी आक्षेपार्ह सेवा ओळखणे हे एक क्षुल्लक कार्य असू शकते, विशेषत: जर सेवांकडून कोणतेही त्रुटी संदेश नोंदवले गेले नाहीत.

सेवा टोपोलॉजी तयार करणे ही कोणत्या सेवेमध्ये त्रुटी दरांमध्ये वाढ होत आहे किंवा विलंबतेमध्ये वाढ होत आहे ज्यामुळे सेवेचे लक्षणीय ऱ्हास होत आहे हे शोधण्यात मोठी मदत होऊ शकते. जेव्हा मी टोपोलॉजी तयार करण्याबद्दल बोलतो तेव्हा मला असे म्हणायचे नाही सेवा नकाशा, प्रणालीमध्ये उपलब्ध असलेली प्रत्येक सेवा प्रदर्शित करत आहे आणि त्यासाठी प्रसिद्ध आहे डेथ स्टारच्या आकारात आर्किटेक्चरचे नकाशे. हे दृश्य निर्देशित अॅसायक्लिक आलेखावर आधारित ट्रेसव्ह्यूपेक्षा चांगले नाही. त्याऐवजी मला बघायला आवडेल डायनॅमिकली व्युत्पन्न सेवा टोपोलॉजी, त्रुटी दर, प्रतिसाद वेळ, किंवा विशिष्ट संशयास्पद सेवांसह परिस्थिती स्पष्ट करण्यात मदत करणारे कोणतेही वापरकर्ता-परिभाषित पॅरामीटर यासारख्या विशिष्ट वैशिष्ट्यांवर आधारित.

एक उदाहरण घेऊ. काल्पनिक बातम्या साइटची कल्पना करूया. मुख्यपृष्ठ सेवा (पहिले पान) Redis सह डेटाची देवाणघेवाण, शिफारस सेवेसह, जाहिरात सेवा आणि व्हिडिओ सेवेसह. व्हिडिओ सेवा S3 वरून व्हिडिओ आणि DynamoDB वरून मेटाडेटा घेते. शिफारस सेवा DynamoDB कडून मेटाडेटा प्राप्त करते, Redis आणि MySQL वरून डेटा लोड करते आणि काफ्काला संदेश लिहिते. जाहिरात सेवा MySQL कडून डेटा प्राप्त करते आणि काफ्काला संदेश लिहिते.

खाली या टोपोलॉजीचे एक योजनाबद्ध प्रतिनिधित्व आहे (अनेक व्यावसायिक रूटिंग प्रोग्राम टोपोलॉजी तयार करतात). सेवा अवलंबित्व समजून घेणे आवश्यक असल्यास ते उपयुक्त ठरू शकते. तथापि, दरम्यान डीबग, जेव्हा एखादी विशिष्ट सेवा (म्हणे, व्हिडिओ सेवा) प्रतिसाद वेळ वाढवते तेव्हा असे टोपोलॉजी फारसे उपयुक्त नसते.

काल्पनिक बातम्या साइटचा सेवा आकृती

खालील आकृती अधिक योग्य असेल. सेवेत समस्या आहे (व्हिडिओ) अगदी मध्यभागी चित्रित. वापरकर्त्याच्या लगेच लक्षात येते. या व्हिज्युअलायझेशनवरून, हे स्पष्ट होते की S3 प्रतिसाद वेळेत वाढ झाल्यामुळे व्हिडिओ सेवा असामान्यपणे कार्य करत आहे, ज्यामुळे मुख्य पृष्ठाच्या काही भागाच्या लोडिंग गतीवर परिणाम होतो.

डायनॅमिक टोपोलॉजी फक्त "रुचीपूर्ण" सेवा प्रदर्शित करते

डायनॅमिकली व्युत्पन्न टोपोलॉजी स्थिर सेवा नकाशांपेक्षा अधिक कार्यक्षम असू शकतात, विशेषत: लवचिक, स्वयं-स्केलिंग पायाभूत सुविधांमध्ये. सर्व्हिस टोपोलॉजीची तुलना आणि कॉन्ट्रास्ट करण्याची क्षमता वापरकर्त्याला अधिक संबंधित प्रश्न विचारू देते. प्रणालीबद्दल अधिक अचूक प्रश्नांमुळे प्रणाली कशी कार्य करते हे अधिक चांगल्या प्रकारे समजून घेण्याची शक्यता असते.

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

आणखी एक उपयुक्त व्हिज्युअलायझेशन तुलनात्मक प्रदर्शन असेल. सध्या ट्रेस शेजारी-बाय-साइड तुलनांसाठी फारसे योग्य नाहीत, त्यामुळे तुलना सहसा पसरणे. आणि या लेखाची मुख्य कल्पना तंतोतंत अशी आहे की ट्रेस परिणामांमधून सर्वात मौल्यवान माहिती काढण्यासाठी स्पॅन्स खूप कमी-स्तरीय आहेत.

दोन ट्रेसची तुलना करण्यासाठी मूलभूतपणे नवीन व्हिज्युअलायझेशनची आवश्यकता नाही. खरं तर, ट्रेसव्ह्यू सारखीच माहिती दर्शविणारे हिस्टोग्राम सारखे काहीतरी पुरेसे आहे. आश्चर्याची गोष्ट म्हणजे, ही साधी पद्धत देखील फक्त दोन ट्रेसचा स्वतंत्रपणे अभ्यास करण्यापेक्षा बरेच फळ आणू शकते. त्याहूनही अधिक शक्तिशाली शक्यता असेल कल्पना करणे ट्रेसची तुलना एकूण. GC (कचरा संकलन) सक्षम करण्यासाठी अलीकडे तैनात केलेला डेटाबेस कॉन्फिगरेशन बदल अनेक तासांच्या प्रमाणात डाउनस्ट्रीम सेवेच्या प्रतिसाद वेळेवर कसा परिणाम करतो हे पाहणे अत्यंत उपयुक्त ठरेल. मी येथे जे वर्णन करत आहे ते पायाभूत सुविधांच्या बदलांच्या परिणामाचे A/B विश्लेषण वाटत असल्यास अनेक सेवांमध्ये ट्रेस परिणाम वापरून, नंतर तुम्ही सत्यापासून फार दूर नाही.

निष्कर्ष

मी स्वतः ट्रेसिंगच्या उपयुक्ततेवर शंका घेत नाही. माझा प्रामाणिकपणे विश्वास आहे की ट्रेसमध्ये समाविष्ट असलेल्या समृद्ध, कारणात्मक आणि संदर्भित डेटा गोळा करण्यासाठी दुसरी कोणतीही पद्धत नाही. तथापि, माझा असा विश्वास आहे की सर्व ट्रेसिंग सोल्यूशन्स हा डेटा अत्यंत अकार्यक्षमपणे वापरतात. जोपर्यंत ट्रेसिंग साधने ट्रेसव्ह्यू प्रतिनिधित्वावर अडकून राहतात, तोपर्यंत ट्रेसमध्ये समाविष्ट असलेल्या डेटामधून काढता येणारी मौल्यवान माहिती वापरण्याची त्यांची क्षमता मर्यादित असेल. या व्यतिरिक्त, एक पूर्णपणे मैत्रीहीन आणि अज्ञानी व्हिज्युअल इंटरफेस विकसित होण्याचा धोका आहे जो अनुप्रयोगातील त्रुटींचे निवारण करण्याच्या वापरकर्त्याच्या क्षमतेस कठोरपणे मर्यादित करेल.

अगदी नवीनतम साधनांसह जटिल प्रणाली डीबग करणे आश्चर्यकारकपणे कठीण आहे. साधनांनी विकासकाला गृहीतक तयार करण्यात आणि चाचणी करण्यात मदत केली पाहिजे, सक्रियपणे प्रदान करते संबंधित माहिती, आउटलियर्स ओळखणे आणि विलंब वितरणातील वैशिष्ट्ये लक्षात घेणे. उत्पादनातील अपयशांचे निवारण करताना किंवा एकाधिक सेवांचा विस्तार करणार्‍या समस्यांचे निराकरण करताना विकासकांसाठी निवडीचे साधन बनण्यासाठी ट्रेसिंगसाठी, मूळ वापरकर्ता इंटरफेस आणि व्हिज्युअलायझेशन आवश्यक आहेत जे त्या सेवा तयार आणि ऑपरेट करणार्‍या विकासकांच्या मानसिक मॉडेलशी अधिक सुसंगत आहेत.

विश्लेषण आणि अनुमान सुलभतेसाठी अनुकूल अशा प्रकारे ट्रेस परिणामांमध्ये उपलब्ध असलेल्या विविध सिग्नल्सचे प्रतिनिधित्व करणारी प्रणाली तयार करण्यासाठी महत्त्वपूर्ण मानसिक प्रयत्न करावे लागतील. डीबगिंग दरम्यान सिस्टम टोपोलॉजीचे सार कसे काढायचे याचा विचार करणे आवश्यक आहे जे वापरकर्त्याला वैयक्तिक ट्रेस किंवा स्पॅन्स न पाहता ब्लाइंड स्पॉट्सवर मात करण्यास मदत करते.

आम्हाला चांगल्या अॅब्स्ट्रॅक्शन आणि लेयरिंग क्षमतांची आवश्यकता आहे (विशेषतः UI मध्ये). एक गृहीतक-चालित डीबगिंग प्रक्रियेमध्ये योग्यरित्या बसतील जेथे आपण पुनरावृत्तीने प्रश्न विचारू शकता आणि गृहीतके तपासू शकता. ते सर्व निरीक्षणक्षमतेच्या समस्या आपोआप सोडवणार नाहीत, परंतु ते वापरकर्त्यांना त्यांची अंतर्ज्ञान तीक्ष्ण करण्यास आणि हुशार प्रश्न तयार करण्यात मदत करतील. मी व्हिज्युअलायझेशनसाठी अधिक विचारशील आणि नाविन्यपूर्ण दृष्टिकोनासाठी कॉल करतो. क्षितिजांचा विस्तार करण्यासाठी येथे खरी संभावना आहे.

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• «कुबर्नेट्स पॉड्समध्ये डीबगिंगसाठी kubectl-debug प्लगइन";
• «मायक्रोसर्व्हिसेस: तुमच्याकडे कुबर्नेट्स असले तरीही आकार महत्त्वाचा";
• «देखरेख आणि कुबर्नेट्स (पुनरावलोकन आणि व्हिडिओ अहवाल)».

स्त्रोत: www.habr.com