हम स्पोर्टमास्टर की निगरानी करते हैं - कैसे और किसके साथ

हमने उत्पाद टीमों के गठन के चरण में एक निगरानी प्रणाली बनाने के बारे में सोचा। यह स्पष्ट हो गया कि हमारा व्यवसाय - शोषण - इन टीमों में नहीं आता है। ऐसा क्यों?

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

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

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

जिस प्लेटफ़ॉर्म पर हमारे ऑनलाइन स्टोर संचालित होते हैं वह इस तरह दिखता है:

• सामने
• मध्य कार्यालय
• वापस कार्यालय

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

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

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

अंततः, ऐसी असमान कहानियाँ संपूर्ण फ्रंटएंड, उपयोगकर्ताओं और हमारे मुख्य व्यवसाय कार्य - ऑनलाइन बिक्री को प्रभावित करती हैं। चूंकि हम किसी टीम का हिस्सा नहीं हैं, लेकिन एक ऑनलाइन स्टोर के हिस्से के रूप में सभी ईकॉमर्स एप्लिकेशन के संचालन में लगे हुए हैं, इसलिए हमने ईकॉमर्स प्लेटफॉर्म के लिए एक व्यापक निगरानी प्रणाली बनाने का काम अपने ऊपर लिया।

सिस्टम संरचना और स्टैक

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

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

इसलिए, उन्होंने हाथी को टुकड़ों में खाने का फैसला किया।

हमारे सिस्टम में शामिल हैं:

• हार्डवेयर;
• ऑपरेटिंग सिस्टम;
• सॉफ्टवेयर;
• निगरानी अनुप्रयोग में यूआई भाग;
• बिजनेस मेट्रिक्स;
• एकीकरण अनुप्रयोग;
• सूचना सुरक्षा;
• नेटवर्क;
• यातायात संतुलनकर्ता.

इस सिस्टम के केंद्र में ही मॉनिटरिंग है. आम तौर पर पूरे सिस्टम की स्थिति को समझने के लिए, आपको यह जानना होगा कि इन सभी परतों और अनुप्रयोगों के पूरे सेट पर अनुप्रयोगों के साथ क्या हो रहा है।

तो, ढेर के बारे में।

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

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

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

अन्य परतों के लिए डेटा स्रोत, उदाहरण के लिए, व्यावसायिक मेट्रिक्स, तीन घटकों में विभाजित हैं।

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

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

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

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

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

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

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

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

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

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

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

संभावना

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

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

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

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

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

औसतन, अब हमें प्रति दिन लगभग सौ अलर्ट प्राप्त होते हैं, इस तथ्य को ध्यान में रखते हुए कि अलर्ट का सहसंबंध अभी तक ठीक से कॉन्फ़िगर नहीं किया गया है। और यदि हमें कोई तकनीकी कार्य करना हो और हम जबरन किसी चीज को बंद कर दें तो उनकी संख्या काफी बढ़ जाती है।

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

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

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

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

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

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

यदि आप भी बड़ी संख्या में एकीकरणों के साथ बड़ी परियोजनाओं की निगरानी करते हैं, तो टिप्पणियों में लिखें कि आपको इसके लिए क्या आशा की किरण मिली।

स्रोत: www.habr.com