आम्ही स्पोर्टमास्टरचे निरीक्षण करतो - कसे आणि कशासह

आम्ही उत्पादन संघ तयार करण्याच्या टप्प्यावर एक देखरेख प्रणाली तयार करण्याचा विचार केला. आपला व्यवसाय - शोषण - या संघांमध्ये येत नाही हे स्पष्ट झाले. अस का?

वस्तुस्थिती अशी आहे की आमची सर्व कार्यसंघ वैयक्तिक माहिती प्रणाली, सूक्ष्म सेवा आणि आघाड्यांभोवती तयार केली गेली आहेत, त्यामुळे संघांना संपूर्ण प्रणालीचे संपूर्ण आरोग्य दिसत नाही. उदाहरणार्थ, डीप बॅकएंडमधील काही लहान भाग पुढच्या टोकावर कसा परिणाम करतात हे त्यांना माहित नसेल. त्यांच्या स्वारस्याची व्याप्ती ज्या सिस्टीमशी समाकलित आहे त्या प्रणालींपुरती मर्यादित आहे. जर संघ आणि त्याची सेवा A चा सेवा B शी जवळजवळ कोणताही संबंध नसेल, तर अशी सेवा संघासाठी जवळजवळ अदृश्य आहे.

आमचा कार्यसंघ, त्या बदल्यात, एकमेकांशी अतिशय मजबूतपणे समाकलित केलेल्या सिस्टमसह कार्य करतो: त्यांच्यामध्ये बरेच कनेक्शन आहेत, ही एक खूप मोठी पायाभूत सुविधा आहे. आणि ऑनलाइन स्टोअरचे ऑपरेशन या सर्व सिस्टमवर अवलंबून असते (ज्यापैकी आमच्याकडे, तसे, खूप मोठी संख्या आहे).

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

आमचे ऑनलाइन स्टोअर ज्या प्लॅटफॉर्मवर चालतात ते असे दिसते:

• समोर
• मध्यम कार्यालय
• परत कार्यालय

आम्हाला कितीही आवडेल, असे होत नाही की सर्व यंत्रणा सुरळीत आणि निर्दोषपणे काम करतात. मुद्दा, पुन्हा, सिस्टम आणि एकत्रीकरणांची संख्या आहे - आमच्यासारख्या गोष्टींसह, चाचणीची गुणवत्ता असूनही काही घटना अपरिहार्य आहेत. शिवाय, वेगळ्या प्रणालीमध्ये आणि त्यांच्या एकत्रीकरणाच्या दृष्टीने दोन्ही. आणि आपल्याला संपूर्ण प्लॅटफॉर्मच्या स्थितीचे सर्वसमावेशकपणे निरीक्षण करणे आवश्यक आहे, आणि केवळ त्याच्या कोणत्याही वैयक्तिक भागावर नाही.

तद्वतच, प्लॅटफॉर्म-व्यापी आरोग्य निरीक्षण स्वयंचलित असावे. आणि या प्रक्रियेचा एक अपरिहार्य भाग म्हणून आम्ही देखरेखीसाठी आलो. सुरुवातीला, हे केवळ फ्रंट-लाइन भागासाठी तयार केले गेले होते, तर नेटवर्क विशेषज्ञ, सॉफ्टवेअर आणि हार्डवेअर प्रशासकांकडे त्यांच्या स्वतःच्या लेयर-बाय-लेयर मॉनिटरिंग सिस्टम होत्या आणि अजूनही आहेत. या सर्व लोकांनी आपापल्या स्तरावर देखरेखीचे पालन केले; कोणालाही सर्वसमावेशक समज नव्हती.

उदाहरणार्थ, व्हर्च्युअल मशीन क्रॅश झाल्यास, बहुतेक प्रकरणांमध्ये फक्त हार्डवेअरसाठी जबाबदार प्रशासक आणि आभासी मशीनला त्याबद्दल माहिती असते. अशा प्रकरणांमध्ये, फ्रंटलाइन टीमने अॅप्लिकेशन क्रॅश झाल्याची वस्तुस्थिती पाहिली, परंतु त्याच्याकडे व्हर्च्युअल मशीनच्या क्रॅशबद्दल डेटा नव्हता. आणि प्रशासक कोण आहे हे जाणून घेऊ शकतो आणि या व्हर्च्युअल मशीनवर सध्या काय चालले आहे याची अंदाजे कल्पना असू शकते, जर हा काही प्रकारचा मोठा प्रकल्प असेल. त्याला बहुधा लहान मुलांबद्दल माहिती नसते. कोणत्याही परिस्थितीत, प्रशासकास मालकाकडे जाणे आवश्यक आहे आणि या मशीनवर काय होते ते विचारले पाहिजे, काय पुनर्संचयित करणे आवश्यक आहे आणि काय बदलणे आवश्यक आहे. आणि जर खरोखर काहीतरी गंभीर खराब झाले, तर ते मंडळांमध्ये फिरू लागले - कारण कोणीही संपूर्ण यंत्रणा पाहिली नाही.

शेवटी, अशा भिन्न कथा संपूर्ण फ्रंटएंड, वापरकर्ते आणि आमच्या मुख्य व्यवसाय कार्यावर - ऑनलाइन विक्रीवर परिणाम करतात. आम्ही एका टीमचा भाग नसून, ऑनलाइन स्टोअरचा भाग म्हणून सर्व ईकॉमर्स ऍप्लिकेशन्सच्या ऑपरेशनमध्ये गुंतलेले असल्याने, आम्ही ईकॉमर्स प्लॅटफॉर्मसाठी एक व्यापक मॉनिटरिंग सिस्टम तयार करण्याचे काम हाती घेतले.

सिस्टम संरचना आणि स्टॅक

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

ऍप्लिकेशन लाँचच्या सुरुवातीच्या टप्प्यावर सर्वसमावेशक देखरेखीचा अभाव (आम्ही ते बांधण्यास सुरुवात केली तेव्हापासून बहुतेक सिस्टीमचे उत्पादन सुरू होते) या वस्तुस्थितीला कारणीभूत ठरले की संपूर्ण प्लॅटफॉर्मचे निरीक्षण सेट करण्यासाठी आमच्याकडे लक्षणीय तांत्रिक कर्ज होते. एका IS साठी देखरेख सेट करणे आणि त्यासाठी तपशीलवार निरीक्षण करणे यावर लक्ष केंद्रित करणे आम्हाला परवडणारे नाही, कारण उर्वरित सिस्टम काही काळ निरीक्षणाशिवाय राहतील. या समस्येचे निराकरण करण्यासाठी, आम्ही माहिती प्रणालीच्या स्थितीचे स्तरानुसार मूल्यांकन करण्यासाठी सर्वात आवश्यक मेट्रिक्सची सूची ओळखली आणि ती लागू करण्यास सुरुवात केली.

त्यामुळे त्यांनी हत्तीचे तुकडे करून खाण्याचा निर्णय घेतला.

आमच्या सिस्टममध्ये हे समाविष्ट आहे:

• हार्डवेअर;
• ऑपरेटिंग सिस्टम;
• सॉफ्टवेअर
• मॉनिटरिंग ऍप्लिकेशनमधील UI भाग;
• व्यवसाय मेट्रिक्स;
• एकत्रीकरण अनुप्रयोग;
• माहिती संरक्षण;
• नेटवर्क;
• रहदारी बॅलन्सर.

या यंत्रणेच्या केंद्रस्थानी स्वतः लक्ष ठेवले जाते. सर्वसाधारणपणे संपूर्ण प्रणालीची स्थिती समजून घेण्यासाठी, तुम्हाला या सर्व स्तरांवर आणि अनुप्रयोगांच्या संपूर्ण संचामध्ये अनुप्रयोगांसह काय होत आहे हे जाणून घेणे आवश्यक आहे.

तर, स्टॅक बद्दल.

आम्ही ओपन सोर्स सॉफ्टवेअर वापरतो. केंद्रस्थानी आमच्याकडे Zabbix आहे, ज्याचा आम्ही प्रामुख्याने सूचना देणारी प्रणाली म्हणून वापर करतो. प्रत्येकाला माहित आहे की ते पायाभूत सुविधांच्या देखरेखीसाठी आदर्श आहे. याचा अर्थ काय? नेमके ते निम्न-स्तरीय मेट्रिक्स जे प्रत्येक कंपनीचे स्वतःचे डेटा सेंटर राखते (आणि स्पोर्टमास्टरचे स्वतःचे डेटा सेंटर आहेत) - सर्व्हर तापमान, मेमरी स्थिती, छापा, नेटवर्क डिव्हाइस मेट्रिक्स.

आम्ही Zabbix ला Telegram messenger आणि Microsoft Teams सह एकत्रित केले आहे, जे संघांमध्ये सक्रियपणे वापरले जातात. Zabbix मध्ये वास्तविक नेटवर्क, हार्डवेअर आणि काही सॉफ्टवेअरचा थर समाविष्ट आहे, परंतु तो रामबाण उपाय नाही. आम्ही हा डेटा इतर काही सेवांमधून समृद्ध करतो. उदाहरणार्थ, हार्डवेअर स्तरावर, आम्ही आमच्या व्हर्च्युअलायझेशन सिस्टमशी API द्वारे थेट कनेक्ट करतो आणि डेटा संकलित करतो.

अजून काय. Zabbix व्यतिरिक्त, आम्ही Prometheus वापरतो, जे आम्हाला डायनॅमिक पर्यावरण अनुप्रयोगामध्ये मेट्रिक्सचे परीक्षण करण्यास अनुमती देते. म्हणजेच, आम्ही HTTP एंडपॉइंटद्वारे ऍप्लिकेशन मेट्रिक्स प्राप्त करू शकतो आणि त्यात कोणते मेट्रिक लोड करायचे आणि कोणते नाही याची काळजी करू शकत नाही. या डेटाच्या आधारे, विश्लेषणात्मक क्वेरी विकसित केल्या जाऊ शकतात.

इतर स्तरांसाठी डेटा स्रोत, उदाहरणार्थ, व्यवसाय मेट्रिक्स, तीन घटकांमध्ये विभागलेले आहेत.

प्रथम, या बाह्य व्यवसाय प्रणाली आहेत, Google Analytics, आम्ही लॉगमधून मेट्रिक्स गोळा करतो. त्यांच्याकडून आम्हाला सक्रिय वापरकर्ते, रूपांतरणे आणि व्यवसायाशी संबंधित इतर सर्व गोष्टींचा डेटा मिळतो. दुसरे म्हणजे, ही एक UI मॉनिटरिंग सिस्टम आहे. त्याचे अधिक तपशीलवार वर्णन केले पाहिजे.

एकेकाळी आम्ही मॅन्युअल चाचणीसह सुरुवात केली आणि ती कार्यक्षमता आणि एकत्रीकरणाच्या स्वयंचलित चाचण्यांमध्ये वाढली. यातून आम्ही केवळ मुख्य कार्यक्षमता सोडून देखरेख केली आणि शक्य तितक्या स्थिर असलेल्या आणि कालांतराने अनेकदा बदलत नसलेल्या मार्करवर अवलंबून राहिलो.

नवीन संघ संरचनेचा अर्थ असा आहे की सर्व अनुप्रयोग क्रियाकलाप उत्पादन संघांपुरते मर्यादित आहेत, म्हणून आम्ही शुद्ध चाचणी करणे थांबवले आहे. त्याऐवजी, आम्ही Java, Selenium आणि Jenkins मध्ये लिहिलेल्या चाचण्यांमधून UI मॉनिटरिंग केले (रिपोर्ट लॉन्च करण्यासाठी आणि जनरेट करण्यासाठी सिस्टम म्हणून वापरले जाते).

आमच्या बर्‍याच चाचण्या झाल्या, पण शेवटी आम्ही मुख्य रस्त्यावर, टॉप-लेव्हल मेट्रिकवर जाण्याचा निर्णय घेतला. आणि जर आमच्याकडे बर्‍याच विशिष्ट चाचण्या असतील तर डेटा अद्ययावत ठेवणे कठीण होईल. प्रत्येक त्यानंतरच्या रिलीझमुळे संपूर्ण प्रणाली लक्षणीयरीत्या खंडित होईल आणि आम्ही फक्त त्याचे निराकरण करू. म्हणून, आम्ही अत्यंत मूलभूत गोष्टींवर लक्ष केंद्रित केले जे क्वचितच बदलतात आणि आम्ही फक्त त्यांचे निरीक्षण करतो.

शेवटी, तिसरे म्हणजे, डेटा स्रोत ही केंद्रीकृत लॉगिंग प्रणाली आहे. आम्ही लॉगसाठी लवचिक स्टॅक वापरतो आणि नंतर आम्ही हा डेटा व्यवसाय मेट्रिक्ससाठी आमच्या मॉनिटरिंग सिस्टममध्ये खेचू शकतो. या सर्वांव्यतिरिक्त, आमच्याकडे पायथनमध्ये लिहिलेली स्वतःची मॉनिटरिंग API सेवा आहे, जी API द्वारे कोणत्याही सेवांची चौकशी करते आणि त्यांच्याकडून Zabbix मध्ये डेटा गोळा करते.

निरीक्षणाचा आणखी एक अपरिहार्य गुणधर्म म्हणजे व्हिज्युअलायझेशन. आमचे ग्राफनावर आधारित आहे. हे इतर व्हिज्युअलायझेशन सिस्टममध्ये वेगळे आहे कारण ते तुम्हाला डॅशबोर्डवरील विविध डेटा स्रोतांमधून मेट्रिक्सची कल्पना करण्याची परवानगी देते. आम्ही ऑनलाइन स्टोअरसाठी उच्च-स्तरीय मेट्रिक्स संकलित करू शकतो, उदाहरणार्थ, डीबीएमएस वरून शेवटच्या तासात दिलेल्या ऑर्डरची संख्या, ज्या OS वर हे ऑनलाइन स्टोअर Zabbix वरून चालत आहे त्या OS साठी कार्यप्रदर्शन मेट्रिक्स आणि या अनुप्रयोगाच्या उदाहरणांसाठी मेट्रिक्स प्रोमिथियस पासून. आणि हे सर्व एकाच डॅशबोर्डवर असेल. स्पष्ट आणि प्रवेशयोग्य.

मी सुरक्षिततेबद्दल लक्षात ठेवतो - आम्ही सध्या सिस्टमला अंतिम स्वरूप देत आहोत, ज्याला आम्ही नंतर जागतिक मॉनिटरिंग सिस्टमसह समाकलित करू. माझ्या मते, माहिती सुरक्षेच्या क्षेत्रात ई-कॉमर्सच्या मुख्य समस्या बॉट्स, पार्सर आणि ब्रूट फोर्सशी संबंधित आहेत. आम्‍ही यावर लक्ष ठेवण्‍याची आवश्‍यकता आहे, कारण या सर्वांचा आमच्‍या अॅप्लिकेशनच्‍या ऑपरेशनवर आणि व्‍यावसायिक दृष्टिकोनातून आमची प्रतिष्ठा या दोहोंवर गंभीर परिणाम होऊ शकतो. आणि निवडलेल्या स्टॅकसह आम्ही ही कार्ये यशस्वीरित्या कव्हर करतो.

दुसरा महत्त्वाचा मुद्दा म्हणजे प्रोमिथियसने अॅप्लिकेशन लेयर असेंबल केले आहे. तो स्वत: देखील Zabbix सह समाकलित आहे. आणि आमच्याकडे साइटस्पीड देखील आहे, एक सेवा जी आम्हाला आमच्या पृष्ठाची लोडिंग गती, अडथळे, पृष्ठ प्रस्तुतीकरण, स्क्रिप्ट लोड करणे इत्यादी पॅरामीटर्स पाहण्याची परवानगी देते, ती देखील API एकीकृत आहे. त्यामुळे आमचे मेट्रिक्स Zabbix मध्ये गोळा केले जातात, आणि त्यानुसार, आम्ही तेथून अलर्ट देखील करतो. सर्व सूचना सध्या मुख्य पाठवण्याच्या पद्धतींवर पाठवल्या जातात (आता ते ईमेल आणि टेलिग्राम आहे, एमएस टीम्स देखील अलीकडे कनेक्ट केले गेले आहेत). स्मार्ट बॉट्स सेवा म्हणून काम करतात आणि सर्व इच्छुक उत्पादन संघांना मॉनिटरिंग माहिती प्रदान करतात अशा स्थितीत अलर्टिंग अपग्रेड करण्याची योजना आहे.

आमच्यासाठी, मेट्रिक्स केवळ वैयक्तिक माहिती प्रणालींसाठीच नाही तर अनुप्रयोग वापरत असलेल्या संपूर्ण पायाभूत सुविधांसाठी सामान्य मेट्रिक्स देखील महत्त्वाचे आहेत: भौतिक सर्व्हरचे क्लस्टर ज्यावर व्हर्च्युअल मशीन चालतात, ट्रॅफिक बॅलन्सर, नेटवर्क लोड बॅलन्सर्स, नेटवर्क स्वतः, संप्रेषण चॅनेलचा वापर . आमच्या स्वतःच्या डेटा सेंटरसाठी प्लस मेट्रिक्स (आमच्याकडे त्यापैकी अनेक आहेत आणि पायाभूत सुविधा खूप मोठी आहे).

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

आणि मेट्रिक्सच्या सहाय्याने, आम्ही आमच्या माहिती प्रणालीद्वारे संसाधनांच्या वापराचा कल पाहतो. आणि त्यांच्या आधारे आपण काहीतरी नियोजन करू शकतो. व्हर्च्युअलायझेशन स्तरावर, आम्ही डेटा संकलित करतो आणि डेटा सेंटरद्वारे उपलब्ध संसाधनांची माहिती पाहतो. आणि आधीच डेटा सेंटरमध्ये तुम्ही रिसायकलिंग, वास्तविक वितरण आणि संसाधनांचा वापर पाहू शकता. शिवाय, स्टँडअलोन सर्व्हर आणि व्हर्च्युअल मशीन आणि भौतिक सर्व्हरचे क्लस्टर ज्यावर ही सर्व आभासी मशीन जोमाने फिरत आहेत.

संभावना

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

आमचे कार्य शेवटी योग्य सूचना देणे आहे. उदाहरणार्थ, हार्डवेअरमध्ये समस्या असल्यास, पुन्हा, व्हर्च्युअल मशीनसह, आणि एक महत्त्वपूर्ण अनुप्रयोग असल्यास, आणि सेवेचा कोणत्याही प्रकारे बॅकअप घेतला गेला नाही. आम्हाला कळले की व्हर्च्युअल मशीनचा मृत्यू झाला आहे. मग व्यवसाय मेट्रिक्स तुम्हाला सतर्क करतील: वापरकर्ते कुठेतरी गायब झाले आहेत, कोणतेही रूपांतरण नाही, इंटरफेसमधील UI अनुपलब्ध आहे, सॉफ्टवेअर आणि सेवा देखील मृत झाल्या आहेत.

या परिस्थितीत, आम्हाला अलर्टमधून स्पॅम प्राप्त होईल आणि हे यापुढे योग्य मॉनिटरिंग सिस्टमच्या स्वरूपनात बसणार नाही. परस्परसंबंधाचा प्रश्न निर्माण होतो. म्हणूनच, आदर्शपणे, आमच्या मॉनिटरिंग सिस्टमने असे म्हणले पाहिजे: "मित्रांनो, तुमचे भौतिक मशीन मरण पावले आहे आणि त्यासोबत हे ऍप्लिकेशन आणि हे मेट्रिक्स," एका इशाऱ्याच्या मदतीने, आमच्यावर शंभर इशाऱ्यांचा भडिमार करण्याऐवजी. हे मुख्य गोष्ट कळवावे - कारण, जे त्याच्या स्थानिकीकरणामुळे त्वरीत समस्या दूर करण्यास मदत करते.

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

हे सर्व अलर्ट तयार करण्याच्या आवश्यकतांबद्दल आहे. मग परिस्थिती दोन दिशांनी विकसित होऊ शकते - एकतर समस्या आहे आणि ती सोडवण्याची गरज आहे, किंवा मॉनिटरिंग सिस्टममध्ये अपयश आले आहे. परंतु कोणत्याही परिस्थितीत, आपल्याला ते शोधून काढण्याची आवश्यकता आहे.

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

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

आमचे सहकारी येऊन काही मेट्रिक जोडण्यास सांगू शकतात जे आम्हाला आणि टीमसाठी उपयुक्त ठरतील. किंवा, उदाहरणार्थ, आमच्याकडे असलेले मूलभूत मेट्रिक्स टीमकडे पुरेसे नसतील; त्यांना काही विशिष्ट गोष्टींचा मागोवा घेणे आवश्यक आहे. Grafana मध्ये, आम्ही प्रत्येक संघासाठी जागा तयार करतो आणि प्रशासक अधिकार देतो. तसेच, जर एखाद्या संघाला डॅशबोर्डची आवश्यकता असेल, परंतु त्यांना ते कसे करावे हे माहित नसेल/न कळत असेल, तर आम्ही त्यांना मदत करतो.

आम्ही संघाच्या मूल्य निर्मितीच्या, त्यांच्या प्रकाशनाच्या आणि नियोजनाच्या प्रवाहाच्या बाहेर असल्याने, आम्ही हळूहळू या निष्कर्षापर्यंत पोहोचत आहोत की सर्व प्रणालींचे प्रकाशन अखंड आहेत आणि आमच्याशी समन्वय न करता ते दररोज आणले जाऊ शकतात. आणि या प्रकाशनांचे निरीक्षण करणे आमच्यासाठी महत्त्वाचे आहे, कारण ते संभाव्यपणे अनुप्रयोगाच्या ऑपरेशनवर परिणाम करू शकतात आणि काहीतरी खंडित करू शकतात आणि हे गंभीर आहे. रिलीझ व्यवस्थापित करण्यासाठी, आम्ही बांबू वापरतो, जिथून आम्हाला API द्वारे डेटा प्राप्त होतो आणि कोणत्या माहिती प्रणालीमध्ये कोणती रिलीझ जारी केली गेली आणि त्यांची स्थिती पाहू शकतो. आणि सर्वात महत्वाची गोष्ट म्हणजे कोणत्या वेळी. आम्ही मुख्य गंभीर मेट्रिक्सवर रिलीझ मार्कर वरती ठेवतो, जे समस्यांच्या बाबतीत दृश्यदृष्ट्या खूप सूचक असतात.

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

आणि भविष्यात या क्षेत्रात आम्ही सक्रियतेवर लक्ष केंद्रित करू इच्छितो. तद्वतच, मला जवळ येत असलेल्या समस्येबद्दल आधीच जाणून घ्यायचे आहे, आणि वस्तुस्थितीनंतर नाही, जेणेकरून मी ती सोडवण्याऐवजी प्रतिबंधित करू शकेन. काहीवेळा मॉनिटरिंग सिस्टीमचे खोटे अलार्म मानवी चुकांमुळे आणि ऍप्लिकेशनमधील बदलांमुळे उद्भवतात. आणि आम्ही यावर काम करतो, ते डीबग करतो आणि मॉनिटरिंग सिस्टममध्ये कोणत्याही फेरफार करण्यापूर्वी आमच्यासोबत वापरणाऱ्या वापरकर्त्यांना चेतावणी देण्याचा प्रयत्न करतो. , किंवा या क्रियाकलाप तांत्रिक विंडोमध्ये पार पाडा.

त्यामुळे, प्रणाली लाँच केली गेली आहे आणि वसंत ऋतूच्या सुरुवातीपासून यशस्वीरित्या काम करत आहे... आणि खूप वास्तविक नफा दाखवत आहे. अर्थात, ही त्याची अंतिम आवृत्ती नाही; आम्ही आणखी अनेक उपयुक्त वैशिष्ट्ये सादर करणार आहोत. परंतु आत्ता, बर्याच एकत्रीकरण आणि अनुप्रयोगांसह, ऑटोमेशनचे निरीक्षण करणे खरोखरच अपरिहार्य आहे.

आपण मोठ्या संख्येने एकत्रीकरणासह मोठ्या प्रकल्पांचे देखील निरीक्षण करत असल्यास, टिप्पण्यांमध्ये लिहा की यासाठी आपल्याला कोणती चांदीची बुलेट सापडली.

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