दुसरी देखरेख प्रणाली

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

परिचय

नमस्कार! हा लेख आम्ही स्वतःसाठी एक नवीन मॉनिटरिंग सिस्टम कशी लिहिली याबद्दल आहे. उच्च-फ्रिक्वेंसी सिंक्रोनस मेट्रिक्स आणि खूप कमी संसाधने वापरण्याच्या क्षमतेमध्ये ते विद्यमान असलेल्यांपेक्षा वेगळे आहे. 0.1 नॅनोसेकंदांच्या मेट्रिक्समधील सिंक्रोनाइझेशन अचूकतेसह मतदान दर 10 मिलीसेकंदपर्यंत पोहोचू शकतो. सर्व बायनरी फाइल्स 6 मेगाबाइट्स व्यापतात.

प्रकल्पाबद्दल

आमच्याकडे एक विशिष्ट उत्पादन आहे. डेटा ट्रान्समिशन चॅनेलच्या थ्रूपुट आणि फॉल्ट टॉलरन्सचा सारांश देण्यासाठी आम्ही एक सर्वसमावेशक उपाय तयार करतो. जेव्हा अनेक चॅनेल असतात तेव्हा असे म्हणूया की Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ दुसरे काहीतरी (5 Mbit/s), परिणाम एक स्थिर आणि वेगवान चॅनेल आहे, ज्याचा वेग काहीतरी असेल हे: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

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

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

समस्येची निर्मिती

मॉनिटरिंग सिस्टम दोन मूलभूतपणे भिन्न वर्गांचे मेट्रिक्स प्रदान करते: रीअल-टाइम मेट्रिक्स आणि इतर सर्व. मॉनिटरिंग सिस्टममध्ये फक्त खालील आवश्यकता होत्या:

1. रिअल-टाइम मेट्रिक्सचे उच्च-फ्रिक्वेंसी सिंक्रोनस संपादन आणि विलंब न करता संप्रेषण व्यवस्थापन प्रणालीमध्ये त्यांचे हस्तांतरण.
   उच्च वारंवारता आणि भिन्न मेट्रिक्सचे सिंक्रोनाइझेशन हे केवळ महत्त्वाचे नाही, तर डेटा ट्रान्समिशन चॅनेलच्या एन्ट्रॉपीचे विश्लेषण करण्यासाठी ते महत्त्वपूर्ण आहे. जर एका डेटा ट्रान्समिशन चॅनेलमध्ये सरासरी विलंब 30 मिलीसेकंद असेल, तर फक्त एक मिलीसेकंदच्या उर्वरित मेट्रिक्समधील समक्रमणातील त्रुटी परिणामी चॅनेलचा वेग अंदाजे 5% ने कमी करेल. जर आम्ही 1 चॅनेलवर 4 मिलीसेकंदने वेळेची चूक केली, तर वेग कमी होणे सहजपणे 30% पर्यंत खाली येऊ शकते. याव्यतिरिक्त, चॅनेलमधील एन्ट्रॉपी खूप लवकर बदलते, म्हणून जर आपण ते प्रत्येक 0.5 मिलीसेकंदांनी एकापेक्षा कमी वेळा मोजले तर, थोड्या विलंबाने वेगवान चॅनेलवर आपल्याला उच्च गतीचे ऱ्हास होईल. अर्थात, अशी अचूकता सर्व मेट्रिक्ससाठी आवश्यक नाही आणि सर्व परिस्थितींमध्ये नाही. जेव्हा चॅनेलमध्ये विलंब 500 मिलीसेकंद असतो आणि आम्ही अशासह कार्य करतो, तेव्हा 1 मिलीसेकंदची त्रुटी जवळजवळ लक्षात येणार नाही. तसेच, लाइफ सपोर्ट सिस्टम मेट्रिक्ससाठी, आमच्याकडे पुरेसे मतदान आणि सिंक्रोनाइझेशन दर 2 सेकंद आहेत, परंतु मॉनिटरिंग सिस्टम स्वतःच अल्ट्रा-हाय पोलिंग रेट आणि मेट्रिक्सचे अल्ट्रा-स्पीस सिंक्रोनायझेशनसह कार्य करण्यास सक्षम असणे आवश्यक आहे.
2. किमान संसाधनाचा वापर आणि एकच स्टॅक.
   शेवटचे यंत्र एकतर एक शक्तिशाली ऑन-बोर्ड कॉम्प्लेक्स असू शकते जे रस्त्यावरील परिस्थितीचे विश्लेषण करू शकते किंवा लोकांचे बायोमेट्रिक रेकॉर्डिंग करू शकते किंवा एक पाम-आकाराचा सिंगल-बोर्ड संगणक असू शकतो जो व्हिडिओ प्रसारित करण्यासाठी विशेष सैन्याचा सैनिक त्याच्या शरीराच्या चिलखतीखाली घालतो. खराब संप्रेषण परिस्थितीत वास्तविक वेळ. अशा विविध वास्तू आणि संगणकीय शक्ती असूनही, आम्हाला समान सॉफ्टवेअर स्टॅक ठेवायला आवडेल.
3. छत्री आर्किटेक्चर
   मेट्रिक्स अंतिम डिव्हाइसवर एकत्रित आणि एकत्रित केल्या पाहिजेत, स्थानिकरित्या संग्रहित केल्या पाहिजेत आणि रिअल टाइममध्ये आणि भूतकाळात दृश्यमान केल्या पाहिजेत. कनेक्शन असल्यास, केंद्रीय मॉनिटरिंग सिस्टममध्ये डेटा हस्तांतरित करा. कोणतेही कनेक्शन नसताना, पाठवणारी रांग जमा झाली पाहिजे आणि RAM चा वापर करू नये.
4. ग्राहकाच्या मॉनिटरिंग सिस्टममध्ये एकत्रीकरणासाठी API, कारण कोणालाही अनेक मॉनिटरिंग सिस्टमची आवश्यकता नाही. ग्राहकाने कोणत्याही डिव्हाइसेस आणि नेटवर्कमधून एकाच मॉनिटरिंगमध्ये डेटा गोळा करणे आवश्यक आहे.

काय झालं

आधीच प्रभावी लाँगरेडवर भार पडू नये म्हणून, मी सर्व मॉनिटरिंग सिस्टमची उदाहरणे आणि मोजमाप देणार नाही. हे दुसर्या लेखाकडे नेईल. मी फक्त असे म्हणेन की 1 मिलीसेकंदपेक्षा कमी त्रुटीसह एकाच वेळी दोन मेट्रिक्स घेण्यास सक्षम असलेली मॉनिटरिंग सिस्टम आम्हाला सापडली नाही आणि जी 64 एमबी रॅम असलेल्या एआरएम आर्किटेक्चरवर आणि 86 सह x64_32 आर्किटेक्चरवर समान प्रभावीपणे कार्य करते. जीबी रॅम. म्हणून, आम्ही आमचे स्वतःचे लिहायचे ठरवले, जे हे सर्व करू शकते. आम्हाला जे मिळाले ते येथे आहे:

वेगवेगळ्या नेटवर्क टोपोलॉजीजसाठी तीन चॅनेलच्या थ्रूपुटचा सारांश

काही प्रमुख मेट्रिक्सचे व्हिज्युअलायझेशन

आर्किटेक्चर

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

प्रणाली क्लासिक मॉड्यूलर तत्त्वानुसार लागू केली गेली आहे आणि त्यात अनेक उपप्रणाली आहेत:

1. मेट्रिक्स नोंदणी.
   प्रत्येक मेट्रिक त्याच्या स्वतःच्या थ्रेडद्वारे सर्व्ह केला जातो आणि चॅनेलवर समक्रमित केला जातो. आम्ही 10 नॅनोसेकंदांपर्यंत समक्रमण अचूकता प्राप्त करण्यात सक्षम होतो.
2. मेट्रिक्स स्टोरेज
   आम्ही वेळ मालिकेसाठी आमचे स्वतःचे स्टोरेज लिहिणे किंवा आधीपासून उपलब्ध असलेले काहीतरी वापरणे यापैकी एक निवडत होतो. त्यानंतरच्या व्हिज्युअलायझेशनच्या अधीन असलेल्या पूर्वलक्ष्यी डेटासाठी डेटाबेस आवश्यक आहे. म्हणजेच, त्यात चॅनेलमध्ये प्रत्येक 0.5 मिलीसेकंदांना होणारा विलंब किंवा वाहतूक नेटवर्कमधील त्रुटी वाचनांवर डेटा नाही, परंतु प्रत्येक इंटरफेसवर प्रत्येक 500 मिलीसेकंदांनी गती आहे. क्रॉस-प्लॅटफॉर्म आणि कमी संसाधनांच्या वापरासाठी उच्च आवश्यकतांव्यतिरिक्त, आमच्यासाठी प्रक्रिया करण्यास सक्षम असणे अत्यंत महत्वाचे आहे. डेटा जिथे संग्रहित केला जातो. हे प्रचंड संगणकीय संसाधने वाचवते. आम्ही 2016 पासून या प्रकल्पात टॅरनटूल डीबीएमएस वापरत आहोत आणि आतापर्यंत आम्हाला क्षितिजावर ते बदललेले दिसत नाही. लवचिक, इष्टतम संसाधन वापरासह, पुरेशा तांत्रिक समर्थनापेक्षा अधिक. टारंटूल एक GIS मॉड्यूल देखील लागू करते. अर्थात, ते PostGIS सारखे शक्तिशाली नाही, परंतु काही स्थान-संबंधित मेट्रिक्स (वाहतुकीसाठी संबंधित) संचयित करण्याच्या आमच्या कार्यांसाठी ते पुरेसे आहे.
3. मेट्रिक्सचे व्हिज्युअलायझेशन
   येथे सर्व काही तुलनेने सोपे आहे. आम्ही वेअरहाऊसमधून डेटा घेतो आणि तो रिअल टाइममध्ये किंवा पूर्वलक्षीपणे प्रदर्शित करतो.
4. केंद्रीय मॉनिटरिंग सिस्टमसह डेटाचे सिंक्रोनाइझेशन.
   सेंट्रल मॉनिटरिंग सिस्टम सर्व उपकरणांमधून डेटा प्राप्त करते, निर्दिष्ट इतिहासासह संग्रहित करते आणि API द्वारे ग्राहकाच्या मॉनिटरिंग सिस्टमला पाठवते. क्लासिक मॉनिटरिंग सिस्टमच्या विपरीत, ज्यामध्ये "डोके" फिरून डेटा गोळा करतो, आमच्याकडे उलट योजना आहे. जेव्हा कनेक्शन असते तेव्हा डिव्हाइस स्वतः डेटा पाठवतात. हा एक अतिशय महत्त्वाचा मुद्दा आहे, कारण ते तुम्हाला त्या कालावधीसाठी डिव्हाइसवरून डेटा प्राप्त करण्यास अनुमती देते ज्या दरम्यान ते उपलब्ध नव्हते आणि डिव्हाइस अनुपलब्ध असताना चॅनेल आणि संसाधने लोड करू शकत नाहीत. आम्ही इन्फ्लक्स मॉनिटरिंग सर्व्हर केंद्रीय मॉनिटरिंग सिस्टम म्हणून वापरतो. त्याच्या अॅनालॉग्सच्या विपरीत, तो पूर्वलक्षी डेटा आयात करू शकतो (म्हणजेच, मेट्रिक्स प्राप्त झाल्याच्या क्षणापेक्षा वेगळ्या टाइम स्टॅम्पसह). गोळा केलेले मेट्रिक्स ग्राफानाद्वारे दृश्यमान केले जातात, फाइलसह सुधारित केले जातात. हा मानक स्टॅक देखील निवडला गेला कारण त्यात जवळजवळ कोणत्याही ग्राहक निरीक्षण प्रणालीसह तयार API एकत्रीकरण आहे.
5. केंद्रीय उपकरण व्यवस्थापन प्रणालीसह डेटा सिंक्रोनाइझेशन.
   डिव्‍हाइस मॅनेजमेंट सिस्‍टम झिरो टच प्रोव्हिजनिंग (फर्मवेअर, कॉन्फिगरेशन अद्ययावत करणे) लागू करते आणि मॉनिटरिंग सिस्‍टमच्‍या विपरीत, प्रति डिव्‍हाइसला फक्त समस्या येतात. हे ऑन-बोर्ड हार्डवेअर वॉचडॉग सेवा आणि लाइफ सपोर्ट सिस्टमच्या सर्व मेट्रिक्सच्या ऑपरेशनसाठी ट्रिगर आहेत: CPU आणि SSD तापमान, CPU लोड, मोकळी जागा आणि डिस्कवरील स्मार्ट आरोग्य. सबसिस्टम स्टोरेज देखील टारनटूलवर तयार केले आहे. यामुळे आम्हाला हजारो डिव्हाइसेसवर वेळ मालिका एकत्रित करण्यात लक्षणीय गती मिळते आणि या उपकरणांसह डेटा सिंक्रोनाइझ करण्याच्या समस्येचे देखील पूर्णपणे निराकरण होते. टारनटूलमध्ये उत्कृष्ट रांग आणि हमी वितरण प्रणाली आहे. आम्हाला बॉक्सच्या बाहेर हे महत्त्वाचे वैशिष्ट्य मिळाले, छान!

नेटवर्क व्यवस्थापन प्रणाली

पुढे काय

आतापर्यंत, आमची सर्वात कमकुवत दुवा म्हणजे केंद्रीय देखरेख यंत्रणा. हे मानक स्टॅकवर 99.9% लागू केले जाते आणि त्याचे अनेक तोटे आहेत:

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

मला वाटते की तुम्ही सर्वांनी ग्राफाना कसा दिसतो ते उत्तम प्रकारे पाहिले आहे आणि माझ्याशिवाय त्याच्या समस्या जाणून घेतल्या आहेत, म्हणून मी चित्रांसह पोस्ट ओव्हरलोड करणार नाही.

निष्कर्ष

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

या लेखाच्या व्याप्तीच्या पलीकडे कोणाला प्रश्न असल्यास, तुम्ही मला a.rodin @ qedr.com वर लिहू शकता

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