गुमशुदा स्कूटर लौटाएं, या एक IoT निगरानी की कहानी

एक साल पहले हमने एक प्रमोशनल प्रोजेक्ट का पायलट संस्करण लॉन्च किया था इलेक्ट्रिक स्कूटरों का विकेन्द्रीकृत किराया.

प्रारंभ में, परियोजना को रोड-टू-बार्सिलोना कहा जाता था, बाद में यह रोड-टू-बर्लिन (इसलिए स्क्रीनशॉट में R2B) बन गया, और अंत में इसे xRide कहा गया।

परियोजना का मुख्य विचार यह था: एक केंद्रीकृत कार या स्कूटर किराये की सेवा (हम स्कूटर उर्फ ​​​​इलेक्ट्रिक मोटरसाइकिल के बारे में बात कर रहे हैं, किकस्कूटर/स्कूटर नहीं) के बजाय हम विकेंद्रीकृत किराये के लिए एक मंच बनाना चाहते थे। उन कठिनाइयों के बारे में जिनका हमने सामना किया पहले भी लिख चुका हूँ.

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

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

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

पिछले साल सितंबर में दो जर्मन शहरों: बॉन और बर्लिन में लॉन्च किया गया हमारा पायलट आम तौर पर ऐसा ही दिखता था।

और फिर, एक दिन, बॉन में, सुबह-सुबह, हमारी सहायता टीम (स्कूटर को चालू हालत में बनाए रखने के लिए साइट पर स्थित) को सतर्क किया गया: स्कूटरों में से एक बिना किसी निशान के गायब हो गया था।

इसे कैसे ढूंढें और वापस कैसे करें?

इस लेख में मैं इस बारे में बात करूंगा, लेकिन पहले - हमने अपना खुद का IoT प्लेटफ़ॉर्म कैसे बनाया और हमने इसकी निगरानी कैसे की।

क्या और क्यों निगरानी करें: स्कूटर, बुनियादी ढाँचा, चार्जिंग स्टेशन?

तो, हम अपने प्रोजेक्ट में क्या निगरानी रखना चाहते थे?

सबसे पहले, ये स्वयं स्कूटर हैं - इलेक्ट्रिक स्कूटर स्वयं काफी महंगे हैं, आप पर्याप्त तैयारी के बिना ऐसा प्रोजेक्ट लॉन्च नहीं कर सकते हैं; यदि संभव हो, तो आप स्कूटर के बारे में यथासंभव अधिक जानकारी एकत्र करना चाहते हैं: उनके स्थान, चार्ज स्तर के बारे में , वगैरह।

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

स्कूटर

हमारे स्कूटर क्या थे और हम उनके बारे में क्या जानना चाहते थे?

पहली और सबसे महत्वपूर्ण चीज़ जीपीएस निर्देशांक है, क्योंकि उनके लिए धन्यवाद हम समझ सकते हैं कि वे कहाँ हैं और कहाँ जा रहे हैं।

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

बेशक, यह जांचना भी आवश्यक है कि हमारे हार्डवेयर घटकों के साथ क्या हो रहा है:

• क्या ब्लूटूथ काम करता है?
• क्या जीपीएस मॉड्यूल स्वयं काम करता है?
  • हमें इस तथ्य से भी समस्या थी कि जीपीएस गलत निर्देशांक भेज सकता था और अटक सकता था, और यह केवल स्कूटर पर अतिरिक्त जांच से ही निर्धारित किया जा सकता था,
    और समस्या के समाधान के लिए यथाशीघ्र सहायता को सूचित करें

और अंत में: सॉफ़्टवेयर की जांच, ओएस और प्रोसेसर, नेटवर्क और डिस्क लोड से शुरू होकर, हमारे अपने मॉड्यूल की जांच के साथ समाप्त होती है जो हमारे लिए अधिक विशिष्ट हैं (जोलोकॉम, चाबी का कपड़ा).

हार्डवेयर

हमारा "लोहा" भाग क्या था?

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

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

इससे निगरानी का उपयोग करना और यात्रा समाप्त होने के बाद भी स्कूटर को चालू करना संभव हो गया, क्योंकि इग्निशन कुंजी को "बंद" स्थिति में बदलने के तुरंत बाद मुख्य बैटरी बंद कर दी गई थी।

डोकर? सादा लिनक्स? और तैनाती

चलिए निगरानी पर लौटते हैं, तो रास्पबेरी - हमारे पास क्या है?

भौतिक उपकरणों में घटकों को तैनात करने, अद्यतन करने और वितरित करने की प्रक्रिया को तेज़ करने के लिए हम जिन पहली चीज़ों का उपयोग करना चाहते थे उनमें से एक थी डॉकर।

दुर्भाग्य से, यह जल्दी ही स्पष्ट हो गया कि आरपीआई पर डॉकर, हालांकि यह काम करता है, इसमें बहुत अधिक ओवरहेड है, खासकर ऊर्जा खपत के मामले में।

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

दूसरा कारण Node.js (sic!) पर हमारे साझेदार पुस्तकालयों में से एक था - सिस्टम का एकमात्र घटक जो Go/C/C++ में नहीं लिखा गया था।

लाइब्रेरी के लेखकों के पास किसी भी "मूल" भाषा में कार्यशील संस्करण प्रदान करने का समय नहीं था।

न केवल नोड स्वयं कम-प्रदर्शन वाले उपकरणों के लिए सबसे शानदार समाधान नहीं है, बल्कि लाइब्रेरी स्वयं बहुत संसाधन-भूखी थी।

हमें एहसास हुआ कि, भले ही हम चाहें, डॉकर का उपयोग करना हमारे लिए बहुत अधिक खर्चीला होगा। चुनाव देशी ओएस और सीधे उसके अंतर्गत काम करने के पक्ष में किया गया था।

OS

परिणामस्वरूप, हमने, फिर से, ओएस के रूप में सबसे सरल विकल्प चुना और रास्पबियन (पीआई के लिए डेबियन बिल्ड) का उपयोग किया।

हम अपने सभी सॉफ़्टवेयर गो में लिखते हैं, इसलिए हमने अपने सिस्टम में मुख्य हार्डवेयर एजेंट मॉड्यूल भी गो में लिखा है।

यह वह है जो जीपीएस, ब्लूटूथ, चार्ज पढ़ने, स्कूटर चालू करने आदि के लिए जिम्मेदार है।

तैनात करना

डिवाइसों (ओटीए) में अपडेट पहुंचाने के लिए एक तंत्र को लागू करने की आवश्यकता के बारे में सवाल तुरंत उठा - हमारे एजेंट/एप्लिकेशन के लिए अपडेट, और ओएस/फर्मवेयर के लिए अपडेट (क्योंकि एजेंट के नए संस्करणों को कर्नेल में अपडेट की आवश्यकता हो सकती है) या सिस्टम घटक, लाइब्रेरी इत्यादि)।

बाजार के काफी लंबे विश्लेषण के बाद, यह पता चला कि डिवाइस पर अपडेट देने के लिए काफी सारे समाधान मौजूद हैं।

अपेक्षाकृत सरल, ज्यादातर अपडेट/डुअल-बूट ओरिएंटेड यूटिलिटीज जैसे swupd/SWUpdate/OSTree से लेकर मेंडर और बलेना जैसे पूर्ण प्लेटफॉर्म तक।

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

बहुत ही बलेना इस तथ्य के कारण बाहर रखा गया था कि यह वास्तव में अपने BalenaEngine के अंदर उसी डॉकर का उपयोग करता है।

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

इसलिए, अंत में चुनाव हार गया मरम्मत करनेवाला. फर्मवेयर को असेंबल करने, वितरित करने और स्थापित करने के लिए मेंडर एक संपूर्ण मंच है।

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

अफसोस, हमारी सीमित समय-सीमा के कारण हमें मेंडर का उपयोग छोड़ने और उससे भी सरल विकल्प चुनने के लिए मजबूर होना पड़ा।

Ansible

हमारी स्थिति में सबसे सरल समाधान Ansible का उपयोग करना था। आरंभ करने के लिए कुछ प्लेबुकें पर्याप्त थीं।

उनका सार यह था कि हम बस एसएसएच के माध्यम से होस्ट (सीआई सर्वर) से अपने रसबेरी से जुड़े और उन्हें अपडेट वितरित किए।

शुरुआत में, सब कुछ सरल था - आपको उपकरणों के साथ एक ही नेटवर्क पर रहना था, वाई-फाई के माध्यम से डालना था।

कार्यालय में बस एक ही नेटवर्क से जुड़े एक दर्जन परीक्षण रास्पबेरी थे, प्रत्येक डिवाइस में एक स्थिर आईपी पता भी था जो एन्सिबल इन्वेंटरी में निर्दिष्ट था।

यह Ansible ही था जिसने हमारे मॉनिटरिंग एजेंट को अंतिम उपकरणों तक पहुंचाया

3G / एलटीई

दुर्भाग्य से, हमारे पास वास्तविक स्कूटर होने से पहले Ansible के लिए यह उपयोग मामला केवल विकास मोड में ही काम कर सका।

क्योंकि स्कूटर, जैसा कि आप समझते हैं, एक वाई-फाई राउटर से कनेक्ट नहीं रहते हैं, लगातार नेटवर्क पर अपडेट का इंतजार करते रहते हैं।

वास्तव में, स्कूटर में मोबाइल 3जी/एलटीई के अलावा कोई भी कनेक्शन नहीं हो सकता (और तब भी हर समय नहीं)।

यह तुरंत कई समस्याएं और सीमाएं लगाता है, जैसे कम कनेक्शन गति और अस्थिर संचार।

लेकिन सबसे महत्वपूर्ण बात यह है कि 3जी/एलटीई नेटवर्क में हम केवल नेटवर्क को दिए गए स्थिर आईपी पर भरोसा नहीं कर सकते हैं।

इसे कुछ सिम कार्ड प्रदाताओं द्वारा आंशिक रूप से हल किया गया है; स्थिर आईपी पते वाले IoT उपकरणों के लिए डिज़ाइन किए गए विशेष सिम कार्ड भी हैं। लेकिन हमारे पास ऐसे सिम कार्ड तक पहुंच नहीं थी और हम आईपी पते का उपयोग नहीं कर सकते थे।

निःसंदेह, कौंसुल की तरह कहीं आईपी पते का पंजीकरण उर्फ ​​सेवा खोज करने के विचार थे, लेकिन हमें ऐसे विचारों को छोड़ना पड़ा, क्योंकि हमारे परीक्षणों में आईपी पता बहुत बार बदल सकता था, जिससे बड़ी अस्थिरता पैदा हुई।

इस कारण से, मेट्रिक्स वितरित करने के लिए सबसे सुविधाजनक उपयोग पुल मॉडल का उपयोग नहीं होगा, जहां हम आवश्यक मेट्रिक्स के लिए डिवाइस पर जाएंगे, बल्कि डिवाइस से सीधे सर्वर पर मेट्रिक्स वितरित करते हुए पुश करेंगे।

वीपीएन

इस समस्या के समाधान के रूप में, हमने विशेष रूप से वीपीएन को चुना वायरगार्ड.

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

सिद्धांत रूप में, उसी सुरंग का उपयोग निगरानी के लिए किया जा सकता है, लेकिन ऐसा कनेक्शन साधारण धक्का की तुलना में अधिक जटिल और कम विश्वसनीय था।

बादल संसाधन

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

Dano

ओह, ऐसा लगता है कि हमने विवरण को सुलझा लिया है, आइए अंत में हमें जो चाहिए उसकी एक सूची बनाएं:

• एक त्वरित समाधान, क्योंकि विकास प्रक्रिया के दौरान पहले से ही निगरानी आवश्यक है
• आयतन/मात्रा - कई मेट्रिक्स की आवश्यकता है
• लॉग संग्रह आवश्यक है
• विश्वसनीयता - लॉन्च की सफलता के लिए डेटा महत्वपूर्ण है
• आप पुल मॉडल का उपयोग नहीं कर सकते - आपको पुश की आवश्यकता है
• हमें न केवल हार्डवेयर, बल्कि क्लाउड की भी एकीकृत निगरानी की आवश्यकता है

अंतिम छवि कुछ इस तरह दिखी

ढेर चयन

इसलिए, हमारे सामने एक निगरानी स्टैक चुनने का प्रश्न था।

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

मॉनिटरिंग समाधानों की एक विशाल विविधता है, जिसकी शुरुआत पूर्ण विकसित प्रणालियों से होती है Nagios, आइसिंगा या Zabbix और बेड़े प्रबंधन के लिए तैयार समाधानों के साथ समाप्त होता है।

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

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

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

इस सब के साथ, हमने स्वयं संपूर्ण निगरानी प्लेटफ़ॉर्म को इकट्ठा करने का प्रयास नहीं किया, बल्कि सबसे कार्यात्मक "रेडी-मेड" स्टैक की तलाश कर रहे थे, केवल उन्हें लचीले ढंग से कॉन्फ़िगर करने की क्षमता के साथ।

(बी)ईएलके?

पहला समाधान जिस पर वास्तव में विचार किया गया वह सुप्रसिद्ध ईएलके स्टैक था।
वास्तव में, इसे BELK कहा जाना चाहिए, क्योंकि यह सब बीट्स से शुरू होता है - https://www.elastic.co/what-is/elk-stack

बेशक, ईएलके निगरानी के क्षेत्र में सबसे प्रसिद्ध और शक्तिशाली समाधानों में से एक है, और लॉग एकत्र करने और संसाधित करने में तो और भी अधिक।

हमारा इरादा था कि ईएलके का उपयोग लॉग एकत्र करने और साथ ही प्रोमेथियस से प्राप्त मेट्रिक्स के दीर्घकालिक भंडारण के लिए किया जाएगा।

विज़ुअलाइज़ेशन के लिए आप ग्राफान का उपयोग कर सकते हैं।

वास्तव में, नया ईएलके स्टैक स्वतंत्र रूप से मेट्रिक्स एकत्र कर सकता है (मेट्रिकबीट), और किबाना उन्हें प्रदर्शित भी कर सकता है।

लेकिन फिर भी, ईएलके शुरू में लॉग से विकसित हुआ और अब तक मेट्रिक्स की कार्यक्षमता में कई गंभीर कमियां हैं:

• प्रोमेथियस की तुलना में काफी धीमा
• प्रोमेथियस की तुलना में बहुत कम स्थानों में एकीकृत होता है
• उनके लिए अलर्ट सेट करना कठिन है
• मेट्रिक्स बहुत अधिक स्थान लेते हैं
• किबन में मेट्रिक्स के साथ डैशबोर्ड सेट करना ग्राफान की तुलना में कहीं अधिक जटिल है

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

और ईएलके स्टैक में स्वयं कई कठिन क्षण हैं:

• यदि आप काफी बड़ी मात्रा में डेटा एकत्र करते हैं तो यह भारी है, कभी-कभी बहुत भारी भी होता है
• आपको यह जानना होगा कि इसे कैसे पकाना है - आपको इसे स्केल करने की आवश्यकता है, लेकिन ऐसा करना कोई मामूली बात नहीं है
• मुफ़्त संस्करण को हटा दिया गया - मुफ़्त संस्करण में सामान्य अलर्टिंग नहीं है, और चयन के समय कोई प्रमाणीकरण नहीं था

मुझे कहना होगा कि हाल ही में अंतिम बिंदु बेहतर और अतिरिक्त हो गया है ओपन-सोर्स एक्स-पैक में आउटपुट (प्रमाणीकरण सहित) मूल्य निर्धारण मॉडल स्वयं बदलना शुरू हो गया।

लेकिन जिस समय हम इस समाधान को तैनात करने जा रहे थे, उस समय कोई चेतावनी नहीं थी।
शायद हम ElastAlert या अन्य सामुदायिक समाधानों का उपयोग करके कुछ बनाने की कोशिश कर सकते थे, लेकिन हमने फिर भी अन्य विकल्पों पर विचार करने का निर्णय लिया।

लोकी - ग्राफाना - प्रोमेथियस

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

दुर्भाग्य से, परियोजना के बिक्री पायलट (सितंबर-अक्टूबर 19) की शुरुआत के समय, लोकी अभी भी बीटा संस्करण 0.3-0.4 में था, और विकास की शुरुआत के समय इसे एक उत्पादन समाधान नहीं माना जा सकता था बिल्कुल भी।

मुझे अभी तक गंभीर परियोजनाओं में लोकी का उपयोग करने का वास्तव में अनुभव नहीं है, लेकिन मैं कह सकता हूं कि प्रोमटेल (लॉग इकट्ठा करने के लिए एक एजेंट) कुबेरनेट्स में बेयर-मेटल और पॉड्स दोनों के लिए बहुत अच्छा काम करता है।

टिकटिक

शायद ईएलके स्टैक का सबसे योग्य (एकमात्र?) पूर्ण विशेषताओं वाला विकल्प अब केवल टिक स्टैक कहा जा सकता है - टेलीग्राफ, इन्फ्लक्सडीबी, क्रोनोग्राफ, कैपेसिटर।

मैं नीचे सभी घटकों का अधिक विस्तार से वर्णन करूंगा, लेकिन सामान्य विचार यह है:

• टेलीग्राफ - मेट्रिक्स एकत्र करने के लिए एजेंट
• इन्फ्लक्सडीबी - मेट्रिक्स डेटाबेस
• कैपेसिटर - अलर्ट करने के लिए रीयल-टाइम मेट्रिक्स प्रोसेसर
• क्रोनोग्रफ़ - विज़ुअलाइज़ेशन के लिए वेब पैनल

इन्फ्लक्सडीबी, कैपेसिटर और क्रोनोग्राफ के लिए आधिकारिक हेल्म चार्ट हैं जिनका उपयोग हम उन्हें तैनात करने के लिए करते थे।

यह ध्यान दिया जाना चाहिए कि इन्फ्लक्स 2.0 (बीटा) के नवीनतम संस्करण में, कैपेसिटर और क्रोनोग्राफ इन्फ्लक्सडीबी का हिस्सा बन गए और अब अलग से मौजूद नहीं हैं

तार

तार राज्य मशीन पर मेट्रिक्स एकत्र करने के लिए एक बहुत हल्का एजेंट है।

वह हर चीज़ की एक बड़ी मात्रा की निगरानी कर सकता है nginx से
सर्वर Minecraft.

इसके कई अच्छे फायदे हैं:

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

चूँकि पुश मेट्रिक्स हमारे लिए आवश्यक थे, अन्य सभी लाभ सुखद परिवर्धन से कहीं अधिक थे।

एजेंट द्वारा लॉग का संग्रह स्वयं भी बहुत सुविधाजनक है, क्योंकि लॉगिंग लॉग के लिए अतिरिक्त उपयोगिताओं को कनेक्ट करने की कोई आवश्यकता नहीं है।

यदि आप उपयोग करते हैं तो इन्फ्लक्स लॉग के साथ काम करने के लिए सबसे सुविधाजनक अनुभव प्रदान करता है syslog.

टेलीग्राफ आम तौर पर मेट्रिक्स एकत्र करने के लिए एक महान एजेंट है, भले ही आप बाकी ICK स्टैक का उपयोग न करें।

कई लोग सुविधा के लिए इसे ईएलके और कई अन्य समय-श्रृंखला डेटाबेस के साथ पार करते हैं, क्योंकि यह लगभग कहीं भी मेट्रिक्स लिख सकता है।

इन्फ्लक्सडीबी

InfluxDB TICK स्टैक का मुख्य केंद्र है, अर्थात् मेट्रिक्स के लिए एक समय-श्रृंखला डेटाबेस।
मेट्रिक्स के अलावा, इन्फ्लक्स लॉग भी स्टोर कर सकता है, हालांकि, संक्षेप में, इसके लिए लॉग केवल एक ही मेट्रिक्स हैं, केवल सामान्य संख्यात्मक संकेतकों के बजाय, मुख्य कार्य लॉग टेक्स्ट की एक पंक्ति द्वारा किया जाता है।

InfluxDB भी Go में लिखा गया है और हमारे (सबसे शक्तिशाली नहीं) क्लस्टर पर ELK की तुलना में बहुत तेज़ चलता है।

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

नुकसान - $$$ या स्केलिंग?

TICK स्टैक में केवल एक ही कमी है जो हमने खोजी - वह प्रिय. और भी।

भुगतान किए गए संस्करण में क्या है जो मुफ़्त संस्करण में नहीं है?

जहां तक ​​हम समझ पाए, टिक स्टैक के भुगतान किए गए संस्करण और मुफ़्त संस्करण के बीच एकमात्र अंतर स्केलिंग क्षमताओं का है।

अर्थात्, आप केवल उच्च उपलब्धता वाला क्लस्टर बढ़ा सकते हैं उद्यम संस्करण.

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

यह अफ़सोस की बात है, लेकिन ऐसा लगता है कि दोनों को छोड़ दिया गया है - कोई नई प्रतिबद्धता नहीं है, मैं मानता हूं कि मुद्दा इन्फ्लक्स 2.0 के नए संस्करण की जल्द ही अपेक्षित रिलीज है, जिसमें कई चीजें अलग होंगी (इसके बारे में कोई जानकारी नहीं है) अभी इसमें स्केलिंग हो रही है)।

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

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

विक्टोरिया मेट्रिक्स?

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

बहुत सारे समय-श्रृंखला डेटाबेस हैं, लेकिन सबसे आशाजनक विक्टोरिया मेट्रिक्स है, इसके कई फायदे हैं:

• तेज़ और आसान, कम से कम परिणामों के अनुसार मानक
• एक क्लस्टर संस्करण है, जिसके बारे में अब और भी अच्छी समीक्षाएँ हैं
  • वह ठीकरा फोड़ सकती है
• इन्फ्लक्सडीबी प्रोटोकॉल का समर्थन करता है

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

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

इसके अलावा, मेट्रिक्स के लिए केवल संख्यात्मक मान समर्थित हैं (हमने कस्टम मेट्रिक्स के लिए स्ट्रिंग मानों का उपयोग किया है - अनुभाग में इसके बारे में अधिक जानकारी) व्यवस्थापक पैनल).

जाहिर है, इसी कारण से, वीएम इन्फ्लक्स की तरह लॉग को स्टोर नहीं कर सकता है।

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

आधार चयन

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

इस विकल्प के कई मुख्य कारण थे:

• हमें वास्तव में TICK स्टैक की संपूर्ण कार्यक्षमता पसंद आई
• हम पहले ही इसे तैनात करने में कामयाब रहे और इसने बहुत अच्छा काम किया
• समय सीमा समाप्त हो रही थी और अन्य विकल्पों का परीक्षण करने के लिए अधिक समय नहीं बचा था।
• हमें इतने भारी बोझ की उम्मीद नहीं थी

पायलट के पहले चरण के लिए हमारे पास अधिक स्कूटर नहीं थे, और विकास के दौरान परीक्षण से कोई प्रदर्शन समस्या सामने नहीं आई।

इसलिए, हमने निर्णय लिया कि इस परियोजना के लिए स्केलिंग की आवश्यकता के बिना एक इन्फ्लक्स नोड हमारे लिए पर्याप्त होगा (अंत में निष्कर्ष देखें)।

हमने स्टैक और आधार पर निर्णय ले लिया है - अब टिक स्टैक के शेष घटकों के बारे में।

कपैसिटर

कैपेसिटर TICK स्टैक का हिस्सा है, एक ऐसी सेवा जो वास्तविक समय में डेटाबेस में प्रवेश करने वाले मेट्रिक्स की निगरानी कर सकती है और नियमों के आधार पर विभिन्न क्रियाएं कर सकती है।

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

इस तरह हमने सूचनाओं के लिए इसका उपयोग किया। जब कोई विशेष स्कूटर ऑफ़लाइन हो जाता है तो हम स्लैक अलर्ट सेट करते हैं, और स्मार्ट चार्जर और महत्वपूर्ण बुनियादी ढांचे के घटकों के लिए भी ऐसा ही किया जाता है।

इससे समस्याओं पर तुरंत प्रतिक्रिया देना संभव हो गया, साथ ही सूचनाएं भी प्राप्त हुईं कि सब कुछ सामान्य हो गया है।

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

इन्फ्लक्स 2.0 में कैपेसिटर डीबी का हिस्सा बन गया

क्रोनोग्रफ़

मैंने निगरानी के लिए कई अलग-अलग यूआई समाधान देखे हैं, लेकिन मैं कह सकता हूं कि कार्यक्षमता और यूएक्स के मामले में, क्रोनोग्राफ की तुलना में कुछ भी नहीं है।

हमने एक वेब इंटरफ़ेस के रूप में ग्राफान के साथ, अजीब तरह से पर्याप्त, टिक स्टैक का उपयोग करना शुरू कर दिया।
मैं इसकी कार्यक्षमता का वर्णन नहीं करूंगा; हर कोई कुछ भी स्थापित करने के लिए इसकी व्यापक संभावनाओं को जानता है।

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

और निश्चित रूप से, इसके लिए धन्यवाद, क्रोनोग्राफ बहुत अधिक चतुर या सुविधाजनक कार्यक्षमता प्रदान कर सकता है।

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

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

किबाना के पास डैशबोर्ड और उनके लिए नियंत्रण बनाने की बहुत समृद्ध क्षमताएं हैं, लेकिन ऐसे संचालन के लिए यूएक्स बहुत जटिल है।

एक सुविधाजनक डैशबोर्ड बनाने के लिए कुछ अच्छी समझ की आवश्यकता होगी। और यद्यपि क्रोनोग्राफ डैशबोर्ड की कार्यक्षमता कम है, उन्हें बनाना और अनुकूलित करना बहुत आसान है।

डैशबोर्ड स्वयं, सुखद दृश्य शैली के अलावा, वास्तव में ग्राफाना या किबाना के डैशबोर्ड से अलग नहीं हैं:

क्वेरी विंडो इस प्रकार दिखती है:

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

और निश्चित रूप से, लॉग देखने के लिए क्रोनोग्रफ़ यथासंभव सुविधाजनक है। यह इस तरह दिख रहा है:

डिफ़ॉल्ट रूप से, इन्फ्लक्स लॉग को syslog का उपयोग करने के लिए तैयार किया जाता है और इसलिए उनके पास एक महत्वपूर्ण पैरामीटर है - गंभीरता।

शीर्ष पर स्थित ग्राफ़ विशेष रूप से उपयोगी है; इस पर आप होने वाली त्रुटियों को देख सकते हैं और गंभीरता अधिक होने पर रंग तुरंत स्पष्ट रूप से दिखाता है।

कुछ बार हमने इस तरह से महत्वपूर्ण बग पकड़े, पिछले सप्ताह के लॉग देखने पर और एक लाल स्पाइक देखा।

बेशक, आदर्श रूप से ऐसी त्रुटियों के लिए अलर्ट सेट करना होगा, क्योंकि हमारे पास इसके लिए पहले से ही सब कुछ है।

हमने इसे कुछ समय के लिए चालू भी किया, लेकिन पायलट तैयार करने की प्रक्रिया में यह पता चला कि हमें बहुत सारी त्रुटियां मिल रही थीं (जिनमें एलटीई नेटवर्क की अनुपलब्धता जैसी सिस्टम त्रुटियां भी शामिल थीं), जिसने स्लैक चैनल को भी "स्पैम" कर दिया था। बहुत कुछ, बिना किसी समस्या के। बहुत लाभ।

सही समाधान यह होगा कि इस प्रकार की अधिकांश त्रुटियों को संभाला जाए, उनकी गंभीरता को समायोजित किया जाए और उसके बाद ही अलर्ट सक्षम किया जाए।

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

प्रमाणीकरण

यह भी उल्लेखनीय है कि क्रोनोग्राफ प्रमाणीकरण के रूप में OAuth और OIDC का समर्थन करता है।

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

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

"व्यवस्थापक"

अंतिम घटक जिसका मैं वर्णन करूंगा वह Vue में हमारा स्व-लिखित "एडमिन पैनल" है।
मूल रूप से यह सिर्फ एक स्टैंडअलोन सेवा है जो हमारे अपने डेटाबेस, माइक्रोसर्विसेज और इन्फ्लक्सडीबी से मेट्रिक्स डेटा से स्कूटर की जानकारी एक साथ प्रदर्शित करती है।

इसके अलावा, कई प्रशासनिक कार्यों को वहां स्थानांतरित कर दिया गया, जैसे आपातकालीन रीबूट या सहायता टीम के लिए दूरस्थ रूप से लॉक खोलना।

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

इन्फ्लक्स के पहले से बताए गए फायदों में से एक आसानी से अपनी खुद की मेट्रिक्स बनाने की क्षमता है।
यह इसे विभिन्न प्रकार के परिदृश्यों के लिए उपयोग करने की अनुमति देता है।

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

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

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

वैसे, हमने द सिम्पसंस के पात्रों के नाम पर स्कूटरों का नाम रखा - उन्हें एक-दूसरे से अलग करना बहुत सुविधाजनक था

और सामान्य तौर पर इस तरह से यह अधिक मज़ेदार था। "दोस्तों, स्मिथर्स मर चुका है!" जैसे वाक्यांश लगातार सुने जा रहे थे।

स्ट्रिंग मेट्रिक्स

यह महत्वपूर्ण है कि InfluxDB आपको न केवल संख्यात्मक मान संग्रहीत करने की अनुमति देता है, जैसा कि विक्टोरिया मेट्रिक्स के मामले में है।

ऐसा प्रतीत होता है कि यह इतना महत्वपूर्ण नहीं है - आखिरकार, लॉग के अलावा, किसी भी मेट्रिक्स को संख्याओं के रूप में संग्रहीत किया जा सकता है (केवल ज्ञात राज्यों के लिए मैपिंग जोड़ें - एक प्रकार का एनम)?

हमारे मामले में, कम से कम एक परिदृश्य ऐसा था जहां स्ट्रिंग मेट्रिक्स बहुत उपयोगी थे।
ऐसा हुआ कि हमारे "स्मार्ट चार्जर्स" का आपूर्तिकर्ता एक तीसरा पक्ष था, हमारा विकास प्रक्रिया और इन चार्जर्स द्वारा आपूर्ति की जा सकने वाली जानकारी पर कोई नियंत्रण नहीं था।

परिणामस्वरूप, चार्जिंग एपीआई आदर्श से बहुत दूर थी, लेकिन मुख्य समस्या यह थी कि हम हमेशा उनकी स्थिति को समझ नहीं पाते थे।

यहीं पर इन्फ्लक्स बचाव के लिए आया। हमने केवल उस स्ट्रिंग स्थिति को लिखा जो बिना किसी बदलाव के इन्फ्लक्सडीबी डेटाबेस फ़ील्ड में हमारे पास आई।

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

जैसा कि बाद में पता चला, यह स्थिति कनेक्शन के नुकसान के बाद एक बार भेजी गई थी, यदि चार्जर एक निश्चित संख्या में प्रयासों के बाद सर्वर के साथ कनेक्शन स्थापित नहीं कर सका।

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

और सामान्य तौर पर, स्ट्रिंग मेट्रिक्स उपयोग के लिए बहुत अधिक संभावनाएं प्रदान करते हैं; आप उनमें वस्तुतः कोई भी जानकारी रिकॉर्ड कर सकते हैं। हालाँकि, निश्चित रूप से, आपको इस टूल का उपयोग सावधानी से करने की भी आवश्यकता है।

सामान्य मेट्रिक्स के अलावा, हमने InfluxDB में जीपीएस स्थान की जानकारी भी दर्ज की। यह हमारे व्यवस्थापक पैनल में स्कूटरों के स्थान की निगरानी के लिए अविश्वसनीय रूप से उपयोगी था।
दरअसल, हमें हमेशा पता होता था कि हमें जिस वक्त जरूरत होगी, उस वक्त कहां और कौन सा स्कूटर होगा।

जब हम स्कूटर की तलाश में थे तो यह हमारे लिए बहुत उपयोगी था (अंत में निष्कर्ष देखें)।

बुनियादी ढांचे की निगरानी

स्कूटरों के अलावा, हमें अपने संपूर्ण (बल्कि व्यापक) बुनियादी ढांचे की निगरानी करने की भी आवश्यकता थी।

एक बहुत ही सामान्य वास्तुकला कुछ इस तरह दिखती थी:

यदि हम शुद्ध निगरानी स्टैक को उजागर करते हैं, तो यह इस तरह दिखता है:

हम क्लाउड में क्या जाँचना चाहेंगे वह है:

• डेटाबेस
• चाबी का कपड़ा
• माइक्रोसर्विसेज

चूँकि हमारी सभी क्लाउड सेवाएँ कुबेरनेट्स में स्थित हैं, इसलिए इसकी स्थिति के बारे में जानकारी एकत्र करना अच्छा होगा।

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

हमने मुख्य रूप से पॉड्स के प्रदर्शन और मेमोरी खपत की निगरानी की। गिरावट की स्थिति में, स्लैक में अलर्ट।

कुबेरनेट्स में पॉड्स को ट्रैक करने के दो तरीके हैं: डेमनसेट और साइडकार।
दोनों विधियों का विस्तार से वर्णन किया गया है इस ब्लॉग पोस्ट में.

हमने टेलीग्राफ साइडकार का उपयोग किया और मेट्रिक्स के अलावा, पॉड लॉग एकत्र किए।

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

मॉनिटर मॉनिटरिंग???

अंत में, निगरानी प्रणालियों की निगरानी का सदियों पुराना प्रश्न उठा, लेकिन सौभाग्य से, या दुर्भाग्य से, हमारे पास इसके लिए पर्याप्त समय नहीं था।

हालाँकि टेलीग्राफ आसानी से अपने स्वयं के मेट्रिक्स भेज सकता है या उसी इन्फ्लक्स या कहीं और भेजने के लिए इन्फ्लक्सडीबी डेटाबेस से मेट्रिक्स एकत्र कर सकता है।

निष्कर्ष

पायलट के परिणामों से हमने क्या निष्कर्ष निकाला?

आप मॉनिटरिंग कैसे कर सकते हैं?

सबसे पहले, TICK स्टैक पूरी तरह से हमारी उम्मीदों पर खरा उतरा और हमें शुरुआत में जितनी उम्मीद थी उससे भी अधिक अवसर दिए।

हमें आवश्यक सभी कार्यक्षमताएँ मौजूद थीं। हमने इसके साथ जो कुछ भी किया वह बिना किसी समस्या के काम किया।

निष्पादन

मुफ़्त संस्करण में TICK स्टैक के साथ मुख्य समस्या स्केलिंग क्षमताओं की कमी है। यह हमारे लिए कोई समस्या नहीं थी.

हमने सटीक लोड डेटा/आंकड़े एकत्र नहीं किए, लेकिन हमने एक समय में लगभग 30 स्कूटरों से डेटा एकत्र किया।

उनमें से प्रत्येक ने तीन दर्जन से अधिक मेट्रिक्स एकत्र किए। उसी समय, उपकरणों से लॉग एकत्र किए गए थे। डेटा संग्रह और भेजना हर 10 सेकंड में होता था।

यह ध्यान रखना महत्वपूर्ण है कि पायलट के डेढ़ सप्ताह के बाद, जब अधिकांश "बचपन की समस्याओं" को ठीक कर लिया गया और सबसे महत्वपूर्ण समस्याओं का समाधान पहले ही हो चुका था, हमें सर्वर पर डेटा भेजने की आवृत्ति को कम करना पड़ा। 30 सेकंड। यह आवश्यक हो गया क्योंकि हमारे LTE सिम कार्ड पर ट्रैफ़िक तेज़ी से गायब होने लगा।

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

परिणामस्वरूप, कुछ समय बाद हमने उपकरणों पर लॉग के संग्रह को पूरी तरह से अक्षम कर दिया, क्योंकि निरंतर संग्रह के बिना भी विशिष्ट समस्याएं पहले से ही स्पष्ट थीं।

कुछ मामलों में, यदि लॉग देखना अभी भी आवश्यक था, तो हम बस वीपीएन के माध्यम से वायरगार्ड से जुड़े हुए थे।

मैं यह भी जोड़ूंगा कि प्रत्येक अलग वातावरण एक दूसरे से अलग किया गया था, और ऊपर वर्णित लोड केवल उत्पादन वातावरण के लिए प्रासंगिक था।

विकास परिवेश में, हमने एक अलग InfluxDB उदाहरण तैयार किया जो हर 10 सेकंड में डेटा एकत्र करता रहा और हमें किसी भी प्रदर्शन समस्या का सामना नहीं करना पड़ा।

टिक - छोटे से मध्यम परियोजनाओं के लिए आदर्श

इस जानकारी के आधार पर, मैं यह निष्कर्ष निकालूंगा कि TICK स्टैक अपेक्षाकृत छोटी परियोजनाओं या परियोजनाओं के लिए आदर्श है जो निश्चित रूप से किसी हाईलोड की अपेक्षा नहीं करते हैं।

यदि आपके पास हजारों पॉड या सैकड़ों मशीनें नहीं हैं, तो एक InfluxDB इंस्टेंस भी लोड को ठीक से संभाल लेगा।

कुछ मामलों में, आप एक आदिम उच्च उपलब्धता समाधान के रूप में इन्फ्लक्स रिले से संतुष्ट हो सकते हैं।

और, निश्चित रूप से, कोई भी आपको "ऊर्ध्वाधर" स्केलिंग स्थापित करने और विभिन्न प्रकार के मेट्रिक्स के लिए अलग-अलग सर्वर आवंटित करने से नहीं रोक रहा है।

यदि आप निगरानी सेवाओं पर अपेक्षित भार के बारे में निश्चित नहीं हैं, या आपके पास बहुत "भारी" आर्किटेक्चर होने की गारंटी है/होगी, तो मैं टिक स्टैक के मुफ्त संस्करण का उपयोग करने की अनुशंसा नहीं करूंगा।

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

इस मामले में, आज, मैं लोकी का उपयोग करके विक्टोरिया मेट्रिक्स और लॉग के माध्यम से मेट्रिक्स एकत्र करने की ओर देखने की सलाह दूंगा।

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

यह महत्वपूर्ण है: यहां वर्णित सभी जानकारी इन्फ्लक्स 1.8 संस्करण के लिए प्रासंगिक है, फिलहाल इन्फ्लक्स 2.0 जारी होने वाला है।

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

यह कार्यक्षमता इन्फ्लक्स 2.0 में भी दिखाई देगी, लेकिन हमें कोई समय सीमा नहीं मिली, यहाँ तक कि अनुमानित भी नहीं।

IoT प्लेटफ़ॉर्म कैसे न बनाएं (अभी)

अंत में, पायलट लॉन्च करने के बाद, हमने अपने मानकों के अनुसार उपयुक्त विकल्प के अभाव में, स्वयं अपना पूर्ण विकसित IoT स्टैक इकट्ठा किया।

हालाँकि, हाल ही में यह बीटा संस्करण में उपलब्ध है ओपनबैलेना - यह अफ़सोस की बात है कि जब हमने प्रोजेक्ट बनाना शुरू किया तो वह वहां नहीं थी।

हम अंतिम परिणाम और Ansible + TICK + वायरगार्ड पर आधारित प्लेटफ़ॉर्म से पूरी तरह संतुष्ट हैं जिसे हमने स्वयं इकट्ठा किया है। लेकिन आज, मैं अपना खुद का IoT प्लेटफ़ॉर्म बनाने का प्रयास करने से पहले Balena पर करीब से नज़र डालने की सलाह दूंगा।

क्योंकि आख़िरकार यह वही सब कर सकता है जो हमने किया, और OpenBalena मुफ़्त और खुला स्रोत है।

यह पहले से ही जानता है कि न केवल अपडेट कैसे भेजना है, बल्कि एक वीपीएन भी पहले से ही बनाया गया है और IoT वातावरण में उपयोग के लिए तैयार किया गया है।

और अभी हाल ही में, उन्होंने अपना रिलीज़ भी किया हार्डवेयर, जो आसानी से उनके पारिस्थितिकी तंत्र से जुड़ जाता है।

अरे, गायब स्कूटर के बारे में क्या?

तो स्कूटर, "राल्फ", बिना किसी निशान के गायब हो गया।

हम तुरंत अपने "एडमिन पैनल" में इन्फ्लक्सडीबी के जीपीएस मेट्रिक्स डेटा वाले मानचित्र को देखने के लिए दौड़े।

डेटा की निगरानी के लिए धन्यवाद, हमने आसानी से निर्धारित किया कि स्कूटर पिछले दिन 21:00 बजे के आसपास पार्किंग स्थल से निकला था, लगभग आधे घंटे तक किसी क्षेत्र में चला गया और किसी जर्मन घर के बगल में सुबह 5 बजे तक पार्क किया गया था।

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

हालांकि, घर का मालिक भी इस बात से हैरान था, क्योंकि असल में वह कल रात ऑफिस से इसी स्कूटर पर सवार होकर घर आया था.

जैसा कि पता चला, सहायक कर्मचारियों में से एक सुबह जल्दी पहुंचा और स्कूटर उठाया, यह देखकर कि इसकी अतिरिक्त बैटरी पूरी तरह से डिस्चार्ज हो गई थी और इसे (पैदल) पार्किंग स्थल पर ले गया। और अतिरिक्त बैटरी नमी के कारण खराब हो गई।

हमने स्कूटर खुद से चुराया। वैसे, मुझे नहीं पता कि पुलिस केस का मामला कैसे और किसने सुलझाया, लेकिन निगरानी ने पूरी तरह से काम किया...

स्रोत: www.habr.com