हम हाथी को टुकड़ों में खाते हैं। उदाहरणों के साथ अनुप्रयोग स्वास्थ्य निगरानी रणनीति

सभी को नमस्कार!

हमारी कंपनी सॉफ्टवेयर विकास और उसके बाद तकनीकी सहायता में लगी हुई है। तकनीकी सहायता के लिए न केवल त्रुटियों को ठीक करना आवश्यक है, बल्कि हमारे अनुप्रयोगों के प्रदर्शन की निगरानी भी आवश्यक है।

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

हमारी एक छोटी सी कंपनी है, हमारे पास अनुप्रयोगों की निगरानी के लिए किसी जटिल समाधान का अध्ययन करने और उसे बनाए रखने के लिए संसाधन नहीं हैं, हमें एक सरल और प्रभावी समाधान खोजने की आवश्यकता है।

निगरानी रणनीति

किसी एप्लिकेशन की कार्यक्षमता की जांच करना आसान नहीं है; यह कार्य गैर-तुच्छ है, कोई इसे रचनात्मक भी कह सकता है। जटिल मल्टी-लिंक सिस्टम को सत्यापित करना विशेष रूप से कठिन है।

आप हाथी को कैसे खा सकते हैं? केवल भागों में! हम अनुप्रयोगों की निगरानी के लिए इस दृष्टिकोण का उपयोग करते हैं।

हमारी निगरानी रणनीति का सार:

अपने एप्लिकेशन को घटकों में विभाजित करें।
प्रत्येक घटक के लिए नियंत्रण जाँच बनाएँ।

एक घटक को चालू माना जाता है यदि उसकी सभी नियंत्रण जाँचें त्रुटियों के बिना की जाती हैं। किसी एप्लिकेशन को स्वस्थ माना जाता है यदि उसके सभी घटक क्रियाशील हों।

इस प्रकार, किसी भी प्रणाली को घटकों के वृक्ष के रूप में दर्शाया जा सकता है। जटिल घटकों को सरल घटकों में तोड़ दिया जाता है। सरल घटकों में जाँच होती है।

बेंचमार्क कार्यात्मक परीक्षण करने के लिए नहीं हैं, वे इकाई परीक्षण नहीं हैं। नियंत्रण जांच में यह जांचना चाहिए कि वर्तमान समय में घटक कैसा महसूस करता है, क्या इसके कामकाज के लिए आवश्यक सभी संसाधन हैं, और क्या कोई समस्या है।

कोई चमत्कार नहीं है; अधिकांश चेकों को स्वतंत्र रूप से विकसित करने की आवश्यकता होगी। लेकिन डरो मत, क्योंकि ज्यादातर मामलों में एक चेक में कोड की 5-10 लाइनें लगती हैं, लेकिन आप कोई भी तर्क लागू कर सकते हैं और आप स्पष्ट रूप से समझ जाएंगे कि चेक कैसे काम करता है।

निगरानी प्रणाली

मान लीजिए कि हमने एप्लिकेशन को घटकों में विभाजित किया है, प्रत्येक घटक के लिए जांचें बनाईं और लागू कीं, लेकिन इन जांचों के परिणामों के साथ क्या किया जाए? हमें कैसे पता चलेगा कि कोई चेक विफल हो गया?

हमें एक निगरानी प्रणाली की आवश्यकता होगी. वह निम्नलिखित कार्य करेगी:

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

ASMO प्रणाली का संक्षिप्त विवरण

एक उदाहरण से समझाना सबसे अच्छा है. आइए देखें कि ASMO प्रणाली के प्रदर्शन की निगरानी कैसे व्यवस्थित की जाती है।

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

तो, सिस्टम की संरचना काफी विशिष्ट है: वेबसाइट, एजेंट, उपकरण। आइए निगरानी शुरू करें.

सिस्टम को घटकों में तोड़ना

निम्नलिखित घटकों को ASMO प्रणाली में प्रतिष्ठित किया जा सकता है:

1. व्यक्तिगत खाता
यह एक वेब एप्लीकेशन है. कम से कम, आपको यह जांचना होगा कि एप्लिकेशन इंटरनेट पर उपलब्ध है।

2. डेटाबेस
डेटाबेस डेटा संग्रहीत करता है जो रिपोर्टिंग के लिए महत्वपूर्ण है, और आपको यह सुनिश्चित करना होगा कि डेटाबेस बैकअप सफलतापूर्वक बनाया गया है।

3. सर्वर
सर्वर से हमारा तात्पर्य उस हार्डवेयर से है जिस पर एप्लिकेशन चलते हैं। एचडीडी, रैम, सीपीयू की स्थिति की जांच करना आवश्यक है।

4. एजेंट
यह एक विंडोज़ सेवा है जो एक शेड्यूल पर कई अलग-अलग कार्य करती है। कम से कम, आपको यह जांचना होगा कि सेवा चल रही है।

5. एजेंट का कार्य
केवल यह जानना कि एक एजेंट काम कर रहा है, पर्याप्त नहीं है। एक एजेंट काम तो कर सकता है, लेकिन अपने निर्धारित कार्य नहीं कर सकता। आइए एजेंट घटक को कार्यों में विभाजित करें और जांचें कि प्रत्येक एजेंट कार्य सफलतापूर्वक काम करता है या नहीं।

6. सड़क नियंत्रण बिंदु (सभी एमपीसी के कंटेनर)
कई सड़क नियंत्रण बिंदु हैं, तो आइए सभी एमपीसी को एक घटक में संयोजित करें। इससे मॉनिटरिंग डेटा को पढ़ना अधिक सुविधाजनक हो जाएगा। "एएसएमओ सिस्टम" घटक की स्थिति को देखते समय, यह तुरंत स्पष्ट हो जाएगा कि समस्याएं कहां हैं: अनुप्रयोगों में, हार्डवेयर में या अधिकतम नियंत्रण प्रणाली में।

7. सड़क नियंत्रण बिंदु (एक अधिकतम सीमा)
यदि इस एमपीसी पर सभी डिवाइस सेवा योग्य हैं तो हम इस घटक को सेवा योग्य मानेंगे।

8. डिवाइस
यह एक वीडियो कैमरा या मौसम स्टेशन है जो अधिकतम सांद्रता सीमा पर स्थापित किया जाता है। यह जांचना आवश्यक है कि उपकरण ठीक से काम कर रहा है।

निगरानी प्रणाली में, घटक वृक्ष इस तरह दिखेगा:

वेब अनुप्रयोग निगरानी

इसलिए, हमने सिस्टम को घटकों में विभाजित कर दिया है, अब हमें प्रत्येक घटक के लिए चेक तैयार करने की आवश्यकता है।

किसी वेब एप्लिकेशन की निगरानी के लिए हम निम्नलिखित जांचों का उपयोग करते हैं:

1. मुख्य पृष्ठ के खुलने की जाँच करना
यह जाँच निगरानी प्रणाली द्वारा की जाती है। इसे निष्पादित करने के लिए, हम पृष्ठ का पता, अपेक्षित प्रतिक्रिया खंड और अधिकतम अनुरोध निष्पादन समय इंगित करते हैं।

2. डोमेन भुगतान की समय सीमा की जाँच करना
एक बहुत ही महत्वपूर्ण जांच. जब कोई डोमेन अवैतनिक रहता है, तो उपयोगकर्ता साइट नहीं खोल सकते। समस्या के समाधान में कई दिन लग सकते हैं, क्योंकि... DNS परिवर्तन तुरंत लागू नहीं होते.

3. एसएसएल प्रमाणपत्र की जाँच करना
आजकल लगभग सभी वेबसाइट एक्सेस के लिए https प्रोटोकॉल का उपयोग करती हैं। प्रोटोकॉल के सही ढंग से काम करने के लिए, आपको एक वैध एसएसएल प्रमाणपत्र की आवश्यकता है।

निगरानी प्रणाली में "व्यक्तिगत खाता" घटक नीचे दिया गया है:

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

आप और क्या जाँच सकते हैं?

अपने वेब एप्लिकेशन की पूरी तरह से निगरानी करने के लिए, आप निम्नलिखित जांच कर सकते हैं:

• प्रति अवधि जावास्क्रिप्ट त्रुटियों की संख्या
• अवधि के लिए वेब एप्लिकेशन पक्ष (बैक-एंड) पर त्रुटियों की संख्या
• असफल वेब एप्लिकेशन प्रतिक्रियाओं की संख्या (प्रतिक्रिया कोड 404, 500, आदि)
• औसत क्वेरी निष्पादन समय

विंडोज़ सेवा की निगरानी (एजेंट)

ASMO प्रणाली में, एजेंट एक कार्य अनुसूचक की भूमिका निभाता है, जो पृष्ठभूमि में निर्धारित कार्यों को निष्पादित करता है।

यदि एजेंट के सभी कार्य सफलतापूर्वक पूरे हो जाते हैं, तो एजेंट ठीक से काम कर रहा है। यह पता चला है कि किसी एजेंट की निगरानी करने के लिए, आपको उसके कार्यों की निगरानी करने की आवश्यकता है। इसलिए, हम "एजेंट" घटक को कार्यों में विभाजित करते हैं। प्रत्येक कार्य के लिए, हम निगरानी प्रणाली में एक अलग घटक बनाएंगे, जहां "एजेंट" घटक "पैरेंट" होगा।

हम एजेंट घटक को चाइल्ड घटकों (कार्यों) में विभाजित करते हैं:

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

ASMO प्रणाली में सौ से अधिक कार्य हैं, क्या प्रत्येक कार्य के लिए अद्वितीय जाँच करना वास्तव में आवश्यक है? बेशक, नियंत्रण बेहतर होगा यदि हम प्रत्येक एजेंट कार्य के लिए अपने स्वयं के विशेष चेक लेकर आएं और उन्हें लागू करें, लेकिन ज्यादातर मामलों में यह सार्वभौमिक चेक का उपयोग करने के लिए पर्याप्त है।

ASMO प्रणाली कार्यों के लिए केवल सार्वभौमिक जांच का उपयोग करती है और यह सिस्टम के प्रदर्शन की निगरानी के लिए पर्याप्त है।

प्रगति की जाँच करना
सबसे सरल और सबसे प्रभावी जाँच निष्पादन जाँच है। जाँच यह सत्यापित करती है कि कार्य त्रुटियों के बिना पूरा हो गया है। सभी कार्यों में यह जाँच होती है।

सत्यापन एल्गोरिथ्म

प्रत्येक कार्य निष्पादन के बाद, यदि कार्य निष्पादन सफल रहा, तो आपको SUCCESS जांच का परिणाम निगरानी प्रणाली को भेजना होगा, या यदि निष्पादन किसी त्रुटि के साथ पूरा हुआ तो त्रुटि।

यह जाँच निम्नलिखित समस्याओं का पता लगा सकती है:

1. कार्य चलता है लेकिन एक त्रुटि के साथ विफल हो जाता है।
2. कार्य चलना बंद हो गया है, उदाहरण के लिए, रुक गया है।

आइए अधिक विस्तार से देखें कि इन समस्याओं का समाधान कैसे किया जाता है।

अंक 1 - कार्य चलता है लेकिन एक त्रुटि के साथ विफल हो जाता है
नीचे एक मामला है जहां कार्य चलता है लेकिन 14:00 और 16:00 के बीच विफल हो जाता है।

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

कृपया ध्यान दें कि निगरानी प्रणाली में, घटक की स्थिति सत्यापन स्थिति पर निर्भर करती है। चेक की अलार्म स्थिति सभी उच्च-स्तरीय घटकों को अलार्म में बदल देगी, नीचे दिया गया चित्र देखें।

समस्या 2 - कार्य निष्पादित होना बंद हो गया (जमे हुए)
मॉनिटरिंग सिस्टम कैसे समझेगा कि कोई काम अटक गया है?

चेक परिणाम की वैधता अवधि होती है, उदाहरण के लिए, 1 घंटा। यदि एक घंटा बीत जाता है और कोई नया परीक्षा परिणाम नहीं आता है, तो निगरानी प्रणाली परीक्षण की स्थिति को अलार्म पर सेट कर देगी।

ऊपर की तस्वीर में, दोपहर 14:00 बजे लाइटें बंद कर दी गईं। 15:00 बजे, निगरानी प्रणाली पता लगाएगी कि परीक्षण परिणाम (14:00 से) खराब है, क्योंकि प्रासंगिकता समय समाप्त हो गया है (एक घंटा), लेकिन कोई नया परिणाम नहीं है, और चेक को अलार्म स्थिति में बदल दिया जाएगा।

16:00 बजे लाइटें फिर से चालू कर दी गईं, प्रोग्राम कार्य पूरा करेगा और निष्पादन परिणाम निगरानी प्रणाली को भेजेगा, परीक्षण की स्थिति फिर से सफल हो जाएगी।

मुझे किस प्रासंगिकता जांच समय का उपयोग करना चाहिए?

प्रासंगिकता समय कार्य निष्पादन अवधि से अधिक होना चाहिए। मैं कार्य निष्पादन अवधि की तुलना में प्रासंगिकता समय को 2-3 गुना अधिक निर्धारित करने की अनुशंसा करता हूं। उदाहरण के लिए, जब किसी कार्य में सामान्य से अधिक समय लगा हो या किसी ने प्रोग्राम को पुनः लोड किया हो, तो झूठी सूचनाएं प्राप्त करने से बचने के लिए यह आवश्यक है।

प्रगति की जाँच करना

एएसएमओ प्रणाली में एक "लोड पूर्वानुमान" कार्य है, जो एक घंटे में एक बार बाहरी स्रोत से एक नया पूर्वानुमान डाउनलोड करने का प्रयास करता है। बाह्य प्रणाली में कोई नया पूर्वानुमान प्रकट होने का सटीक समय ज्ञात नहीं है, लेकिन यह ज्ञात है कि ऐसा दिन में 2 बार होता है। इससे पता चलता है कि यदि कई घंटों तक कोई नया पूर्वानुमान नहीं है, तो यह सामान्य है, लेकिन यदि एक दिन से अधिक समय तक कोई नया पूर्वानुमान नहीं है, तो इसका मतलब है कि कहीं कुछ टूट गया है। उदाहरण के लिए, बाहरी पूर्वानुमान प्रणाली में डेटा प्रारूप बदल सकता है, यही कारण है कि ASMO को कोई नया पूर्वानुमान रिलीज़ नहीं दिखाई देगा।

सत्यापन एल्गोरिथ्म

जब कार्य प्रगति प्राप्त करने में सफल हो जाता है (नया मौसम पूर्वानुमान डाउनलोड करना) तो सफलता जांच का परिणाम निगरानी प्रणाली को भेजता है। यदि कोई प्रगति नहीं होती है या कोई त्रुटि होती है, तो निगरानी प्रणाली को कुछ भी नहीं भेजा जाता है।

चेक में प्रासंगिकता अंतराल होना चाहिए ताकि इस दौरान नई प्रगति प्राप्त होने की गारंटी हो।

कृपया ध्यान दें कि हम समस्या के बारे में देरी से जान पाएंगे, क्योंकि निगरानी प्रणाली अंतिम स्कैन परिणाम की वैधता अवधि समाप्त होने तक प्रतीक्षा करती है। इसलिए चेक की वैधता अवधि को ज्यादा लंबा करने की जरूरत नहीं है.

डेटाबेस निगरानी

ASMO प्रणाली में डेटाबेस को नियंत्रित करने के लिए, हम निम्नलिखित जाँच करते हैं:

1. बैकअप निर्माण का सत्यापन किया जा रहा है
2. मुक्त डिस्क स्थान की जाँच करना

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

ASMO सप्ताह में एक बार एक बैकअप प्रतिलिपि बनाता है और उसे भंडारण में भेजता है। जब यह प्रक्रिया सफलतापूर्वक पूरी हो जाती है, तो सफलता जांच का परिणाम निगरानी प्रणाली को भेज दिया जाता है। सत्यापन परिणाम 9 दिनों के लिए वैध है। वे। बैकअप के निर्माण को नियंत्रित करने के लिए, "प्रगति जांच" तंत्र का उपयोग किया जाता है, जिसकी हमने ऊपर चर्चा की है।

मुक्त डिस्क स्थान की जाँच करना
यदि डिस्क पर पर्याप्त खाली स्थान नहीं है, तो डेटाबेस ठीक से काम नहीं कर पाएगा, इसलिए खाली स्थान की मात्रा को नियंत्रित करना महत्वपूर्ण है।

संख्यात्मक मापदंडों की जांच के लिए मेट्रिक्स का उपयोग करना सुविधाजनक है।

मैट्रिक्स एक संख्यात्मक चर है, जिसका मान निगरानी प्रणाली को प्रेषित किया जाता है। निगरानी प्रणाली थ्रेशोल्ड मानों की जांच करती है और मीट्रिक स्थिति की गणना करती है।

निगरानी प्रणाली में "डेटाबेस" घटक कैसा दिखता है इसकी एक तस्वीर नीचे दी गई है:

सर्वर मॉनिटरिंग

सर्वर की निगरानी के लिए हम निम्नलिखित जांच और मैट्रिक्स का उपयोग करते हैं:

1. खाली डिस्क स्थान
यदि डिस्क स्थान समाप्त हो जाता है, तो एप्लिकेशन काम नहीं कर पाएगा। हम 2 थ्रेशोल्ड मानों का उपयोग करते हैं: पहला स्तर चेतावनी है, दूसरा स्तर अलार्म है।

2. औसत रैम मान प्रति घंटे प्रतिशत में
हम प्रति घंटा औसत का उपयोग करते हैं क्योंकि... हमें दुर्लभ दौड़ में कोई दिलचस्पी नहीं है.

3. प्रति घंटा औसत सीपीयू प्रतिशत
हम प्रति घंटा औसत का उपयोग करते हैं क्योंकि... हमें दुर्लभ दौड़ में कोई दिलचस्पी नहीं है.

4. पिंग चेक
जाँचता है कि सर्वर ऑनलाइन है। निगरानी प्रणाली यह जाँच कर सकती है; कोड लिखने की कोई आवश्यकता नहीं है।

निगरानी प्रणाली में "सर्वर" घटक कैसा दिखता है इसकी एक तस्वीर नीचे दी गई है:

उपकरण निगरानी

मैं आपको बताऊंगा कि डेटा कैसे प्राप्त किया जाता है। प्रत्येक सड़क नियंत्रण बिंदु (एमपीसी) के लिए कार्य योजनाकार में एक कार्य है, उदाहरण के लिए, "सर्वेक्षण एमपीसी एम2 किमी 200"। कार्य हर 30 मिनट में सभी एमपीसी उपकरणों से डेटा प्राप्त करता है।

संचार चैनल की समस्या
अधिकांश उपकरण शहर के बाहर स्थित हैं; डेटा ट्रांसमिशन के लिए एक जीएसएम नेटवर्क का उपयोग किया जाता है, जो स्थिर रूप से काम नहीं करता है (कोई नेटवर्क है, या कोई नहीं है)।

बार-बार नेटवर्क फेल होने के कारण सबसे पहले मॉनिटरिंग में एमपीसी सर्वे की जांच इस तरह होती थी:

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

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

निगरानी प्रणाली में उपकरण कैसा दिखता है इसकी एक तस्वीर नीचे दी गई है:

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

अंतिम ASMO निगरानी योजना

आइए सब कुछ एक साथ रखें और देखें कि हमारे पास किस प्रकार की निगरानी योजना है।

निष्कर्ष

आइए संक्षेप करें।
ASMO के प्रदर्शन की निगरानी से हमें क्या मिला?

1. दोष निवारण का समय कम हो गया है
हमने पहले उपयोगकर्ताओं से दोषों के बारे में सुना है, लेकिन सभी उपयोगकर्ता दोषों की रिपोर्ट नहीं करते हैं। ऐसा हुआ कि हमें सिस्टम घटक की खराबी के बारे में उसके सामने आने के एक सप्ताह बाद पता चला। अब किसी समस्या का पता चलते ही मॉनिटरिंग सिस्टम हमें सूचित कर देता है।

2. सिस्टम स्थिरता बढ़ी है
चूँकि दोषों को पहले ही समाप्त किया जाना शुरू हो गया था, समग्र रूप से सिस्टम अधिक स्थिर रूप से काम करने लगा।

3. तकनीकी सहायता के लिए कॉल की संख्या कम करना
कई समस्याएं अब उपयोगकर्ताओं को उनके बारे में पता चलने से पहले ही ठीक कर दी गई हैं। उपयोगकर्ता तकनीकी सहायता से कम बार संपर्क करने लगे। इन सबका हमारी प्रतिष्ठा पर अच्छा प्रभाव पड़ता है।

4. ग्राहक और उपयोगकर्ता की वफादारी बढ़ाना
ग्राहक ने सिस्टम की स्थिरता में सकारात्मक बदलाव देखे। उपयोगकर्ताओं को सिस्टम का उपयोग करने में कम समस्याओं का सामना करना पड़ता है।

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

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

मॉनिटरिंग सिस्टम को दूसरे डेटा सेंटर में एक अलग सर्वर पर चलना चाहिए।

यदि आप किसी नए डेटा सेंटर में समर्पित सर्वर का उपयोग नहीं करना चाहते हैं, तो आप क्लाउड मॉनिटरिंग सिस्टम का उपयोग कर सकते हैं। हमारी कंपनी ज़िडियम क्लाउड मॉनिटरिंग सिस्टम का उपयोग करती है, लेकिन आप किसी अन्य मॉनिटरिंग सिस्टम का उपयोग कर सकते हैं। क्लाउड मॉनिटरिंग सिस्टम की लागत एक नए सर्वर को किराए पर लेने से कम है।

सिफारिशें:

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

यदि आप अभी तक निगरानी प्रणाली का उपयोग नहीं कर रहे हैं, तो शुरू करें! यह उतना कठिन नहीं है जितना लगता है। अपने द्वारा उगाए गए हरे अवयवों के पेड़ को देखकर आनंद उठाएँ।

गुड लक।

स्रोत: www.habr.com