डॉन जोन्स। "अपने वातावरण में एकीकृत आईटी निगरानी प्रणाली बनाना" अध्याय 4. निगरानी: डेटा केंद्र से परे एक नज़र

इस अध्याय में चर्चा होगी कि बाहरी और आंतरिक निगरानी को कैसे संयोजित किया जाए। सिस्टम बनाते समय क्या देखना है, क्या सीमाएँ हैं? छोटी चीजों को कैसे याद न करें और तस्वीर को न केवल नीचे से ऊपर तक, बल्कि ऊपर से नीचे तक देखने का अवसर प्राप्त करें।


सामग्री

अध्याय 1. अपने आईटी वातावरण का प्रबंधन: चार चीजें जो आप गलत करते हैं
अध्याय 2. आईटी प्रबंधन में व्यक्तिगत साइटों के लिए प्रबंधन प्रथाओं का उन्मूलन
अध्याय 3. एक आईटी प्रबंधन चक्र में सब कुछ जोड़ना
अध्याय 4. निगरानी: डेटा केंद्र से परे एक नज़र
अध्याय 5: समस्याओं को समाधान में बदलना
अध्याय 6: उदाहरणों के साथ एकीकृत प्रबंधन

अध्याय 4: निगरानी: डेटा केंद्र से परे एक नज़र

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

तकनीकी मीटर बनाम एंड-यूज़र अनुभव की निगरानी (EUE)

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

चित्र 4.1: डेटा सेंटर से निगरानी।

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

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

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

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

कैसे EUE SLA को बेहतर बनाता है

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


चित्र 4.2: यूरोपीय संघ की निगरानी।

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


चित्र 4.3: खराब EUE के कारण पर नज़र रखना।

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

EUE को मापने की क्षमता आपको अधिक यथार्थवादी SLAs बनाने की अनुमति देती है। अपने उपयोगकर्ताओं से कहने के बजाय "हम गारंटी देते हैं कि सिस्टम 2 सेकंड के भीतर अनुरोध का जवाब देगा", आप कहेंगे "ऐसा और इस तरह के लेनदेन को संसाधित होने में 3 सेकंड से अधिक नहीं लगेगा"। इसका मतलब है कि उपयोगकर्ता इन चीजों को स्वयं माप सकता है: "हम इनपुट दबाते हैं और गिनती करते हैं - एक, दो, तीन ... ओह, यह काम किया!"। इस प्रकार का SLA एक फ्रेमवर्क स्थापित करता है जो उपयोगकर्ता के अनुकूल और समझने योग्य है। वे जानते हैं कि जब सिस्टम ने धीरे-धीरे काम करना शुरू किया, क्योंकि वे आपके जैसी ही चीजों को मापते हैं।

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

यह कैसे करें: सिंथेटिक लेनदेन, लेनदेन ट्रैकिंग, आदि।

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

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

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

चित्र 4.4: EUE की निगरानी के लिए लेनदेन ट्रैकिंग का उपयोग करना।

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

टॉप-डाउन मॉनिटरिंग: ईयूई से लेकर सभी बुराई की जड़ तक

EUE को एक उच्च स्तर का निदान माना जाता है; वह बस कहती है - "कुछ गलत हुआ," लेकिन वास्तव में क्या कहता है। कारणों को समझने के लिए, आपको पारंपरिक निगरानी प्रणाली पर लौटने की आवश्यकता है, जिसे आप हमेशा जानते थे और प्यार करते थे, केवल इस बार, आप खाली जगह पर ध्यान नहीं देंगे: आप गारंटी मौजूदा समस्या के स्रोत की तलाश करेंगे।

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

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

एजेंट मॉनिटरिंग बनाम एजेंटलेस मॉनिटरिंग

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

चित्र 4.5: एजेंटों के माध्यम से निगरानी।

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

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


चित्र 4.6: एजेंट रहित निगरानी।

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

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

मॉनिटरिंग जो आपके पास नहीं है

हमारे कार्यालय और / या जिम्मेदारी के बाहर स्थित उपकरण वह जगह है जहाँ सामान्य निगरानी काम नहीं करती है। यह संभावना नहीं है कि अमेज़ॅन आपको उनके लोचदार कम्प्यूट क्लाउड (EC2) के स्वास्थ्य पर विस्तृत आँकड़े प्रदान करेगा, यह संभावना नहीं है कि Microsoft अपने विंडोज एज़्योर के लिए भी ऐसा ही करेगा। SalesForce.com आपको अपने वेब सर्वरों के DBMS रिस्पांस टाइम मान या CPU उपयोग पैरामीटर भेजने नहीं जा रहा है। यहां तक ​​कि होस्टिंग कंपनी जहां आप अपने सर्वर को होस्ट करते हैं, आपको उनके राउटर पर खोए हुए पैकेटों के प्रतिशत और उनके बुनियादी ढांचे से अन्य आंकड़ों के बारे में विस्तृत जानकारी नहीं दिखाने जा रहे हैं।

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

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

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

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

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

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


चित्र 4.8: बाह्य, संकर निगरानी।

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

महत्वपूर्ण सीमाएं: जब आपको सब कुछ नियंत्रित करने की आवश्यकता होती है

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

चित्र 4.9: क्या यहां सब कुछ है जिस पर नजर रखने की आवश्यकता है?

निश्चित रूप से नहीं। इस योजना में कई चूक हैं, और अधिकांश भाग ऐसी चीजें हैं जो प्रदर्शन पर महत्वपूर्ण प्रभाव डाल सकती हैं। अंजीर को देखें। 4.10 - यहां सब कुछ थोड़ा भरा हुआ और अधिक विस्तृत है।


चित्र 4.10: सुनिश्चित करें कि आप सब कुछ नियंत्रित करते हैं।

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

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

निष्कर्ष

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

अगले अध्याय में ...

अगले अध्याय में, हम उस मूलभूत समस्या को संबोधित करेंगे, जिसे हर संगठन को निपटना होगा: पुनरावृत्ति । दूसरे शब्दों में, समस्या हल होने के बाद, यदि आप अचानक फिर से हो जाते हैं, तो आप इसे तेजी से हल करने का प्रबंधन कैसे करते हैं? हम इस बात पर ध्यान देंगे कि समस्याओं को समाधान में कैसे बदलना है और हम भविष्य में सेवाओं के प्रावधान को कैसे बेहतर बना सकते हैं।