सेवाको रूपमा निगरानी: माइक्रोसर्भिस आर्किटेक्चरको लागि एक मोड्युलर प्रणाली

आज, मोनोलिथिक कोडको अतिरिक्त, हाम्रो परियोजनाले दर्जनौं माइक्रो सेवाहरू समावेश गर्दछ। तिनीहरू मध्ये प्रत्येक अनुगमन गर्न आवश्यक छ। DevOps इन्जिनियरहरू प्रयोग गरेर यस्तो स्केलमा यो गर्न समस्याग्रस्त छ। हामीले विकासकर्ताहरूको लागि सेवाको रूपमा काम गर्ने अनुगमन प्रणाली विकास गरेका छौं। तिनीहरूले स्वतन्त्र रूपमा निगरानी प्रणालीमा मेट्रिकहरू लेख्न सक्छन्, तिनीहरूलाई प्रयोग गर्न सक्छन्, तिनीहरूमा आधारित ड्यासबोर्डहरू निर्माण गर्न सक्छन्, र तिनीहरूमा अलर्टहरू संलग्न गर्न सक्छन् जुन थ्रेसहोल्ड मानहरू पुग्दा ट्रिगर हुनेछ। DevOps इन्जिनियरहरूका लागि, केवल पूर्वाधार र कागजातहरू।

यो पोष्ट हाम्रो साथको मेरो भाषणको ट्रान्सक्रिप्ट हो सेक्सनहरू RIT++ मा। धेरै मानिसहरूले हामीलाई त्यहाँबाट रिपोर्टहरूको पाठ संस्करण बनाउन आग्रह गरे। यदि तपाईं सम्मेलनमा हुनुहुन्थ्यो वा भिडियो हेर्नुभयो भने, तपाईंले केही नयाँ फेला पार्नुहुनेछैन। र अरू सबै - बिरालो स्वागत छ। म तपाईलाई बताउनेछु कि हामी कसरी यस्तो प्रणालीमा आयौं, यसले कसरी काम गर्छ र हामी यसलाई कसरी अपडेट गर्ने योजना गर्छौं।

विगत: योजना र योजनाहरू

हामी वर्तमान अनुगमन प्रणालीमा कसरी आइपुग्यौं? यस प्रश्नको जवाफ दिनको लागि, तपाइँ 2015 मा जानु आवश्यक छ। यो त्यसबेला जस्तो देखिन्थ्यो:

हामीसँग लगभग 24 नोडहरू थिए जुन अनुगमनको लागि जिम्मेवार थिए। त्यहाँ विभिन्न क्राउनहरू, लिपिहरू, डेमनहरूको सम्पूर्ण प्याक छ जुन कुनै न कुनै रूपमा केहि निगरानी गर्दछ, सन्देशहरू पठाउँदछ, र कार्यहरू प्रदर्शन गर्दछ। हामीले सोचेका थियौं कि हामी जति अगाडि जान्छौं, यस्तो प्रणाली कम व्यवहार्य हुनेछ। यसलाई विकास गर्न कुनै मतलब छैन: यो धेरै बोझिल छ।
हामीले ती अनुगमन तत्वहरू छनोट गर्ने निर्णय गर्यौं जुन हामीले राख्नेछौं र विकास गर्नेछौं, र हामीले त्याग्नेछौं। त्यहाँ 19 ग्रेफाइटहरू, एग्रीगेटरहरू र ड्यासबोर्डको रूपमा मात्र रह्यो। तर नयाँ प्रणाली कस्तो हुनेछ? यो जस्तो:

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

मानक: निगरानी 2.0

2015 मा योजनाहरू जस्तो देखिन्थ्यो। तर हामीले पूर्वाधार र सेवा मात्र होइन, यसको लागि कागजातहरू पनि तयार गर्नुपर्थ्यो। हामीले आफ्नो लागि एक कर्पोरेट मानक विकास गरेका छौं, जसलाई हामी अनुगमन 2.0 भन्छौं। प्रणालीका लागि के आवश्यकताहरू थिए?

• निरन्तर उपलब्धता;
• मेट्रिक्स भण्डारण अन्तराल = 10 सेकेन्ड;
• मेट्रिक्स र ड्यासबोर्डहरूको संरचित भण्डारण;
• SLA > 99,99%
• UDP (!) मार्फत घटना मेट्रिक्स को संग्रह।

हामीलाई UDP चाहिन्छ किनभने हामीसँग ट्राफिकको ठूलो प्रवाह र मेट्रिक्स उत्पन्न गर्ने घटनाहरू छन्। यदि तपाईंले ती सबैलाई एकैचोटि ग्रेफाइटमा लेख्नुभयो भने, भण्डारण पतन हुनेछ। हामीले सबै मेट्रिक्सका लागि पहिलो-स्तर उपसर्गहरू पनि छनोट गर्यौं।

प्रत्येक उपसर्गको केही गुण हुन्छ। त्यहाँ सर्भरहरू, नेटवर्कहरू, कन्टेनरहरू, स्रोतहरू, अनुप्रयोगहरू, र यतिका लागि मेट्रिकहरू छन्। स्पष्ट, कडा, टाइप गरिएको फिल्टरिङ लागू गरिएको छ, जहाँ हामी पहिलो-स्तरको मेट्रिक्स स्वीकार गर्छौं र बाँकीलाई छोड्छौं। यसरी हामीले २०१५ मा यो प्रणालीको योजना बनायौं। वर्तमानमा के छ?

वर्तमान: अनुगमन अवयवहरूको अन्तरक्रियाको रेखाचित्र

सबैभन्दा पहिले, हामी अनुप्रयोगहरू निगरानी गर्छौं: हाम्रो PHP कोड, अनुप्रयोगहरू र माइक्रोसेवाहरू - छोटोमा, हाम्रा विकासकर्ताहरूले लेखेका सबै कुरा। सबै अनुप्रयोगहरूले ब्रुबेक एग्रीगेटरलाई UDP मार्फत मेट्रिकहरू पठाउँछन् (statsd, C मा पुन: लेखिएको)। यो सिंथेटिक परीक्षण मा सबै भन्दा छिटो भयो। र यसले पहिले नै एकत्रित मेट्रिक्सलाई TCP मार्फत ग्रेफाइटमा पठाउँछ।

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

हामीसँग हार्डवेयर, सफ्टवेयर, प्रणाली मेट्रिक्स र हाम्रो पुरानो मुनिन अनुगमन प्रणाली (यसले २०१५ सम्म हाम्रो लागि काम गर्‍यो) मा मेट्रिक्सको लागि एकीकरण पनि छ। हामी यो सबै C deemon CollectD मार्फत सङ्कलन गर्छौं (यसमा निर्मित विभिन्न प्लगइनहरूको सम्पूर्ण गुच्छा छ, यसले होस्ट प्रणालीको सबै स्रोतहरू पोल गर्न सक्छ जसमा यो स्थापना गरिएको छ, केवल डेटा कहाँ लेख्ने कन्फिगरेसनमा निर्दिष्ट गर्नुहोस्) र यसको माध्यमबाट ग्रेफाइटमा डाटा लेख्नुहोस्। यसले पाइथन प्लगइनहरू र शेल स्क्रिप्टहरूलाई पनि समर्थन गर्दछ, त्यसैले तपाईंले आफ्नै अनुकूलन समाधानहरू लेख्न सक्नुहुन्छ: CollectD ले यो डाटा स्थानीय वा रिमोट होस्टबाट सङ्कलन गर्नेछ (कर्ल मान्दै) र यसलाई ग्रेफाइटमा पठाउनेछ।

त्यसपछि हामीले कार्बन-सी-रिलेमा सङ्कलन गरेका सबै मेट्रिक्स पठाउँछौं। यो ग्रेफाइटबाट कार्बन रिले समाधान हो, C मा परिमार्जित। यो एक राउटर हो जसले हामीले हाम्रा एग्रीगेटरहरूबाट पठाउने सबै मेट्रिकहरू सङ्कलन गर्छ र तिनीहरूलाई नोडहरूमा रूट गर्छ। राउटिंग चरणमा पनि, यसले मेट्रिक्सको वैधता जाँच गर्दछ। पहिलो, तिनीहरू उपसर्ग योजना अनुरूप हुनुपर्छ जुन मैले पहिले देखाएको छु र, दोस्रो, तिनीहरू ग्रेफाइटका लागि मान्य छन्। अन्यथा तिनीहरू झर्नेछन्।

कार्बन-सी-रिलेले मेट्रिक्सलाई ग्रेफाइट क्लस्टरमा पठाउँछ। हामी मेट्रिक्सको मुख्य भण्डारणको रूपमा Go मा पुन: लेखिएको कार्बन-क्यास प्रयोग गर्छौं। गो-कार्बन, यसको मल्टिथ्रेडिङको कारणले, कार्बन-क्यास भन्दा धेरै टाढा छ। यसले डेटा प्राप्त गर्दछ र यसलाई व्हिस्पर प्याकेज (मानक, पाइथनमा लेखिएको) प्रयोग गरेर डिस्कहरूमा लेख्छ। हाम्रो भण्डारणबाट डाटा पढ्नको लागि, हामी Graphite API प्रयोग गर्छौं। यो मानक Graphite WEB भन्दा धेरै छिटो छ। त्यसपछि डाटामा के हुन्छ?

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

अगाडि बढौं: चेतावनी। यो एक बलियो प्रणाली प्रयोग गरेर संगठित छ - Moira। यो स्वतन्त्र छ किनभने हुड अन्तर्गत यसको आफ्नै ग्रेफाइट छ। SKB "Kontur" बाट केटाहरू द्वारा विकसित, python and Go मा लेखिएको, पूर्ण रूपमा खुला स्रोत। मोइराले उही प्रवाह प्राप्त गर्दछ जुन ग्रेफाइटमा जान्छ। यदि कुनै कारणले तपाईंको भण्डारण मर्छ भने, तपाईंको चेतावनी अझै पनि काम गर्नेछ।

हामीले Kubernetes मा Moira तैनात गर्यौं; यसले मुख्य डाटाबेसको रूपमा Redis सर्भरहरूको क्लस्टर प्रयोग गर्दछ। परिणाम एक दोष-सहिष्णु प्रणाली थियो। यसले मेट्रिक्सको स्ट्रिमलाई ट्रिगरहरूको सूचीसँग तुलना गर्छ: यदि यसमा कुनै उल्लेख छैन भने, यसले मेट्रिक छोड्छ। त्यसैले यो प्रति मिनेट मेट्रिक्स को गिगाबाइट पचाउन सक्षम छ।

हामीले यसमा एक कर्पोरेट LDAP पनि संलग्न गरेका छौं, जसको मद्दतले कर्पोरेट प्रणालीको प्रत्येक प्रयोगकर्ताले अवस्थित (वा नयाँ सिर्जना गरिएको) ट्रिगरहरूको आधारमा आफ्नै लागि सूचनाहरू सिर्जना गर्न सक्छ। मोइराले ग्रेफाइट समावेश गरेको हुनाले, यसले यसको सबै सुविधाहरूलाई समर्थन गर्दछ। त्यसोभए तपाईंले पहिले लाइन लिनुहोस् र यसलाई Grafana मा प्रतिलिपि गर्नुहोस्। ग्राफमा डाटा कसरी प्रदर्शित हुन्छ हेर्नुहोस्। र त्यसपछि तपाइँ उही लाइन लिनुहुन्छ र यसलाई मोइरामा प्रतिलिपि गर्नुहुन्छ। तपाइँ यसलाई सीमा संग झुण्ड्याउनुहोस् र आउटपुटमा अलर्ट प्राप्त गर्नुहोस्। यो सबै गर्न को लागी, तपाईलाई कुनै विशेष ज्ञान आवश्यक पर्दैन। मोइराले एसएमएस, इमेल, जिरा, स्ल्याक मार्फत अलर्ट गर्न सक्छ ... यसले अनुकूलन लिपिहरूको कार्यान्वयनलाई पनि समर्थन गर्दछ। जब उसलाई ट्रिगर हुन्छ, र उसले आफू अनुकूल स्क्रिप्ट वा बाइनरीको सदस्यता लिन्छ, उसले यसलाई चलाउँछ र JSON लाई यो बाइनरीको लागि stdin मा पठाउँछ। तदनुसार, तपाइँको कार्यक्रम यसलाई पार्स गर्नुपर्छ। तपाईले यो JSON सँग के गर्नुहुन्छ तपाईमा निर्भर छ। यदि तपाई चाहनुहुन्छ भने, यसलाई टेलिग्राममा पठाउनुहोस्, यदि तपाई चाहनुहुन्छ भने, जिरामा कार्यहरू खोल्नुहोस्, जे पनि गर्नुहोस्।

हामी सतर्कता - Imagotag को लागि हाम्रो आफ्नै विकास पनि प्रयोग गर्दछौं। हामीले प्यानललाई अनुकूलन गर्यौं, जुन सामान्यतया पसलहरूमा इलेक्ट्रोनिक मूल्य ट्यागहरूको लागि प्रयोग गरिन्छ, हाम्रो आवश्यकताहरू अनुरूप। हामीले यसमा मोइराबाट ट्रिगरहरू ल्यायौं। यसले तिनीहरू कुन अवस्थामा छन् र कहिले भयो भनेर संकेत गर्दछ। केही विकासकर्ताहरूले यस प्यानलको पक्षमा Slack र इमेलमा सूचनाहरू त्यागे।

ठिक छ, हामी एक प्रगतिशील कम्पनी भएकाले, हामीले यस प्रणालीमा कुबेरनेटहरू पनि निगरानी गर्यौं। हामीले यसलाई Heapster प्रयोग गरेर प्रणालीमा समावेश गर्यौं, जुन हामीले क्लस्टरमा स्थापना गर्यौं, यसले डाटा सङ्कलन गर्छ र ग्रेफाइटमा पठाउँछ। नतिजाको रूपमा, रेखाचित्र यस्तो देखिन्छ:

अनुगमन अवयवहरू

हामीले यस कार्यको लागि प्रयोग गरेका कम्पोनेन्टहरूको लिङ्कहरूको सूची यहाँ छ। ती सबै खुला स्रोत हुन्।

ग्रेफाइट:

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

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

github.com/grobian/carbon-c-relay

Brubeck:

github.com/github/brubeck

सङ्कलन:

collected.org

मोइरा:

github.com/moira-alert

ग्राफना:

grafana.com

हेपस्टर:

github.com/kubernetes/heapster

तथ्याङ्कहरू

र प्रणालीले हाम्रो लागि कसरी काम गर्छ भन्ने बारे यहाँ केही संख्याहरू छन्।

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

मेट्रिकको संख्या: ~300/सेकेन्ड
ग्रेफाइटमा मेट्रिक्स पठाउनको लागि अन्तराल: ३० सेकेन्ड
सर्भर स्रोत उपयोग: ~ 6% CPU (हामी पूर्ण सर्भरहरूको बारेमा कुरा गर्दैछौं); ~ १ जीबी र्याम; ~1 Mbps LAN

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

मेट्रिक्सको संख्या: ~ 1 / मिनेट
मेट्रिक्स अपडेट अन्तराल: ३० सेकेन्ड
मेट्रिक्स भण्डारण योजना: 30sec 35d, 5min 90d, 10min 365d (तपाईंलाई लामो समयको अवधिमा सेवामा के हुन्छ भन्ने बुझिन्छ)
सर्भर स्रोत उपयोग: ~ 10% CPU; ~ 20GB RAM; ~30 Mbps LAN

लचिलोपन

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

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

उदाहरण SQL क्वेरी बाट उदाहरणको रूपमा लिइएको छ साइट postgrespro.ru

हामीले Redis सर्भर सेटअप गर्छौं र हाम्रो संग्रहित प्लगइनहरू प्रयोग गर्छौं, जुन Postgres मा जान्छ र त्यहाँबाट सबै डाटा लिन्छ, ग्रेफाइटमा मेट्रिक्स पठाउँछ। तर हामीले मेट्रिक नामलाई ह्यासले प्रतिस्थापन गर्छौं। हामी एकै साथ एकै ह्यासलाई कुञ्जीको रूपमा Redis मा पठाउँछौं, र सम्पूर्ण SQL क्वेरी मानको रूपमा। हामीले गर्नुपर्ने भनेको Grafana Redis मा गएर यो जानकारी लिन सक्छ भनी सुनिश्चित गर्नु हो। हामी Graphite API खोल्दै छौं किनभने... यो ग्रेफाइटसँग सबै निगरानी घटकहरूको अन्तरक्रियाको लागि मुख्य इन्टरफेस हो, र हामी त्यहाँ एउटा नयाँ प्रकार्य प्रविष्ट गर्छौं जसलाई aliasByHash() भनिन्छ - Grafana बाट हामीले मेट्रिकको नाम प्राप्त गर्छौं, र यसलाई कुञ्जीको रूपमा Redis लाई अनुरोधमा प्रयोग गर्दछौं। प्रतिक्रिया हामीले कुञ्जीको मान पाउँछौं, जुन हाम्रो "SQL क्वेरी" हो। यसरी, हामीले Grafana मा SQL क्वेरीको प्रदर्शन देख्यौं, जुन सिद्धान्तमा त्यहाँ प्रदर्शन गर्न असम्भव थियो, यसमा तथ्याङ्कहरू सहित (कल, पङ्क्तिहरू, कुल_समय, ...)।

परिणामहरू

उपलब्धता हाम्रो निगरानी सेवा कुनै पनि अनुप्रयोग र कुनै पनि कोडबाट 24/7 उपलब्ध छ। यदि तपाइँसँग भण्डारण सुविधाहरूमा पहुँच छ भने, तपाइँ सेवामा डाटा लेख्न सक्नुहुन्छ। भाषा महत्त्वपूर्ण छैन, निर्णय महत्त्वपूर्ण छैन। तपाईंले सकेट कसरी खोल्ने, त्यहाँ मेट्रिक राख्ने र सकेट बन्द गर्ने तरिका जान्न आवश्यक छ।

विश्वसनीयता। सबै कम्पोनेन्टहरू गल्ती-सहनशील छन् र हाम्रो भारहरू राम्रोसँग ह्यान्डल गर्छन्।

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

स्वतन्त्रता। DevOps ईन्जिनियरहरूको मद्दत बिना तपाईं यो सबै आफै गर्न सक्नुहुन्छ। र यो एक फाइदा हो, किनकि तपाईं अहिले आफ्नो परियोजना निगरानी गर्न सक्नुहुन्छ, तपाईंले कसैलाई सोध्नु पर्दैन - या त काम सुरु गर्न वा परिवर्तनहरू गर्न।

हामीले के को लागि लक्ष्य राखेका छौं?

तल सूचीबद्ध सबै कुरा अमूर्त विचारहरू मात्र होइन, तर कम्तिमा पहिलो चरणहरू लिइएका कुराहरू हुन्।

1. विसंगति डिटेक्टर। हामी हाम्रो ग्रेफाइट भण्डारणहरूमा जाने र विभिन्न एल्गोरिदमहरू प्रयोग गरेर प्रत्येक मेट्रिक जाँच गर्ने सेवा सिर्जना गर्न चाहन्छौं। त्यहाँ पहिले नै एल्गोरिदमहरू छन् जुन हामी हेर्न चाहन्छौं, त्यहाँ डेटा छ, हामी जान्दछौं कि कसरी काम गर्ने।
2. मेटाडेटा। हामीसँग धेरै सेवाहरू छन्, तिनीहरू समयसँगै परिवर्तन हुन्छन्, तिनीहरूसँग काम गर्ने मानिसहरू जस्तै। म्यानुअल रूपमा कागजातहरू निरन्तर कायम राख्नु विकल्प होइन। यसैले हामी अब हाम्रो माइक्रोसर्भिसेसहरूमा मेटाडेटा इम्बेड गर्दैछौं। यसले यसलाई कसले विकास गर्‍यो, यसले अन्तर्क्रिया गर्ने भाषाहरू, SLA आवश्यकताहरू, कहाँ र कसलाई सूचनाहरू पठाउनुपर्छ भनी बताउँछ। सेवा प्रयोग गर्दा, सबै निकाय डेटा स्वतन्त्र रूपमा सिर्जना गरिन्छ। नतिजाको रूपमा, तपाईंले दुई लिङ्कहरू प्राप्त गर्नुहुन्छ - एउटा ट्रिगर गर्न, अर्को Grafana मा ड्यासबोर्डहरूमा।
3. प्रत्येक घरमा निगरानी। हामी विश्वास गर्छौं कि सबै विकासकर्ताहरूले यस्तो प्रणाली प्रयोग गर्नुपर्छ। यस अवस्थामा, तपाइँ सधैं बुझ्नुहुन्छ कि तपाइँको ट्राफिक कहाँ छ, यसलाई के हुन्छ, यो कहाँ खस्छ, यसको कमजोरीहरू कहाँ छन्। यदि, उदाहरण को लागी, केहि आउँछ र तपाइँको सेवा क्र्यास गर्दछ, तब तपाइँ यसको बारे मा प्रबन्धक को कल को समयमा, तर एक चेतावनी बाट थाहा पाउनुहुनेछ, र तपाइँ तुरुन्तै नवीनतम लगहरू खोल्न सक्नुहुन्छ र त्यहाँ के भयो भनेर हेर्न सक्नुहुन्छ।
4. उच्च प्रदर्शन। हाम्रो परियोजना निरन्तर बढिरहेको छ, र आज यसले प्रति मिनेट लगभग 2 मेट्रिक मानहरू प्रशोधन गर्दछ। एक वर्ष पहिले, यो आंकडा 000 थियो र वृद्धि जारी छ, र यसको मतलब केहि समय पछि ग्रेफाइट (ह्वीस्पर) डिस्क सबसिस्टम भारी लोड गर्न सुरु हुनेछ। मैले पहिले नै भनेझैं, यो निगरानी प्रणाली कम्पोनेन्टहरूको आदानप्रदानको कारणले धेरै विश्वव्यापी छ। कसैले ग्रेफाइटको लागि विशेष गरी आफ्नो पूर्वाधार कायम राख्छ र विस्तार गर्दछ, तर हामीले फरक मार्गमा जाने निर्णय गर्यौं: प्रयोग गर्नुहोस्। क्लिकहाउस हाम्रो मेट्रिक्सको लागि भण्डारको रूपमा। यो ट्रान्जिसन लगभग पूरा भएको छ, र धेरै चाँडै म तपाईंलाई थप विवरणमा बताउनेछु कि यो कसरी गरियो: त्यहाँ के कठिनाइहरू थिए र तिनीहरू कसरी पार गरियो, कसरी माइग्रेसन प्रक्रिया गयो, म बाध्यकारी रूपमा छनौट गरिएका घटकहरू र तिनीहरूको कन्फिगरेसनहरू वर्णन गर्नेछु।

तपाईको ध्यानाकर्सनको लागि धन्यवाद! यस विषयमा तपाईका प्रश्नहरू सोध्नुहोस्, म यहाँ वा निम्न पोस्टहरूमा जवाफ दिने प्रयास गर्नेछु। सायद कसैसँग यस्तै अनुगमन प्रणाली निर्माण गर्ने वा यस्तै परिस्थितिमा क्लिकहाउसमा स्विच गर्ने अनुभव छ - यसलाई टिप्पणीहरूमा साझा गर्नुहोस्।

स्रोत: www.habr.com