व्यवहार में अवलोकनशीलता की ओर एक दृष्टिकोण

2019 में सॉफ्टवेयर इन्फ्रास्ट्रक्चर में प्रमुख रुझानों में से एक अवलोकन है ।

इसने हाल ही में बहुत ध्यान आकर्षित किया है।

अवलोकन क्या है?

इस शब्द को लेकर काफी चर्चाएं और चुटकुले चल रहे हैं। उदाहरण के लिए:

• इसे निगरानी क्यों कहते हैं? वो अब ज्यादा सेक्सी नहीं है।
• ऑब्जर्वबिलिटी, क्योंकि ऑप्स को देवो के रूप में रीब्रांड करना काफी बुरा नहीं था, अब वे निगरानी को भी विचलित कर रहे हैं।
• DevOps का नया चक नॉरिस।
• मैं एक इंजीनियर हूं जो संगठन में अन्य इंजीनियरों को निगरानी प्रदान करने में मदद कर सकता हूं।
• > महान, यहाँ $ 80k है।
• मैं एक वास्तुकार हूं जो क्लाउड-देशी, कंटेनर-आधारित अनुप्रयोगों के लिए अवलोकन प्रदान कर सकता है।
• > बहुत बढ़िया! यहाँ $ 300k है!

सिंडी श्रीधरन

यदि एक हो तो निगरानी और अवलोकनशीलता में क्या अंतर है?

खोज रहे हैं ...

सालों पहले, हम ज्यादातर अपना सॉफ्टवेयर भौतिक सर्वर पर चलाते थे। हमारे अनुप्रयोग मोनोलिथ थे जिन्हें LAMP या अन्य ढेर पर बनाया गया था। अपटाइम की जाँच करना नियमित पिंग भेजने और अपने आवेदन के लिए सीपीयू / डिस्क के उपयोग की जाँच करने के समान सरल था।

प्रतिमान बदलाव

मुख्य प्रतिमान बुनियादी ढांचे और वास्तुकला के क्षेत्रों से आया है। क्लाउड आर्किटेक्चर, माइक्रोसर्विसेस, कुबेरनेट्स और अपरिवर्तनीय बुनियादी ढांचे ने कंपनियों के निर्माण और संचालन के तरीके को बदल दिया।



इन नए विचारों को अपनाने के परिणामस्वरूप, हमने जो सिस्टम बनाए हैं, वे अधिक से अधिक वितरित और अल्पकालिक हो गए हैं।

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

अंतर्निहित हार्डवेयर और नेटवर्किंग से अमूर्तता की ओर बढ़ने का मतलब है कि हमें यह सुनिश्चित करने पर ध्यान केंद्रित करना चाहिए कि हमारे अनुप्रयोग हमारी व्यावसायिक प्रक्रियाओं के संदर्भ में काम करते हैं।

निगरानी क्या है?

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



मुख्य मुद्दा यह है कि उत्पादन में संभावित समस्याओं की मात्रा को किसी भी तरह से परीक्षण के साथ कवर नहीं किया जा सकता है। एक परिपक्व, स्थिर प्रणाली में अधिकांश समस्याएं अज्ञात-अज्ञात हैं जो न केवल सॉफ्टवेयर विकास से संबंधित हैं, बल्कि वास्तविक दुनिया से भी संबंधित हैं।

ब्लैक बॉक्स बनाम। सफेद बॉक्स की निगरानी

निगरानी के लिए दो दृष्टिकोण हैं।

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



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



तो, सफेद बॉक्स की निगरानी के लिए अवलोकन एक और नाम है? काफी नहीं है।

हमें निगरानी की एक नई तरह की आवश्यकता क्यों है

अक्सर, निगरानी और अवलोकन की अवधारणा के बीच एक अंतर किया जाता है, बाद के रूप में परिभाषित कुछ के साथ जो कि बुनियादी ढांचे / क्षुधा और प्रदर्शन के निशान के बारे में एक तरह से डेटा एकत्र करता है या किसी अन्य (https://thenewstack.io/monitoring-and) -बहुत-अक्षमता-व्हाट्स-ऑफ-द-डिफरेंस-एंड-व्हाट्स-इट-मैटर /)।

या, मधुकोश के अनुसार:

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

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

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

क्यों डैशबोर्ड बेकार हैं

वास्तव में, वे नहीं हैं। लेकिन केवल अगर आप जानते हैं कि कब और कहाँ देखना है। अन्यथा, YouTube देखना बेहतर है।

डैशबोर्ड पैमाने नहीं हैं।

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

आप अपनी निगरानी में तृतीय-पक्ष एकीकरण सेवा चेक जोड़ने का निर्णय लेते हैं और अपने टीवी सेट पर मैट्रिक्स और डैशबोर्ड का एक अतिरिक्त गुच्छा प्राप्त करते हैं। जब तक अगला मामला सामने नहीं आ जाता।

यह पूछे जाने पर कि ग्राहक साइट क्यों नहीं खोल सकते, प्रतिक्रिया अक्सर इस तरह दिखती है:



डैशबोर्ड का स्पैगेटिफिकेशन

सिस्टम के विभिन्न हिस्सों के टेलीमेट्री को अपनाना एक आम बात है, यह आमतौर पर डैशबोर्ड पर खींची गई स्पेगेटी के एक समूह के साथ समाप्त होता है।

ये गिटलैब के ऑपरेशनल मेट्रिक्स हैं जो जनता के लिए खुले हैं।

और यह डैशबोर्ड की पूरी सेना का एक छोटा सा हिस्सा है



यह एक टेपेस्ट्री की तरह दिखता है जहां धागा खोना आसान है।

लॉग एग्रेशन

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

हालाँकि, यह एक लागत के साथ आता है। आधुनिक सिस्टम बड़ी मात्रा में लॉग उत्पन्न करते हैं और आपके ट्रैफ़िक में वृद्धि आपके ईएलके संसाधनों को समाप्त कर सकती है या स्प्लंक की बिलिंग दर को चंद्रमा तक बढ़ा सकती है।

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

लॉग से एक इवेंट मॉडल तक

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

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

उदाहरण के लिए, लॉगिन सेवा ईवेंट्स को स्वयं के डायनामिक संदर्भ के साथ successful_logins, fail_logins द्वारा अलग किया जा सकता है।

मैट्रिक्स और घटनाओं को सिस्टम में प्रक्रियाओं के आसपास एक कहानी का निर्माण करना चाहिए।

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

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

उच्च हृदयता के साथ लिखित यह डेटा सिस्टम में अज्ञात-अज्ञात को प्रकट करता है।

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

"एक घटना को एक कार्य के रूप में परिभाषित करना एक विशेष सेवा के उद्देश्यों से संबंधित के रूप में देखा जा सकता है।"

क्यों हम पूर्ण एआई समाधान के लिए तैयार नहीं हैं

स्टार्टअप निवेश को आकर्षित करने के लिए AI एक अच्छा buzzword है। हालाँकि, शैतान हमेशा विवरण में होता है।

1. प्रतिक्रमण

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

जब आप अत्यधिक ग्रेन्युलर डेटा या मेट्रिक्स के साथ काम कर रहे हों, तो सिस्टम को स्वयं को ऑप्टिमाइज़ करना आवश्यक है, लेकिन इसे बिना प्रतिलिपि बनाए रखना बहुत कठिन है।

2. संसाधन की खपत

किसी भी प्रकार की निरंतर मशीन सीखने के लिए, आपको एक महत्वपूर्ण मात्रा में कम्प्यूटेशनल संसाधनों की आवश्यकता होती है। आमतौर पर, यह डेटा के बैच प्रोसेसिंग सेट का रूप लेता है। कुछ उत्पादों के मामले में, 200,000 मीट्रिक प्रसंस्करण की न्यूनतम आवश्यकताएं v32CPU और 64 Gb RAM हैं। यदि आप मीट्रिक की मात्रा को दोगुना करना चाहते हैं, तो आपको एक और मशीन की आवश्यकता होती है जो समान आवश्यकताओं को पूरा करती है।

3. आप अभी तक पूरी तरह से पूर्ण स्वचालन सीखने का पैमाना नहीं बना सकते

Samreen Hassan Massak द्वारा लिखित एक मास्टर की थीसिस (पूरी तरह से अभी तक पूरी नहीं हुई) के अनुसार, हजारों मेट्रिक्स के लिए प्रशिक्षण प्रक्रिया में CPU समय या घंटों का GPU समय लगता है। आप अपने बजट को उड़ाए बिना इसे स्केल नहीं कर सकते।

4. गति

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

5. स्पष्टता

Google के अनुभव के आधार पर:

"नियम जो वास्तविक घटनाओं को सबसे अधिक बार पकड़ते हैं, उन्हें यथासंभव सरल, अनुमानित और विश्वसनीय होना चाहिए।"

landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems

जब मॉडल या नियम लगातार बदल रहे हैं, तो आप सिस्टम की समझ खो देते हैं और यह एक ब्लैक बॉक्स के रूप में काम करता है।

विसंगतियाँ = अलर्ट?

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

https://berlinbuzzwords.de/15/session/signatures-patterns-and-trends-timeseries-data-mining-etsy

Etsy's Kale प्रोजेक्ट से मुख्य पाठ तैयार किए जा सकते हैं:



मेट्रिक्स विसंगतियों के बारे में चेतावनी देने से अंततः भारी मात्रा में अलर्ट और मैनुअल काम थ्रेसहोल्ड और हैंड-क्राफ्टिंग फिल्टर के साथ हो जाएंगे।

हम एक स्ट्रीमिंग दृष्टिकोण की आवश्यकता क्यों है

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

यहां तक ​​कि अगर आप ध्यान से अपने मैट्रिक्स और घटनाओं को डिजाइन करते हैं, तो आप अंततः उनमें से एक बड़ी राशि के साथ समाप्त हो जाएंगे। वास्तविक समय में इस पैमाने पर काम करते समय, नियमित क्वेरी या बैच नौकरियों में महत्वपूर्ण विलंबता और ओवरहेड होगा।

जिन बातों पर विचार किया जाना है

डेटा की अनंत धारा पर किया गया कोई भी ऑपरेशन काफी इंजीनियरिंग प्रयास है। आपको वितरित सिस्टम से संबंधित निहितार्थों से निपटने की आवश्यकता है।



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

कुछ स्ट्रीमिंग फ्रेमवर्क, जैसे कि अपाचे स्टॉर्म, अपाचे फ्लिंक और अपाचे स्पार्क, टपल प्रसंस्करण की ओर उन्मुख हैं और बॉक्स से समय-श्रृंखला प्रसंस्करण की ओर नहीं।

वितरित प्रणालियों के शब्दार्थों के साथ भी समस्याएं हैं।

मान लीजिए कि आपके पास विभिन्न डेटा केंद्रों में बहुत सारी तैनाती है। आपको नेटवर्क की समस्या हो सकती है और आपके KPI मैट्रिक्स को संग्रहीत करने वाला एजेंट उन्हें आगे नहीं बढ़ा सकता है। थोड़ी देर के बाद - चलो 3 मिनट कहते हैं - एजेंट इस डेटा को सिस्टम में भेजता है। और इस नई जानकारी को इस शर्त के आधार पर एक कार्रवाई को ट्रिगर करना चाहिए। क्या हमें इस डेटा विंडो को मेमोरी में स्टोर करना चाहिए और न केवल बैकवर्ड बल्कि समय के साथ-साथ स्थितियों की जांच करनी चाहिए? यह वंशानुक्रम विंडो कितनी बड़ी होनी चाहिए? वास्तविक समय में हजारों मीट्रिक पर काम करना इन सवालों को बहुत महत्वपूर्ण बनाता है। आप गति को खोए बिना स्ट्रीम-प्रोसेसिंग सिस्टम के मामले में डेटाबेस में सब कुछ स्टोर नहीं कर सकते।

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

Google SRE वर्कबुक के अनुसार एक निगरानी रणनीति की वांछनीय विशेषताएं

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

चैरिटी मैजर्स और सिंडी श्रीधरन के लिए बेहतरीन थैंक्स
उसकी मदद के लिए माशिमं को सिग्रिड से थांक्स