इस्टियो ट्रेसिंग एंड मॉनिटरिंग: माइक्रोसर्विसेस एंड द अनसेंटी प्रिंसिपल

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



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

पारिभाषिक शब्दावली को परिभाषित कीजिए

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

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

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

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

निक्कर छोड़ो

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


निम्नलिखित हेडर सेटिंग्स का उपयोग किया जाता है:


यदि आप जावा का उपयोग करते हैं, तो आप कोड को अछूता छोड़ सकते हैं, बस मावेन पोम फ़ाइल में कुछ लाइनें जोड़ सकते हैं और पर्यावरण चर सेट कर सकते हैं। यहां वे पंक्तियाँ हैं जो आपको जैमर ट्रेसर रिज़ॉल्वर को लागू करने के लिए POM.XML फ़ाइल में जोड़ने की आवश्यकता है:


और संबंधित पर्यावरण चर डॉकफाइल में सेट किए गए हैं:


बस यही है, अब यह सब सेट अप हो गया है, और हमारे माइक्रोसर्विसेज ट्रेस डेटा जनरेट करने लगेंगे।

हम सामान्य शब्दों में देखते हैं

इस्तियो में ग्राफाना पर आधारित एक सरल नियंत्रण कक्ष शामिल है। जब सब कुछ Red Hat OpenShift Paa प्लेटफ़ॉर्म पर कॉन्फ़िगर किया गया और चल रहा है (हमारे उदाहरण में, Red Hat OpenShift और Kubernetes को minishift पर तैनात किया गया है), इस पैनल को निम्न कमांड के साथ लॉन्च किया गया है:

open "$(minishift openshift service grafana -u)/d/1/istio-dashboard?refresh=5⩝Id=1" 

ग्राफाना पैनल आपको सिस्टम का त्वरित मूल्यांकन करने की अनुमति देता है। इस पैनल का एक टुकड़ा नीचे चित्र में दिखाया गया है:


यहां आप देख सकते हैं कि माइक्रो सर्विस ग्राहक microservice वरीयता v1 को कॉल करता है, और बदले में माइक्रोसर्विस सिफारिश v1 और v2 को कॉल करता है। ग्राफाना पैनल में उच्च-स्तरीय मीट्रिक के लिए डैशबोर्ड रो ब्लॉक है, जैसे अनुरोधों की कुल संख्या (वैश्विक अनुरोध मात्रा), सफल अनुरोधों का प्रतिशत (सफलता दर), 4xx त्रुटियां। इसके अलावा, प्रत्येक सेवा के लिए ग्राफ़ के साथ एक सर्वर मेष दृश्य और प्रत्येक सेवा के लिए प्रत्येक कंटेनर के लिए विस्तृत जानकारी देखने के लिए एक सेवा पंक्ति ब्लॉक है।

अब गहरी खुदाई करें

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

 minishift openshift service jaeger-query --in-browser 

इस स्क्रीन पर ट्रेस के बारे में क्या कहा जा सकता है:

• इसे 7 स्पैन में विभाजित किया गया है।
• कुल निष्पादन समय 6.99 एमएस है।
• माइक्रोसेर की सिफारिश, जो श्रृंखला में अंतिम है, 0.69 एमएस लेता है।

इस प्रकार के आरेख आपको ऐसी स्थिति का शीघ्रता से पता लगाने की अनुमति देते हैं जहां पूरी प्रणाली का प्रदर्शन एक एकल खराब सेवा के कारण होता है।

अब आइए कार्य को जटिल करते हैं और अनुशंसा के दो उदाहरणों को लॉन्च करते हैं microservice: v2 with oc scale --replicas = 2 तैनाती / अनुशंसा-v2 कमांड। इसके बाद हमारे पास मौजूद फली हैं:


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

सब कुछ कहाँ और कैसे जाता है

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

यह केवल शुरुआत है

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

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

कम से कम सवालों के जवाब देने के लिए हमेशा "कहाँ?" और "कितनी जल्दी?" 100% निश्चितता के साथ।

इस्तियो में अराजकता इंजीनियरिंग: यह कल्पना की गई थी

चीजों को तोड़ने की क्षमता यह सुनिश्चित करने में मदद करती है कि वे टूट न जाएं

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

और अब हम दिखाएंगे कि कैसे इस्तियो इन कठिनाइयों से एक-दो का सामना करने में मदद करती है।

जब सब ठीक है तो कैसा लग रहा है

इस परिदृश्य पर विचार करें: हमारे पास हमारे अनुशंसा microservice के लिए दो पॉड हैं, जिसे हमने Istio ट्यूटोरियल से लिया था। एक पॉड को v1 और दूसरे को v2 के रूप में चिह्नित किया गया है। जैसा कि आप देख सकते हैं, जबकि सब कुछ ठीक काम करता है:


(वैसे, दाईं ओर की संख्या प्रत्येक पॉड के लिए एक कॉल काउंटर है)

लेकिन हमें इसकी आवश्यकता नहीं है, क्या यह है? खैर, चलो स्रोत कोड को छूने के बिना सब कुछ तोड़ने की कोशिश करते हैं।

हम माइक्रो सर्विस के काम में रुकावट की व्यवस्था करते हैं

नीचे Istio रूटिंग नियम के लिए yaml फ़ाइल है, जो आधे मामलों में विफल हो जाएगी (सर्वर त्रुटि 503):


कृपया ध्यान दें कि हम स्पष्ट रूप से लिखते हैं कि आधे मामलों में त्रुटि 503 वापस आनी चाहिए।

और यहां हम लूप में लॉन्च किए गए कर्ल कमांड का एक स्क्रीनशॉट है, जब हम विफलताओं को अनुकरण करने के लिए इस नियम को सक्रिय करते हैं। जैसा कि आप देख सकते हैं, अनुरोधों में से आधे में त्रुटि 503 है, और इसकी परवाह किए बिना कि फली - v1 या v2 - वे कहां जाते हैं:


सामान्य ऑपरेशन को पुनर्स्थापित करने के लिए, इस नियम को हटाने के लिए पर्याप्त है, हमारे मामले में, आइसटियोक्लेट डिलीट राउटर्यूल सिफारिश -503-एन ट्यूटोरियल कमांड। यहाँ ट्यूटोरियल Red Hat OpenShift प्रोजेक्ट का नाम है, जो हमारे Istio ट्यूटोरियल को चलाता है।

कृत्रिम विलंब बनाना

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

कृपया ध्यान दें कि इस तरह के परीक्षण के बाद, आपको अपने कोड को परिष्कृत करने की आवश्यकता हो सकती है (या चाहते हैं)। अच्छी खबर यह है, इस मामले में आप प्रतिक्रियात्मक रूप से कार्य करेंगे, न कि प्रतिक्रियात्मक रूप से। यह है कि विकास चक्र कैसे बनाया जाना चाहिए: कोडिंग-परीक्षण-प्रतिक्रिया-कोडिंग-परीक्षण ...

यह वही है जो नियम जैसा दिखता है ... हालांकि आप जानते हैं कि क्या है? इस्तियो इतना सरल है, और यह यमल फ़ाइल इतनी स्पष्ट है कि इस उदाहरण में सब कुछ खुद के लिए बोलता है, बस एक नज़र डालें:


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


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

वापस मत करो और हार मत मानो

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

इसलिए, हम चाहते हैं कि सेवा समय-समय पर 503 त्रुटि दे, और उसके बाद इस्तियो फिर से उससे संपर्क करने की कोशिश करेगी। और यहां हमें स्पष्ट रूप से कोड को छूने के बिना, त्रुटि 503 उत्पन्न करने का एक तरीका चाहिए ...

रुकिए रुकिए! हमने बस कर दिया।

यह फ़ाइल अनुशंसा-v2 सेवा आधे मामले में 503 त्रुटि उत्पन्न करेगी:


जाहिर है, अनुरोधों का हिस्सा विफल हो जाएगा:


और अब हम Retry Istio फ़ंक्शन का उपयोग करेंगे:


यह रूटिंग नियम दो-सेकंड के अंतराल के साथ तीन रिट्रीट करता है और इसे कम करना चाहिए (और आदर्श रूप से रडार से पूरी तरह से हटा दें)


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

और हां, हमने इसे फिर से कोड को छूने के बिना किया। हम सभी की जरूरत दो Istio रूटिंग नियम थे:

कैसे एक उपयोगकर्ता को नीचे या सात इंतज़ार न करने दें

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

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

इसलिए, हमने अनुशंसा v2 सेवा कोड में तीन सेकंड की नींद सम्मिलित की, संबंधित छवि को फिर से बनाया और एक कंटेनर को फिर से बनाया, और अब हम निम्नलिखित इस्तियो रूटिंग नियम का उपयोग करके एक टाइमआउट जोड़ेंगे:


ऊपर दिए गए स्क्रीनशॉट से पता चलता है कि हम अनुशंसा सेवा से संपर्क करने की कोशिश कर रहे हैं यदि हमें एक सेकंड के भीतर प्रतिक्रिया नहीं मिलती है, अर्थात, त्रुटि 504 होने से पहले। इस रूलिंग नियम को लागू करने के बाद (और सिफारिश सेवा कोड में तीन सेकंड की नींद जोड़कर। : v2), हम इसे प्राप्त करते हैं:


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

और अब सब एक साथ

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