हत्तीला आपण भागांमध्ये खातो. उदाहरणांसह अॅप्लिकेशन हेल्थ मॉनिटरिंग स्ट्रॅटेजी

हॅलो प्रत्येकजण!

आमची कंपनी सॉफ्टवेअर डेव्हलपमेंट आणि त्यानंतरच्या तांत्रिक समर्थनामध्ये गुंतलेली आहे. तांत्रिक समर्थनासाठी केवळ त्रुटी दूर करणे आवश्यक नाही तर आमच्या अनुप्रयोगांच्या कार्यक्षमतेचे परीक्षण करणे आवश्यक आहे.

उदाहरणार्थ, जर एखादी सेवा क्रॅश झाली असेल, तर आपल्याला ही समस्या स्वयंचलितपणे रेकॉर्ड करण्याची आणि त्याचे निराकरण करण्यास प्रारंभ करण्याची आवश्यकता आहे आणि असंतुष्ट वापरकर्त्यांनी तांत्रिक समर्थनाशी संपर्क साधण्याची प्रतीक्षा करू नये.

आमची एक छोटी कंपनी आहे, आमच्याकडे ॲप्लिकेशन्सचे परीक्षण करण्यासाठी कोणत्याही जटिल उपायांचा अभ्यास करण्यासाठी आणि देखरेख करण्यासाठी संसाधने नाहीत, आम्हाला एक सोपा आणि प्रभावी उपाय शोधण्याची आवश्यकता आहे.

देखरेख धोरण

अनुप्रयोगाची कार्यक्षमता तपासणे सोपे नाही; जटिल मल्टी-लिंक सिस्टम सत्यापित करणे विशेषतः कठीण आहे.

तुम्ही हत्ती कसा खाऊ शकता? फक्त भागांमध्ये! अनुप्रयोगांचे परीक्षण करण्यासाठी आम्ही हा दृष्टिकोन वापरतो.

आमच्या देखरेख धोरणाचे सार:

तुमचा अर्ज घटकांमध्ये विभाजित करा.
प्रत्येक घटकासाठी नियंत्रण तपासणी तयार करा.

जर एखाद्या घटकाची सर्व नियंत्रण तपासणी त्रुटींशिवाय केली गेली असेल तर तो कार्यरत मानला जातो. एखादे ऍप्लिकेशन निरोगी मानले जाते जर त्याचे सर्व घटक कार्यरत असतील.

अशा प्रकारे, कोणतीही प्रणाली घटकांचे झाड म्हणून दर्शविली जाऊ शकते. जटिल घटक सोप्या भागांमध्ये विभागले जातात. साध्या घटकांमध्ये चेक असतात.

बेंचमार्क फंक्शनल टेस्टिंगसाठी नसतात, त्या युनिट टेस्ट नाहीत. नियंत्रण तपासण्यांनी घटकाला सध्याच्या क्षणी कसे वाटते, त्याच्या कार्यासाठी आवश्यक असलेली सर्व संसाधने आहेत का आणि काही समस्या आहेत का हे तपासले पाहिजे.

कोणतेही चमत्कार नाहीत; बहुतेक चेक स्वतंत्रपणे विकसित करणे आवश्यक आहे. परंतु घाबरू नका, कारण बहुतेक प्रकरणांमध्ये एका चेकसाठी 5-10 ओळी कोड लागतात, परंतु आपण कोणतेही तर्क लागू करू शकता आणि चेक कसे कार्य करते हे आपल्याला स्पष्टपणे समजेल.

देखरेख यंत्रणा

चला असे म्हणूया की आम्ही ऍप्लिकेशनला घटकांमध्ये विभाजित केले, प्रत्येक घटकासाठी चेक तयार केले आणि लागू केले, परंतु या चेकच्या परिणामांचे काय करायचे? काही चेक अयशस्वी झाल्यास आम्हाला कसे कळेल?

आम्हाला मॉनिटरिंग सिस्टमची आवश्यकता असेल. ती खालील कार्ये करेल:

• चाचणी परिणाम प्राप्त करा आणि घटकांची स्थिती निर्धारित करण्यासाठी त्यांचा वापर करा.
  दृश्यमानपणे, हे घटक वृक्ष हायलाइट केल्यासारखे दिसते. कार्यात्मक घटक हिरवे होतात, समस्याग्रस्त घटक लाल होतात.
• बॉक्सच्या बाहेर सामान्य तपासणी करा.
  मॉनिटरिंग सिस्टम काही तपासण्या स्वतः करू शकते. का चाक पुन्हा शोधू, चला त्यांचा वापर करूया. उदाहरणार्थ, तुम्ही वेबसाइट पेज उघडत आहे किंवा सर्व्हर पिंग करत आहे हे तपासू शकता.
• इच्छुक पक्षांना समस्यांच्या सूचना पाठवा.
• मॉनिटरिंग डेटाचे व्हिज्युअलायझेशन, अहवालांची तरतूद, आलेख आणि आकडेवारी.

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

उदाहरणासह स्पष्ट करणे चांगले. ASMO प्रणालीच्या कामगिरीचे निरीक्षण कसे आयोजित केले जाते ते पाहू या.

ASMO ही एक स्वयंचलित हवामान सहाय्य प्रणाली आहे. रस्ता डी-आयसिंग सामग्रीसह कुठे आणि केव्हा उपचार करणे आवश्यक आहे हे रस्ता सेवा तज्ञांना ही प्रणाली मदत करते. सिस्टम रोड कंट्रोल पॉइंट्सवरून डेटा गोळा करते. रोड कंट्रोल पॉईंट हे रस्त्यावरील एक ठिकाण आहे जिथे उपकरणे स्थापित केली जातात: हवामान स्टेशन, व्हिडिओ कॅमेरा इ. धोकादायक परिस्थितीचा अंदाज लावण्यासाठी, प्रणाली बाह्य स्त्रोतांकडून हवामान अंदाज प्राप्त करते.

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

प्रणालीचे घटकांमध्ये खंडित करणे

ASMO प्रणालीमध्ये खालील घटक ओळखले जाऊ शकतात:

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

2. डेटाबेस
डेटाबेस अहवालासाठी महत्त्वाचा डेटा संग्रहित करतो आणि डेटाबेस बॅकअप यशस्वीरित्या तयार केले आहेत याची खात्री करणे आवश्यक आहे.

3. सर्व्हर
सर्व्हर म्हणजे ज्या हार्डवेअरवर ॲप्लिकेशन्स चालतात. एचडीडी, रॅम, सीपीयूची स्थिती तपासणे आवश्यक आहे.

4. एजंट
ही एक विंडोज सेवा आहे जी वेळापत्रकानुसार अनेक भिन्न कार्ये करते. कमीतकमी, आपल्याला सेवा चालू आहे की नाही हे तपासण्याची आवश्यकता आहे.

5. एजंट कार्य
एजंट कार्यरत आहे हे जाणून घेणे पुरेसे नाही. एजंट काम करू शकतो, परंतु नियुक्त केलेली कामे करू शकत नाही. चला एजंट घटकाला कार्यांमध्ये विभाजित करू आणि प्रत्येक एजंट कार्य यशस्वीरित्या कार्य करते की नाही ते तपासू.

6. रोड कंट्रोल पॉइंट्स (सर्व MPC चे कंटेनर)
अनेक रोड कंट्रोल पॉइंट्स आहेत, त्यामुळे सर्व MPCs एका घटकामध्ये एकत्र करूया. हे मॉनिटरिंग डेटा वाचणे अधिक सोयीस्कर करेल. “ASMO सिस्टम” घटकाची स्थिती पाहताना, समस्या कोठे आहेत हे त्वरित स्पष्ट होईल: अनुप्रयोगांमध्ये, हार्डवेअरमध्ये किंवा कमाल नियंत्रण प्रणालीमध्ये.

7. रस्ता नियंत्रण बिंदू (एक कमाल मर्यादा)
या MPC वरील सर्व उपकरणे सेवायोग्य असल्यास आम्ही हा घटक सेवायोग्य असल्याचे समजू.

8. डिव्हाइस
हा एक व्हिडिओ कॅमेरा किंवा हवामान स्टेशन आहे जो जास्तीत जास्त एकाग्रतेच्या मर्यादेवर स्थापित केला जातो. डिव्हाइस योग्यरित्या कार्य करत आहे हे तपासणे आवश्यक आहे.

मॉनिटरिंग सिस्टममध्ये, घटक वृक्ष असे दिसेल:

वेब ऍप्लिकेशन मॉनिटरिंग

म्हणून, आम्ही सिस्टमला घटकांमध्ये विभागले आहे, आता आम्हाला प्रत्येक घटकासाठी तपासणी करणे आवश्यक आहे.

वेब ऍप्लिकेशनचे परीक्षण करण्यासाठी आम्ही खालील तपासण्या वापरतो:

1. मुख्य पृष्ठ उघडणे तपासत आहे
ही तपासणी मॉनिटरिंग सिस्टमद्वारे केली जाते. ते कार्यान्वित करण्यासाठी, आम्ही पृष्ठ पत्ता, अपेक्षित प्रतिसाद तुकडा आणि कमाल विनंती अंमलबजावणी वेळ सूचित करतो.

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

3. SSL प्रमाणपत्र तपासत आहे
आजकाल, जवळजवळ सर्व वेबसाइट्स प्रवेशासाठी https प्रोटोकॉल वापरतात. प्रोटोकॉल योग्यरित्या कार्य करण्यासाठी, तुम्हाला वैध SSL प्रमाणपत्र आवश्यक आहे.

मॉनिटरिंग सिस्टममध्ये खाली "वैयक्तिक खाते" घटक आहे:

वरील सर्व तपासण्या बऱ्याच अनुप्रयोगांसाठी कार्य करतील आणि त्यांना कोडिंगची आवश्यकता नाही. हे खूप छान आहे कारण तुम्ही 5 मिनिटांत कोणत्याही वेब ऍप्लिकेशनचे निरीक्षण सुरू करू शकता. खाली अतिरिक्त तपासण्या आहेत ज्या वेब ऍप्लिकेशनसाठी केल्या जाऊ शकतात, परंतु त्यांची अंमलबजावणी अधिक क्लिष्ट आणि ऍप्लिकेशन-विशिष्ट आहे, म्हणून आम्ही त्यांना या लेखात समाविष्ट करणार नाही.

आपण आणखी काय तपासू शकता?

तुमच्या वेब ऍप्लिकेशनचे अधिक पूर्णपणे निरीक्षण करण्यासाठी, तुम्ही खालील तपासण्या करू शकता:

• प्रति कालावधी JavaScript त्रुटींची संख्या
• कालावधीसाठी वेब ऍप्लिकेशनच्या बाजूवर (बॅक-एंड) त्रुटींची संख्या
• अयशस्वी वेब अनुप्रयोग प्रतिसादांची संख्या (प्रतिसाद कोड 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 पट जास्त वेळ सेट करण्याची शिफारस करतो. जेव्हा, उदाहरणार्थ, एखाद्या कार्याला नेहमीपेक्षा जास्त वेळ लागतो किंवा कोणीतरी प्रोग्राम रीलोड केला तेव्हा खोट्या सूचना प्राप्त करणे टाळण्यासाठी हे आवश्यक आहे.

प्रगती तपासत आहे

ASMO प्रणालीमध्ये "लोड अंदाज" कार्य आहे, जे तासातून एकदा बाह्य स्त्रोताकडून नवीन अंदाज डाउनलोड करण्याचा प्रयत्न करते. बाह्य प्रणालीमध्ये नवीन अंदाज केव्हा दिसला याची अचूक वेळ माहित नाही, परंतु हे ज्ञात आहे की हे दिवसातून 2 वेळा होते. असे दिसून आले की जर काही तासांसाठी नवीन अंदाज नसेल तर हे सामान्य आहे, परंतु जर एका दिवसापेक्षा जास्त काळ नवीन अंदाज नसेल तर कुठेतरी काहीतरी खंडित झाले आहे. उदाहरणार्थ, बाह्य अंदाज प्रणालीमधील डेटा फॉरमॅट बदलू शकतो, म्हणूनच ASMO नवीन अंदाज रिलीझ पाहणार नाही.

सत्यापन अल्गोरिदम

जेव्हा कार्य प्रगती प्राप्त करण्यात यशस्वी होते (नवीन हवामान अंदाज डाउनलोड करणे) तेव्हा यशस्वी तपासणीचा परिणाम मॉनिटरिंग सिस्टमला पाठवते. कोणतीही प्रगती नसल्यास किंवा त्रुटी आढळल्यास, मॉनिटरिंग सिस्टमला काहीही पाठवले जात नाही.

चेकमध्ये एक प्रासंगिक अंतराल असणे आवश्यक आहे जेणेकरुन या काळात नवीन प्रगती प्राप्त होण्याची हमी दिली जाईल.

कृपया लक्षात घ्या की आम्ही विलंबाने समस्येबद्दल जाणून घेऊ, कारण मॉनिटरिंग सिस्टम शेवटच्या स्कॅन निकालाची वैधता कालावधी संपेपर्यंत प्रतीक्षा करते. त्यामुळे धनादेशाचा वैधता कालावधी फार मोठा करण्याची गरज नाही.

डेटाबेस मॉनिटरिंग

ASMO प्रणालीमधील डेटाबेस नियंत्रित करण्यासाठी, आम्ही खालील तपासण्या करतो:

1. बॅकअप निर्मितीची पडताळणी करत आहे
2. मोकळी डिस्क जागा तपासत आहे

बॅकअप निर्मितीची पडताळणी करत आहे
बऱ्याच ऍप्लिकेशन्समध्ये, अद्ययावत डेटाबेस बॅकअप असणे महत्त्वाचे आहे जेणेकरून सर्व्हर अयशस्वी झाल्यास, तुम्ही प्रोग्रामला नवीन सर्व्हरवर तैनात करू शकता.

ASMO आठवड्यातून एकदा बॅकअप प्रत तयार करते आणि स्टोरेजमध्ये पाठवते. ही प्रक्रिया यशस्वीरीत्या पूर्ण झाल्यावर, यशस्वी तपासणीचा परिणाम मॉनिटरिंग सिस्टमकडे पाठविला जातो. पडताळणीचा निकाल 9 दिवसांसाठी वैध आहे. त्या. बॅकअपच्या निर्मितीवर नियंत्रण ठेवण्यासाठी, आम्ही वर चर्चा केलेली "प्रगती तपासणी" यंत्रणा वापरली जाते.

मोकळी डिस्क जागा तपासत आहे
डिस्कवर पुरेशी मोकळी जागा नसल्यास, डेटाबेस योग्यरित्या कार्य करण्यास सक्षम होणार नाही, म्हणून मोकळ्या जागेचे प्रमाण नियंत्रित करणे महत्वाचे आहे.

संख्यात्मक पॅरामीटर्स तपासण्यासाठी मेट्रिक्स वापरणे सोयीचे आहे.

मेट्रिक्स एक संख्यात्मक चल आहे, ज्याचे मूल्य मॉनिटरिंग सिस्टममध्ये प्रसारित केले जाते. मॉनिटरिंग सिस्टम थ्रेशोल्ड मूल्ये तपासते आणि मेट्रिक स्थितीची गणना करते.

मॉनिटरिंग सिस्टममध्ये "डेटाबेस" घटक कसा दिसतो याचे चित्र खाली दिले आहे:

सर्व्हर निरीक्षण

सर्व्हरचे निरीक्षण करण्यासाठी आम्ही खालील तपासण्या आणि मेट्रिक्स वापरतो:

1. मोकळी डिस्क जागा
डिस्क स्पेस संपल्यास, अनुप्रयोग कार्य करण्यास सक्षम होणार नाही. आम्ही 2 थ्रेशोल्ड मूल्ये वापरतो: पहिली पातळी चेतावणी आहे, दुसरी पातळी अलार्म आहे.

2. प्रति तास टक्के मध्ये सरासरी RAM मूल्य
आम्ही ताशी सरासरी वापरतो कारण... आम्हाला दुर्मिळ शर्यतींमध्ये रस नाही.

3. प्रति तास सरासरी CPU टक्केवारी
आम्ही ताशी सरासरी वापरतो कारण... आम्हाला दुर्मिळ शर्यतींमध्ये रस नाही.

4. पिंग चेक
सर्व्हर ऑनलाइन असल्याचे तपासते. मॉनिटरिंग सिस्टम ही तपासणी करू शकते, कोड लिहिण्याची गरज नाही.

मॉनिटरिंग सिस्टममध्ये "सर्व्हर" घटक कसा दिसतो याचे चित्र खाली दिले आहे:

उपकरणे निरीक्षण

डेटा कसा मिळवला जातो ते मी तुम्हाला सांगेन. प्रत्येक रोड कंट्रोल पॉइंट (MPC) साठी टास्क प्लॅनरमध्ये एक कार्य आहे, उदाहरणार्थ, “सर्वे MPC M2 km 200”. टास्क प्रत्येक 30 मिनिटांनी सर्व MPC उपकरणांकडून डेटा प्राप्त करते.

संप्रेषण चॅनेल समस्या
बहुतेक उपकरणे शहराच्या बाहेर स्थित आहेत; डेटा ट्रान्समिशनसाठी जीएसएम नेटवर्क वापरले जाते, जे स्थिरपणे कार्य करत नाही (तेथे नेटवर्क आहे, किंवा एक नाही).

वारंवार नेटवर्क अयशस्वी झाल्यामुळे, प्रथम, मॉनिटरिंगमध्ये MPC सर्वेक्षण तपासताना असे दिसले:

हे स्पष्ट झाले की हा एक कार्यरत पर्याय नाही, कारण समस्यांबद्दल अनेक खोट्या सूचना होत्या. मग प्रत्येक उपकरणासाठी “प्रगती तपासणी” वापरण्याचा निर्णय घेण्यात आला, म्हणजे. जेव्हा डिव्हाइसमध्ये त्रुटीशिवाय मतदान केले जाते तेव्हा केवळ यश सिग्नल मॉनिटरिंग सिस्टमला पाठविला जातो. संबंधित वेळ 5 तासांवर सेट केली होती.

आता मॉनिटरिंग समस्यांबद्दल सूचना पाठवते जेव्हा डिव्हाइस 5 तासांपेक्षा जास्त काळ मतदान करू शकत नाही. उच्च संभाव्यतेसह, हे खोटे अलार्म नाहीत, परंतु वास्तविक समस्या आहेत.

मॉनिटरिंग सिस्टममध्ये उपकरणे कशी दिसतात याचे चित्र खाली दिले आहे:

महत्त्वाचे!
जेव्हा GSM नेटवर्क काम करणे थांबवते, तेव्हा सर्व MDC उपकरणे पोल होत नाहीत. मॉनिटरिंग सिस्टममधील ईमेलची संख्या कमी करण्यासाठी, आमचे अभियंते "डिव्हाइस" ऐवजी "MPC" प्रकारातील घटक समस्यांबद्दल सूचनांचे सदस्यत्व घेतात. हे तुम्हाला प्रत्येक डिव्हाइससाठी स्वतंत्र सूचना प्राप्त करण्याऐवजी प्रत्येक MPC साठी एक सूचना प्राप्त करण्यास अनुमती देते.

अंतिम ASMO देखरेख योजना

चला सर्वकाही एकत्र ठेवू आणि आमच्याकडे कोणत्या प्रकारची देखरेख योजना आहे ते पाहू.

निष्कर्ष

चला सारांश द्या.
ASMO च्या कामगिरीचे निरीक्षण केल्याने आम्हाला काय मिळाले?

1. दोष काढून टाकण्याची वेळ कमी झाली आहे
आम्ही यापूर्वी वापरकर्त्यांकडून दोषांबद्दल ऐकले आहे, परंतु सर्व वापरकर्ते दोष नोंदवत नाहीत. असे घडले की आम्हाला सिस्टम घटकाच्या खराबीबद्दल ते दिसल्याच्या एका आठवड्यानंतर कळले. आता मॉनिटरिंग सिस्टीम समस्या आढळल्याबरोबर आम्हाला समस्यांबद्दल सूचित करते.

2. सिस्टम स्थिरता वाढली आहे
दोष आधी दूर होऊ लागल्याने, संपूर्ण प्रणालीने अधिक स्थिर कार्य करण्यास सुरवात केली.

3. तांत्रिक समर्थनासाठी कॉलची संख्या कमी करणे
वापरकर्त्यांना त्यांच्याबद्दल माहिती होण्याआधीच बऱ्याच समस्यांचे निराकरण केले आहे. वापरकर्ते कमी वेळा तांत्रिक समर्थनाशी संपर्क साधू लागले. या सर्वांचा आपल्या प्रतिष्ठेवर चांगला परिणाम होतो.

4. ग्राहक आणि वापरकर्ता निष्ठा वाढवणे
ग्राहकाने सिस्टमच्या स्थिरतेमध्ये सकारात्मक बदल लक्षात घेतले. वापरकर्त्यांना सिस्टम वापरताना कमी समस्या येतात.

5. तांत्रिक समर्थन खर्च कमी करा
आम्ही कोणतीही मॅन्युअल तपासणी करणे थांबवले आहे. आता सर्व चेक स्वयंचलित आहेत. पूर्वी, आम्ही वापरकर्त्यांकडून समस्यांबद्दल शिकलो होतो; वापरकर्ता कोणत्या समस्येबद्दल बोलत आहे हे समजणे कठीण होते. आता, बहुतेक समस्या मॉनिटरिंग सिस्टमद्वारे नोंदवल्या जातात, ज्यामध्ये तांत्रिक डेटा असतो, जे नेहमी स्पष्ट करते की काय चूक झाली आणि कुठे.

महत्त्वाचे!
तुमची ॲप्लिकेशन्स ज्या सर्व्हरवर चालतात त्याच सर्व्हरवर तुम्ही मॉनिटरिंग सिस्टम इन्स्टॉल करू शकत नाही. सर्व्हर डाउन झाल्यास, ऍप्लिकेशन्स काम करणे थांबवतील आणि त्याबद्दल कोणीही सूचित करणार नाही.

मॉनिटरिंग सिस्टम दुसर्या डेटा सेंटरमध्ये वेगळ्या सर्व्हरवर चालणे आवश्यक आहे.

तुम्हाला नवीन डेटा सेंटरमध्ये समर्पित सर्व्हर वापरायचा नसेल, तर तुम्ही क्लाउड मॉनिटरिंग सिस्टम वापरू शकता. आमची कंपनी झिडियम क्लाउड मॉनिटरिंग सिस्टम वापरते, परंतु तुम्ही इतर कोणतीही मॉनिटरिंग सिस्टम वापरू शकता. क्लाउड मॉनिटरिंग सिस्टमची किंमत नवीन सर्व्हर भाड्याने घेण्यापेक्षा कमी आहे.

शिफारसी:

1. घटकांच्या झाडाच्या स्वरूपात ऍप्लिकेशन्स आणि सिस्टम्सला शक्य तितक्या तपशीलांमध्ये खंडित करा, त्यामुळे कुठे आणि काय तुटलेले आहे हे समजून घेणे सोयीचे होईल आणि नियंत्रण अधिक पूर्ण होईल.
2. घटकाची कार्यक्षमता तपासण्यासाठी, चाचण्या वापरा. एक जटिल तपासण्यापेक्षा अनेक साध्या तपासण्या वापरणे चांगले.
3. कोडमध्ये लिहिण्याऐवजी मॉनिटरिंग सिस्टमच्या बाजूला मेट्रिक थ्रेशोल्ड कॉन्फिगर करा. हे तुम्हाला ॲप्लिकेशन पुन्हा कंपाइल, रीकॉन्फिगर किंवा रीस्टार्ट करण्यापासून वाचवेल.
4. सानुकूल तपासण्यांसाठी, खोट्या सूचना प्राप्त होण्यापासून टाळण्यासाठी प्रासंगिक वेळेचा मार्जिन वापरा कारण काही चेक पूर्ण होण्यासाठी नेहमीपेक्षा थोडा जास्त वेळ लागला.
5. जेव्हा निश्चितपणे समस्या असेल तेव्हाच मॉनिटरिंग सिस्टममधील घटक लाल करण्याचा प्रयत्न करा. जर ते काहीही न करता लाल झाले तर आपण मॉनिटरिंग सिस्टमच्या सूचनांकडे लक्ष देणे थांबवाल, त्याचा अर्थ गमावला जाईल.

तुम्ही अद्याप मॉनिटरिंग सिस्टम वापरत नसल्यास, सुरू करा! हे दिसते तितके अवघड नाही. तुम्ही स्वतः वाढलेल्या हिरव्या घटकांच्या झाडाकडे बघून एक किक मिळवा.

शुभेच्छा.

स्त्रोत: www.habr.com