हाईलोअड ++, मिखाइल मकरोव (इंटर्सिवेज़): एक बैकअप और क्लस्टर ज़ैबिक्स सेवा बनाने का अनुभव

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

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

मैं संक्षेप में बात करूंगा कि घर पर एक क्लस्टर कैसे शुरू किया जाए, स्रोत कहां से प्राप्त किए जाएं, और अतिरिक्त क्या हैं। क्लस्टर के लिए सेटिंग्स की आवश्यकता होगी।



हाईलाड ++ साइबेरिया 2019. टॉम्स्क हॉल। 24 जून, शाम 5 बजे। सार और प्रस्तुति । अगला हाईलाड ++ सम्मेलन 6 और 7 अप्रैल, 2020 को सेंट पीटर्सबर्ग में आयोजित किया जाएगा। विवरण और टिकट यहां ।

मिखाइली मकरोव (बाद में - एमएम): - मैं एक प्रदाता कंपनी के लिए काम करता हूं। प्रदाता को Intersvyaz कहा जाता है, यह चेल्याबिंस्क शहर में काम करता है। हमारे पास लगभग 1.5 मिलियन लोग हैं। और प्रदाता के काम करने के लिए एक बड़ा बुनियादी ढाँचा है। हमारे पास लगभग 70 हजार उपकरण हैं: स्विचेस, IoT डिवाइसेस ... - सब कुछ जो निगरानी की आवश्यकता है। विशेष रूप से, यह रिपोर्ट Zabbix के उपयोग के बारे में है, बुनियादी ढांचे की निगरानी के लिए Zabbix पर आधारित क्लस्टर बनाने के बारे में है।

मैं प्रदाता में 12 साल हूं। अब मैं तकनीकी चीजों को नहीं कर रहा हूं, यह लोगों को प्रबंधित करने के बारे में अधिक है। और यह (तकनीकी सामान) वास्तव में मेरा शौक है। मैं इस विषय को थोड़ा विकसित करूंगा।

निगरानी के मुद्दे

मुझे लगता है कि मैं भाग्यशाली हूं। लगभग डेढ़ साल पहले, मैंने एक ऐसी परियोजना को समाप्त किया, जो इस तरह लग रही थी: "हमें अपनी निगरानी के साथ कुछ समस्याओं को हल करने की आवश्यकता है।" मुझे जिम्मेदारी का एक क्षेत्र (निगरानी) विरासत में मिली, जिसमें सर्वरों का एक समूह शामिल था, विशेष रूप से 21 सर्वरों का:



4 शक्तिशाली सर्वर और 15 प्रॉक्सी थे - यह सब हार्डवेयर था। इस निगरानी के बारे में कुछ शिकायतें थीं। पहला यह कि यह बहुत कुछ था। हमारे पास प्रदाता के साथ एक भी सर्वर नहीं है जो इतना स्थान ले ले। यह पैसा है, बिजली है ... वास्तव में, यह कोई बड़ी समस्या नहीं है।



बड़ी समस्या यह थी कि निगरानी यह नहीं रखती थी कि हम उससे कितना चाहते थे। उन लोगों के लिए जो ज़ैबिक्स का सक्रिय रूप से उपयोग नहीं करते हैं, यह एक डैशबोर्ड है जो चेक पर विलंबता दिखाता है:



हमारे ज्यादातर चेक रेड जोन में थे। वे 10 मिनट से भी अधिक धीमी गति से भागे, जैसा कि हम चाहते थे, यानी वे 10 मिनट देर से आए थे। यह बहुत सुखद नहीं था, लेकिन कम या ज्यादा जीना संभव था। सबसे बड़ी समस्या यह थी:



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

"हम इस परियोजना के साथ कुछ करना चाहिए!"

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

ज़बिक्स = लोग + एपीआई + दक्षता

छोटे टुकड़ों से लोगों ने एक प्रणाली का निर्माण शुरू किया। और कई उत्साही लोगों के साथ, मैंने ज़ाबिक्स पर काम करना जारी रखा। उसके कारण थे। क्या कारण हैं?

• सबसे पहले, एक शांत एपीआई है। और जब आपके पास 60-70 हजार मॉनिटरिंग तत्व होते हैं, तो यह स्पष्ट है कि यह सब केवल स्वचालित रूप से काम करता है - आप त्रुटियों के बिना इतने सारे हाथ नहीं जोड़ सकते।
• फ्रेम्स। ऑन-ड्यूटी मॉनिटरिंग शिफ्ट हैं जो 24/7 बैठते हैं। ये आईटी विशेषज्ञ नहीं हैं, ये लोग ड्यूटी पर हैं। हमने "ग्राफन" को कुछ अन्य प्रणालियों को दिखाया - यह उनके लिए कठिन है। ऐसे व्यवस्थापक हैं जो विविधता के आदी हैं, Zabbix में खुद की निगरानी की सुविधा: टेम्पलेट्स, ऑटो-डिटेक्शन - और यह सब अच्छा है!
• ज़बिक्स प्रभावी हो सकता है।

SQL डेटाबेस धीमा हो जाता है? एक उत्तर - क्लिकहाउस

पहला कारण स्पष्ट था। हमने तब MySQL पर काम किया, और हम प्रति सेकंड लगभग 6-7 हज़ार मेट्रिक्स में भाग गए, हमने डिस्क पर लगातार देरी देखी।



आज यह पहले ही 100 बार बज चुका है: एकमात्र उत्तर है क्लिकहाउस:



प्रश्नों की संरचना में, प्रश्नों का थोक (कुछ घंटों में हमारा प्रोफाइल) मैट्रिक्स रिकॉर्ड हैं। SQL डेटाबेस में मेट्रिक्स लिखना बेहद महंगा है। यहां TimeScaleDB दिखाई दिया ... तब हमारे पास अन्य कार्यों के लिए लगभग एक साल तक "क्लिकहाउस" था (हम बड़े डेटा करते हैं, हमारे पास एक बड़ा अनुप्रयोग है - सामान्य तौर पर, एक प्रदाता अब एक संपूर्ण आईटी व्यवसाय है)।

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



इसके अलावा, हम "सामने" के लिए एक मॉड्यूल लिखा था। Zabbix व्यवस्थापक पैनल में इन सभी सुंदर ग्राफिक्स को Clickhouse से बनाया जा सकता है। यह स्पष्ट है कि एपीआई भी काम करता है।

प्रभाव लगभग समान है - एक समर्पित इकाई के रूप में SQL सर्वर पूरी तरह से नहीं बन गया, अर्थात, लोड शून्य पर गिरा दिया गया। जो सबसे उल्लेखनीय है, हमारे पास पहले से ही एक "क्लिकहाउस" क्लस्टर है: जब हमने अपना सारा भार वहाँ दिया, तो यह 6 से बढ़कर 10.5 मीट्रिक हो गया। जो लोग प्रशासन करते हैं, उन्होंने कहा: "लेकिन हम कुछ ऐसा नहीं देखते हैं जो आया है। नहीं! ”

हमने क्लिकहाउस का विस्तार कैसे किया

मैं आगे भी कहूंगा: परीक्षणों के लिए हमने प्रति सेकंड 140-150 हजार मीट्रिक तक लोड करने की कोशिश की (हम अब ज़ैबिक्स से निचोड़ नहीं सकते थे, बाद में मैं कहूंगा क्यों), और क्लिकहाउस भी इस लोड को नहीं देखता है। यही है, यह बहुत आरामदायक, शांत भार है। सामान्य तौर पर, ऐसा एक मॉड्यूल होता है।

इसके अलावा, हमने इसे थोड़ा विस्तारित किया:



हमारे संस्करण में, आप नैनोसेकंड को बंद कर सकते हैं। आप शायद जानते हैं: ज़ैबिक्स सेकंड और नैनोसेकंड दो क्षेत्रों में लिखता है। "क्लिकहाउस" फ़ील्ड में, जिसमें परिवर्तनशीलता बहुत बड़ी है, बहुत सी जगह लेती है।

वैसे, जगह के बारे में। Clickhouse में एक मीट्रिक (हमारे पास अब लगभग 700 बिलियन मीट्रिक रिकॉर्ड किए गए हैं) 2.9 बाइट्स लेता है। Zabbix प्रलेखन के अनुसार, SQL डेटाबेस में एक मीट्रिक 40 से 100 बाइट्स तक होती है। नैनोसेकंड को बंद करने से एक और 40% की बचत होती है, यानी लगभग 1.5 बाइट प्रति मीट्रिक। यही है, स्थान के संदर्भ में "क्लिकहाउस" बहुत प्रभावी है।

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

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

ऐसे मामलों में जहां बुनियादी ढांचे से इकट्ठा करना आसान है, वहाँ अभी भी ऐसा विकल्प है: कैश से कुछ समय के लिए पढ़ने पर रोक लगाना। 5 मिनट के लिए जल्दी से काम करना बेहतर है, ट्रिगर्स की गिनती नहीं करना, और फिर कैश भरना होगा - यदि आप ऐसा नहीं करते हैं, तो इतिहास-सिंकर्स का ठहराव शुरू होता है।

सामान्य तौर पर, "क्लिकहाउस" मॉड्यूल होता है। इसका उपयोग किया जा सकता है।

मतदान की दक्षता

इस तथ्य के बावजूद कि हमने आधार के साथ समस्याओं को हल किया, ब्रेक और पंद्रह प्रॉक्सी के साथ समस्या अभी भी बनी हुई है। वे इसके साथ जुड़े थे:



यह Zabbix पर मुख्य डेटा प्रोसेसिंग पाइपलाइन है। डेटा संग्रह का एक चरण है, प्रीप्रोसेसिंग है, और ऐसे ऐतिहासिक सिंकर्स हैं जो सभी काम करते हैं (ट्रिगर, अलर्ट, बचत इतिहास की गणना)। कैश की अड़चन बनी:



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



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

थोक प्रसंस्करण क्या है? पोलर कॉन्फ़िगरेशन कैश में जाता है और एक मीट्रिक के लिए नहीं, बल्कि 4 या 8 हजार के लिए कार्य लेता है। उसी समय, उसे एक और महान अवसर मिलता है: वह अब असंगत रूप से मतदान कर सकता है, क्योंकि उसे 4 हजार मेट्रिक्स मिले थे ... वे एक के बाद एक क्यों करते हैं? आप तुरंत सब कुछ पूछ सकते हैं!

अतुल्यकालिक मतदान प्रॉक्सी से अधिक कुशल है!

प्रदाता द्वारा उपयोग किए जाने वाले मुख्य प्रकारों के लिए - ये एसएनएमपी और एजेंट हैं, हमने मतदान को एसिंक्रोनस मोड में फिर से लिखा है, और कुल मिलाकर इसने 100 से 200 गुना तक की गति दी है। हमारे पास 15 प्रॉक्सी थे, हमने उन्हें 150 में विभाजित किया - वे पूरी तरह से चले गए। नतीजतन, यह सब दो बैंकों में बदल गया, जिनकी आवश्यकता केवल रिजर्व के लिए है:



यूनीप्रोसेसर बैंक (एक Xeon 1280 लागत)। यह मैं समय है:



लगभग 60% नि: शुल्क है, लेकिन 60% से 40% तक की यह रिंगिंग मशीन (बाहरी स्क्रिप्ट) पर आवधिक स्क्रिप्ट चलाती है। समस्याओं का निर्माण होने तक उन्हें अनुकूलित किया जा सकता है।

स्केल कुछ इस प्रकार है:



ये 62 हजार होस्ट हैं, लगभग 5 मिलियन मीट्रिक। हमारी वर्तमान ज़रूरत लगभग 20 हज़ार मेट्रिक्स प्रति सेकंड है।

खैर, सब कुछ पसंद है? हमने प्रदर्शन की समस्याओं को हल किया, इतिहास का विस्तार किया, मतदान भयानक है। क्या समस्या का समाधान हो गया है? वास्तव में नहीं ... सब कुछ बहुत सरल होगा।

मैंने पिछले चार्ट पर एक ट्रिक खेली है (सभी को नहीं दिखाया गया है):



दो समस्याएं हैं। मैं कहना चाहता हूं: "मूर्ख, सड़कें।" एक मानवीय कारक है, उपकरण है।

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

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

अनुरोध किया गया क्लस्टर ...

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



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

मैं अपनी अधिकतम सीमा 60-70 हजार मेट्रिक्स के आसपास प्राप्त करना चाहूंगा, क्योंकि भूख खाने के साथ आती है। हमारे पास ऐसे लोग हैं जो QoE में लगे हुए हैं ... अनुभव की गुणवत्ता - पारगमन मैट्रिक्स के आधार पर ग्राहकों के लिए इंटरनेट कैसे काम करता है, इसका एक विश्लेषण, यानी, आप सभी टीसीपी मैट्रिक्स को 1.5 मिलियन लोगों को आपूर्ति करते हैं, इसे निगरानी में डालते हैं - बहुत अधिक डेटा है।

और मुझे विश्वसनीयता चाहिए थी। मैं चाहता था कि ऐसा कुछ हो ... शिफ्ट ड्यूटी ऑफिसर ने फोन किया, कहा, "हमें सर्वर के साथ समस्या है," इसे बंद कर दिया, हम कल इसका पता लगाएंगे।

पहला क्लस्टर

पहले संस्करण को etcd के आधार पर लागू किया गया था:



Etcd एक वितरित की-वैल्यू स्टोरेज है जो कई प्रगतिशील परियोजनाओं (जहाँ तक मेरी समझ में, कुबेरनेट्स में है) में उपयोग किया जाता है। सब कुछ बहुत अच्छा था। Etcd बहुत दिलचस्प उपकरण प्रदान करता है - उदाहरण के लिए, यह मुख्य सर्वर को चुनने की समस्या को हल करता है। लेकिन ऐसी समस्या ...

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



यह न्यूनतम परिवर्तनों के साथ चौराहे संचार के लिए काफी अच्छा है। इसने etcd को कम से कम (कम से कम अस्थायी रूप से) उपयोग करने की अनुमति नहीं दी, कोड को सरल बनाया और सबसे महत्वपूर्ण बात यह है कि उस कोड पर काम किया गया जिसे सत्यापित किया गया है (ऐसा लगता है कि यह कोड 5 या 7 साल पुराना है)।

सर्वर क्लस्टर में कैसे समन्वित होते हैं?

आईजीपी प्रोटोकॉल की तरह, समन्वय द्वारा किया जाता है। सर्वर में प्राथमिकता के लिए (अब मैं कहूंगा कि यह क्यों आवश्यक है) और लॉग लिखते समय SQL डेटाबेस में टकराव से बचने के लिए, प्रत्येक सर्वर को एक पहचानकर्ता (अब तक मैन्युअल रूप से) सौंपा जाता है - यह 0 से 63 तक एक संख्या है (63) यह सिर्फ एक निरंतर है, शायद अधिक):



अधिकतम पहचानकर्ता वाला सर्वर "मास्टर" बन जाता है। जब हमने अपना पहला परीक्षण क्लस्टर लॉन्च किया, तो सबसे पहली बात जो हमारे व्यवस्थापक ने कही, वह थी: “वाह! और उन्हें विभिन्न साइटों पर डालते हैं। ठीक है, महान! ”(हम इस पर वापस आएंगे)। और जब किसी ने क्लस्टर वितरित किया है, तो यह नियंत्रित करना संभव होगा कि टोपोलॉजी का पुनर्वितरण कैसे किया जाता है: मुख्य "ज़ैबिक्स" सर्वर में गिरावट के मामले में "मास्टर" की भूमिका कहां जाएगी:



इस मामले में, इस तरह:

स्टेपिंग

मूल ज़ैबिक्स में, यह इस तरह से किया जाता है: सर्वर स्वयं ऑटो-इंक्रीमेंट इंडेक्स उत्पन्न करने के लिए जिम्मेदार है। कई उदाहरणों को एक-दूसरे की ऊँची एड़ी के जूते पर कदम रखने से रोकने के लिए (ताकि एक ही सूचकांक के साथ लॉग बनाने के लिए नहीं), कदम का उपयोग किया जाता है: पहचानकर्ता "1" के साथ "Zabbix" एक - 1, 11, 21 के गुणकों को उत्पन्न करेगा; पहचानकर्ता "7" के साथ - 7, 17, 27 (बारीकियों के साथ)।
हमने मॉडिफायर्स के साथ काम किया।

सर्वर एक दूसरे के साथ कैसे बातचीत करते हैं?

यह हर 5 सेकंड में IGP के हैलो पैकेट्स की विरासत है। इसलिए सर्वर जानते हैं कि उनके पास पड़ोसी हैं। तो "मास्टर" जानता है कि आस-पास पड़ोसी हैं, और इसके आधार पर, "मास्टर" यह तय करता है कि कौन से मेजबान को किस सर्वर पर वितरित किया जा सकता है।



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

प्रोटोकॉल सरल है - यह JSON है:



यह Zabbix प्रॉक्सी और Zabbix सर्वर संचार की विरासत भी है। सामान्य तौर पर, यह कुछ और उपयोग करने के लिए कोई मतलब नहीं है। केवल एक चीज यह है कि ज़ैबिक्स के मामले में 4 बाइट्स (ZBXD) हैं, लेकिन यह बात नहीं है।

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

दरअसल, टोपोलॉजी केवल एक पेड़ है, सर्वरों की एक सूची है। प्रत्येक सर्वर के लिए, मेजबानों की एक सूची जिसका वह समर्थन करता है:



और फिर एक दिलचस्प समस्या पैदा होती है।

इस तरह के एक जादू वाक्यांश है - निगरानी डोमेन

क्या कहना है? क्लासिक ज़ैबिक्स में, सब कुछ सरल था - एक अस्पष्ट रवैया: इस मेजबान की निगरानी इस प्रॉक्सी द्वारा की जाती है, यह प्रॉक्सी सर्वर को डेटा देता है। यदि प्रॉक्सी स्थापित नहीं किया गया है (या आवश्यक नहीं है), तो यह सर्वर सभी मेजबानों की निगरानी करता है:



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



हम यह नहीं चाहते हैं। हम किसी प्रकार का तंत्र बनाना चाहते हैं ताकि सभी सर्वर न हों, लेकिन जिन्हें हमने चुना है (संभवतः भूगोल पर आधारित) एक विशेष मेजबान की निगरानी कर सकते हैं। उसी समय, हम इसे प्रबंधित करना चाहते हैं, और हम चाहते हैं कि यह सरल हो। इसके लिए, डोमेन की निगरानी के विचार का आविष्कार किया गया था। वास्तव में, ये सरल समूह हैं - बस रिकॉर्ड में पहले से ही समूह हैं।
और जब मैंने ऐसा किया, तो ऑपरेशन के लोगों ने मेरे साथ बात की - उन्होंने कहा: "समूह हमें बहुत भ्रमित करते हैं। हम हमेशा सामान्य समूहों के बारे में सोचना शुरू करते हैं। ” इसलिए, यह नाम: डोमेन की निगरानी करना।

मेजबान अनायास संबंधित: एक मेजबान - एक डोमेन:



होस्ट डोमेन में किसी भी संख्या में सर्वर शामिल हो सकते हैं। सर्वर किसी भी संख्या में डोमेन में हो सकते हैं। यह बहुत लचीली चीज है। लचीलेपन का विस्तार करने और मस्तिष्क को पूरी तरह से तोड़ने के लिए, एक डिफ़ॉल्ट डोमेन भी है:



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

यह सिर्फ हमें कुछ सर्वरों पर मेजबानों को बांधने की अनुमति देता है और एक सर्वर के नीचे गिर जाने पर मेजबानों को वितरित करने के तरीके को नियंत्रित करता है:



अगली समस्या जो हमें मिली ...

क्लस्टर: अलग सोचो

जब हमारे पास बहुत सारे सर्वर होते हैं, तो एक टोपोलॉजी के निर्माण के लिए क्लस्टर बनाने के नए अवसर होते हैं। यह एक ऐसा क्लासिक है जब हमारे पास कुछ प्रकार की केंद्रीय साइट होती है और दूरदराज के होते हैं; या, यह कहें कि एक प्रॉक्सी जहां लोड को प्रत्यायोजित किया जाता है:



क्लस्टर ज़ैबिक्स के मामले में, इसे दो तरीकों से लागू किया जा सकता है। आप क्लासिक तरीके से जा सकते हैं: बस बुनियादी ढांचे को दोगुना करें। केंद्र में, हमारे पास दो सर्वर हैं जो क्लस्टर बनाते हैं, मेजबानों को पुनर्व्यवस्थित कर सकते हैं या पड़ोसी गिर जाने पर खुद पर बोझ उठा सकते हैं। तदनुसार, आप एक ही सर्वर पर अतिरिक्त प्रॉक्सी बढ़ा सकते हैं - हमें एक डबल रिज़र्व मिलता है:



आप नई "सुविधाओं" का उपयोग कर सकते हैं और यह कर सकते हैं:



मुख्य बात ऐसी स्थिति में नहीं जाना है जहां भौगोलिक रूप से दूरस्थ सर्वर किसी अन्य स्थान पर कुछ बड़े बुनियादी ढांचे की निगरानी कर रहा है। यह एक प्रशासन समस्या है (मैं इसे व्यवसाय कहता हूं) क्योंकि यह एक कॉन्फ़िगरेशन समस्या है।

क्लस्टर: विभाजित मस्तिष्क और बिंदु

क्लस्टर के साथ एक और दिलचस्प स्थिति आई जिसका हमने सामना किया:

• विभाजित मस्तिष्क;
• देखने का बिंदु।

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

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



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

SQL डेटाबेस क्लस्टर

जाहिर है, अगर हम सर्वर का एक गुच्छा वितरित करते हैं, तो हम चाहेंगे कि हर कोई पास में अपना आधार बनाए। एक आम पर टाई करना गलत होगा। दुर्भाग्य से, यह कहने के लिए कि मेरे पास अब एक तैयार समाधान है ... मेरे पास अभी तक ऐसा कोई अनुभव नहीं है। मैं आपको बताऊंगा कि क्यों।

सबसे पहले, मैं मानता हूं कि यदि कोई क्लस्टर का परीक्षण और उपयोग करना शुरू कर देता है, तो आप मानक समाधानों का उपयोग कर सकते हैं। कहते हैं, MySQL के लिए गैलेरा।

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

कोई तैयार समाधान क्यों नहीं है?

अनुरोधों की सामान्य संरचना में, ऐसा एक छोटा सा हिस्सा है जो इतिहास से संबंधित नहीं है:





इस छोटे से हिस्से में, हमारे पास अब जितने अनुरोध हैं, उनमें से अधिकांश लॉग हैं। लॉग मूल रूप से तीन टेबल बनाते हैं:

• कुछ चीजों की लॉगिंग (लॉग) जो बुनियादी ढांचे के लिए हुई। ये समस्याएं, घटनाएं और घटनाएं रिकवरी टेबल हैं। सर्वर क्रैश हो गया, सर्वर ठीक हो गया - जब ट्रिगर में आग लगती है, तो यह सब लिखा जाता है।
• 15 प्रतिशत राज्य है। एक राज्य अवसंरचना तत्वों में परिवर्तन है (सर्वर या होस्ट गिर गया है - ट्रिगर ने काम किया है - Zabbix डेटाबेस को लिखता है)। वास्तव में, यह डेटाबेस में अपना राज्य संग्रहीत करता है। एक तरफ, यह बहुत अच्छा है; दूसरे पर, मुझे इस विषय पर कुछ कहना है ...
• बहुत सारे अनुरोध कॉन्फ़िगरेशन (कॉन्फ़िगरेशन अद्यतन) को लोड करने और बदलने से संबंधित हैं।

यहाँ क्लासिक ज़ैबिक्स है। इसमें एक "क्लिकहाउस" जोड़ा गया था, मैट्रिक्स को SQL डेटाबेस से बाहर ले जाया गया था:



सबसे पहले, मैं स्थिति के लिए सर्वर पर जाना चाहूंगा:



यह सही है। यदि आप सर्वर को छोड़ देते हैं और दो घंटे में वेब व्यवस्थापक को खोलते हैं, तो यह आपको दिखाएगा कि स्थिति की निगरानी क्या है ... यह सच नहीं होगा - यह दिखाएगा कि यह 2 घंटे पहले क्या था! यह कहना सही होगा: "मुझे नहीं पता कि नेटवर्क राज्य अब क्या है।" यदि कुछ विशिष्ट रुचियां, आप समस्याओं या घटनाओं के इतिहास को देख सकते हैं, तो वास्तव में वहां क्या हुआ था।

दूसरा वाला। लॉग को एक सस्ते स्टोरेज सिस्टम पर ले जाने के लिए कहा जाता है, जो डिस्क स्थान को काफी कम लेता है और कम संसाधन खर्च करता है:



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

अभ्यास। स्थापना

क्लस्टर, सिद्धांत, "पानी" मैंने बताया। बारीकियाँ। यदि आप अपने लिए एक क्लस्टर स्थापित करने का निर्णय लेते हैं, तो आपको क्या करना चाहिए?



दूसरा "ज़ैबिक्स" सर्वर डालना आवश्यक है (अर्थात, यह "सैशनी" डेमॉन है)। क्लस्टर के लिए दो नए पैरामीटर दिखाई देते हैं (मैंने उनके बारे में बात की): सर्वर पहचानकर्ता (1 से 63 की संख्या, उच्चतम पहचानकर्ता वाला सर्वर "मास्टर" बन जाता है) और होस्ट नाम (सर्वर से पहचान की आवश्यकता होती है जब यह डेटाबेस से सर्वर की सूची को लोड करता है)।

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

आगे छोटे बदलाव। जहाँ हम प्रॉक्सी कंट्रोल करते थे, "क्लस्टर मैनेजमेंट" पैनल अब सामने आया है:



कई नई वस्तुएँ हैं:



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

सामान्य तौर पर, यह सब है।

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

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

तकनीकी हिस्सा नहीं

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



और यहां एक दिलचस्प बात है: कई उत्साही लोग दिखाई दिए हैं जो कुछ करते हैं, देखते हैं, गिटलैब, सीआई / सीडी को कॉन्फ़िगर करते हैं, और शांत विचारों को लाते हैं। यहाँ, उदाहरण के लिए, नैनोसेकंड - यह समुदाय से आया है।

सामान्य तौर पर, जबकि यह एक अलग परियोजना के रूप में रहता है, इसे वर्तमान संस्करण में लगभग स्वचालित रूप से अपडेट किया जाता है - यह 4.0.9 पर है (हमें 4.2 नहीं मिला)। एक निश्चित रोडमैप है - अब इसे पहले से ही डेबियन पैकेज के रूप में डाउनलोड किया जा सकता है। मेरी राय में, यूबुंटा के लिए विधानसभाएं हैं; मुझे नहीं पता कि आरपीएम हैं या नहीं।



जल्द ही Zabbix पैनल में क्लस्टर की स्थिति को देखने के लिए परदे के पीछे (कुछ हिचकोले) और "ट्यूनिंग" के लिए पूर्ण समर्थन मिलेगा। हमारे अनुभव में। प्रशासकों के लिए यह जानना महत्वपूर्ण है कि समस्याओं की तलाश शुरू करने के लिए किस सर्वर पर होस्ट की प्रक्रिया की जा रही है। सिस्टम नया है - विशुद्ध रूप से मनोवैज्ञानिक कारक: हम एक क्लस्टर स्थापित करते हैं, कुछ गलत काम कर रहा है ... किसे दोष देना है? क्लस्टर! .. इसलिए, आपको "ट्यूनिंग" की आवश्यकता है, आपको समझने की आवश्यकता है।

गर्मियों के अंत तक, मैं SQL डेटाबेस से उन सभी सूचना प्रवाह को बाहर निकालना चाहूंगा, जिनकी आवश्यकता नहीं है, होना नहीं है। इतिहास संग्रहण।

संदर्भ

मेरे पास अभी भी 5 मिनट हैं। मैं अपने अतिरिक्त विषयों पर चर्चा करना चाहूंगा।
सबसे पहले, मैंने जो कुछ भी बात की थी, वह सक्रिय रूप से सक्रिय निगरानी की विचारधारा में फिट बैठता है, अर्थात, जब सर्वर कहीं चेक के लिए जाता है।

सक्रिय और निष्क्रिय मतदान

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



सर्वर हैं। "मास्टर" सर्वर ने तय किया कि किस सर्वर पर होस्ट किया जा रहा है।

• तो इस घटना में कि मेजबान जबरन अपने सर्वर को डेटा नहीं भेजता है, तो यह सर्वर डेटा प्राप्त करता है, इसे संसाधित करता है।
• मानक "ज़ैबिक्स" में एक जांच है: यह सुनिश्चित करता है कि ये मीट्रिक कॉन्फ़िगरेशन कैश में वास्तव में मौजूद हैं, प्रत्येक प्रकार की जांच करता है।
• , , . , , .
• - , . , , . 200 , – .

नोट: निष्क्रिय प्रॉक्सी अभी तक समर्थित नहीं है!

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

सक्रिय प्रॉक्सी स्वयं सर्वरों पर जाते हैं। इसके लिए एक सर्वर विकल्प है (मानक प्रॉक्सी)। संशोधित प्रॉक्सी में सर्वर विकल्प है:



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

सवाल

दर्शकों से सवाल (बाद में - ए): - मैं स्पष्ट करना चाहूंगा कि सर्वर के बीच चीजें कैसे चल रही हैं? वे किस प्रोटोकॉल के साथ संवाद करते हैं? क्या किसी तरह की सुरक्षा है? क्योंकि इंटरनेट के लिए सर्वर के बीच संचार लाने के लिए यह बहुत "सुरक्षित" नहीं है ... यह कैसे हो रहा है?

MM: - मुझे लगता है कि यह सबसे अच्छे सवाल का एक दावेदार है - बिंदु तक! वास्तव में, जब हमने मानक संचार पर स्विच किया, तो उनके चौराहे संचार के लिए सर्वर उन सभी संचार प्रोटोकॉल विशेषताओं को विरासत में मिला जो सर्वर और प्रॉक्सी के बीच मौजूद हैं। मैं स्पष्ट करूंगा: एन्क्रिप्शन, डेटा संपीड़न है। कृपया - उसी तरह से वेब के माध्यम से सब कुछ कॉन्फ़िगर किया गया है, क्योंकि यह सर्वर और प्रॉक्सी के लिए मानक रूप से कॉन्फ़िगर किया गया है; सब कुछ काम करेगा।

ए: - क्लिकहाउस के मामले में हॉसकिपर आपके लिए कैसे काम करता है?

MM: - मानक "ज़ैबिक्स" में "हाउसकीपर" से इतिहास इंटरफ़ेस तक कोई इंटरफ़ेस नहीं है, अर्थात, इतिहास इंटरफ़ेस डेटा रोटेशन का समर्थन नहीं करता है (ElasticSearch, उदाहरण के लिए, समर्थन नहीं करता है)। शायद 4.2 में यह है (मैंने नहीं देखा), लेकिन अब तक 4.0.9 पर।

इसे आसान बनाओ! नए "Clickhouse" में एक विभाजन है। मैं पुराने विभाजन को समाप्त करके करना चाहूंगा। यह स्पष्ट है कि व्यक्तिगत वस्तुओं के स्तर पर कोई रोटेशन नहीं होगा, लेकिन ज़ैबिक्स में एक चाल है: आप वैश्विक मूल्यों को निर्दिष्ट कर सकते हैं (उदाहरण के लिए, पूरे इतिहास को 90 दिनों से अधिक नहीं स्टोर करें) - आप सभी आइटम, इन वैश्विक मूल्यों के पूरे इतिहास को साफ कर सकते हैं। । और यह किया जाएगा! Gitlab में इस विषय पर और भी बहुत कुछ है।

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

A: - आप इस बारे में कैसा महसूस करते हैं? आप, यह पता चला है, काफी गैर-प्रदाता काम कर रहे हैं।

MM: - मैंने शायद इसे सही ढंग से नहीं रखा है। यह मेरा शौक है! मैं वास्तव में तकनीकी विशेषज्ञ नहीं हूं - मैं एक प्रबंधक हूं। अपने खाली समय में मैं अभ्यास करता हूं।

A: - मुझे लगा कि आप इसे अपने मुख्य व्यवसाय के हिस्से के रूप में कर रहे हैं ...

MM: - व्यवसाय मुझे परीक्षण करने के लिए एक ठंडी जगह देता है। वास्तव में, मैं अत्यधिक सलाह देता हूं - यह मस्तिष्क को राहत देता है। कहीं न कहीं प्रबंधकीय "बात" पर मैं यह कहूंगा - जब आप मानवीय समस्याओं से इन पर स्विच कर सकते हैं। वे बहुत शांत हल कर रहे हैं! ये तकनीकी मुद्दे हैं। आपने क्रमादेशित किया, और यह उस तरह से काम करता है जैसे आपने प्रोग्राम किया था! यह एक दयालु लोगों को ऐसा नहीं करना चाहिए।

A: - क्या आप कुछ प्रॉक्सी के माध्यम से या सीधे "Clickhouse" लिखते हैं?

एमएम: - सीधे। वास्तव में, परिवर्तित इतिहास इंटरफ़ेस, जिसका उपयोग "एलास्टिक्स" के लिए किया जाता है, को भी विरासत में मिला है। यूआरएल का उपयोग किया जाता है, अर्थात http-इंटरफ़ेस "ज़ैबिक्स" के माध्यम से "क्लिकहाउस" भेजता है। जब इतिहास की एक बड़ी धारा, एक पैक में हजारों मीट्रिक, और यह बहुत अच्छी तरह से Clickhouse पर आती है, तो क्या कूल, ज़ैबिक्स एकत्र करता है।

A: - वास्तव में, वह उसके लिए बाची लिखता है?

एमएम: - हां। एक SQL क्वेरी जो url द्वारा निष्पादित की जाती है, उसमें आमतौर पर एक हज़ार मैट्रिक्स होते हैं। Admins "Clickhouse" बस खुश।

प्रस्तुतकर्ता: - यह इस कमरे में कार्यक्रम का अंत है। एक शाम का कार्यक्रम है जो आयोजित किया जाता है, और कुछ ऐसा है जो केवल आप कर सकते हैं। और मेरा सुझाव है, जब आप एक-दूसरे के साथ संवाद करेंगे, तो यह सोचने के लिए कि आप क्या दिलचस्प बातें कर सकते हैं ... जब आप एक-दूसरे को अपने मामलों के बारे में बताते हैं, तो यह सबसे अधिक संभावना है कि आप किस बारे में रिपोर्ट बना सकते हैं। एक-दूसरे के साथ चर्चा करते हुए, आप केवल कुछ रूपरेखा ढूंढने के लिए पा सकते हैं - कार्यक्रम समिति आपके आवेदन को स्वीकार करेगी, विचार करेगी और इसमें से एक अच्छी, पैक्ड कहानी बनाने में मदद करेगी। शायद आपके पास कार्यक्रम समिति के साथ काम करने के बारे में किसी तरह की कहानी है?

MM: - वास्तव में, बहुत सारी प्रतिक्रिया दी जाती है। मैं बहुत भाग्यशाली था: कार्यक्रम समिति का एक व्यक्ति मेरे चेल्याबिंस्क में रहता है, और हाईलोड एकमात्र सम्मेलन है जो वक्ताओं के साथ मिलकर काम करता है। मैंने ऐसा कहीं और कभी नहीं देखा। यह बहुत फायदेमंद है! विभिन्न चरणों: लोग वीडियो देखते हैं, स्लाइड पर टिप्पणी देते हैं - यह वास्तव में विषय (वर्तनी, टाइपो) में होता है। बहुत मस्त! मैं इसे सुझाता हूं! अपने आप कोशिश करो!

विज्ञापन का एक सा :)

हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक ऑर्डर देकर या अपने दोस्तों से, $ 4.99 से डेवलपर्स के लिए क्लाउड-आधारित VPS , एंट्री-लेवल सर्वरों का एक अनोखा एनालॉग , जो आपके लिए हमारे द्वारा ईजाद किया गया था: VPS (KVM) E5-2696 v3 (6 करोड़) 10GB DDR4 480GB SSD 1Gbps के बारे में पूरी सच्चाई का समर्थन करके हमें समर्थन दें । $ 19 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।

डेल R730xd एम्स्टर्डम में इक्विनिक्स टीयर IV डेटा सेंटर में 2 गुना सस्ता? केवल हमारे पास 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV नीदरलैंड के 199 डॉलर में से है! डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $ 99 से! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?