हरवलेली स्कूटर परत करा किंवा एका IoT मॉनिटरिंगची गोष्ट

एका वर्षापूर्वी आम्ही एका प्रचारात्मक प्रकल्पाची पायलट आवृत्ती लाँच केली इलेक्ट्रिक स्कूटरचे विकेंद्रित भाडे.

सुरुवातीला, प्रकल्पाला रोड-टू-बार्सिलोना असे म्हटले गेले, नंतर ते रोड-टू-बर्लिन बनले (म्हणूनच स्क्रीनशॉटमध्ये R2B), आणि शेवटी त्याला xRide म्हटले गेले.

प्रकल्पाची मुख्य कल्पना अशी होती: केंद्रीकृत कार किंवा स्कूटर भाड्याने देण्याची सेवा घेण्याऐवजी (आम्ही स्कूटर उर्फ ​​​​इलेक्ट्रिक मोटरसायकलबद्दल बोलत आहोत, किकस्कूटर/स्कूटर नाही) आम्हाला विकेंद्रित भाड्याने प्लॅटफॉर्म बनवायचा होता. आम्हाला आलेल्या अडचणींबद्दल आधीच लिहिले आहे.

सुरुवातीला, प्रकल्पाने कारवर लक्ष केंद्रित केले, परंतु अंतिम मुदत, उत्पादकांशी अत्यंत लांब संप्रेषण आणि मोठ्या संख्येने सुरक्षा निर्बंधांमुळे, पायलटसाठी इलेक्ट्रिक स्कूटर निवडले गेले.

वापरकर्त्याने फोनवर iOS किंवा Android ऍप्लिकेशन स्थापित केले, त्याला आवडलेल्या स्कूटरशी संपर्क साधला, त्यानंतर फोन आणि स्कूटरने पीअर-टू-पीअर कनेक्शन स्थापित केले, ETH ची देवाणघेवाण झाली आणि वापरकर्ता स्कूटर चालू करून राइड सुरू करू शकतो. फोन. ट्रिपच्या शेवटी, फोनवरील वापरकर्त्याच्या वॉलेटमधून इथरियम वापरून ट्रिपसाठी पैसे देणे देखील शक्य होते.

स्कूटर व्यतिरिक्त, वापरकर्त्याला अनुप्रयोगात “स्मार्ट चार्जर” दिसले, ज्याला भेट देऊन वापरकर्ता वर्तमान बॅटरी कमी असल्यास स्वतः बदलू शकतो.

बॉन आणि बर्लिन या दोन जर्मन शहरांमध्ये गेल्या वर्षी सप्टेंबरमध्ये लॉन्च करण्यात आलेला आमचा पायलट हा साधारणपणे कसा दिसत होता.

आणि मग, एके दिवशी, बॉनमध्ये, पहाटे, आमच्या सपोर्ट टीमला (कार्यक्रमात स्कूटर राखण्यासाठी साइटवर स्थित) चेतावणी देण्यात आली: स्कूटरपैकी एक ट्रेसशिवाय गायब झाली होती.

ते कसे शोधायचे आणि परत कसे करायचे?

या लेखात मी याबद्दल बोलेन, परंतु प्रथम - आम्ही आमचे स्वतःचे IoT प्लॅटफॉर्म कसे तयार केले आणि आम्ही त्याचे परीक्षण कसे केले याबद्दल.

काय आणि का निरीक्षण करावे: स्कूटर, पायाभूत सुविधा, चार्जिंग स्टेशन?

तर, आम्हाला आमच्या प्रकल्पात काय निरीक्षण करायचे होते?

सर्व प्रथम, ही स्वतः स्कूटर आहेत - इलेक्ट्रिक स्कूटर स्वतः खूप महाग आहेत, आपण पुरेशी तयारी केल्याशिवाय असा प्रकल्प सुरू करू शकत नाही; शक्य असल्यास, आपल्याला स्कूटरबद्दल शक्य तितकी माहिती गोळा करायची आहे: त्यांचे स्थान, चार्ज पातळी , इ.

याव्यतिरिक्त, मी आमच्या स्वतःच्या आयटी इन्फ्रास्ट्रक्चरच्या स्थितीचे निरीक्षण करू इच्छितो - डेटाबेस, सेवा आणि त्यांना कार्य करण्यासाठी आवश्यक असलेल्या सर्व गोष्टी. "स्मार्ट चार्जर" च्या स्थितीचे निरीक्षण करणे देखील आवश्यक होते, जर ते तुटले किंवा पूर्ण बॅटरी संपली.

स्कूटर

आमच्या स्कूटर काय होत्या आणि आम्हाला त्यांच्याबद्दल काय जाणून घ्यायचे होते?

पहिली आणि सर्वात महत्त्वाची गोष्ट म्हणजे जीपीएस कोऑर्डिनेट्स, कारण त्यांच्यामुळे ते कुठे आहेत आणि कुठे फिरत आहेत हे आपण समजू शकतो.

पुढे बॅटरी चार्ज आहे, ज्यामुळे आम्ही निर्धारित करू शकतो की स्कूटरचे चार्जिंग समाप्त होत आहे आणि ज्यूसर पाठवू किंवा किमान वापरकर्त्याला चेतावणी देऊ.

अर्थात, आमच्या हार्डवेअर घटकांसह काय होत आहे ते तपासणे देखील आवश्यक आहे:

• ब्लूटूथ काम करते का?
• जीपीएस मॉड्यूल स्वतः कार्य करते का?
  • जीपीएस चुकीचे निर्देशांक पाठवू शकते आणि अडकू शकते या वस्तुस्थितीसह आम्हाला समस्या होती आणि हे केवळ स्कूटरवरील अतिरिक्त तपासणीद्वारे निर्धारित केले जाऊ शकते,
    आणि समस्येचे निराकरण करण्यासाठी शक्य तितक्या लवकर समर्थन सूचित करा

आणि शेवटी: सॉफ्टवेअरची तपासणी, OS आणि प्रोसेसरपासून सुरू होणारी, नेटवर्क आणि डिस्क लोड, आमच्या स्वतःच्या मॉड्यूल्सच्या तपासणीसह समाप्त होते जे आमच्यासाठी अधिक विशिष्ट आहेत (जोलोकॉम, कीक्लोक).

हार्डवेअर

आमचा "लोह" भाग काय होता?

कमीत कमी संभाव्य कालावधी आणि जलद प्रोटोटाइपिंगची आवश्यकता लक्षात घेऊन, आम्ही घटकांची अंमलबजावणी आणि निवड करण्यासाठी सर्वात सोपा पर्याय निवडला - रास्पबेरी पाई.
आरपीआय व्यतिरिक्त, आमच्याकडे एक सानुकूल बोर्ड होता (जे आम्ही स्वतः विकसित केले आणि अंतिम सोल्यूशनच्या असेंब्ली प्रक्रियेस गती देण्यासाठी चीनमधून ऑर्डर केले) आणि घटकांचा एक संच - एक रिले (स्कूटर चालू/बंद करण्यासाठी), बॅटरी चार्ज रीडर, मॉडेम, अँटेना. हे सर्व एका खास "xRide बॉक्स" मध्ये संक्षिप्तपणे पॅक केले होते.

हे देखील लक्षात घ्यावे की संपूर्ण बॉक्स अतिरिक्त पॉवर बँकद्वारे समर्थित होता, जो स्कूटरच्या मुख्य बॅटरीद्वारे समर्थित होता.

यामुळे ट्रिप संपल्यानंतरही मॉनिटरिंग वापरणे आणि स्कूटर चालू करणे शक्य झाले, कारण इग्निशन की "ऑफ" स्थितीकडे वळवल्यानंतर लगेचच मुख्य बॅटरी बंद केली गेली.

डॉकर? साधा लिनक्स? आणि उपयोजन

चला मॉनिटरिंगवर परत येऊ, म्हणून रास्पबेरी - आमच्याकडे काय आहे?

भौतिक उपकरणांवर घटक उपयोजित करणे, अद्यतनित करणे आणि वितरीत करणे या प्रक्रियेला गती देण्यासाठी आम्हाला वापरायची असलेली पहिली गोष्ट म्हणजे डॉकर.

दुर्दैवाने, हे त्वरीत स्पष्ट झाले की RPi वरील डॉकर, जरी ते कार्य करत असले तरी, विशेषत: वीज वापराच्या बाबतीत बरेच ओव्हरहेड आहे.

"नेटिव्ह" OS वापरून असलेला फरक, जरी तितका मजबूत नसला तरी, आमच्यासाठी खूप लवकर चार्ज गमावण्याच्या शक्यतेपासून सावध राहण्यासाठी पुरेसा होता.

दुसरे कारण म्हणजे Node.js (sic!) वरील आमच्या भागीदार लायब्ररींपैकी एक - प्रणालीचा एकमेव घटक जो Go/C/C++ मध्ये लिहिलेला नव्हता.

लायब्ररीच्या लेखकांना कोणत्याही "नेटिव्ह" भाषेत कार्यरत आवृत्ती प्रदान करण्यासाठी वेळ नव्हता.

केवळ नोड हाच कमी-कार्यक्षमता असलेल्या उपकरणांसाठी सर्वात मोहक उपाय नाही, तर लायब्ररी स्वतः खूप संसाधन-भुकेली होती.

आम्हाला समजले की, आम्हाला हवे असले तरीही, डॉकर वापरणे आमच्यासाठी खूप जास्त असेल. निवड नेटिव्ह ओएसच्या बाजूने केली गेली होती आणि थेट त्याखाली काम करत होती.

OS

परिणामी, आम्ही, पुन्हा, OS म्हणून सर्वात सोपा पर्याय निवडला आणि Raspbian (Pi साठी डेबियन बिल्ड) वापरला.

आम्ही आमचे सर्व सॉफ्टवेअर Go मध्ये लिहितो, म्हणून आम्ही आमच्या सिस्टममधील मुख्य हार्डवेअर एजंट मॉड्यूल Go मध्ये देखील लिहिले.

जीपीएस, ब्लूटूथसह काम करणे, चार्ज वाचणे, स्कूटर चालू करणे इत्यादीसाठी तोच जबाबदार आहे.

तैनात करणे

डिव्‍हाइसेस (OTA) वर अपडेट वितरीत करण्‍याची यंत्रणा कार्यान्वित करण्‍याची आवश्‍यकता असा प्रश्‍न लगेचच उद्भवला - आमच्‍या एजंट/अ‍ॅप्लिकेशनच्‍या अपडेटस् आणि स्‍वत: OS/फर्मवेअरचे अपडेट (कारण एजंटच्‍या नवीन आवृत्‍तींना कर्नलच्‍या अपडेटची आवश्‍यकता असू शकते. किंवा सिस्टम घटक, लायब्ररी इ.) .

बाजाराच्या दीर्घ विश्लेषणानंतर, असे दिसून आले की डिव्हाइसवर अद्यतने वितरीत करण्यासाठी बरेच उपाय आहेत.

तुलनेने सोप्या, swupd/SWUpdate/OSTree सारख्या बहुतांशी अपडेट/ड्युअल-बूट ओरिएंटेड युटिलिटीपासून ते Mender आणि Balena सारख्या पूर्ण प्लॅटफॉर्मवर.

सर्व प्रथम, आम्ही ठरवले की आम्हाला एंड-टू-एंड सोल्यूशन्समध्ये स्वारस्य आहे, म्हणून निवड लगेचच प्लॅटफॉर्मवर पडली.

स्वतः बालेना तो प्रत्यक्षात त्याच्या बॅलेनाइंजिनमध्ये समान डॉकर वापरतो या वस्तुस्थितीमुळे वगळण्यात आले.

परंतु मी लक्षात घेतो की असे असूनही, आम्ही त्यांचे उत्पादन सतत वापरत होतो बलेना एचर SD कार्डवरील फ्लॅश फर्मवेअरसाठी - यासाठी एक साधी आणि अत्यंत सोयीस्कर उपयुक्तता.

त्यामुळे अखेर निवडीवर पडदा पडला मेन्डर. फर्मवेअर असेंबलिंग, डिलिव्हरी आणि इन्स्टॉल करण्यासाठी मेन्डर हे एक संपूर्ण व्यासपीठ आहे.

एकूणच प्लॅटफॉर्म छान दिसत आहे, परंतु मेन्डर बिल्डरचा वापर करून आमच्या फर्मवेअरची योग्य आवृत्ती तयार करण्यासाठी आम्हाला सुमारे दीड आठवडा लागला.
आणि आपण त्याच्या वापराच्या गुंतागुंतींमध्ये जितके जास्त मग्न झालो, तितकेच हे स्पष्ट झाले की ते पूर्णपणे उपयोजित करण्यासाठी आपल्याला आपल्यापेक्षा जास्त वेळ लागेल.

अरेरे, आमच्या घट्ट मुदतीचा अर्थ असा आहे की आम्हाला मेन्डरचा वापर सोडून देणे आणि आणखी सोपे निवडणे भाग पडले.

उत्तर द्या

आमच्या परिस्थितीत सर्वात सोपा उपाय म्हणजे Ansible वापरणे. सुरुवात करण्यासाठी काही प्लेबुक्स पुरेशी होती.

त्यांचे सार हे होते की आम्ही होस्ट (CI सर्व्हर) वरून ssh द्वारे आमच्या rasberries शी कनेक्ट केले आणि त्यांना अद्यतने वितरित केली.

अगदी सुरुवातीस, सर्वकाही सोपे होते - आपल्याला डिव्हाइसेससह समान नेटवर्कवर असणे आवश्यक होते, वाय-फाय द्वारे ओतणे होते.

कार्यालयात एकाच नेटवर्कशी फक्त डझनभर चाचणी रास्पबेरी जोडल्या गेल्या होत्या, प्रत्येक उपकरणाचा एक स्थिर IP पत्ता होता जो उत्तरदायी इन्व्हेंटरीमध्ये देखील निर्दिष्ट केला होता.

हे Ansible होते ज्याने आमच्या मॉनिटरिंग एजंटला शेवटच्या डिव्हाइसेसवर वितरित केले

3G / एलटीई

दुर्दैवाने, आमच्याकडे वास्तविक स्कूटर असण्याआधीच Ansible साठी हे वापर प्रकरण केवळ विकास मोडमध्ये कार्य करू शकते.

कारण स्कूटर, तुम्हाला समजल्याप्रमाणे, एका वाय-फाय राउटरला जोडून बसू नका, सतत नेटवर्कवर अपडेट्सची वाट पहात.

प्रत्यक्षात, स्कूटरमध्ये मोबाइल 3G/LTE व्यतिरिक्त इतर कोणतेही कनेक्शन असू शकत नाही (आणि तरीही नेहमीच नाही).

हे ताबडतोब अनेक समस्या आणि मर्यादा लादते, जसे की कमी कनेक्शन गती आणि अस्थिर संप्रेषण.

परंतु सर्वात महत्वाची गोष्ट म्हणजे 3G/LTE नेटवर्कमध्ये आम्ही नेटवर्कला नियुक्त केलेल्या स्थिर IP वर अवलंबून राहू शकत नाही.

हे काही सिम कार्ड प्रदात्यांद्वारे अंशतः सोडवले जाते; स्थिर IP पत्त्यांसह IoT उपकरणांसाठी डिझाइन केलेले विशेष सिम कार्ड देखील आहेत. परंतु आमच्याकडे अशा सिमकार्डमध्ये प्रवेश नव्हता आणि आम्ही आयपी पत्ते वापरू शकत नाही.

अर्थात, कॉन्सुल प्रमाणे कुठेतरी IP पत्त्यांची नोंदणी उर्फ ​​सेवा शोध करण्याच्या कल्पना होत्या, परंतु आम्हाला अशा कल्पना सोडून द्याव्या लागल्या, कारण आमच्या चाचण्यांमध्ये IP पत्ता बर्‍याचदा बदलू शकतो, ज्यामुळे मोठ्या प्रमाणात अस्थिरता निर्माण होते.

या कारणास्तव, मेट्रिक्स वितरीत करण्यासाठी सर्वात सोयीस्कर वापर पुल मॉडेलचा वापर केला जाणार नाही, जिथे आम्ही आवश्यक मेट्रिक्ससाठी डिव्हाइसेसवर जाऊ, परंतु पुश, मेट्रिक्स डिव्हाइसवरून थेट सर्व्हरवर वितरित करू.

व्हीपीएन

या समस्येचे निराकरण म्हणून, आम्ही VPN निवडले - विशेषतः वायरगार्ड.

सिस्टमच्या सुरूवातीस क्लायंट (स्कूटर्स) VPN सर्व्हरशी जोडलेले होते आणि त्यांच्याशी कनेक्ट करण्यात सक्षम होते. अपडेट देण्यासाठी या बोगद्याचा वापर करण्यात आला.

सिद्धांततः, समान बोगदा निरीक्षणासाठी वापरला जाऊ शकतो, परंतु असे कनेक्शन साध्या पुशपेक्षा अधिक क्लिष्ट आणि कमी विश्वासार्ह होते.

मेघ संसाधने

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

दिले

अरेरे, आम्ही वर्णन क्रमवारी लावले आहे असे दिसते, शेवटी आम्हाला काय हवे आहे याची यादी बनवूया:

• एक द्रुत उपाय, कारण विकास प्रक्रियेदरम्यान आधीच निरीक्षण करणे आवश्यक आहे
• व्हॉल्यूम/प्रमाण – अनेक मेट्रिक्स आवश्यक आहेत
• लॉग संग्रह आवश्यक आहे
• विश्वसनीयता - यश लॉन्च करण्यासाठी डेटा महत्त्वपूर्ण आहे
• आपण पुल मॉडेल वापरू शकत नाही - आपल्याला पुश आवश्यक आहे
• आम्हाला केवळ हार्डवेअरच नव्हे तर क्लाउडचे देखील एकत्रित निरीक्षण आवश्यक आहे

अंतिम प्रतिमा असे काहीतरी दिसत होती

स्टॅक निवड

तर, आम्हाला मॉनिटरिंग स्टॅक निवडण्याच्या प्रश्नाचा सामना करावा लागला.

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

सारख्या पूर्ण-प्रणालींपासून सुरू होणारी अनेक प्रकारचे मॉनिटरिंग सोल्यूशन्स आहेत Nagios, आयसिंगा किंवा झब्बीक्स आणि फ्लीट मॅनेजमेंटसाठी तयार केलेल्या उपायांसह समाप्त होते.

सुरुवातीला, नंतरचे आमच्यासाठी एक आदर्श उपाय असल्यासारखे वाटले, परंतु काहींचे पूर्ण निरीक्षण नव्हते, इतरांकडे विनामूल्य आवृत्त्यांची तीव्रपणे मर्यादित क्षमता होती आणि इतरांनी आमच्या "इच्छा" कव्हर केल्या नाहीत किंवा आमच्या परिस्थितींमध्ये बसण्यासाठी पुरेसे लवचिक नव्हते. काही फक्त कालबाह्य आहेत.

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

जवळजवळ निश्चितपणे, सर्व विपुल समाधानांमध्ये, आधीच एक रेडीमेड आहे जो आपल्यासाठी पूर्णपणे अनुकूल आहे, परंतु आमच्या बाबतीत एक विशिष्ट स्टॅक स्वतः एकत्र करणे आणि ते "स्वतःसाठी" सानुकूलित करणे खूप जलद होते. तयार उत्पादनांची चाचणी.

या सर्व गोष्टींसह, आम्ही स्वतः संपूर्ण मॉनिटरिंग प्लॅटफॉर्म एकत्र करण्याचा प्रयत्न केला नाही, परंतु सर्वात कार्यक्षम "रेडीमेड" स्टॅक शोधत होतो, फक्त त्यांना लवचिकपणे कॉन्फिगर करण्याच्या क्षमतेसह.

(B)ELK?

प्रत्यक्षात विचारात घेतलेला पहिला उपाय म्हणजे सुप्रसिद्ध ELK स्टॅक.
खरं तर, याला BELK म्हटले पाहिजे, कारण हे सर्व बीट्सपासून सुरू होते - https://www.elastic.co/what-is/elk-stack

अर्थात, ELK हे मॉनिटरिंगच्या क्षेत्रातील सर्वात प्रसिद्ध आणि शक्तिशाली उपायांपैकी एक आहे आणि त्याहूनही अधिक नोंदी गोळा करणे आणि त्यावर प्रक्रिया करणे.

आमचा हेतू होता की ELK चा वापर लॉग गोळा करण्यासाठी आणि तसेच Prometheus कडून मिळवलेल्या मेट्रिक्सच्या दीर्घकालीन स्टोरेजसाठी केला जाईल.

व्हिज्युअलायझेशनसाठी तुम्ही ग्राफन वापरू शकता.

खरं तर, नवीन ELK स्टॅक स्वतंत्रपणे मेट्रिक्स गोळा करू शकतो (मेट्रिकबीट), आणि किबाना देखील त्यांना प्रदर्शित करू शकतो.

परंतु तरीही, ELK सुरुवातीला लॉगमधून वाढले आणि आतापर्यंत मेट्रिक्सच्या कार्यक्षमतेमध्ये अनेक गंभीर कमतरता आहेत:

• Prometheus पेक्षा लक्षणीय हळू
• प्रोमिथियसपेक्षा खूपच कमी ठिकाणी समाकलित होते
• त्यांच्यासाठी अलर्ट सेट करणे कठीण आहे
• मेट्रिक्स खूप जागा घेतात
• Grafan पेक्षा किबानमध्ये मेट्रिक्ससह डॅशबोर्ड सेट करणे अधिक क्लिष्ट आहे

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

आणि ELK स्टॅकमध्येच अनेक कठीण क्षण आहेत:

• जर तुम्ही बर्‍यापैकी मोठ्या प्रमाणात डेटा संकलित केला तर ते जड आहे, काहीवेळा अगदी जड आहे
• आपल्याला ते "कसे शिजवायचे" हे माहित असणे आवश्यक आहे - आपल्याला ते मोजणे आवश्यक आहे, परंतु हे करणे क्षुल्लक नाही
• स्ट्रिप डाउन विनामूल्य आवृत्ती - विनामूल्य आवृत्तीमध्ये सामान्य सूचना नाही आणि निवडीच्या वेळी कोणतेही प्रमाणीकरण नव्हते

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

पण ज्या वेळी आम्ही हे उपाय तैनात करणार होतो, त्या वेळी अजिबात इशारा नव्हता.
कदाचित आम्ही ElastAlert किंवा इतर समुदाय उपाय वापरून काहीतरी तयार करण्याचा प्रयत्न करू शकलो असतो, परंतु तरीही आम्ही इतर पर्यायांचा विचार करण्याचा निर्णय घेतला.

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

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

दुर्दैवाने, प्रकल्पाच्या विक्री पायलटच्या प्रारंभाच्या वेळी (सप्टेंबर-ऑक्टोबर 19), लोकी अद्याप बीटा आवृत्ती 0.3-0.4 मध्ये होती आणि विकासाच्या प्रारंभाच्या वेळी ते उत्पादन उपाय म्हणून मानले जाऊ शकत नाही. अजिबात.

मला अद्याप गंभीर प्रकल्पांमध्ये लोकी वापरण्याचा अनुभव नाही, परंतु मी असे म्हणू शकतो की प्रॉमटेल (लॉग गोळा करण्यासाठी एक एजंट) बेअर-मेटल आणि कुबर्नेट्समधील पॉड्स दोन्हीसाठी उत्कृष्ट कार्य करते.

टिक

ELK स्टॅकसाठी कदाचित सर्वात योग्य (केवळ?) पूर्ण-वैशिष्ट्यपूर्ण पर्याय आता फक्त TICK स्टॅक - टेलीग्राफ, इन्फ्लक्सडीबी, क्रोनोग्राफ, कपॅसिटर असे म्हटले जाऊ शकते.

मी खाली सर्व घटकांचे अधिक तपशीलवार वर्णन करेन, परंतु सामान्य कल्पना ही आहे:

• टेलीग्राफ - मेट्रिक्स गोळा करण्यासाठी एजंट
• InfluxDB - मेट्रिक्स डेटाबेस
• कपॅसिटर - अलर्टिंगसाठी रिअल-टाइम मेट्रिक्स प्रोसेसर
• क्रोनोग्राफ - व्हिज्युअलायझेशनसाठी वेब पॅनेल

InfluxDB, Kapacitor आणि Chronograf साठी अधिकृत हेल्म चार्ट आहेत जे आम्ही ते तैनात करायचे.

हे लक्षात घ्यावे की इन्फ्लक्स 2.0 (बीटा) च्या नवीनतम आवृत्तीमध्ये, कपॅसिटर आणि क्रोनोग्राफ इन्फ्लक्सडीबीचा भाग बनले आहेत आणि यापुढे वेगळे अस्तित्वात नाहीत.

टेलीग्राफ

टेलीग्राफ राज्य मशीनवर मेट्रिक्स गोळा करण्यासाठी एक अतिशय हलका एजंट आहे.

तो सर्वकाही एक प्रचंड रक्कम निरीक्षण करू शकता, पासून nginx ते
सर्व्हर Minecraft.

त्याचे अनेक छान फायदे आहेत:

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

पुश मेट्रिक्स आमच्यासाठी आवश्यक असल्याने, इतर सर्व फायदे आनंददायी जोडण्यांपेक्षा जास्त होते.

एजंटद्वारे लॉग संग्रहित करणे देखील खूप सोयीचे आहे, कारण लॉगिंग लॉगसाठी अतिरिक्त उपयुक्तता जोडण्याची आवश्यकता नाही.

जर तुम्ही वापरत असाल तर लॉगसह काम करण्यासाठी Influx सर्वात सोयीस्कर अनुभव देते syslog.

जरी तुम्ही बाकीचा ICK स्टॅक वापरत नसला तरीही मेट्रिक्स गोळा करण्यासाठी Telegraf हा एक उत्तम एजंट आहे.

बरेच लोक सोयीसाठी ELK आणि इतर विविध वेळ-मालिका डेटाबेससह ते पार करतात, कारण ते जवळजवळ कुठेही मेट्रिक्स लिहू शकते.

InfluxDB

InfluxDB हा TICK स्टॅकचा मुख्य गाभा आहे, म्हणजे मेट्रिक्ससाठी टाइम-सीरीज डेटाबेस.
मेट्रिक्स व्यतिरिक्त, इन्फ्लक्स लॉग देखील संग्रहित करू शकते, जरी, थोडक्यात, त्यासाठीचे लॉग फक्त समान मेट्रिक्स आहेत, फक्त नेहमीच्या संख्यात्मक निर्देशकांऐवजी, मुख्य कार्य लॉग मजकूराच्या एका ओळीद्वारे केले जाते.

InfluxDB देखील Go मध्ये लिहिलेले आहे आणि आमच्या (सर्वात शक्तिशाली नाही) क्लस्टरवर ELK च्या तुलनेत खूप वेगाने चालत असल्याचे दिसते.

Influx च्या छान फायद्यांपैकी एक डेटा क्वेरीसाठी एक अतिशय सोयीस्कर आणि समृद्ध API देखील समाविष्ट करेल, ज्याचा आम्ही अतिशय सक्रियपणे वापर केला.

तोटे - $$$ किंवा स्केलिंग?

TICK स्टॅकमध्ये फक्त एक कमतरता आहे जी आम्ही शोधली - ती प्रिय. आणखी.

सशुल्क आवृत्तीमध्ये असे काय आहे जे विनामूल्य आवृत्तीमध्ये नाही?

जोपर्यंत आम्ही समजू शकलो, TICK स्टॅकच्या सशुल्क आवृत्ती आणि विनामूल्य आवृत्तीमधील फरक म्हणजे स्केलिंग क्षमता.

बहुदा, तुम्ही केवळ उच्च उपलब्धतेसह क्लस्टर वाढवू शकता एंटरप्राइझ आवृत्त्या.

तुम्हाला पूर्ण वाढ झालेला HA हवा असल्यास, तुम्हाला एकतर पैसे द्यावे लागतील किंवा काही क्रॅच वापरावे लागतील. काही सामुदायिक उपाय आहेत - उदाहरणार्थ influxdb-ha एक सक्षम समाधान दिसते, परंतु असे लिहिले आहे की ते उत्पादनासाठी योग्य नाही, तसेच
आवक - NATS द्वारे डेटा पंपिंगसह एक सोपा उपाय (हे देखील मोजावे लागेल, परंतु हे सोडवले जाऊ शकते).

ही खेदाची गोष्ट आहे, परंतु ते दोन्ही सोडून दिलेले दिसत आहेत - कोणतीही नवीन कमिट नाहीत, मी गृहित धरतो की समस्या ही इन्फ्लक्स 2.0 च्या नवीन आवृत्तीची लवकरच अपेक्षित रिलीज आहे, ज्यामध्ये बर्‍याच गोष्टी वेगळ्या असतील (त्याबद्दल कोणतीही माहिती नाही त्यात अजून स्केलिंग).

अधिकृतपणे एक विनामूल्य आवृत्ती आहे रिले - खरं तर, हे एक आदिम HA आहे, परंतु केवळ संतुलनाद्वारे,
सर्व डेटा लोड बॅलन्सरच्या मागे सर्व InfluxDB उदाहरणांवर लिहिला जाईल.
त्याच्याकडे काही आहेत तोटे जसे की ओव्हरराइटिंग पॉइंट्ससह संभाव्य समस्या आणि मेट्रिक्ससाठी अगोदर बेस तयार करण्याची आवश्यकता
(जे InfluxDB सह सामान्य कार्यादरम्यान स्वयंचलितपणे होते).

याशिवाय शार्डिंग समर्थित नाही, याचा अर्थ डुप्लिकेट मेट्रिक्ससाठी अतिरिक्त ओव्हरहेड (दोन्ही प्रक्रिया आणि स्टोरेज) ज्याची तुम्हाला आवश्यकता नसेल, परंतु त्यांना वेगळे करण्याचा कोणताही मार्ग नाही.

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

परिणामी, आम्ही सशुल्क स्केलिंग व्यतिरिक्त इतर सर्व गोष्टींमध्ये TICK स्टॅकवर पूर्णपणे समाधानी असलो तरीही, आम्ही उर्वरित T_CK घटक सोडताना, InfluxDB डेटाबेस पुनर्स्थित करू शकणारे कोणतेही विनामूल्य उपाय आहेत का ते पाहण्याचा निर्णय घेतला.

तेथे बरेच वेळ-मालिका डेटाबेस आहेत, परंतु सर्वात आशादायक म्हणजे व्हिक्टोरिया मेट्रिक्स, त्याचे बरेच फायदे आहेत:

• जलद आणि सोपे, किमान परिणामांनुसार बेंचमार्क
• एक क्लस्टर आवृत्ती आहे, ज्याबद्दल आता चांगली पुनरावलोकने आहेत
  • ती शार्ड करू शकते
• InfluxDB प्रोटोकॉलचे समर्थन करते

व्हिक्टोरियावर आधारित पूर्णपणे सानुकूल स्टॅक तयार करण्याचा आमचा हेतू नव्हता आणि मुख्य आशा होती की आम्ही ते InfluxDB साठी ड्रॉप-इन बदली म्हणून वापरू शकू.

दुर्दैवाने, हे शक्य नाही, InfluxDB प्रोटोकॉल समर्थित असूनही, ते केवळ मेट्रिक्स रेकॉर्ड करण्यासाठी कार्य करते - फक्त Prometheus API “बाहेर” उपलब्ध आहे, याचा अर्थ त्यावर क्रोनोग्राफ सेट करणे शक्य होणार नाही.

शिवाय, मेट्रिक्ससाठी फक्त संख्यात्मक मूल्ये समर्थित आहेत (आम्ही सानुकूल मेट्रिक्ससाठी स्ट्रिंग मूल्ये वापरली आहेत - विभागातील त्याबद्दल अधिक प्रशासन पॅनेल).

अर्थात, त्याच कारणास्तव, व्हीएम इन्फ्लक्सप्रमाणे लॉग संग्रहित करू शकत नाही.

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

बेस निवडणे

परिणामी, असे ठरवण्यात आले की पायलटसाठी आम्ही अद्याप एका InfluxDB नोडपर्यंत स्वतःला मर्यादित करू.

या निवडीची अनेक मुख्य कारणे होती:

• आम्हाला TICK स्टॅकची संपूर्ण कार्यक्षमता आवडली
• आम्ही ते आधीच उपयोजित करण्यात व्यवस्थापित केले आणि ते चांगले कार्य केले
• मुदत संपत आली होती आणि इतर पर्यायांची चाचणी घेण्यासाठी जास्त वेळ शिल्लक नव्हता.
• इतक्या मोठ्या भाराची आम्हाला अपेक्षा नव्हती

आमच्याकडे पायलटच्या पहिल्या टप्प्यासाठी अनेक स्कूटर नाहीत आणि विकासादरम्यान चाचणी करताना कोणत्याही कार्यप्रदर्शन समस्या उघड झाल्या नाहीत.

म्हणून, आम्ही ठरवले की या प्रकल्पासाठी एक इन्फ्लक्स नोड आमच्यासाठी स्केलिंगच्या गरजेशिवाय पुरेसा असेल (शेवटी निष्कर्ष पहा).

आम्ही स्टॅक आणि बेसवर निर्णय घेतला आहे - आता TICK स्टॅकच्या उर्वरित घटकांबद्दल.

कपॅसिटर

कपॅसिटर हा TICK स्टॅकचा भाग आहे, ही सेवा जी रिअल टाइममध्ये डेटाबेसमध्ये प्रवेश करणाऱ्या मेट्रिक्सचे निरीक्षण करू शकते आणि नियमांवर आधारित विविध क्रिया करू शकते.

सर्वसाधारणपणे, हे संभाव्य विसंगती ट्रॅकिंग आणि मशीन लर्निंगसाठी एक साधन म्हणून स्थित आहे (मला खात्री नाही की ही कार्ये मागणीत आहेत), परंतु त्याच्या वापराचे सर्वात लोकप्रिय प्रकरण अधिक सामान्य आहे - अलर्टिंग.

आम्ही ते सूचनांसाठी अशा प्रकारे वापरले. जेव्हा एखादी विशिष्ट स्कूटर ऑफलाइन जाते तेव्हा आम्ही स्लॅक अॅलर्ट सेट करतो आणि स्मार्ट चार्जर आणि महत्त्वाच्या पायाभूत घटकांसाठीही असेच केले जाते.

यामुळे समस्यांना त्वरीत प्रतिसाद देणे शक्य झाले, तसेच सर्व काही सामान्य झाल्याच्या सूचना प्राप्त झाल्या.

एक साधे उदाहरण: आमच्या "बॉक्स" ची उर्जा देण्यासाठी अतिरिक्त बॅटरी खराब झाली आहे किंवा काही कारणास्तव पॉवर संपली आहे; फक्त एक नवीन स्थापित करून, काही वेळानंतर आम्हाला एक सूचना प्राप्त होईल की स्कूटरची कार्यक्षमता पुनर्संचयित केली गेली आहे.

Influx 2.0 मध्ये कपॅसिटर DB चा भाग बनला

क्रोनोग्राफ

मी निरीक्षणासाठी अनेक भिन्न UI उपाय पाहिले आहेत, परंतु मी असे म्हणू शकतो की कार्यक्षमता आणि UX च्या बाबतीत, क्रोनोग्राफशी काहीही तुलना होत नाही.

आम्ही TICK स्टॅक वापरण्यास सुरुवात केली, विचित्रपणे, Grafan सह वेब इंटरफेस म्हणून.
मी त्याच्या कार्यक्षमतेचे वर्णन करणार नाही; प्रत्येकाला काहीही सेट करण्यासाठी त्याच्या विस्तृत शक्यता माहित आहेत.

तथापि, ग्रॅफना अजूनही पूर्णपणे सार्वत्रिक साधन आहे, तर क्रोनोग्राफ प्रामुख्याने इन्फ्लक्ससह वापरण्यासाठी डिझाइन केलेले आहे.

आणि अर्थातच, याबद्दल धन्यवाद, क्रोनोग्राफ अधिक हुशार किंवा सोयीस्कर कार्यक्षमता घेऊ शकते.

कदाचित क्रोनोग्राफसह काम करण्याची मुख्य सोय अशी आहे की तुम्ही एक्सप्लोरद्वारे तुमच्या इन्फ्लक्सडीबीचे आतील भाग पाहू शकता.

असे दिसते की ग्राफानामध्ये जवळजवळ एकसारखी कार्यक्षमता आहे, परंतु प्रत्यक्षात, क्रोनोग्राफमध्ये डॅशबोर्ड सेट करणे काही माऊस क्लिकसह केले जाऊ शकते (त्याचवेळी तेथे व्हिज्युअलायझेशन पहात), तर ग्राफानामध्ये आपल्याला अद्याप लवकरच किंवा नंतर मिळेल. JSON कॉन्फिगरेशन संपादित करण्यासाठी (अर्थातच क्रोनोग्राफ तुमच्या हाताने कॉन्फिगर केलेले डॅश अपलोड करण्याची आणि आवश्यक असल्यास JSON म्हणून संपादित करण्याची परवानगी देतो - परंतु UI वर तयार केल्यानंतर मला त्यांना कधीही स्पर्श करावा लागला नाही).

किबाना त्यांच्यासाठी डॅशबोर्ड आणि नियंत्रणे तयार करण्यासाठी खूप समृद्ध क्षमता आहेत, परंतु अशा ऑपरेशन्ससाठी UX खूप जटिल आहे.

सोयीस्कर डॅशबोर्ड तयार करण्यासाठी काही चांगली समज लागेल. आणि जरी क्रोनोग्राफ डॅशबोर्डची कार्यक्षमता कमी असली तरी, ते बनवणे आणि सानुकूल करणे खूप सोपे आहे.

आनंददायी व्हिज्युअल शैली व्यतिरिक्त डॅशबोर्ड स्वतः ग्राफाना किंवा किबाना मधील डॅशबोर्डपेक्षा वेगळे नाहीत:

क्वेरी विंडो असे दिसते:

इतर गोष्टींबरोबरच, हे लक्षात घेणे महत्त्वाचे आहे की, InfluxDB डेटाबेसमधील फील्डचे प्रकार जाणून घेतल्यास, क्रोनोग्राफ काहीवेळा आपोआप क्वेरी लिहिण्यात किंवा मध्यासारखे योग्य एकत्रीकरण कार्य निवडण्यात मदत करू शकते.

आणि अर्थातच, क्रोनोग्राफ लॉग पाहण्यासाठी शक्य तितके सोयीस्कर आहे. हे असे दिसते:

डीफॉल्टनुसार, इन्फ्लक्स लॉग हे सिस्लॉग वापरण्यासाठी तयार केले जातात आणि म्हणून त्यांच्याकडे एक महत्त्वाचा पॅरामीटर आहे - तीव्रता.

शीर्षस्थानी आलेख विशेषतः उपयुक्त आहे; त्यावर आपण त्रुटी पाहू शकता आणि तीव्रता जास्त असल्यास रंग लगेच स्पष्टपणे दर्शवितो.

गेल्या आठवड्यातील नोंदी पाहण्यासाठी आणि लाल स्पाइक दिसण्यासाठी, अशा प्रकारे काही वेळा आम्ही महत्त्वाचे बग पकडले.

अर्थात, आदर्शपणे अशा त्रुटींसाठी अलर्ट सेट करणे असेल, कारण आमच्याकडे यासाठी सर्वकाही आधीच होते.

आम्ही हे काही काळासाठी चालू देखील केले, परंतु पायलट तयार करण्याच्या प्रक्रियेत असे दिसून आले की आम्हाला बर्‍याच त्रुटी (एलटीई नेटवर्कची अनुपलब्धता सारख्या सिस्टमसह) येत आहेत, ज्यामुळे स्लॅक चॅनेल देखील "स्पॅम" झाले. जास्त, कोणतीही समस्या न आणता. मोठा फायदा.

यापैकी बहुतेक त्रुटी हाताळणे, त्यांची तीव्रता समायोजित करणे आणि त्यानंतरच अलर्टिंग सक्षम करणे हा योग्य उपाय असेल.

अशा प्रकारे, स्लॅकवर फक्त नवीन किंवा महत्त्वाच्या त्रुटी पोस्ट केल्या जातील. घट्ट मुदतीमुळे अशा सेटअपसाठी पुरेसा वेळ नव्हता.

प्रमाणीकरण

क्रोनोग्राफ OAuth आणि OIDC चे प्रमाणीकरण म्हणून समर्थन करते हे देखील नमूद करण्यासारखे आहे.

हे खूप सोयीस्कर आहे, कारण ते तुम्हाला तुमच्या सर्व्हरशी सहजपणे संलग्न करू देते आणि पूर्ण SSO तयार करू देते.

आमच्या बाबतीत, सर्व्हर होता कीक्लोक — हे मॉनिटरिंगशी कनेक्ट करण्यासाठी वापरले गेले होते, परंतु त्याच सर्व्हरचा वापर स्कूटर आणि बॅक-एंडच्या विनंत्या प्रमाणित करण्यासाठी देखील केला गेला.

"प्रशासक"

शेवटचा घटक ज्याचे मी वर्णन करेन ते Vue मधील आमचे स्व-लिखित "प्रशासक पॅनेल" आहे.
मुळात ही फक्त एक स्वतंत्र सेवा आहे जी आमच्या स्वतःच्या डेटाबेस, मायक्रोसर्व्हिसेस आणि InfluxDB वरील मेट्रिक्स डेटामधून स्कूटर माहिती एकाच वेळी प्रदर्शित करते.

याव्यतिरिक्त, अनेक प्रशासकीय कार्ये तेथे हलवली गेली, जसे की आपत्कालीन रीबूट किंवा समर्थन कार्यसंघासाठी दूरस्थपणे लॉक उघडणे.

नकाशेही होते. मी आधीच नमूद केले आहे की आम्ही क्रोनोग्राफ ऐवजी ग्राफानाने सुरुवात केली - कारण ग्राफना नकाशे प्लगइनच्या स्वरूपात उपलब्ध आहेत, ज्यावर आम्ही स्कूटरचे निर्देशांक पाहू शकतो. दुर्दैवाने, ग्राफानासाठी मॅप विजेटची क्षमता खूप मर्यादित आहे आणि परिणामी, काही दिवसात नकाशांसह तुमचा स्वतःचा वेब ऍप्लिकेशन लिहिणे खूप सोपे होते, जेणेकरुन या क्षणी केवळ निर्देशांकच दिसत नाहीत तर ते प्रदर्शित देखील केले जातील. स्कूटरने घेतलेला मार्ग, नकाशावरील डेटा फिल्टर करण्यात सक्षम व्हा, इ.

इन्फ्लक्सच्या आधीच नमूद केलेल्या फायद्यांपैकी एक म्हणजे आपले स्वतःचे मेट्रिक्स सहजपणे तयार करण्याची क्षमता.
हे त्यास विविध प्रकारच्या परिस्थितींसाठी वापरण्याची अनुमती देते.

आम्ही तेथे सर्व उपयुक्त माहिती रेकॉर्ड करण्याचा प्रयत्न केला: बॅटरी चार्ज, लॉक स्थिती, सेन्सर कार्यप्रदर्शन, ब्लूटूथ, GPS आणि इतर अनेक आरोग्य तपासणी.
आम्ही हे सर्व अॅडमिन पॅनलवर प्रदर्शित केले.

अर्थात, आमच्यासाठी सर्वात महत्त्वाचा निकष स्कूटरची ऑपरेटिंग स्थिती होती - खरं तर, इन्फ्लक्स हे स्वतः तपासते आणि नोड्स विभागात "हिरव्या दिवे" सह दर्शवते.

हे फंक्शनद्वारे केले जाते मृत मनुष्य — आम्ही ते आमच्या बॉक्सचे कार्यप्रदर्शन समजून घेण्यासाठी आणि तेच अलर्ट स्लॅकला पाठवण्यासाठी वापरले.

तसे, आम्ही द सिम्पसनमधील पात्रांच्या नावावरून स्कूटरचे नाव दिले - त्यांना एकमेकांपासून वेगळे करणे खूप सोयीचे होते

आणि सर्वसाधारणपणे या मार्गाने ते अधिक मजेदार होते. “Guys, Smithers is dead!” सारखी वाक्ये सतत ऐकायला मिळत होती.

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

हे महत्त्वाचे आहे की InfluxDB तुम्हाला व्हिक्टोरिया मेट्रिक्सच्या बाबतीत केवळ संख्यात्मक मूल्येच साठवण्याची परवानगी देत ​​नाही.

असे दिसते की हे इतके महत्त्वाचे नाही - सर्व केल्यानंतर, लॉग व्यतिरिक्त, कोणतेही मेट्रिक्स संख्यांच्या स्वरूपात संग्रहित केले जाऊ शकतात (फक्त ज्ञात राज्यांसाठी मॅपिंग जोडा - एक प्रकारचा एनम)?

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

परिणामी, चार्जिंग API आदर्शपासून दूर होते, परंतु मुख्य समस्या अशी होती की आम्ही त्यांची स्थिती नेहमी समजू शकत नाही.

येथेच इन्फ्लक्स बचावासाठी आला. आम्ही फक्त बदल न करता InfluxDB डेटाबेस फील्डमध्ये आमच्याकडे आलेली स्ट्रिंग स्थिती लिहिली.

काही काळासाठी, फक्त "ऑनलाइन" आणि "ऑफलाइन" सारखी मूल्ये तेथे आली, ज्याच्या आधारावर आमच्या प्रशासक पॅनेलमध्ये माहिती प्रदर्शित केली गेली आणि स्लॅकला सूचना पाठवल्या गेल्या. तथापि, काही क्षणी, "डिस्कनेक्ट" सारखी मूल्ये देखील तेथे दिसू लागली.

हे नंतर दिसून आले की, ही स्थिती कनेक्शन गमावल्यानंतर एकदा पाठविली गेली, जर चार्जर काही प्रयत्नांनंतर सर्व्हरशी कनेक्शन स्थापित करू शकला नाही.

अशा प्रकारे, जर आम्ही मूल्यांचा एक निश्चित संच वापरला तर, आम्हाला फर्मवेअरमध्ये हे बदल योग्य वेळी दिसणार नाहीत.

आणि सर्वसाधारणपणे, स्ट्रिंग मेट्रिक्स वापरण्यासाठी अधिक शक्यता प्रदान करतात; आपण त्यांच्यामध्ये अक्षरशः कोणतीही माहिती रेकॉर्ड करू शकता. जरी, नक्कीच, आपल्याला हे साधन काळजीपूर्वक वापरण्याची देखील आवश्यकता आहे.

नेहमीच्या मेट्रिक्स व्यतिरिक्त, आम्ही InfluxDB मध्ये GPS स्थान माहिती देखील रेकॉर्ड केली. आमच्या अॅडमिन पॅनेलमधील स्कूटरच्या स्थानाचे परीक्षण करण्यासाठी हे आश्चर्यकारकपणे उपयुक्त होते.
खरं तर, आपल्याला आवश्यक त्या क्षणी कुठे आणि कोणती स्कूटर आहे हे आम्हाला नेहमीच माहित होते.

जेव्हा आम्ही स्कूटर शोधत होतो तेव्हा हे आमच्यासाठी खूप उपयुक्त होते (शेवटी निष्कर्ष पहा).

पायाभूत सुविधांचे निरीक्षण

स्वतः स्कूटर व्यतिरिक्त, आम्हाला आमच्या संपूर्ण (त्याऐवजी व्यापक) पायाभूत सुविधांचे निरीक्षण करणे देखील आवश्यक होते.

एक अतिशय सामान्य आर्किटेक्चर असे काहीतरी दिसले:

आम्ही शुद्ध मॉनिटरिंग स्टॅक हायलाइट केल्यास, ते असे दिसते:

आम्ही क्लाउडमध्ये काय तपासू इच्छितो:

• डेटाबेस
• कीक्लोक
• सूक्ष्म सेवा

आमच्या सर्व क्लाउड सेवा Kubernetes मध्ये स्थित असल्याने, त्याच्या स्थितीबद्दल माहिती गोळा करणे चांगले होईल.

सुदैवाने, बॉक्सच्या बाहेर टेलीग्राफ कुबर्नेट्स क्लस्टरच्या स्थितीबद्दल मोठ्या संख्येने मेट्रिक्स गोळा करू शकते आणि क्रोनोग्राफ यासाठी त्वरित सुंदर डॅशबोर्ड ऑफर करते.

आम्ही प्रामुख्याने शेंगा आणि मेमरी वापराच्या कामगिरीचे परीक्षण केले. पडल्यास, स्लॅकमध्ये अलर्ट.

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

आम्ही टेलीग्राफ साइडकार वापरला आणि मेट्रिक्स व्यतिरिक्त, पॉड लॉग गोळा केले.

आमच्या बाबतीत, आम्हाला लॉगसह टिंकर करावे लागले. टेलीग्राफ डॉकर एपीआय मधून लॉग काढू शकते हे असूनही, आम्हाला आमच्या शेवटच्या उपकरणांसह लॉगचा एकसमान संग्रह हवा होता आणि त्यासाठी कंटेनरसाठी सिस्लॉग कॉन्फिगर केले होते. कदाचित हे समाधान सुंदर नव्हते, परंतु त्याच्या कार्याबद्दल कोणतीही तक्रार नव्हती आणि क्रोनोग्राफमध्ये लॉग चांगले प्रदर्शित केले गेले.

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

सरतेशेवटी, मॉनिटरिंग सिस्टमचे निरीक्षण करण्याचा जुना प्रश्न उद्भवला, परंतु सुदैवाने, किंवा दुर्दैवाने, आमच्याकडे यासाठी पुरेसा वेळ नव्हता.

जरी टेलीग्राफ सहजपणे स्वतःचे मेट्रिक्स पाठवू शकते किंवा इन्फ्लक्सडीबी डेटाबेसमधून समान इन्फ्लक्स किंवा इतरत्र पाठवण्यासाठी मेट्रिक्स गोळा करू शकते.

निष्कर्ष

पायलटच्या निकालांवरून आम्ही कोणते निष्कर्ष काढले?

आपण निरीक्षण कसे करू शकता?

सर्वप्रथम, TICK स्टॅकने आमच्या अपेक्षा पूर्ण केल्या आणि आम्हाला सुरुवातीला अपेक्षा केल्यापेक्षा अधिक संधी दिल्या.

आम्हाला आवश्यक असलेली सर्व कार्यक्षमता उपस्थित होती. आम्ही यासह जे काही केले ते कोणत्याही समस्यांशिवाय कार्य केले.

उत्पादकता

विनामूल्य आवृत्तीमध्ये TICK स्टॅकची मुख्य समस्या स्केलिंग क्षमतांची कमतरता आहे. आमच्यासाठी ही समस्या नव्हती.

आम्ही अचूक लोड डेटा/आकडे गोळा केले नाहीत, परंतु आम्ही एका वेळी सुमारे 30 स्कूटरमधून डेटा गोळा केला.

त्यांच्यापैकी प्रत्येकाने तीन डझनपेक्षा जास्त मेट्रिक्स गोळा केल्या. त्याच वेळी, डिव्हाइसेसमधून लॉग गोळा केले गेले. डेटा संकलन आणि पाठवणे दर 10 सेकंदांनी होते.

हे लक्षात घेणे महत्वाचे आहे की पायलटच्या दीड आठवड्यांनंतर, जेव्हा "बालपणीच्या समस्या" मोठ्या प्रमाणात दुरुस्त केल्या गेल्या आणि सर्वात महत्वाच्या समस्यांचे आधीच निराकरण केले गेले, तेव्हा आम्हाला सर्व्हरवर डेटा पाठविण्याची वारंवारता कमी करावी लागली. 30 सेकंद. हे आवश्यक झाले कारण आमच्या LTE सिम कार्डवरील रहदारी त्वरीत अदृश्य होऊ लागली.

मोठ्या प्रमाणात रहदारी लॉगद्वारे वापरली गेली; स्वतः मेट्रिक्स, अगदी 10-सेकंद मध्यांतराने, व्यावहारिकरित्या ते वाया घालवले नाही.

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

काही प्रकरणांमध्ये, लॉग पाहणे अद्याप आवश्यक असल्यास, आम्ही फक्त वायरगार्डद्वारे VPN द्वारे कनेक्ट केले.

मी हे देखील जोडेन की प्रत्येक स्वतंत्र वातावरण एकमेकांपासून वेगळे केले गेले होते आणि वर वर्णन केलेले लोड केवळ उत्पादन वातावरणासाठी संबंधित होते.

डेव्हलपमेंट वातावरणात, आम्ही एक वेगळा InfluxDB उदाहरण तयार केला जो दर 10 सेकंदांनी डेटा संकलित करत राहिला आणि आम्हाला कोणत्याही कार्यप्रदर्शन समस्यांना सामोरे जावे लागले नाही.

TICK - लहान-मध्यम प्रकल्पांसाठी आदर्श

या माहितीच्या आधारे, मी असा निष्कर्ष काढतो की TICK स्टॅक तुलनेने लहान प्रकल्पांसाठी किंवा निश्चितपणे कोणत्याही हायलोडची अपेक्षा नसलेल्या प्रकल्पांसाठी आदर्श आहे.

तुमच्याकडे हजारो पॉड्स किंवा शेकडो मशीन्स नसल्यास, अगदी एक InfluxDB उदाहरण देखील भार अगदी व्यवस्थित हाताळेल.

काही प्रकरणांमध्ये, आपण प्राथमिक उच्च उपलब्धता समाधान म्हणून इन्फ्लक्स रिलेसह समाधानी असू शकता.

आणि, अर्थातच, तुम्हाला "उभ्या" स्केलिंग सेट करण्यापासून आणि वेगवेगळ्या प्रकारच्या मेट्रिक्ससाठी भिन्न सर्व्हर वाटप करण्यापासून कोणीही रोखत नाही.

जर तुम्हाला देखरेख सेवांवर अपेक्षित लोड बद्दल खात्री नसेल, किंवा तुमच्याकडे खूप "भारी" आर्किटेक्चर असण्याची/असण्याची हमी असेल, तर मी TICK स्टॅकची विनामूल्य आवृत्ती वापरण्याची शिफारस करणार नाही.

अर्थात, खरेदी करणे हा एक सोपा उपाय असेल InfluxDB Enterprise - परंतु येथे मी कसा तरी भाष्य करू शकत नाही, कारण मी स्वत: सूक्ष्मतेशी परिचित नाही. याशिवाय ते खूप महाग आहे आणि लहान कंपन्यांसाठी निश्चितपणे योग्य नाही.

या प्रकरणात, आज मी लोकी वापरून व्हिक्टोरिया मेट्रिक्स आणि लॉगद्वारे मेट्रिक्स गोळा करण्याच्या दिशेने पाहण्याची शिफारस करतो.

खरे आहे, मी पुन्हा एक आरक्षण करेन की लोकी/ग्राफाना तयार TICK पेक्षा कमी सोयीस्कर आहेत (त्यांच्या अष्टपैलुत्वामुळे), परंतु ते विनामूल्य आहेत.

महत्वाचे: येथे वर्णन केलेली सर्व माहिती इन्फ्लक्स 1.8 आवृत्तीसाठी संबंधित आहे, ज्या क्षणी Influx 2.0 रिलीज होणार आहे.

मला लढाईच्या परिस्थितीत प्रयत्न करण्याची संधी मिळाली नाही आणि सुधारणांबद्दल निष्कर्ष काढणे कठीण आहे, इंटरफेस नक्कीच अधिक चांगला झाला आहे, आर्किटेक्चर सरलीकृत केले गेले आहे (कॅपॅसिटर आणि क्रोनोग्राफशिवाय),
टेम्पलेट दिसू लागले ("किलर वैशिष्ट्य" - तुम्ही Fortnite मध्ये खेळाडूंचा मागोवा घेऊ शकता आणि तुमचा आवडता खेळाडू गेम जिंकल्यावर सूचना मिळवू शकता). परंतु, दुर्दैवाने, याक्षणी, आवृत्ती 2 मध्ये मुख्य गोष्ट नाही ज्यासाठी आम्ही पहिली आवृत्ती निवडली - कोणतेही लॉग संग्रह नाही.

ही कार्यक्षमता Influx 2.0 मध्ये देखील दिसून येईल, परंतु आम्हाला कोणतीही अंतिम मुदत सापडली नाही, अगदी अंदाजे.

IoT प्लॅटफॉर्म कसे बनवायचे नाही (आता)

सरतेशेवटी, पायलट लाँच केल्यावर, आमच्या मानकांनुसार योग्य पर्याय नसताना आम्ही स्वतः आमचा पूर्ण वाढ झालेला IoT स्टॅक एकत्र केला.

तथापि, अलीकडे ते बीटा आवृत्तीमध्ये उपलब्ध आहे उघडेबाळेना - आम्ही प्रोजेक्ट बनवायला सुरुवात केली तेव्हा ती तिथे नव्हती ही खेदाची गोष्ट आहे.

अंतिम परिणाम आणि आम्ही स्वतः एकत्र केलेल्या Ansible + TICK + WireGuard वर आधारित प्लॅटफॉर्मवर आम्ही पूर्णपणे समाधानी आहोत. परंतु आज, मी स्वतःचे स्वतःचे आयओटी प्लॅटफॉर्म तयार करण्याचा प्रयत्न करण्यापूर्वी बलेनाकडे जवळून पाहण्याची शिफारस करतो.

कारण शेवटी आम्ही जे काही केले ते बहुतेक ते करू शकते आणि OpenBalena विनामूल्य आणि मुक्त स्रोत आहे.

केवळ अद्यतने कशी पाठवायची हे आधीच माहित नाही, तर व्हीपीएन देखील आधीच तयार केले आहे आणि IoT वातावरणात वापरण्यासाठी तयार केले आहे.

आणि अलीकडेच, त्यांनी त्यांचे प्रकाशन देखील केले हार्डवेअर, जे त्यांच्या इकोसिस्टमशी सहजपणे जोडते.

अहो, हरवलेल्या स्कूटरचे काय?

त्यामुळे ‘राल्फ’ ही स्कूटर कोणताही मागमूस न घेता गायब झाली.

InfluxDB कडील GPS मेट्रिक्स डेटासह आम्ही आमच्या “प्रशासक पॅनेल” मधील नकाशा पाहण्यासाठी लगेच धावलो.

डेटाचे निरीक्षण केल्याबद्दल धन्यवाद, आम्ही सहज ठरवले की स्कूटरने गेल्या दिवशी 21:00 च्या सुमारास पार्किंग लॉट सोडला, काही भागात सुमारे अर्धा तास गाडी चालवली आणि काही जर्मन घराजवळ पहाटे 5 वाजेपर्यंत पार्क केली गेली.

पहाटे 5 नंतर, कोणताही मॉनिटरिंग डेटा प्राप्त झाला नाही - याचा अर्थ एकतर अतिरिक्त बॅटरी पूर्णपणे डिस्चार्ज झाली किंवा आक्रमणकर्त्याने शेवटी स्कूटरमधून स्मार्ट हार्डवेअर कसे काढायचे ते शोधून काढले.
असे असतानाही स्कूटर ज्या पत्त्यावर होती त्या पत्त्यावर पोलिसांना बोलावण्यात आले. स्कूटर तिथे नव्हती.

मात्र, काल रात्री ऑफिसमधून ही स्कूटर घरी घेऊन आल्याने घरमालकही आश्चर्यचकित झाला.

असे झाले की, सपोर्ट कर्मचार्‍यांपैकी एक सकाळी लवकर आला आणि त्याने स्कूटर उचलली, त्याची अतिरिक्त बॅटरी पूर्णपणे डिस्चार्ज झाली आहे आणि ती (पायातून) पार्किंगच्या ठिकाणी नेली. आणि आर्द्रतेमुळे अतिरिक्त बॅटरी अयशस्वी झाली.

आम्ही स्वतःहून स्कूटर चोरली. तसे, मला माहित नाही की नंतर पोलिस केसमधील समस्येचे निराकरण कसे आणि कोणी केले, परंतु मॉनिटरिंगने उत्तम प्रकारे कार्य केले ...

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