हराएको स्कूटर फिर्ता गर्नुहोस्, वा एउटा IoT निगरानीको कथा

एक वर्ष पहिले हामीले प्रचारात्मक परियोजनाको लागि पायलट संस्करण सुरु गर्यौं इलेक्ट्रिक स्कुटरको विकेन्द्रीकृत भाडा.

सुरुमा, परियोजनालाई रोड-टू-बार्सिलोना भनिन्थ्यो, पछि यो रोड-टू-बर्लिन भयो (यसैले स्क्रिनसटहरूमा R2B), र अन्तमा यसलाई xRide भनिन्थ्यो।

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

प्रारम्भमा, परियोजनाले कारहरूमा ध्यान केन्द्रित गर्यो, तर समयसीमा, निर्माताहरूसँग धेरै लामो सञ्चार र सुरक्षा प्रतिबन्धहरूको ठूलो संख्याको कारणले, पायलटको लागि इलेक्ट्रिक स्कूटरहरू छनौट गरियो।

प्रयोगकर्ताले फोनमा आईओएस वा एन्ड्रोइड अनुप्रयोग स्थापना गर्यो, उसलाई मनपर्ने स्कूटरमा पुग्यो, त्यसपछि फोन र स्कूटरले पियर-टु-पियर जडान स्थापित गर्यो, ETH आदानप्रदान भयो र प्रयोगकर्ताले स्कूटर खोलेर सवारी सुरु गर्न सक्थे। फोन। यात्राको अन्त्यमा, फोनमा प्रयोगकर्ताको वालेटबाट Ethereum प्रयोग गरेर यात्राको लागि भुक्तान गर्न पनि सम्भव थियो।

स्कूटरको अतिरिक्त, प्रयोगकर्ताले एपमा "स्मार्ट चार्जरहरू" देखे, जसलाई भ्रमण गरेर प्रयोगकर्ताले हालको ब्याट्री कम भएमा आफैं परिवर्तन गर्न सक्छ।

यो सामान्यतया हाम्रो पाइलट जस्तो देखिन्छ, गत वर्ष सेप्टेम्बरमा दुई जर्मन शहरहरू: बोन र बर्लिनमा लन्च गरियो।

र त्यसपछि, एक दिन, बोनमा, बिहान सबेरै, हाम्रो समर्थन टोली (कार्यक्रममा स्कूटरहरू कायम राख्न साइटमा अवस्थित) लाई सचेत गरियो: एउटा स्कूटर बिना ट्रेस हराएको थियो।

कसरी फेला पार्ने र फिर्ता गर्ने?

यस लेखमा म यसको बारेमा कुरा गर्नेछु, तर पहिले - हामीले हाम्रो आफ्नै IoT प्लेटफर्म कसरी बनायौं र हामीले यसलाई कसरी निगरानी गर्यौं भन्ने बारे।

के र किन अनुगमन गर्ने: स्कूटर, पूर्वाधार, चार्जिङ स्टेशनहरू?

त्यसोभए, हामीले हाम्रो परियोजनामा ​​​​के अनुगमन गर्न चाहन्थ्यौं?

सबैभन्दा पहिले, यी स्कूटरहरू आफैं हुन् - इलेक्ट्रिक स्कूटरहरू आफैंमा धेरै महँगो हुन्छन्, तपाईं पर्याप्त रूपमा तयार नगरी यस्तो परियोजना सुरु गर्न सक्नुहुन्न; यदि सम्भव छ भने, तपाईं स्कूटरहरूको बारेमा सकेसम्म धेरै जानकारी सङ्कलन गर्न चाहनुहुन्छ: तिनीहरूको स्थान, चार्ज स्तर बारे। , आदि

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

स्कुटर

हाम्रा स्कुटरहरू के थिए र हामी तिनीहरूको बारेमा के जान्न चाहन्छौं?

पहिलो र सबैभन्दा महत्त्वपूर्ण कुरा जीपीएस समन्वयहरू हो, किनकि तिनीहरूको लागि धन्यवाद हामी तिनीहरू कहाँ छन् र तिनीहरू कहाँ सर्दै छन् भनेर बुझ्न सक्छौं।

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

अवश्य पनि, हाम्रो हार्डवेयर कम्पोनेन्टहरूसँग के भइरहेको छ भनेर जाँच गर्न पनि आवश्यक छ:

• ब्लुटुथ काम गर्छ?
• के जीपीएस मोड्युल आफैले काम गर्छ?
  • हामीलाई GPS ले गलत निर्देशांकहरू पठाउन र अड्किएको तथ्यसँग पनि समस्या थियो, र यो स्कूटरमा थप जाँचहरूद्वारा मात्र निर्धारण गर्न सकिन्छ,
    र समस्या समाधान गर्न सकेसम्म चाँडो समर्थन सूचित गर्नुहोस्

र अन्तमा: सफ्टवेयरको जाँचहरू, OS र प्रोसेसरबाट सुरु हुँदै, नेटवर्क र डिस्क लोड, हाम्रा आफ्नै मोड्युलहरूको जाँचहरूसँग समाप्त हुन्छ जुन हामीलाई थप विशिष्ट छन् (Jolocom, किक्लोक).

हार्डवेयर

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

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

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

यसले अनुगमन प्रयोग गर्न र यात्राको अन्त्य पछि पनि स्कूटर खोल्न सम्भव बनायो, किनकि मुख्य ब्याट्रीलाई "बन्द" स्थितिमा इग्निशन कुञ्जी बदले पछि तुरुन्तै बन्द गरिएको थियो।

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

अनुगमनमा फर्कौं, त्यसैले रास्पबेरी - हामीसँग के छ?

भौतिक उपकरणहरूमा कम्पोनेन्टहरू डिप्लोइ, अपडेट गर्ने र डेलिभर गर्ने प्रक्रियालाई गति दिन हामीले प्रयोग गर्न चाहेको पहिलो चीजहरू मध्ये एक डकर थियो।

दुर्भाग्यवश, यो छिट्टै स्पष्ट भयो कि RPi मा डकर, यद्यपि यसले काम गर्दछ, धेरै ओभरहेड छ, विशेष गरी पावर खपतको सन्दर्भमा।

"नेटिभ" OS प्रयोग गर्ने भिन्नता, यद्यपि त्यति बलियो नभए पनि, चाँडै चार्ज गुमाउने सम्भावनाबाट सावधान रहन हामीलाई पर्याप्त थियो।

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

पुस्तकालयका लेखकहरूसँग कुनै पनि "स्थानीय" भाषाहरूमा काम गर्ने संस्करण उपलब्ध गराउन समय थिएन।

नोड आफैंमा कम प्रदर्शन यन्त्रहरूको लागि सबैभन्दा सुन्दर समाधान होइन, तर पुस्तकालय आफैंमा धेरै संसाधन-भोको थियो।

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

OS

नतिजाको रूपमा, हामीले फेरि, OS को रूपमा सरल विकल्प रोज्यौं र Raspbian (Pi को लागि डेबियन निर्माण) प्रयोग गर्‍यौं।

हामी हाम्रा सबै सफ्टवेयर Go मा लेख्छौं, त्यसैले हामीले Go मा हाम्रो प्रणालीमा मुख्य हार्डवेयर एजेन्ट मोड्युल पनि लेख्यौं।

जीपीएस, ब्लुटुथ, चार्ज पढ्ने, स्कुटर अन गर्ने आदि काम गर्ने जिम्मेवारी उहाँ नै हो।

तैनाथ गर्नुहोस्

यन्त्रहरू (OTA) मा अद्यावधिकहरू डेलिभर गर्नको लागि एउटा संयन्त्र लागू गर्ने आवश्यकताको बारेमा प्रश्न तुरुन्तै उठ्यो - दुबै हाम्रो एजेन्ट/एप्लिकेशनमा अद्यावधिकहरू, र OS/फर्मवेयरमा अद्यावधिकहरू (एजेन्टको नयाँ संस्करणहरूले कर्नेलमा अद्यावधिकहरू आवश्यक हुन सक्छ। वा प्रणाली कम्पोनेन्टहरू, पुस्तकालयहरू, आदि)।

बजारको धेरै लामो विश्लेषण पछि, यो पत्ता लाग्यो कि त्यहाँ उपकरणमा अद्यावधिकहरू प्रदान गर्नका लागि धेरै समाधानहरू छन्।

अपेक्षाकृत सरल देखि, अधिकतर अपडेट/डुअल-बुट उन्मुख उपयोगिताहरू जस्तै swupd/SWUpdate/OSTree पूर्ण-मण्डर र बलेना जस्ता प्लेटफर्महरूमा।

सबैभन्दा पहिले, हामीले निर्णय गर्यौं कि हामी अन्त्य-देखि-अन्त समाधानहरूमा रुचि राख्छौं, त्यसैले छनोट तुरुन्तै प्लेटफर्महरूमा पर्यो।

आफैं बलेना यो वास्तवमा यसको balenaEngine भित्र उही डकर प्रयोग गर्दछ भन्ने तथ्यको कारण बहिष्कार गरिएको थियो।

तर म नोट गर्छु कि यसको बावजुद, हामीले तिनीहरूको उत्पादन निरन्तर प्रयोग गरिरह्यौं बलेना ईचर SD कार्डहरूमा फ्ल्यास फर्मवेयरको लागि - यसको लागि एक सरल र अत्यन्त सुविधाजनक उपयोगिता।

त्यसकारण, अन्तिममा छनोट भयो मेन्डर। मेन्डर फर्मवेयर भेला, वितरण र स्थापनाको लागि एक पूर्ण प्लेटफर्म हो।

समग्रमा प्लेटफर्म राम्रो देखिन्छ, तर यसले मेन्डर बिल्डर प्रयोग गरेर हाम्रो फर्मवेयरको सही संस्करण निर्माण गर्न लगभग डेढ हप्ता लियो।
र जति धेरै हामीले यसको प्रयोगको जटिलताहरूमा आफूलाई डुब्यौं, त्यति नै यो स्पष्ट भयो कि यसलाई पूर्ण रूपमा प्रयोग गर्न हामीलाई हामीसँग भएको भन्दा धेरै समय चाहिन्छ।

काश, हाम्रो कडा समयसीमाको मतलब हामी मेन्डरको प्रयोग त्याग्न र अझ सरल छनौट गर्न बाध्य भयौं।

अज्ञात

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

तिनीहरूको सार यो थियो कि हामीले होस्ट (CI सर्भर) बाट ssh मार्फत हाम्रो rasberries मा जडान गर्यौं र तिनीहरूलाई अद्यावधिकहरू वितरण गर्यौं।

सुरुमा, सबै कुरा सरल थियो - तपाईं यन्त्रहरूसँग एउटै नेटवर्कमा हुनुपर्दछ, वाइफाइ मार्फत खन्याइयो।

कार्यालयमा त्यहाँ एक दर्जन परीक्षण रास्पबेरीहरू एउटै नेटवर्कमा जडान भएका थिए, प्रत्येक उपकरणको स्थिर आईपी ठेगाना पनि उत्तरदायी सूचीमा निर्दिष्ट गरिएको थियो।

यो Ansible थियो जसले हाम्रो निगरानी एजेन्टलाई अन्तिम उपकरणहरूमा डेलिभर गर्यो

3G / एलटीई

दुर्भाग्यवश, Ansible को लागि यो प्रयोग केसले हामीसँग वास्तविक स्कूटरहरू हुनु अघि मात्र विकास मोडमा काम गर्न सक्छ।

किनभने स्कुटरहरू, तपाईंले बुझ्नुभएको रूपमा, एक Wi-Fi राउटरमा जडान गरी नबस्नुहोस्, नेटवर्कमा अद्यावधिकहरूको लागि निरन्तर पर्खनुहोस्।

वास्तवमा, स्कूटरहरूमा मोबाइल 3G/LTE बाहेक अन्य कुनै पनि जडान हुन सक्दैन (र त्यसपछि पनि सबै समय होइन)।

यसले तुरुन्तै धेरै समस्या र सीमितताहरू लगाउँछ, जस्तै कम जडान गति र अस्थिर संचार।

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

यो आंशिक रूपमा केहि SIM कार्ड प्रदायकहरू द्वारा हल गरिएको छ; त्यहाँ स्थिर IP ठेगानाहरू भएका IoT यन्त्रहरूका लागि डिजाइन गरिएका विशेष SIM कार्डहरू पनि छन्। तर हामीसँग त्यस्ता सिम कार्डहरूमा पहुँच थिएन र आईपी ठेगानाहरू प्रयोग गर्न सकेनौं।

निस्सन्देह, त्यहाँ कन्सुल जस्तै कतै IP ठेगानाहरू उर्फ ​​सेवा खोजको दर्ता गर्ने विचारहरू थिए, तर हामीले त्यस्ता विचारहरू त्याग्नुपर्छ, किनकि हाम्रो परीक्षणहरूमा IP ठेगाना धेरै पटक परिवर्तन हुन सक्छ, जसले ठूलो अस्थिरता निम्त्याउँछ।

यस कारणका लागि, मेट्रिक्स डेलिभर गर्नको लागि सबैभन्दा सुविधाजनक प्रयोग पुल मोडेल प्रयोग गर्दैन, जहाँ हामी आवश्यक मेट्रिक्सका लागि उपकरणहरूमा जान्छौं, तर धक्का, मेट्रिक्स यन्त्रबाट सीधा सर्भरमा डेलिभर गर्दै।

VPN

यस समस्याको समाधानको रूपमा, हामीले VPN रोज्यौं - विशेष गरी ताररक्षक.

प्रणालीको सुरुमा ग्राहकहरू (स्कूटरहरू) VPN सर्भरमा जडान भएका थिए र उनीहरूसँग जडान गर्न सक्षम थिए। यो सुरुङ अद्यावधिकहरू प्रदान गर्न प्रयोग गरिएको थियो।

सिद्धान्तमा, एउटै सुरुङ निगरानीको लागि प्रयोग गर्न सकिन्छ, तर यस्तो जडान सरल धक्का भन्दा बढी जटिल र कम भरपर्दो थियो।

क्लाउड स्रोतहरू

अन्तमा, हाम्रा क्लाउड सेवाहरू र डाटाबेसहरू अनुगमन गर्न आवश्यक छ, किनकि हामी तिनीहरूका लागि Kubernetes प्रयोग गर्छौं, आदर्श रूपमा ताकि क्लस्टरमा अनुगमन गर्न सकेसम्म सरल होस्। आदर्श रूपमा, प्रयोग गर्दै हेलमेट, जब देखि तैनाती को लागी, हामी यसलाई धेरै अवस्थामा प्रयोग गर्छौं। र, निस्सन्देह, क्लाउड निगरानी गर्न तपाईंले स्कूटरहरू आफैंको लागि समान समाधानहरू प्रयोग गर्न आवश्यक छ।

दिएको छ

ओफ, हामीले विवरणलाई क्रमबद्ध गरिसकेका छौँ, अन्तमा हामीलाई के चाहिन्छ भनेर सूची बनाउनुहोस्:

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

अन्तिम छवि यस्तो देखियो

स्ट्याक चयन

त्यसोभए, हामीले अनुगमन स्ट्याक छनौट गर्ने प्रश्नको सामना गर्यौं।

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

त्यहाँ धेरै प्रकारका निगरानी समाधानहरू छन्, जस्तै पूर्ण विकसित प्रणालीहरूबाट सुरु हुँदै Nagios, आईसिंगा वा zabbih र फ्लीट व्यवस्थापनको लागि तयार समाधानहरूको साथ समाप्त हुन्छ।

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

धेरै समान समाधानहरू विश्लेषण गरेपछि, हामी तुरुन्तै निष्कर्षमा पुग्यौं कि समान स्ट्याक आफैंलाई भेला गर्न सजिलो र छिटो हुनेछ। हो, यो पूर्ण रूपमा तयार-निर्मित फ्लीट व्यवस्थापन प्लेटफर्म तैनात गर्नु भन्दा अलि बढी जटिल हुनेछ, तर हामीले सम्झौता गर्नुपर्दैन।

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

यी सबैको साथ, हामीले सम्पूर्ण निगरानी प्लेटफर्म आफैंलाई भेला गर्न कोसिस गरेनौं, तर सबैभन्दा कार्यात्मक "रेडी-मेड" स्ट्याकहरू खोजिरहेका थियौं, केवल तिनीहरूलाई लचिलो रूपमा कन्फिगर गर्ने क्षमताको साथ।

(B) ELK?

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

निस्सन्देह, ELK अनुगमनको क्षेत्रमा सबैभन्दा प्रसिद्ध र शक्तिशाली समाधानहरू मध्ये एक हो, र अझ धेरै लगहरू सङ्कलन र प्रशोधनमा।

हामीले ELK लगहरू सङ्कलन गर्न र साथै प्रोमिथियसबाट प्राप्त मेट्रिक्सको दीर्घकालीन भण्डारण गर्न प्रयोग गरिने उद्देश्य राखेका थियौं।

तपाईं दृश्यका लागि Grafan प्रयोग गर्न सक्नुहुन्छ।

वास्तवमा, नयाँ ELK स्ट्याकले मेट्रिकहरू स्वतन्त्र रूपमा सङ्कलन गर्न सक्छ (मेट्रिकबिट), र किबानाले पनि तिनीहरूलाई प्रदर्शन गर्न सक्छ।

तर अझै पनि, ELK सुरुमा लगहरूबाट बढ्यो र अहिलेसम्म मेट्रिक्सको कार्यक्षमतामा धेरै गम्भीर कमजोरीहरू छन्:

• Prometheus भन्दा उल्लेखनीय ढिलो
• Prometheus भन्दा धेरै कम ठाउँहरूमा एकीकृत
• तिनीहरूका लागि अलर्टहरू सेट अप गर्न गाह्रो छ
• मेट्रिक्सले धेरै ठाउँ लिन्छ
• Grafan मा भन्दा Kiban मा मेट्रिक्स संग ड्यासबोर्ड सेट अप धेरै जटिल छ

सामान्यतया, ELK मा मेट्रिकहरू भारी छन् र अझै अन्य समाधानहरूमा जस्तै सुविधाजनक छैन, जसमध्ये अब प्रोमेथियस भन्दा धेरै छन्: TSDB, Victoria Metrics, Cortex, आदि। निस्सन्देह, म साँच्चिकै एक पूर्ण-मा-एक समाधान प्राप्त गर्न चाहन्छु, तर मेट्रिकबिटको मामलामा त्यहाँ धेरै सम्झौताहरू थिए।

र ELK स्ट्याक आफैंमा धेरै कठिन क्षणहरू छन्:

• यो भारी हुन्छ, कहिलेकाहीँ धेरै भारी हुन्छ यदि तपाइँ पर्याप्त मात्रामा डेटा सङ्कलन गर्नुहुन्छ
• तपाईंले यसलाई "कसरी पकाउने" जान्नुपर्छ - तपाईंले यसलाई मापन गर्न आवश्यक छ, तर यो गर्न मामूली छैन
• स्ट्रिप डाउन नि: शुल्क संस्करण - नि: शुल्क संस्करणमा सामान्य चेतावनी छैन, र चयनको समयमा त्यहाँ कुनै प्रमाणीकरण थिएन

मैले भन्नु पर्छ कि हालै अन्तिम बिन्दु राम्रो र थप भएको छ खुला स्रोत X-pack मा आउटपुट (प्रमाणीकरण सहित) मूल्य निर्धारण मोडेल आफै परिवर्तन गर्न थाले।

तर जब हामी यो समाधान डिप्लोय गर्न जाँदै थियौं, त्यहाँ कुनै चेतावनी थिएन।
सायद हामीले ElastAlert वा अन्य सामुदायिक समाधानहरू प्रयोग गरेर केहि निर्माण गर्ने प्रयास गर्न सक्थ्यौं, तर हामीले अझै अन्य विकल्पहरू विचार गर्ने निर्णय गर्यौं।

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

यस समयमा, एक राम्रो समाधान मेट्रिक्स प्रदायकको रूपमा प्रोमिथियसमा आधारित निगरानी स्ट्याक, लगहरूको लागि लोकी, र भिजुअलाइजेसनको लागि तपाईंले उही Grafana प्रयोग गर्न सक्नुहुन्छ।

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

मसँग वास्तवमा गम्भीर परियोजनाहरूमा लोकी प्रयोग गर्ने अनुभव छैन, तर म भन्न सक्छु कि प्रोमटेल (लगहरू सङ्कलन गर्नका लागि एजेन्ट) कुबर्नेट्समा बेयर-मेटल र पोड दुवैका लागि राम्रो काम गर्दछ।

टिक

सायद सबैभन्दा योग्य (केवल?) ELK स्ट्याकको पूर्ण-विशेषतायुक्त विकल्पलाई अब केवल TICK स्ट्याक भनिन्छ - Telegraf, InfluxDB, Chronograf, Kapacitor।

म तलका सबै घटकहरूलाई थप विवरणमा वर्णन गर्नेछु, तर सामान्य विचार यो हो:

• Telegraf - मेट्रिक्स सङ्कलन को लागी एजेन्ट
• InfluxDB - मेट्रिक्स डाटाबेस
• Kapacitor - सचेतनाको लागि वास्तविक समय मेट्रिक्स प्रोसेसर
• क्रोनोग्राफ - दृश्यका लागि वेब प्यानल

InfluxDB, Kapacitor र Chronograf को लागि त्यहाँ आधिकारिक हेल्म चार्टहरू छन् जुन हामीले तिनीहरूलाई प्रयोग गर्यौं।

यो ध्यान दिनु पर्छ कि Influx 2.0 (beta) को नवीनतम संस्करणमा, Kapacitor र Chronograf InfluxDB को भाग बने र अब अलग देखि अवस्थित छैन।

टेलिग्राफ

टेलिग्राफ राज्य मेशिन मा मेट्रिक्स सङ्कलन को लागी एक धेरै हल्का एजेन्ट हो।

उहाँले सबै कुराको ठूलो मात्रा निगरानी गर्न सक्नुहुन्छ, देखि nginx गर्न
सर्भर minecraft.

यसमा धेरै राम्रो फाइदाहरू छन्:

• छिटो र हल्का वजन (गो मा लेखिएको)
  • न्यूनतम स्रोतहरू खान्छ
• पूर्वनिर्धारित रूपमा पुश मेट्रिक्स
• सबै आवश्यक मेट्रिक्स सङ्कलन
  • कुनै पनि सेटिङ बिना प्रणाली मेट्रिक्स
  • हार्डवेयर मेट्रिक्स जस्तै सेन्सरहरूबाट जानकारी
  • आफ्नो मेट्रिक्स थप्न धेरै सजिलो छ
• बाकस बाहिर धेरै प्लगइनहरू
• लगहरू सङ्कलन गर्दछ

हाम्रो लागि पुश मेट्रिक्स आवश्यक भएकोले, अन्य सबै फाइदाहरू सुखद थपहरू भन्दा बढी थिए।

एजेन्ट आफैंले लगहरूको सङ्कलन पनि धेरै सुविधाजनक छ, किनभने लगिङ लगहरूका लागि थप उपयोगिताहरू जडान गर्न आवश्यक छैन।

यदि तपाइँ प्रयोग गर्नुहुन्छ भने लगहरूसँग काम गर्नको लागि Influx ले सबैभन्दा सुविधाजनक अनुभव प्रदान गर्दछ syslog.

Telegraf सामान्यतया मेट्रिक्स सङ्कलन गर्न को लागी एक महान एजेन्ट हो, यदि तपाईले बाँकी ICK स्ट्याक प्रयोग गर्नुहुन्न भने।

धेरै मानिसहरूले यसलाई ELK र अन्य विभिन्न समय-श्रृङ्खला डाटाबेसहरूसँग सुविधाको लागि पार गर्छन्, किनकि यसले मेट्रिक्स लगभग कहिँ पनि लेख्न सक्छ।

InfluxDB

InfluxDB TICK स्ट्याकको मुख्य कोर हो, अर्थात् मेट्रिक्सको लागि समय-श्रृङ्खला डाटाबेस।
मेट्रिक्सको अतिरिक्त, इन्फ्लक्सले लगहरू पनि भण्डारण गर्न सक्छ, यद्यपि, सारमा, यसको लागि लगहरू मात्र समान मेट्रिक्स हुन्, सामान्य संख्यात्मक संकेतकहरूको सट्टा, मुख्य कार्य लग पाठको लाइनद्वारा गरिन्छ।

InfluxDB Go मा पनि लेखिएको छ र हाम्रो (सबैभन्दा शक्तिशाली होइन) क्लस्टरमा ELK को तुलनामा धेरै छिटो चलेको देखिन्छ।

Influx को उत्कृष्ट फाइदाहरू मध्ये एक डेटा प्रश्नहरूको लागि एक धेरै सुविधाजनक र समृद्ध API समावेश गर्दछ, जुन हामीले धेरै सक्रिय रूपमा प्रयोग गर्यौं।

बेफाइदाहरू - $$$ वा स्केलिंग?

TICK स्ट्याकमा हामीले पत्ता लगाएको एउटा मात्र त्रुटि छ - यो प्रिय। अझ बढी।

सशुल्क संस्करणमा के छ जुन नि: शुल्क संस्करणमा छैन?

जहाँसम्म हामीले बुझ्न सक्षम थियौं, TICK स्ट्याकको सशुल्क संस्करण र नि: शुल्क संस्करण बीचको मात्र भिन्नता भनेको स्केलिंग क्षमताहरू हो।

अर्थात्, तपाईले उच्च उपलब्धताको साथमा मात्र क्लस्टर बढाउन सक्नुहुन्छ उद्यम संस्करणहरू.

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

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

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

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

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

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

त्यहाँ धेरै समय-श्रृंखला डाटाबेसहरू छन्, तर सबैभन्दा आशाजनक एक हो भिक्टोरिया मेट्रिक्स, यसका धेरै फाइदाहरू छन्:

• छिटो र सजिलो, कम्तिमा परिणाम अनुसार बेन्चमार्कहरू
• त्यहाँ एक क्लस्टर संस्करण छ, जसको बारेमा अहिले पनि राम्रो समीक्षाहरू छन्
  • तिनी छिन्न सक्छिन्
• InfluxDB प्रोटोकल समर्थन गर्दछ

हामीले भिक्टोरियामा आधारित पूर्ण रूपमा अनुकूलन स्ट्याक निर्माण गर्ने इरादा राखेका थिएनौं र मुख्य आशा यो थियो कि हामीले यसलाई InfluxDB को लागि ड्रप-इन प्रतिस्थापनको रूपमा प्रयोग गर्न सक्छौं।

दुर्भाग्यवश, यो सम्भव छैन, InfluxDB प्रोटोकल समर्थित छ भन्ने तथ्यको बावजुद, यसले केवल मेट्रिक्स रेकर्डिङको लागि काम गर्दछ - केवल Prometheus API "बाहिर" उपलब्ध छ, जसको मतलब यसमा क्रोनोग्राफ सेट गर्न सम्भव छैन।

यसबाहेक, केवल संख्यात्मक मानहरू मेट्रिक्सका लागि समर्थित छन् (हामीले अनुकूलन मेट्रिक्सका लागि स्ट्रिङ मानहरू प्रयोग गर्यौं - खण्डमा थप व्यवस्थापक प्यानल).

स्पष्ट रूपमा, उही कारणको लागि, VM ले लगहरू भण्डारण गर्न सक्दैन जस्तै Influx ले गर्छ।

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

आधार चयन

नतिजाको रूपमा, यो निर्णय गरियो कि पायलटको लागि हामी अझै पनि आफूलाई एकल InfluxDB नोडमा सीमित गर्नेछौं।

यस छनौटको लागि धेरै मुख्य कारणहरू थिए:

• हामीले TICK स्ट्याकको सम्पूर्ण कार्यक्षमतालाई साँच्चै मन पराउँथ्यौं
• हामीले यसलाई पहिले नै प्रयोग गर्न व्यवस्थित गर्यौं र यसले राम्रो काम गर्‍यो
• समयसीमा सकिँदै थियो र अन्य विकल्पहरू परीक्षण गर्न धेरै समय बाँकी थिएन।
• हामीले यति ठूलो भारको अपेक्षा गरेका थिएनौं

हामीसँग पायलटको पहिलो चरणको लागि धेरै स्कूटरहरू थिएनन्, र विकासको क्रममा परीक्षण गर्दा कुनै पनि कार्यसम्पादन समस्याहरू प्रकट भएन।

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

हामीले स्ट्याक र आधारमा निर्णय गरेका छौं - अब TICK स्ट्याकको बाँकी घटकहरूको बारेमा।

कपासिटर

Kapacitor TICK स्ट्याकको अंश हो, एक सेवा जसले वास्तविक समयमा डाटाबेसमा प्रवेश गर्ने मेट्रिक्सलाई निगरानी गर्न र नियमहरूमा आधारित विभिन्न कार्यहरू गर्न सक्छ।

सामान्यतया, यो सम्भावित विसंगति ट्र्याकिङ र मेसिन लर्निङको लागि एक उपकरणको रूपमा राखिएको छ (म निश्चित छैन कि यी प्रकार्यहरू मागमा छन्), तर यसको प्रयोगको सबैभन्दा लोकप्रिय मामला अधिक सामान्य छ - चेतावनी।

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

यसले चाँडै समस्याहरूको जवाफ दिन सम्भव बनायो, साथै सूचनाहरू प्राप्त गर्यो कि सबै सामान्यमा फर्कियो।

एउटा साधारण उदाहरण: हाम्रो "बक्स" लाई पावर गर्नको लागि अतिरिक्त ब्याट्री बिग्रिएको छ वा कुनै कारणले पावर सकिएको छ; केवल नयाँ स्थापना गरेर, केही समय पछि हामीले स्कूटरको कार्यक्षमता पुनर्स्थापित भएको सूचना प्राप्त गर्नुपर्छ।

Influx 2.0 Kapacitor DB को भाग भयो

क्रोनोग्राफ

मैले निगरानीको लागि धेरै फरक UI समाधानहरू देखेको छु, तर म भन्न सक्छु कि कार्यक्षमता र UX को सर्तमा, केहि पनि क्रोनोग्राफसँग तुलना गर्दैन।

हामीले TICK स्ट्याक प्रयोग गर्न थाल्यौं, अनौठो रूपमा, Grafan सँग वेब इन्टरफेसको रूपमा।
म यसको कार्यक्षमता वर्णन गर्दिन; सबैलाई केहि पनि सेटअप गर्न को लागी यसको व्यापक संभावनाहरु थाहा छ।

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

र निस्सन्देह, यसका लागि धन्यवाद, क्रोनोग्राफले धेरै चतुर वा सुविधाजनक कार्यक्षमता किन्न सक्छ।

सायद क्रोनोग्राफसँग काम गर्ने मुख्य सुविधा यो हो कि तपाइँ अन्वेषण मार्फत तपाइँको InfluxDB को भित्री भागहरू हेर्न सक्नुहुन्छ।

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

किबानासँग ड्यासबोर्डहरू र तिनीहरूका लागि नियन्त्रणहरू सिर्जना गर्न धेरै समृद्ध क्षमताहरू छन्, तर त्यस्ता अपरेसनहरूको लागि UX धेरै जटिल छ।

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

ड्यासबोर्डहरू आफैंमा, सुखद दृश्य शैली बाहेक, वास्तवमा Grafana वा Kibana मा ड्यासबोर्डहरू भन्दा फरक छैन:

यो क्वेरी सञ्झ्याल जस्तो देखिन्छ:

यो नोट गर्न महत्त्वपूर्ण छ, अन्य चीजहरूको बीचमा, InfluxDB डाटाबेसमा फिल्डहरूको प्रकारहरू थाहा पाउँदा, क्रोनोग्राफ आफैले कहिलेकाहीँ तपाईंलाई क्वेरी लेख्न वा मतलब जस्तै सही एकत्रीकरण प्रकार्य छनौट गर्न मद्दत गर्न सक्छ।

र अवश्य पनि, क्रोनोग्राफ लगहरू हेर्नको लागि सकेसम्म सुविधाजनक छ। यो यस्तो देखिन्छ:

पूर्वनिर्धारित रूपमा, इन्फ्लक्स लगहरू syslog प्रयोग गर्नका लागि अनुकूल हुन्छन् र त्यसैले तिनीहरूसँग महत्त्वपूर्ण प्यारामिटर हुन्छ - गम्भीरता।

माथिको ग्राफ विशेष गरी उपयोगी छ; यसमा तपाइँ त्रुटिहरू देख्न सक्नुहुन्छ र रंगले तुरुन्तै स्पष्ट रूपमा देखाउँदछ यदि गम्भीरता उच्च छ।

केही पल्ट हामीले यसरी महत्त्वपूर्ण बगहरू समात्यौं, पछिल्लो हप्ताको लगहरू हेर्न र रातो स्पाइक हेर्दै।

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

हामीले यसलाई केही समयको लागि अन गर्यौं, तर पायलट तयार गर्ने प्रक्रियामा हामीले धेरै त्रुटिहरू (LTE नेटवर्कको अनुपलब्धता जस्ता प्रणालीहरू सहित) पाइरहेका थियौं, जसले स्ल्याक च्यानललाई पनि "स्प्याम" गर्‍यो। धेरै, कुनै पनि समस्या बिना। ठूलो लाभ।

सही समाधान यी प्रकारका अधिकांश त्रुटिहरू ह्यान्डल गर्न, तिनीहरूको लागि गम्भीरता समायोजन, र त्यसपछि मात्र सतर्कता सक्षम गर्न हो।

यस तरिकाले, केवल नयाँ वा महत्त्वपूर्ण त्रुटिहरू Slack मा पोस्ट गरिनेछ। कडा समयसीमा दिएर यस्तो सेटअपको लागि पर्याप्त समय थिएन।

प्रमाणीकरण

यो पनि उल्लेखनीय छ कि क्रोनोग्राफले OAuth र OIDC लाई प्रमाणीकरणको रूपमा समर्थन गर्दछ।

यो धेरै सुविधाजनक छ, किनकि यसले तपाइँलाई सजिलैसँग तपाइँको सर्भरमा संलग्न गर्न र पूर्ण SSO सिर्जना गर्न अनुमति दिन्छ।

हाम्रो अवस्थामा, सर्भर थियो किक्लोक - यो निगरानीमा जडान गर्न प्रयोग गरिएको थियो, तर उही सर्भर पनि स्कूटरहरू र ब्याक-एन्डमा अनुरोधहरू प्रमाणीकरण गर्न प्रयोग गरिएको थियो।

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

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

थप रूपमा, धेरै प्रशासनिक कार्यहरू त्यहाँ सारियो, जस्तै आपतकालीन रिबुट वा समर्थन टोलीको लागि टाढैबाट लक खोल्ने।

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

Influx को पहिले नै उल्लेख गरिएका फाइदाहरू मध्ये एक सजिलै आफ्नो मेट्रिक्स सिर्जना गर्ने क्षमता हो।
यसले यसलाई परिदृश्यहरूको विशाल विविधताको लागि प्रयोग गर्न अनुमति दिन्छ।

हामीले त्यहाँ सबै उपयोगी जानकारी रेकर्ड गर्ने प्रयास गर्यौं: ब्याट्री चार्ज, लक स्थिति, सेन्सर प्रदर्शन, ब्लुटुथ, GPS, र अन्य धेरै स्वास्थ्य जाँचहरू।
हामीले यो सबै प्रशासक प्यानलमा प्रदर्शन गर्यौं।

निस्सन्देह, हाम्रो लागि सबैभन्दा महत्त्वपूर्ण मापदण्ड स्कूटरको सञ्चालन अवस्था थियो - वास्तवमा, इन्फ्लक्सले यसलाई आफैं जाँच गर्दछ र नोड्स खण्डमा "हरियो बत्तीहरू" देखाउँछ।

यो कार्य द्वारा गरिन्छ मृत मानिस — हामीले यसलाई हाम्रो बक्सको कार्यसम्पादन बुझ्न र स्ल्याकमा उही अलर्टहरू पठाउन प्रयोग गर्यौं।

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

र सामान्यतया यो यस तरिकामा अधिक रमाइलो थियो। "केटाहरू, स्मिथर्स मरेका छन्!" जस्ता वाक्यांशहरू लगातार सुनिन्थ्यो।

स्ट्रिङ मेट्रिक्स

यो महत्त्वपूर्ण छ कि InfluxDB ले तपाईंलाई संख्यात्मक मानहरू मात्र भण्डारण गर्न अनुमति दिन्छ, जस्तै Victoria Metrics को मामलामा।

यस्तो देखिन्छ कि यो धेरै महत्त्वपूर्ण छैन - सबै पछि, लगहरू बाहेक, कुनै पनि मेट्रिक्स संख्याको रूपमा भण्डारण गर्न सकिन्छ (केवल ज्ञात राज्यहरूको लागि म्यापिङ थप्नुहोस् - एक प्रकारको enum)?

हाम्रो केसमा, त्यहाँ कम्तिमा एउटा परिदृश्य थियो जहाँ स्ट्रिङ मेट्रिकहरू धेरै उपयोगी थिए।
यो यति मात्र भयो कि हाम्रो "स्मार्ट चार्जरहरू" को आपूर्तिकर्ता तेस्रो पक्ष थियो, हामीसँग विकास प्रक्रिया र यी चार्जरहरूले आपूर्ति गर्न सक्ने जानकारीमा कुनै नियन्त्रण थिएन।

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

यो जहाँ इन्फ्लुक्स उद्धारको लागि आयो। हामीले केवल स्ट्रिङ स्थिति लेख्यौं जुन हामीलाई InfluxDB डाटाबेस क्षेत्रमा परिवर्तन बिना आएको थियो।

केही समयको लागि, "अनलाइन" र "अफलाइन" जस्ता मानहरू मात्र त्यहाँ पुगे, जसको आधारमा जानकारी हाम्रो प्रशासक प्यानलमा देखाइएको थियो, र सूचनाहरू Slack मा पठाइयो। यद्यपि, केहि बिन्दुमा, "विच्छेदन" जस्ता मानहरू पनि त्यहाँ देखा पर्न थाले।

यो पछि देखा पर्यो, यो स्थिति जडान गुमाए पछि एक पटक पठाइएको थियो, यदि चार्जरले निश्चित संख्याको प्रयास पछि सर्भरसँग जडान स्थापित गर्न सकेन।

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

र सामान्यतया, स्ट्रिङ मेट्रिक्सले प्रयोगको लागि धेरै सम्भावनाहरू प्रदान गर्दछ; तपाईंले तिनीहरूमा कुनै पनि जानकारी रेकर्ड गर्न सक्नुहुन्छ। यद्यपि, निस्सन्देह, तपाईंले यो उपकरणलाई सावधानीपूर्वक प्रयोग गर्न आवश्यक छ।

सामान्य मेट्रिक्सको अतिरिक्त, हामीले InfluxDB मा GPS स्थान जानकारी पनि रेकर्ड गर्यौं। हाम्रो प्रशासक प्यानलमा स्कूटरहरूको स्थान अनुगमन गर्नको लागि यो अविश्वसनीय रूपमा उपयोगी थियो।
वास्तवमा, हामीलाई चाहिने बेला कहाँ र कुन स्कुटर थियो भन्ने हामीलाई सधैं थाहा थियो।

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

पूर्वाधार अनुगमन

स्कूटरहरू बाहेक, हामीले हाम्रो सम्पूर्ण (बरु व्यापक) पूर्वाधारको निगरानी गर्न आवश्यक छ।

एक धेरै सामान्य वास्तुकला केहि यस्तो देखिन्छ:

यदि हामीले शुद्ध निगरानी स्ट्याक हाइलाइट गर्छौं भने, यो यस्तो देखिन्छ:

हामी क्लाउडमा के जाँच गर्न चाहन्छौं:

• डेटाबेस
• किक्लोक
• सूक्ष्म सेवाहरू

हाम्रा सबै क्लाउड सेवाहरू Kubernetes मा अवस्थित भएकाले, यसको राज्यको बारेमा जानकारी सङ्कलन गर्न पाउँदा राम्रो हुनेछ।

सौभाग्य देखि, Telegraf आउट द बक्सले Kubernetes क्लस्टरको अवस्थाको बारेमा ठूलो संख्यामा मेट्रिक्स सङ्कलन गर्न सक्छ, र क्रोनोग्राफले तुरुन्तै यसको लागि सुन्दर ड्यासबोर्डहरू प्रस्ताव गर्दछ।

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

Kubernetes मा पोडहरू ट्र्याक गर्ने दुई तरिकाहरू छन्: DaemonSet र Sidecar।
दुबै विधिहरू विस्तृत रूपमा वर्णन गरिएको छ यो ब्लग पोस्ट मा.

हामीले टेलीग्राफ साइडकार प्रयोग गर्यौं र मेट्रिक्सको अतिरिक्त, पोड लगहरू सङ्कलन गर्‍यौं।

हाम्रो अवस्थामा, हामीले लगहरूसँग टिंकर गर्नुपर्‍यो। Telegraf ले Docker API बाट लगहरू तान्न सक्छ भन्ने तथ्यको बावजुद, हामी हाम्रो अन्तिम यन्त्रहरू र यसका लागि कन्टेनरहरूको लागि कन्फिगर गरिएको syslog सँग लगहरूको एक समान संग्रह हुन चाहन्थ्यौं। सायद यो समाधान सुन्दर थिएन, तर यसको कामको बारेमा कुनै गुनासो थिएन र लगहरू क्रोनोग्राफमा राम्रोसँग देखाइएको थियो।

अनुगमन निगरानी???

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

यद्यपि Telegraf ले सजिलैसँग आफ्नै मेट्रिकहरू पठाउन सक्छ वा InfluxDB डाटाबेसबाट मेट्रिकहरू सङ्कलन गर्न सक्छ कि त उही इन्फ्लक्समा वा अरू कतै पठाउनको लागि।

निष्कर्ष

पायलटको नतिजाबाट हामीले के निष्कर्ष निकाल्यौं?

तपाईं कसरी अनुगमन गर्न सक्नुहुन्छ?

सबैभन्दा पहिले, TICK स्ट्याकले हाम्रा अपेक्षाहरू पूर्ण रूपमा पूरा गर्‍यो र हामीले सुरुमा अपेक्षा गरेको भन्दा बढी अवसरहरू दियो।

हामीलाई चाहिने सबै प्रकार्यहरू उपस्थित थिए। हामीले यससँग गरेका सबै काम बिना समस्याहरू भयो।

उत्पादकता

नि: शुल्क संस्करणमा TICK स्ट्याकको साथ मुख्य समस्या स्केलिंग क्षमताहरूको कमी हो। यो हाम्रो लागि समस्या थिएन।

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

तिनीहरू प्रत्येकले तीन दर्जन भन्दा बढी मेट्रिकहरू सङ्कलन गरे। एकै समयमा, उपकरणहरूबाट लगहरू सङ्कलन गरियो। डाटा सङ्कलन र पठाउने प्रत्येक 10 सेकेन्ड भयो।

यो नोट गर्न महत्त्वपूर्ण छ कि पाइलटको डेढ हप्ता पछि, जब "बालपनका समस्याहरू" को ठूलो हिस्सा सच्याइयो र सबैभन्दा महत्त्वपूर्ण समस्याहरू पहिले नै समाधान भइसकेको थियो, हामीले सर्भरमा डाटा पठाउने आवृत्ति घटाउनुपर्‍यो। ३० सेकेन्ड। यो आवश्यक भयो किनभने हाम्रो LTE SIM कार्डहरूमा ट्राफिक चाँडै गायब हुन थाल्यो।

ट्राफिकको ठूलो हिस्सा लगहरू द्वारा खपत भएको थियो; मेट्रिक्स आफैं, 10-सेकेन्ड अन्तरालको साथ पनि, व्यावहारिक रूपमा यसलाई बर्बाद गरेन।

नतिजाको रूपमा, केहि समय पछि हामीले यन्त्रहरूमा लगहरूको सङ्कलन पूर्ण रूपमा असक्षम पार्यौं, किनकि विशिष्ट समस्याहरू निरन्तर सङ्कलन बिना पनि स्पष्ट थिए।

केही अवस्थामा, यदि लगहरू हेर्न अझै आवश्यक थियो भने, हामीले केवल VPN मार्फत WireGuard मार्फत जडान गर्यौं।

म यो पनि थप्नेछु कि प्रत्येक अलग वातावरण एक अर्काबाट अलग गरिएको थियो, र माथि वर्णन गरिएको लोड उत्पादन वातावरणको लागि मात्र सान्दर्भिक थियो।

विकास वातावरणमा, हामीले एउटा छुट्टै InfluxDB उदाहरण उठायौं जसले प्रत्येक 10 सेकेन्डमा डाटा सङ्कलन गर्न जारी राख्यो र हामीले कुनै पनि कार्यसम्पादन समस्याहरूमा भागेनौं।

TICK - साना देखि मध्यम परियोजनाहरु को लागी आदर्श

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

यदि तपाईंसँग हजारौं पोडहरू वा सयौं मेसिनहरू छैनन् भने, एक InfluxDB उदाहरणले पनि लोडलाई राम्रोसँग ह्यान्डल गर्नेछ।

केही अवस्थामा, तपाईं एक आदिम उच्च उपलब्धता समाधानको रूपमा Influx Relay सँग सन्तुष्ट हुन सक्नुहुन्छ।

र, निस्सन्देह, कसैले तपाईंलाई "ठाडो" स्केलिंग सेटअप गर्न र विभिन्न प्रकारका मेट्रिक्सका लागि विभिन्न सर्भरहरू आवंटित गर्नबाट रोकिरहेको छैन।

यदि तपाइँ निगरानी सेवाहरूमा अपेक्षित लोडको बारेमा निश्चित हुनुहुन्न भने, वा तपाइँसँग धेरै "भारी" वास्तुकला छ/हुने ग्यारेन्टी छ, म TICK स्ट्याकको नि: शुल्क संस्करण प्रयोग गर्न सिफारिस गर्दिन।

निस्सन्देह, एक सरल समाधान खरीद गर्न हुनेछ InfluxDB उद्यम - तर यहाँ म कुनै न कुनै रूपमा टिप्पणी गर्न सक्दिन, किनकि म आफैं सूक्ष्मताहरूसँग परिचित छैन। यो धेरै महँगो र साना कम्पनीहरूको लागि निश्चित रूपमा उपयुक्त छैन भन्ने तथ्यको अलावा।

यस अवस्थामा, आज, म भिक्टोरिया मेट्रिक्स र लोकी प्रयोग गरेर लगहरू मार्फत मेट्रिक्स सङ्कलन गर्न खोज्न सिफारिस गर्दछु।

साँचो, म फेरि रिजर्भेसन गर्नेछु कि लोकी/ग्राफाना तयार TICK भन्दा धेरै कम सुविधाजनक छन् (उनीहरूको ठूलो बहुमुखी प्रतिभाको कारणले), तर तिनीहरू निःशुल्क छन्।

महत्त्वपूर्ण: यहाँ वर्णन गरिएका सबै जानकारी संस्करण Influx 1.8 को लागि सान्दर्भिक छ, अहिले Influx 2.0 जारी हुन लागेको छ।

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

यो प्रकार्यता Influx 2.0 मा पनि देखा पर्नेछ, तर हामीले कुनै समयसीमा फेला पार्न सकेनौं, अनुमानित पनि।

IoT प्लेटफर्महरू कसरी बनाउने (अब)

अन्तमा, पायलट सुरु गरिसकेपछि, हामीले आफैंले हाम्रो मापदण्ड अनुसार उपयुक्त विकल्पको अभावमा हाम्रो आफ्नै पूर्ण IoT स्ट्याक जम्मा गर्यौं।

यद्यपि, हालै यो बिटा संस्करणमा उपलब्ध छ ओपनबलेना - यो एउटा दु:खको कुरा हो जब हामीले परियोजना बनाउन थाल्यौं उनी त्यहाँ थिइनन्।

हामी अन्तिम परिणाम र Ansible + TICK + WireGuard मा आधारित प्लेटफर्मबाट पूर्ण रूपमा सन्तुष्ट छौं जुन हामीले आफैंलाई भेला गरेका छौं। तर आज, म आफ्नै IoT प्लेटफर्म आफैं निर्माण गर्ने प्रयास गर्नु अघि बलेनालाई नजिकबाट हेर्ने सिफारिस गर्दछु।

किनभने अन्ततः यसले हामीले गरेको धेरैजसो गर्न सक्छ, र OpenBalena नि: शुल्क र खुला स्रोत हो।

यसलाई पहिले नै थाहा छ कि कसरी अपडेटहरू पठाउने मात्र होइन, तर VPN पनि पहिले नै बनाइएको छ र IoT वातावरणमा प्रयोगको लागि अनुकूल छ।

र भर्खरै, तिनीहरूले आफ्नो रिलीज पनि गरे हार्डवेयर, जसले सजिलै आफ्नो इकोसिस्टममा जडान गर्दछ।

हे, हराएको स्कुटरको बारेमा के हो?

त्यसैले स्कूटर, "राल्फ", कुनै ट्रेस बिना गायब भयो।

हामी तुरुन्तै हाम्रो "व्यवस्थापक प्यानल" मा नक्सा हेर्न दौडियौं, InfluxDB बाट GPS मेट्रिक्स डेटाको साथ।

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

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

तर, घरधनी पनि यो देखेर अचम्ममा परेका छन्, किनकि उनी हिजो राति अफिसबाट यो स्कुटरमा चढेर घर गएका थिए ।

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

हामीले आफैंबाट स्कुटर चोर्यौं। वैसे, मलाई थाहा छैन कसरी र कसले त्यसपछि पुलिस केसको साथ मुद्दा हल गर्यो, तर अनुगमनले पूर्ण रूपमा काम गर्यो ...

स्रोत: www.habr.com