एक और निगरानी प्रणाली

4 मोबाइल ऑपरेटरों के 16 मॉडेम पर गति का योग। एक स्ट्रीम में आउटगोइंग स्पीड - 933.45 एमबीपीएस

परिचय

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

परियोजना के बारे में

हमारे पास एक विशिष्ट उत्पाद है। हम डेटा चैनलों के प्रवाह और दोष सहिष्णुता को संक्षेप करने के लिए एक व्यापक समाधान का उत्पादन करते हैं। यह तब होता है जब कई चैनल होते हैं, उदाहरण के लिए, Operator1 (40Mbit / s) + Operator2 (30Mbit / s) + कुछ और (5 Mbit / s), परिणाम एक स्थिर और तेज़ चैनल है, जिसकी गति कुछ इस तरह होगी: (40+) 30 + 5) x0.92 = 75x0.92 = 69 एमबीपीएस।

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

कई वर्षों के लिए, हम एक बहु-स्तरीय तेज, क्रॉस-प्लेटफॉर्म और हल्के निगरानी प्रणाली बनाने में कामयाब रहे हैं। हम एक सम्मानित समुदाय के साथ क्या साझा करना चाहते हैं।

समस्या का बयान

निगरानी प्रणाली दो मूलभूत रूप से विभिन्न वर्गों के लिए मैट्रिक्स प्रदान करती है: वास्तविक समय की मैट्रिक्स और बाकी सभी। निगरानी प्रणाली में निम्नलिखित आवश्यकताएं थीं:

1. वास्तविक समय मैट्रिक्स के उच्च आवृत्ति तुल्यकालिक अधिग्रहण और बिना देरी के संचार नियंत्रण प्रणाली में उनका स्थानांतरण।
   विभिन्न मैट्रिक्स की उच्च आवृत्ति और सिंक्रनाइज़ेशन सिर्फ महत्वपूर्ण नहीं है, यह डेटा ट्रांसमिशन चैनलों के एन्ट्रॉपी के विश्लेषण के लिए महत्वपूर्ण है। यदि एक डेटा चैनल में 30 मिलीसेकेंड की औसत देरी होती है, तो केवल एक मिलीसेकंड द्वारा शेष मैट्रिक्स के बीच सिंक्रनाइज़ेशन में त्रुटि के परिणामस्वरूप परिणामी चैनल की गति में लगभग 5% की गिरावट होगी। यदि हम 4 चैनलों में 1 मिलीसेकंड के लिए सिंक्रनाइज़ेशन में गलती करते हैं, तो गति में गिरावट आसानी से 30% तक गिर सकती है। इसके अलावा, चैनलों में एन्ट्रापी बहुत जल्दी बदल जाती है, इसलिए यदि हम इसे हर 0.5 मिलीसेकंड से कम एक बार मापते हैं, तो हमें एक छोटी सी देरी के साथ तेज चैनलों पर उच्च गति की गिरावट मिलेगी। बेशक, ऐसी सटीकता की आवश्यकता सभी मीट्रिक के लिए नहीं है और सभी स्थितियों में नहीं है। जब चैनल में देरी 500 मिलीसेकंड होती है, और हम इस तरह के साथ काम करते हैं, तो 1 मिलीसेकंड की त्रुटि शायद ही ध्यान देने योग्य नहीं होगी। इसके अलावा, लाइफ सपोर्ट सिस्टम के मेट्रिक्स के लिए, 2 सेकंड का मतदान और सिंक्रोनाइज़ेशन फ्रीक्वेंसी हमारे लिए पर्याप्त हैं, हालांकि, मॉनिटरिंग सिस्टम को अल्ट्रा-हाई पोलिंग फ्रिक्वेंसी और अल्ट्रा-सटीक मीट्रिक सिंक्रोनाइज़ेशन के साथ काम करने में सक्षम होना चाहिए।
2. न्यूनतम संसाधन खपत और एक स्टैक।
   अंतिम डिवाइस एक शक्तिशाली ऑन-बोर्ड कॉम्प्लेक्स हो सकता है जो लोगों की सड़क या रिकॉर्ड बायोमेट्रिक्स की स्थिति का विश्लेषण कर सकता है, या एक एकल-बोर्ड हथेली के आकार का कंप्यूटर जो शरीर के कवच के तहत एक विशेष बल के सैनिक द्वारा खराब संचार स्थितियों में वास्तविक समय वीडियो प्रसारित करने के लिए पहना जाता है। इतनी सारी वास्तुकला और कंप्यूटिंग शक्ति के बावजूद, हम एक ही सॉफ्टवेयर स्टैक रखना चाहेंगे।
3. छाता वास्तुकला
   मेट्रिक्स को अंतिम डिवाइस पर एकत्र और एकत्र किया जाना चाहिए, एक स्थानीय भंडारण प्रणाली और वास्तविक समय और पूर्वव्यापी रूप से दृश्य होना चाहिए। यदि संचार उपलब्ध है, तो डेटा को केंद्रीय निगरानी प्रणाली में स्थानांतरित करें। जब कोई संबंध नहीं है, तो भेजने वाली कतार जमा होनी चाहिए और रैम का उपभोग नहीं करना चाहिए।
4. ग्राहक की निगरानी प्रणाली में एकीकरण के लिए एक एपीआई, क्योंकि किसी को बहुत अधिक निगरानी प्रणाली की आवश्यकता नहीं है। ग्राहक को एकल निगरानी में किसी भी उपकरण और नेटवर्क से डेटा एकत्र करना होगा।

क्या हुआ?

पहले से ही प्रभावशाली longrid को लोड करने के लिए, मैं सभी मॉनिटरिंग सिस्टम के उदाहरण और माप नहीं दूंगा। यह एक और लेख खींचेगा। मैं सिर्फ इतना कहूंगा कि हम एक मॉनिटरिंग सिस्टम नहीं खोज पाए हैं जो एक ही समय में 1 मिलीसेकंड से कम की त्रुटि के साथ दो मैट्रिक्स लेने में सक्षम हो और जो 64 एमबी रैम और x86-64 आर्किटेक्चर के साथ 32 जीबी रैम के साथ एआरएम आर्किटेक्चर दोनों पर समान रूप से कुशलता से काम करता हो। इसलिए, हमने अपना खुद का लिखने का फैसला किया, जो बस ऐसा कर सकता है। यहाँ हमें क्या मिला है:

विभिन्न नेटवर्क टोपोलॉजी के लिए तीन चैनलों के थ्रूपुट को समेटना

कुछ प्रमुख मैट्रिक्स का विज़ुअलाइज़ेशन

आर्किटेक्चर

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

प्रणाली को शास्त्रीय मॉड्यूलर सिद्धांत के अनुसार लागू किया गया है और इसमें कई उपप्रणालियां शामिल हैं:

1. मेट्रिक्स का पंजीकरण।
   प्रत्येक मीट्रिक को अपनी स्ट्रीम द्वारा और चैनलों के माध्यम से सिंक्रनाइज़ किया जाता है। हम 10 नैनोसेकंड तक की सिंक्रनाइज़ेशन सटीकता प्राप्त करने में कामयाब रहे।
2. मीट्रिक भंडारण
   हमने समय श्रृंखला के लिए अपनी रिपॉजिटरी लिखने या उपलब्ध लोगों में से किसी एक का उपयोग करने के बीच चुना। डेटाबेस को पूर्वव्यापी डेटा के लिए आवश्यक है, जो बाद के विज़ुअलाइज़ेशन के अधीन है। अर्थात, चैनल में प्रत्येक 0.5 मिलीसेकंड या परिवहन नेटवर्क में त्रुटि संकेतों में देरी का डेटा नहीं है, लेकिन प्रत्येक 500 मिलीसेकंड पर प्रत्येक इंटरफ़ेस पर एक गति है। क्रॉस-प्लेटफ़ॉर्म और कम संसाधन खपत के लिए उच्च आवश्यकताओं के अलावा, हमारे लिए प्रक्रिया करने में सक्षम होना बेहद महत्वपूर्ण है। उसी स्थान पर डेटा जहां इसे संग्रहीत किया जाता है। यह जबरदस्त रूप से कंप्यूटिंग संसाधनों को बचाता है। 2016 से, हम इस परियोजना में टारनटूल डीबीएमएस का उपयोग कर रहे हैं और अब तक हम क्षितिज में इसके लिए प्रतिस्थापन नहीं देख रहे हैं। लचीले, संसाधनों की इष्टतम खपत के साथ, पर्याप्त तकनीकी सहायता से अधिक। टारनटूल में एक जीआईएस मॉड्यूल भी है। यह निश्चित रूप से PostGIS जितना शक्तिशाली नहीं है, लेकिन यह कुछ मैट्रिक्स को किसी स्थान से जोड़ने (परिवहन के लिए प्रासंगिक) के हमारे कार्यों के लिए पर्याप्त है।
3. मेट्रिक्स विज़ुअलाइज़ेशन
   यहां सब कुछ अपेक्षाकृत सरल है। हम संग्रहण से डेटा लेते हैं और इसे वास्तविक समय या पूर्वव्यापी रूप से दिखाते हैं।
4. एक केंद्रीय निगरानी प्रणाली के साथ डेटा सिंक्रनाइज़ेशन।
   केंद्रीय निगरानी प्रणाली सभी उपकरणों से डेटा प्राप्त करती है, इसे दिए गए पूर्वव्यापी के साथ संग्रहीत करती है, और इसे एपीआई के माध्यम से ग्राहक की निगरानी प्रणाली में भेजती है। शास्त्रीय निगरानी प्रणालियों के विपरीत, जिसमें "सिर" चलता है और डेटा एकत्र करता है - हमारे पास विपरीत योजना है। कनेक्शन होने पर डिवाइस स्वयं डेटा भेजते हैं। यह एक बहुत ही महत्वपूर्ण बिंदु है, क्योंकि यह आपको उन समय के लिए डिवाइस से डेटा प्राप्त करने की अनुमति देता है जिन पर यह उपलब्ध नहीं था और चैनल और संसाधनों को लोड नहीं करता है जबकि डिवाइस अनुपलब्ध है। केंद्रीय निगरानी प्रणाली के रूप में, हम इनफ्लक्स मॉनिटरिंग सर्वर का उपयोग करते हैं। एनालॉग्स के विपरीत, यह पूर्वव्यापी डेटा आयात कर सकता है (जो कि मीट्रिक प्राप्त होने के क्षण से अलग एक समय की मुहर के साथ) एकत्र किए गए मीट्रिक को संशोधित Grafana फ़ाइल द्वारा विज़ुअलाइज़ किया जाता है। यह मानक स्टैक भी चुना गया था क्योंकि इसमें लगभग किसी भी ग्राहक निगरानी प्रणाली के साथ तैयार एकीकरण एपीआई हैं।
5. एक केंद्रीय उपकरण प्रबंधन प्रणाली के साथ डेटा सिंक्रनाइज़ेशन।
   डिवाइस प्रबंधन प्रणाली जीरो टच प्रोविजनिंग (फर्मवेयर, कॉन्फ़िगरेशन, आदि को अपडेट करना) को लागू करती है और, मॉनिटरिंग सिस्टम के विपरीत, केवल डिवाइस की समस्याएं प्राप्त करती हैं। ये ऑनबोर्ड हार्डवेयर वॉचडॉग सेवाओं और लाइफ सपोर्ट सिस्टम के सभी मैट्रिक्स के ट्रिगर हैं: सीपीयू और एसएसडी तापमान, सीपीयू लोड, मुफ्त स्थान और डिस्क पर स्मार्ट स्वास्थ्य। सबसिस्टम भंडारण भी टारेंटूल पर बनाया गया है। यह हमें हजारों उपकरणों में समय श्रृंखला के एकत्रीकरण में महत्वपूर्ण गति देता है, और इन उपकरणों के साथ डेटा सिंक्रनाइज़ेशन के मुद्दे को भी पूरी तरह से हल करता है। टारेंटूल में एक उत्कृष्ट कतार प्रणाली और गारंटीकृत वितरण है। हमें यह महत्वपूर्ण सुविधा अच्छी लगी!

नेटवर्क प्रबंधन प्रणाली

आगे क्या है

अब तक, हमारे देश की सबसे कमजोर कड़ी केंद्रीय निगरानी प्रणाली है। इसे मानक स्टैक पर 99.9% पर लागू किया गया है और इसके कई नुकसान हैं:

1. बिजली बंद होने पर InfluxDB डेटा खो देता है। एक नियम के रूप में, ग्राहक तुरंत उन सभी चीजों को लेता है जो उपकरणों से आती हैं और डेटाबेस में 5 मिनट से अधिक पुराना कोई डेटा नहीं है, लेकिन भविष्य में यह एक दर्द हो सकता है।
2. ग्राफाना में डेटा एकत्रीकरण और उनके प्रदर्शन के सिंक्रनाइज़ेशन के साथ कई समस्याएं हैं। सबसे सामान्य समस्या तब होती है जब डेटाबेस में एक समय श्रृंखला होती है जिसमें 2 सेकंड का अंतराल 00:00:00 बजे से शुरू होता है, और ग्राफाना +1 सेकंड से एकत्रीकरण डेटा दिखाना शुरू कर देता है। नतीजतन, उपयोगकर्ता एक डांसिंग चार्ट देखता है।
3. तृतीय-पक्ष मॉनिटरिंग सिस्टम के साथ एपीआई एकीकरण के लिए अतिरिक्त कोड। बहुत अधिक कॉम्पैक्ट बनाया जा सकता है और निश्चित रूप से गो को फिर से लिखना)

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

निष्कर्ष

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

अगर किसी के पास इस लेख के बाहर प्रश्न हैं, तो मैं a.rodin @ qedr.com पर लिख सकता हूं