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

16 मॉडेम, 4 सेल्युलर ऑपरेटर = आउटगोइंग स्पीड 933.45 एमबीटी/एस

परिचय

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

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

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

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

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

समस्या का निरूपण

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

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

क्या हुआ

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

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

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

आर्किटेक्चर

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

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

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

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

आगे क्या है

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

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

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

निष्कर्ष

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

यदि किसी के पास इस लेख के दायरे से परे कोई प्रश्न है, तो आप मुझे [email protected] पर लिख सकते हैं

स्रोत: www.habr.com