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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

हमारी प्रणाली में निम्नलिखित शामिल हैं:

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

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

तो, स्टैक के बारे में।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

संभावना

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

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

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

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

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

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

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

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

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

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

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

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

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

स्रोत: www.habr.com