वितरित ट्रेसिङ: हामीले यो सबै गलत गर्यौं

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

[बाट लिइएको दृष्टान्त अन्य सामग्री वितरित ट्रेसिङ बारे।]

यो विश्वास छ ट्रेसिङ वितरित कार्यान्वयन गर्न गाह्रो छ, र यसको प्रतिफल सबै भन्दा राम्रो मा संदिग्ध। त्यहाँ धेरै कारणहरू छन् किन ट्रेसिङ समस्याग्रस्त छ, प्रायः प्रत्येक अनुरोधको साथ उपयुक्त हेडरहरू प्रसारण गर्न प्रत्येक प्रणाली कम्पोनेन्ट कन्फिगर गर्न संलग्न श्रमलाई उद्धृत गर्दै। यद्यपि यो समस्या अवस्थित छ, यो कुनै पनि हालतमा समाधान गर्न योग्य छैन। वैसे, यसले विकासकर्ताहरूले किन ट्रेसिङ मन पराउँदैनन् (यसले पहिले नै काम गरिरहेको बेला पनि) व्याख्या गर्दैन।

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

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

यस्तो फरक ट्रेस

वितरित ट्रेसिङले धेरै भिन्न घटकहरू समावेश गर्दछ:

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

वितरित ट्रेसिङको बारेमा धेरै कुराहरूले यसलाई एक प्रकारको अनरी अपरेशनको रूपमा व्यवहार गर्दछ जसको एकमात्र उद्देश्य प्रणालीलाई पूर्ण रूपमा निदान गर्न मद्दत गर्नु हो। यो धेरै हदसम्म वितरित ट्रेसिङको बारेमा विचारहरू ऐतिहासिक रूपमा गठन भएको कारण हो। IN ब्लग प्रविष्टिहरूजिपकिन खोलिदै गर्दा बनेको भन्ने उल्लेख थियो यसले [जिपकिन] ट्विटरलाई छिटो बनाउँछ। ट्रेसिङको लागि पहिलो व्यावसायिक प्रस्तावहरू पनि रूपमा प्रचार गरिएको थियो APM उपकरणहरू.

नोट। अनुवाद।: थप पाठ बुझ्न सजिलो बनाउन, हामी अनुसार दुई आधारभूत सर्तहरू परिभाषित गरौं OpenTracing परियोजना दस्तावेज:

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

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

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

माथि सूचीबद्ध विकल्पहरू मध्ये कुनै पनि परिदृश्यमा पूर्ण रूपमा लागू हुँदैन डिबग, जसको समयमा इन्जिनियरले ट्रेस हेरेर समस्या समाधान गर्ने प्रयास गर्दछ।

जब आउँछ अझै डिबगिङ स्क्रिप्टमा पुग्छ, प्राथमिक इन्टरफेस रेखाचित्र नै रहन्छ ट्रेसदृश्य (यद्यपि केहीले यसलाई पनि बोलाउँछन् "Gantt चार्ट" वा "झरना रेखाचित्र")। अन्तर्गत ट्रेसदृश्य я मेरो मतलब सबै स्प्यान र सँगैको मेटाडेटा जसले ट्रेस बनाउँछ। प्रत्येक खुला स्रोत ट्रेसिङ प्रणाली, साथै प्रत्येक व्यावसायिक ट्रेसिङ समाधान, प्रदान गर्दछ ट्रेसदृश्य दृश्य, विवरण र फिल्टर ट्रेस लागि प्रयोगकर्ता इन्टरफेस।

मैले अहिलेसम्म देखेको सबै ट्रेसिङ प्रणालीहरूको समस्या भनेको परिणाम हो दृश्यावलोकन (ट्रेसभ्यू) लगभग पूर्ण रूपमा ट्रेस उत्पादन प्रक्रिया को विशेषताहरु प्रतिबिम्बित गर्दछ। वैकल्पिक भिजुअलाइजेसनहरू प्रस्तावित भए तापनि: तापम्यापहरू, सेवा टोपोलोजीहरू, विलम्बता हिस्टोग्रामहरू, तिनीहरू अझै पनि अन्ततः तल आउँछन्। ट्रेसदृश्य.

विगतमा म गुनासो गरे जसमा UI/UX ट्रेसिङमा धेरै "नव आविष्कारहरू" सीमित देखिन्छन् खोल्दै ट्रेसमा अतिरिक्त मेटाडेटा, उच्च कार्डिनलिटीको साथ जानकारीमा लगानी गर्दै (उच्च कार्डिनलिटी) वा विशिष्ट स्प्यानहरूमा ड्रिल डाउन वा क्वेरीहरू चलाउने क्षमता प्रदान गर्दै अन्तर- र अन्तर-ट्रेस... जसमा ट्रेसदृश्य प्राथमिक दृश्य उपकरण रहन्छ। जबसम्म यो अवस्था जारी रहन्छ, वितरित ट्रेसिङले मेट्रिक्स, लगहरू र स्ट्याक ट्रेसहरू पछि, डिबगिङ उपकरणको रूपमा (उत्तम रूपमा) चौथो स्थान लिनेछ, र सबैभन्दा खराबमा यो पैसा र समयको बर्बादीमा परिणत हुनेछ।

ट्रेसभ्यूको साथ समस्या

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

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

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

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

अर्को कारण मलाई लाग्छ कि ट्रेसभ्यू गलत छ किनभने यो परिकल्पना-संचालित डिबगिङको लागि राम्रो छैन। यसको मूल मा, डिबगिंग छ पुनरावृत्ति परिकल्पनाबाट सुरु हुने प्रक्रिया, विभिन्न भेक्टरहरू, निष्कर्षहरू/सामान्यीकरणहरू र परिकल्पनाको सत्यताको थप मूल्याङ्कनसँगै प्रणालीबाट प्राप्त विभिन्न अवलोकन र तथ्यहरूको प्रमाणीकरण पछि।

अवसर छिटो र सस्तो परिकल्पना परीक्षण र तदनुसार मानसिक मोडेल सुधार छ आधारशिला डिबगिङ कुनै पनि डिबगिङ उपकरण हुनुपर्छ अन्तरक्रियात्मक र खोजी ठाउँ साँघुरो पार्नुहोस् वा, गलत नेतृत्वको अवस्थामा, प्रयोगकर्तालाई पछाडि जान र प्रणालीको फरक क्षेत्रमा फोकस गर्न अनुमति दिनुहोस्। उत्तम उपकरणले यो गर्नेछ सक्रिय रूपमा, तत्काल सम्भावित समस्या क्षेत्रहरूमा प्रयोगकर्ताको ध्यान आकर्षित।

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

स्प्यान्स धेरै कम स्तर छन्

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

यसबाहेक, म निम्न दाबी गर्ने स्वतन्त्रता लिनेछु: आदर्श रूपमा, हामीलाई आवश्यक छैन पूरा तस्वीर अनुरोध जीवनचक्रको समयमा भयो, जुन आधुनिक ट्रेसिङ उपकरणहरूद्वारा प्रतिनिधित्व गरिएको छ। यसको सट्टा, उच्च-स्तर अमूर्तता को केहि रूप आवश्यक छ जसमा के बारे जानकारी समावेश छ गलत भयो (ब्याकट्रेस जस्तै), केहि सन्दर्भ सहित। सम्पूर्ण ट्रेस हेर्नुको सट्टा, म यसलाई हेर्न रुचाउँछु को भाग, जहाँ केहि रोचक वा असामान्य हुन्छ। हाल, खोज म्यानुअल रूपमा गरिन्छ: इन्जिनियरले ट्रेस प्राप्त गर्दछ र स्वतन्त्र रूपमा केहि रोचक खोजीमा स्प्यानहरू विश्लेषण गर्दछ। शंकास्पद गतिविधि पत्ता लगाउने आशामा स्प्यानहरूमा व्यक्तिगत ट्रेसहरूमा हेरिरहेका मानिसहरूको दृष्टिकोणले मापन गर्दैन (विशेष गरी जब तिनीहरूले विभिन्न स्प्यानहरूमा इन्कोड गरिएका सबै मेटाडेटाहरू बुझ्नुपर्छ, जस्तै span ID, RPC विधि नाम, स्प्यान अवधि। 'a, लग, ट्याग, आदि)।

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

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

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

विशेष सेवाहरूमा फोकस गर्नुहोस्

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

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

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

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

यसले प्रश्न उठाउँछ: विभिन्न टोलीहरूद्वारा नियन्त्रित विविध सेवाहरू बीचको जटिल अन्तरक्रियाको बारेमा के हो? हैन त ट्रेसदृश्य यस्तो अवस्था हाइलाइट गर्न सबैभन्दा उपयुक्त उपकरण मानिँदैन?

मोबाइल विकासकर्ताहरू, राज्यविहीन सेवाहरूका मालिकहरू, व्यवस्थित राज्य सेवाहरूका मालिकहरू (जस्तै डाटाबेसहरू) र प्लेटफर्म मालिकहरूले अरू कुरामा चासो राख्न सक्छन्। प्रस्तुति वितरण प्रणाली; ट्रेसदृश्य यी मौलिक रूपमा फरक आवश्यकताहरूको लागि धेरै सामान्य समाधान हो। धेरै जटिल माइक्रोसर्भिस आर्किटेक्चरमा पनि, सेवा मालिकहरूलाई दुई वा तीन भन्दा बढी अपस्ट्रीम र डाउनस्ट्रीम सेवाहरूको गहिरो ज्ञान आवश्यक पर्दैन। अनिवार्य रूपमा, धेरै परिदृश्यहरूमा, प्रयोगकर्ताहरूले मात्र सम्बन्धित प्रश्नहरूको जवाफ दिन आवश्यक छ सेवाहरूको सीमित सेट.

यो छानबिनको लागि म्याग्निफाइङ्ग ग्लास मार्फत सेवाहरूको सानो उपसमूह हेर्नु जस्तै हो। यसले प्रयोगकर्तालाई यी सेवाहरू र तिनीहरूको तत्काल निर्भरताहरू बीचको जटिल अन्तरक्रियाको सन्दर्भमा थप दबाबपूर्ण प्रश्नहरू सोध्न अनुमति दिनेछ। यो सेवा संसारमा ब्याकट्रेस जस्तै छ, जहाँ इन्जिनियरलाई थाहा छ कि गलत, र बुझ्नको लागि वरपरका सेवाहरूमा के भइरहेको छ भन्ने बारे केही बुझाइ पनि छ किन.

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

टोपोलोजी निर्माण गर्दै

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

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

एउटा उदाहरण लिऔं। एक काल्पनिक समाचार साइट कल्पना गरौं। गृह पृष्ठ सेवा (अगाडिको पाना) Redis सँग डेटा आदानप्रदान गर्दछ, सिफारिस सेवाको साथ, विज्ञापन सेवा र भिडियो सेवाको साथ। भिडियो सेवाले S3 बाट भिडियोहरू र DynamoDB बाट मेटाडेटा लिन्छ। सिफारिस सेवाले DynamoDB बाट मेटाडेटा प्राप्त गर्दछ, Redis र MySQL बाट डाटा लोड गर्दछ, र काफ्कालाई सन्देशहरू लेख्छ। विज्ञापन सेवाले MySQL बाट डाटा प्राप्त गर्छ र काफ्कालाई सन्देशहरू लेख्छ।

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

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

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

गतिशील टोपोलोजी मात्र "रोचक" सेवाहरू प्रदर्शन गर्दै

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

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

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

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

निष्कर्षमा

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

जटिल प्रणालीहरू डिबग गर्न, नवीनतम उपकरणहरूसँग पनि, अविश्वसनीय रूपमा गाह्रो छ। उपकरणहरूले विकासकर्तालाई परिकल्पना तयार गर्न र परीक्षण गर्न मद्दत गर्नुपर्छ, सक्रिय रूपमा प्रदान गर्दै सान्दर्भिक जानकारी, आउटलियरहरू पहिचान गर्ने र ढिलाइको वितरणमा विशेषताहरू नोट गर्ने। उत्पादन विफलताहरूको समस्या निवारण गर्दा वा धेरै सेवाहरू फैलाउने समस्याहरू समाधान गर्दा विकासकर्ताहरूको छनौटको उपकरण बन्नको लागि ट्रेसिङको लागि, ती सेवाहरू सिर्जना गर्ने र सञ्चालन गर्ने विकासकर्ताहरूको मानसिक मोडेलसँग अधिक अनुरूप मौलिक प्रयोगकर्ता इन्टरफेसहरू र दृश्यहरू आवश्यक हुन्छन्।

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

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

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Kubernetes pods मा डिबग गर्न को लागी kubectl-debug प्लगइन»;
• «Microservices: साइजको महत्व हुन्छ, यदि तपाईंसँग Kubernetes छ भने पनि»;
• «निगरानी र Kubernetes (समीक्षा र भिडियो रिपोर्ट)"।

स्रोत: www.habr.com