सेवा म्हणून देखरेख: मायक्रोसर्व्हिस आर्किटेक्चरसाठी मॉड्यूलर सिस्टम

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

हे पोस्ट माझ्या आमच्या भाषणाचा उतारा आहे विभाग RIT++ वर. बऱ्याच लोकांनी आम्हाला तेथून अहवालांची मजकूर आवृत्ती तयार करण्यास सांगितले. तुम्ही कॉन्फरन्समध्ये असाल किंवा व्हिडिओ पाहिल्यास, तुम्हाला नवीन काहीही सापडणार नाही. आणि इतर प्रत्येकजण - मांजरीमध्ये आपले स्वागत आहे. आम्ही अशा प्रणालीमध्ये कसे आलो, ते कसे कार्य करते आणि आम्ही ते कसे अद्यतनित करायचे हे मी तुम्हाला सांगेन.

भूतकाळ: योजना आणि योजना

आम्ही सध्याच्या मॉनिटरिंग सिस्टमवर कसे पोहोचलो? या प्रश्नाचे उत्तर देण्यासाठी, आपल्याला 2015 मध्ये जाण्याची आवश्यकता आहे. तेव्हा हे असे दिसत होते:

आमच्याकडे जवळपास २४ नोड्स होते जे निरीक्षणासाठी जबाबदार होते. वेगवेगळ्या क्राउन्स, स्क्रिप्ट्स, डिमनचा एक संपूर्ण पॅक आहे जो कसा तरी काहीतरी निरीक्षण करतो, संदेश पाठवतो आणि कार्ये करतो. आम्हाला वाटले की आम्ही जितके पुढे जाऊ तितकी ही व्यवस्था कमी व्यवहार्य असेल. ते विकसित करण्यात काही अर्थ नाही: ते खूप अवजड आहे.
आम्ही ते देखरेख घटक निवडण्याचे ठरवले जे आम्ही ठेवू आणि विकसित करू आणि ज्यांचा आम्ही त्याग करू. डॅशबोर्ड म्हणून त्यापैकी फक्त 19 ग्रेफाइट, एग्रीगेटर आणि ग्राफना राहिले. पण नवीन प्रणाली कशी असेल? याप्रमाणे:

आमच्याकडे मेट्रिक्स स्टोरेज आहे: हे ग्रेफाइट्स आहेत, जे वेगवान SSD ड्राइव्हवर आधारित असतील, हे मेट्रिक्ससाठी काही विशिष्ट एकत्रित आहेत. पुढे - डॅशबोर्ड प्रदर्शित करण्यासाठी ग्राफाना आणि अलर्टिंगसाठी मोइरा. आम्हाला विसंगती शोधण्यासाठी एक प्रणाली विकसित करायची होती.

मानक: मॉनिटरिंग 2.0

2015 मध्ये या योजना कशा दिसत होत्या. परंतु आम्हाला केवळ पायाभूत सुविधा आणि सेवाच नव्हे तर त्यासाठी कागदपत्रेही तयार करायची होती. आम्ही आमच्यासाठी कॉर्पोरेट मानक विकसित केले आहे, ज्याला आम्ही मॉनिटरिंग 2.0 म्हणतो. सिस्टमसाठी कोणत्या आवश्यकता होत्या?

• सतत उपलब्धता;
• मेट्रिक्स स्टोरेज इंटरव्हल = 10 सेकंद;
• मेट्रिक्स आणि डॅशबोर्डचे संरचित स्टोरेज;
• SLA > 99,99%
• UDP (!) द्वारे इव्हेंट मेट्रिक्सचे संकलन.

आम्हाला UDP ची गरज होती कारण आमच्याकडे रहदारीचा मोठा प्रवाह आणि मेट्रिक्स निर्माण करणाऱ्या घटना आहेत. तुम्ही ते सर्व एकाच वेळी ग्रेफाइटमध्ये लिहिल्यास, स्टोरेज कोलमडेल. आम्ही सर्व मेट्रिक्ससाठी प्रथम-स्तरीय उपसर्ग देखील निवडले.

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

वर्तमान: मॉनिटरिंग घटकांच्या परस्परसंवादाचा आकृती

सर्व प्रथम, आम्ही ऍप्लिकेशन्सचे निरीक्षण करतो: आमचा PHP कोड, ऍप्लिकेशन्स आणि मायक्रोसर्व्हिसेस - थोडक्यात, आमचे डेव्हलपर जे काही लिहितात. सर्व ॲप्लिकेशन्स UDP द्वारे ब्रुबेक एग्रीगेटरला मेट्रिक्स पाठवतात (statsd, C मध्ये पुन्हा लिहिलेले). सिंथेटिक चाचण्यांच्या निकालांनुसार ते सर्वात वेगवान असल्याचे दिसून आले. आणि ते आधीपासून एकत्रित मेट्रिक्स ग्रेफाइटला TCP द्वारे पाठवते.

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

आमच्याकडे हार्डवेअर, सॉफ्टवेअर, सिस्टम मेट्रिक्स आणि आमच्या जुन्या मुनिन मॉनिटरिंग सिस्टमवरील मेट्रिक्ससाठी एकत्रीकरण देखील आहे (याने आमच्यासाठी 2015 पर्यंत काम केले). आम्ही हे सर्व C deemon CollectD द्वारे संकलित करतो (त्यामध्ये विविध प्लगइन्सचा संपूर्ण समूह तयार केला आहे, ते ज्या होस्ट सिस्टमवर स्थापित केले आहे त्या सर्व संसाधनांचे सर्वेक्षण करू शकते, फक्त डेटा कुठे लिहायचा ते कॉन्फिगरेशनमध्ये निर्दिष्ट करा) आणि त्याद्वारे ग्रेफाइटवर डेटा लिहा. हे पायथन प्लगइन आणि शेल स्क्रिप्टला देखील समर्थन देते, जेणेकरून तुम्ही तुमचे स्वतःचे सानुकूल उपाय लिहू शकता: CollectD हा डेटा स्थानिक किंवा रिमोट होस्टकडून गोळा करेल (कर्ल गृहीत धरून) आणि तो Graphite ला पाठवेल.

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

कार्बन-सी-रिले नंतर मेट्रिक्स ग्रेफाइट क्लस्टरला पाठवते. आम्ही मेट्रिक्सचे मुख्य स्टोरेज म्हणून Go मध्ये पुन्हा लिहिलेले कार्बन-कॅशे वापरतो. गो-कार्बन, त्याच्या मल्टीथ्रेडिंगमुळे, कार्बन-कॅशेपेक्षा जास्त कामगिरी करते. हे डेटा प्राप्त करते आणि व्हिस्पर पॅकेज (मानक, पायथनमध्ये लिहिलेले) वापरून डिस्कवर लिहिते. आमच्या स्टोरेजमधील डेटा वाचण्यासाठी, आम्ही Graphite API वापरतो. हे मानक Graphite WEB पेक्षा खूप वेगवान आहे. डेटाचे पुढे काय होईल?

ते ग्राफाना जातात. आम्ही आमचे ग्रेफाइट क्लस्टर्स डेटाचा मुख्य स्त्रोत म्हणून वापरतो, तसेच आमच्याकडे मेट्रिक्स प्रदर्शित करण्यासाठी आणि डॅशबोर्ड तयार करण्यासाठी वेब इंटरफेस म्हणून Grafana आहे. त्यांच्या प्रत्येक सेवेसाठी, विकासक त्यांचा स्वतःचा डॅशबोर्ड तयार करतात. मग ते त्यांच्या आधारे आलेख तयार करतात, जे त्यांनी त्यांच्या ऍप्लिकेशन्समधून लिहिलेले मेट्रिक्स प्रदर्शित करतात. ग्राफाना व्यतिरिक्त, आमच्याकडे SLAM देखील आहे. हा एक अजगर राक्षस आहे जो ग्रेफाइटच्या डेटावर आधारित SLA ची गणना करतो. मी आधीच म्हटल्याप्रमाणे, आमच्याकडे अनेक डझन मायक्रो सर्व्हिसेस आहेत, ज्यापैकी प्रत्येकाची स्वतःची आवश्यकता आहे. SLAM वापरून, आम्ही दस्तऐवजीकरणाकडे जातो आणि ग्रेफाइटमध्ये असलेल्या गोष्टींशी त्याची तुलना करतो आणि आवश्यकता आमच्या सेवांच्या उपलब्धतेशी किती चांगल्या प्रकारे जुळतात याची तुलना करतो.

चला पुढे जाऊया: अलर्टिंग. हे एक मजबूत प्रणाली वापरून आयोजित केले जाते - मोइरा. ते स्वतंत्र आहे कारण त्याच्या खाली स्वतःचे ग्रेफाइट आहे. SKB "Kontur" मधील मुलांनी विकसित केलेले, python आणि Go मध्ये लिहिलेले, पूर्णपणे मुक्त स्रोत. मोइराला तोच प्रवाह प्राप्त होतो जो ग्रेफाइट्समध्ये जातो. काही कारणास्तव तुमचा स्टोरेज मरत असल्यास, तुमची सूचना अजूनही कार्य करेल.

आम्ही कुबर्नेट्समध्ये मोइरा तैनात केला आहे; तो मुख्य डेटाबेस म्हणून रेडिस सर्व्हरचा क्लस्टर वापरतो. परिणामी दोष-सहिष्णु प्रणाली होती. हे ट्रिगरच्या सूचीसह मेट्रिक्सच्या प्रवाहाची तुलना करते: त्यात कोणतेही उल्लेख नसल्यास, ते मेट्रिक कमी करते. त्यामुळे ते प्रति मिनिट गीगाबाइट्स मेट्रिक्स पचवण्यास सक्षम आहे.

आम्ही त्यास कॉर्पोरेट LDAP देखील जोडले आहे, ज्याच्या मदतीने कॉर्पोरेट प्रणालीचा प्रत्येक वापरकर्ता विद्यमान (किंवा नव्याने तयार केलेल्या) ट्रिगर्सच्या आधारे स्वतःसाठी सूचना तयार करू शकतो. मोइरामध्ये ग्रेफाइट असल्याने, ते त्याच्या सर्व वैशिष्ट्यांना समर्थन देते. तर तुम्ही प्रथम ओळ घ्या आणि ती ग्राफनामध्ये कॉपी करा. आलेखांवर डेटा कसा प्रदर्शित होतो ते पहा. आणि मग तुम्ही तीच ओळ घेऊन मोइरा मध्ये कॉपी करा. तुम्ही ते मर्यादेसह टांगता आणि आउटपुटवर अलर्ट मिळवा. हे सर्व करण्यासाठी, आपल्याला कोणत्याही विशिष्ट ज्ञानाची आवश्यकता नाही. मोइरा एसएमएस, ईमेल, जिरा, स्लॅक द्वारे अलर्ट करू शकते... हे सानुकूल स्क्रिप्टच्या अंमलबजावणीला देखील समर्थन देते. जेव्हा तिला ट्रिगर होतो आणि तिने कस्टम स्क्रिप्ट किंवा बायनरीचे सदस्यत्व घेतले होते, तेव्हा ती ती चालवते आणि JSON ला या बायनरीसाठी stdin ला पाठवते. त्यानुसार, आपल्या प्रोग्रामचे विश्लेषण करणे आवश्यक आहे. तुम्ही या JSON सह काय कराल ते तुमच्यावर अवलंबून आहे. हवे असल्यास टेलिग्रामवर पाठवा, हवे असल्यास जिरामध्ये टास्क उघडा, काहीही करा.

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

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

निरीक्षण घटक

आम्ही या कार्यासाठी वापरलेल्या घटकांच्या लिंकची यादी येथे आहे. ते सर्व ओपन सोर्स आहेत.

ग्रेफाइट:

• गो-कार्बन: github.com/lomik/go-carbon
• कुजबुजणे: github.com/graphite-project/whisper
• ग्रेफाइट-एपीआय: github.com/brutasse/graphite-api

कार्बन-सी-रिले:

github.com/grobian/carbon-c-relay

ब्रुबेक:

github.com/github/brubeck

संकलित:

collected.org

मोइरा:

github.com/moira-alert

ग्राफना:

grafana.com

हीपस्टर:

github.com/kubernetes/heapster

आकडेवारी

आणि सिस्टम आमच्यासाठी कसे कार्य करते याबद्दल काही संख्या येथे आहेत.

एग्रीगेटर (ब्रुबेक)

मेट्रिक्सची संख्या: ~300/से
ग्रेफाइटला मेट्रिक्स पाठवण्यासाठी मध्यांतर: 30 से
सर्व्हर संसाधन वापर: ~ 6% CPU (आम्ही पूर्ण सर्व्हरबद्दल बोलत आहोत); ~ 1 जीबी रॅम; ~3 Mbps LAN

ग्रेफाइट (गो-कार्बन)

मेट्रिक्सची संख्या: ~ 1 / मिनिट
मेट्रिक्स अपडेट मध्यांतर: 30 से
मेट्रिक्स स्टोरेज स्कीम: 30sec 35d, 5min 90d, 10min 365d (आपल्याला दीर्घ कालावधीत सेवेचे काय होते हे समजते)
सर्व्हर संसाधन वापर: ~10% CPU; ~ 20 जीबी रॅम; ~30 Mbps LAN

लवचिकता

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

येथे वास्तविक समस्येचे उदाहरण आहे. ग्रेफाइटमधील मेट्रिक एक फाइल आहे. त्याला एक नाव आहे. फाईलचे नाव = मेट्रिक नाव. आणि तिथे जाण्याचा मार्ग आहे. लिनक्समधील फाइलची नावे 255 वर्णांपर्यंत मर्यादित आहेत. आणि आमच्याकडे डेटाबेस विभागातील लोक (“अंतर्गत ग्राहक” म्हणून) आहेत. ते आम्हाला सांगतात: “आम्हाला आमच्या SQL क्वेरींचे निरीक्षण करायचे आहे. आणि ते 255 वर्ण नसून प्रत्येकी 8 MB आहेत. आम्हाला ते Grafana मध्ये दाखवायचे आहेत, या विनंतीचे पॅरामीटर्स पहायचे आहेत, आणि त्याहूनही चांगले, आम्हाला अशा विनंत्यांचा सर्वात वरचा भाग पहायचा आहे. ते रिअल टाइममध्ये प्रदर्शित झाल्यास ते छान होईल. त्यांना अलर्टमध्ये ठेवणे खरोखरच छान होईल.”

उदाहरण एसक्यूएल क्वेरीचे उदाहरण म्हणून घेतले आहे साइट postgrespro.ru

आम्ही रेडिस सर्व्हर सेट अप करतो आणि आमचे एकत्रित प्लगइन वापरतो, जे पोस्टग्रेसवर जातात आणि तेथून सर्व डेटा घेतात, ग्रेफाइटला मेट्रिक्स पाठवतात. परंतु आम्ही मेट्रिकचे नाव हॅशसह बदलतो. आम्ही एकाच वेळी समान हॅश रेडिसला की म्हणून पाठवतो आणि संपूर्ण SQL क्वेरी मूल्य म्हणून पाठवतो. ग्राफाना रेडिसमध्ये जाऊन ही माहिती घेऊ शकेल याची आम्हाला खात्री करायची आहे. आम्ही Graphite API उघडत आहोत कारण... ग्रेफाइटसह सर्व मॉनिटरिंग घटकांच्या परस्परसंवादासाठी हा मुख्य इंटरफेस आहे, आणि आम्ही तेथे उपनाम बायहॅश() नावाचे नवीन फंक्शन एंटर करतो - ग्राफना वरून आम्हाला मेट्रिकचे नाव मिळते आणि रेडिसला की म्हणून विनंती करण्यासाठी त्याचा वापर करतो. प्रतिसादात आम्हाला कीचे मूल्य मिळते, जी आमची "SQL क्वेरी" आहे अशाप्रकारे, आम्ही ग्राफानामध्ये एसक्यूएल क्वेरीचे प्रदर्शन प्रदर्शित केले, जे सिद्धांततः तेथे प्रदर्शित करणे अशक्य होते, त्यावरील आकडेवारीसह (कॉल, पंक्ती, एकूण_ वेळ, ...).

परिणाम

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

विश्वसनीयता. सर्व घटक दोष-सहिष्णु आहेत आणि आमचे भार चांगल्या प्रकारे हाताळतात.

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

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

आम्ही कशासाठी ध्येय ठेवत आहोत?

खाली सूचीबद्ध केलेली प्रत्येक गोष्ट केवळ अमूर्त विचार नाही, तर असे काहीतरी आहे ज्यासाठी किमान पहिली पावले उचलली गेली आहेत.

1. विसंगती डिटेक्टर. आम्हाला एक सेवा तयार करायची आहे जी आमच्या ग्रेफाइट स्टोरेजमध्ये जाईल आणि विविध अल्गोरिदम वापरून प्रत्येक मेट्रिक तपासेल. तेथे आधीच अल्गोरिदम आहेत जे आम्हाला पहायचे आहेत, डेटा आहे, आम्हाला त्याच्यासह कसे कार्य करावे हे माहित आहे.
2. मेटाडेटा. आमच्याकडे बऱ्याच सेवा आहेत, त्या काळानुसार बदलतात, त्यांच्याबरोबर काम करणाऱ्या लोकांप्रमाणेच. कागदपत्रे सतत मॅन्युअली सांभाळणे हा पर्याय नाही. म्हणूनच आम्ही आता आमच्या मायक्रो सर्व्हिसेसमध्ये मेटाडेटा एम्बेड करत आहोत. ते कोणी विकसित केले, ते कोणत्या भाषांशी संवाद साधते, SLA आवश्यकता, कोठे आणि कोणाला सूचना पाठवल्या पाहिजेत हे सांगते. सेवा उपयोजित करताना, सर्व घटक डेटा स्वतंत्रपणे तयार केला जातो. परिणामी, तुम्हाला दोन लिंक मिळतात - एक ट्रिगर करण्यासाठी, दुसरी ग्राफनामधील डॅशबोर्डसाठी.
3. प्रत्येक घरात देखरेख. आमचा विश्वास आहे की सर्व विकासकांनी अशी प्रणाली वापरली पाहिजे. या प्रकरणात, तुमची रहदारी कुठे आहे, त्याचे काय होते, ते कुठे पडते, त्याचे कमकुवतपणा कुठे आहे हे तुम्हाला नेहमी समजते. जर, उदाहरणार्थ, एखादी गोष्ट आली आणि तुमची सेवा क्रॅश झाली, तर तुम्हाला त्याबद्दल मॅनेजरच्या कॉल दरम्यान नाही तर ॲलर्टवरून कळेल आणि तुम्ही ताबडतोब नवीनतम लॉग उघडू शकता आणि तेथे काय झाले ते पाहू शकता.
4. उच्च कार्यक्षमता. आमचा प्रकल्प सतत वाढत आहे आणि आज तो प्रति मिनिट सुमारे 2 मेट्रिक मूल्यांवर प्रक्रिया करतो. एक वर्षापूर्वी, हा आकडा 000 होता आणि वाढ सुरूच आहे आणि याचा अर्थ असा आहे की काही काळानंतर ग्रेफाइट (व्हिस्पर) डिस्क सबसिस्टमवर जोरदारपणे लोड करण्यास सुरवात करेल. मी आधीच म्हटल्याप्रमाणे, ही मॉनिटरिंग सिस्टम घटकांच्या अदलाबदलीमुळे सार्वत्रिक आहे. कोणीतरी विशेषतः ग्रेफाइटसाठी त्यांच्या पायाभूत सुविधांची देखभाल आणि सतत विस्तार करते, परंतु आम्ही वेगळ्या मार्गाने जाण्याचा निर्णय घेतला: वापर क्लिकहाऊस आमच्या मेट्रिक्ससाठी भांडार म्हणून. हे संक्रमण जवळजवळ पूर्ण झाले आहे, आणि लवकरच मी तुम्हाला हे कसे केले गेले याबद्दल अधिक तपशीलवार सांगेन: कोणत्या अडचणी होत्या आणि त्या कशा दूर झाल्या, स्थलांतर प्रक्रिया कशी झाली, मी बंधनकारक म्हणून निवडलेल्या घटकांचे आणि त्यांच्या कॉन्फिगरेशनचे वर्णन करेन.

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

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