هڪ گم ٿيل اسڪوٽر واپس ڪريو، يا هڪ IoT نگراني جي ڪهاڻي

هڪ سال اڳ اسان هڪ پروموشنل پروجيڪٽ جو پائلٽ ورزن شروع ڪيو اليڪٽرڪ اسڪوٽر جي غير مرڪزي ڪرائي تي ڏيڻ.

شروعات ۾، منصوبي کي روڊ-ٽو-بارسلونا سڏيو ويندو هو، بعد ۾ اهو روڊ-ٽو-برلن بڻجي ويو (تنهنڪري اسڪرين شاٽ ۾ R2B)، ۽ آخر ۾ ان کي xRide سڏيو ويو.

پروجيڪٽ جو بنيادي خيال هي هو: هڪ مرڪزي ڪار يا اسڪوٽر ڪرائي تي ڏيڻ جي خدمت ڪرڻ بدران (اسان ڳالهائي رهيا آهيون اسڪوٽر عرف اليڪٽرڪ موٽرسائيڪلن بابت، نه ڪيڪ اسڪوٽرز/اسڪوٽرز) اسان چاهيون ٿا ته هڪ پليٽ فارم ٺاهڻ لاءِ ڊي سينٽرلائيز ڪرائي تي. انهن مشڪلاتن جي باري ۾ جيڪي اسان کي منهن ڏيڻو پيو اڳ ۾ ئي لکيو آهي.

شروعات ۾، پروجيڪٽ ڪارن تي ڌيان ڏنو، پر آخري وقت جي ڪري، ٺاهيندڙن سان انتهائي ڊگهي رابطي ۽ حفاظت جي پابندين جي وڏي تعداد، پائلٽ لاء برقي اسڪوٽر چونڊيو ويو.

صارف فون تي iOS يا اينڊرائيڊ ايپليڪيشن انسٽال ڪئي، پنهنجي پسند جي اسڪوٽر سان رابطو ڪيو، جنهن کان پوءِ فون ۽ اسڪوٽر وچ ۾ پيئر-ٽو-پيئر ڪنيڪشن قائم ٿي ويو، ETH مٽائي وئي ۽ صارف ان ذريعي اسڪوٽر کي آن ڪري سواري شروع ڪري سگهي ٿو. فون. سفر جي آخر ۾، اهو پڻ ممڪن هو ته سفر لاء ادا ڪرڻ لاء Ethereum استعمال ڪندي فون تي صارف جي والٽ مان.

اسڪوٽرز کان علاوه صارف کي ايپليڪيشن ۾ ”سمارٽ چارجرز“ به نظر آيا، جن کي ڏسڻ سان صارف موجوده بيٽري کي تبديل ڪري سگهي ٿو جيڪڏهن اها گهٽ هجي.

اهو عام طور تي اسان جي پائلٽ وانگر نظر آيو، گذريل سال سيپٽمبر ۾ ٻن جرمن شهرن ۾ شروع ڪيو ويو: بون ۽ برلن.

۽ پوءِ، هڪ ڏينهن، بون ۾، صبح جو، اسان جي سپورٽ ٽيم (اسڪوٽرن کي ڪم جي ترتيب ۾ برقرار رکڻ لاءِ سائيٽ تي موجود آهي) کي خبردار ڪيو ويو: هڪ اسڪوٽر بغير ڪنهن نشان جي غائب ٿي چڪو هو.

ان کي ڪيئن ڳولي ۽ ان کي واپس ڪرڻ لاء؟

هن آرٽيڪل ۾ آئون هن بابت ڳالهائيندس، پر پهريون - اسان ڪيئن پنهنجو IoT پليٽ فارم ٺاهيو ۽ اسان ان جي نگراني ڪيئن ڪئي.

ڇا ۽ ڇو مانيٽر ڪرڻ: اسڪوٽر، انفراسٽرڪچر، چارجنگ اسٽيشنون؟

تنهن ڪري، اسان پنهنجي منصوبي ۾ ڇا مانيٽر ڪرڻ چاهيندا هئاسين؟

سڀ کان پهريان، اهي خود اسڪوٽر آهن - اليڪٽرڪ اسڪوٽر پاڻ ۾ ڪافي مهانگو آهن، توهان اهڙي منصوبي کي ڪافي تيار ڪرڻ کان سواء شروع نه ٿا ڪري سگهو؛ جيڪڏهن ممڪن هجي، توهان اسڪوٽر بابت جيترو ممڪن معلومات گڏ ڪرڻ چاهيو ٿا: انهن جي مقام بابت، چارج جي سطح بابت. وغيره

ان کان علاوه، مان اسان جي پنهنجي آئي ٽي انفراسٽرڪچر جي حالت مانيٽر ڪرڻ چاهيان ٿو - ڊيٽابيس، خدمتون ۽ هر شيء جيڪا انهن کي ڪم ڪرڻ جي ضرورت آهي. اهو پڻ ضروري هو ته "سمارٽ چارجرز" جي صورتحال جي نگراني ڪرڻ لاء، جيڪڏهن اهي ڀڄي ويا يا مڪمل بيٽرين مان ڀڄي ويا.

اسڪوٽر

اسان جا اسڪوٽر ڪهڙا هئا ۽ اسان انهن بابت ڇا ڄاڻڻ چاهيون ٿا؟

پهرين ۽ سڀ کان اهم شيءِ آهي GPS ڪوآرڊينيٽس، ڇاڪاڻ ته انهن جي مهرباني اسان سمجهي سگهون ٿا ته اهي ڪٿي آهن ۽ ڪيڏانهن هلي رهيا آهن.

اڳيان آهي بيٽري جي چارج، جنهن جي مهرباني اسان اهو طئي ڪري سگهون ٿا ته اسڪوٽر جي چارجنگ ختم ٿي رهي آهي ۽ هڪ جوسر موڪليو يا گهٽ ۾ گهٽ صارف کي ڊيڄاريو.

يقينا، اهو پڻ ضروري آهي ته اسان جي هارڊويئر حصن سان ڇا ٿي رهيو آهي چيڪ ڪرڻ لاء:

• ڇا بلوٽوت ڪم ڪري ٿو؟
• ڇا GPS ماڊل پاڻ ڪم ڪري ٿو؟
  • اسان کي ان حقيقت سان پڻ مسئلو هو ته GPS غلط ڪوآرڊينيٽس موڪلي سگهي ٿو ۽ ڦاسي پيو، ۽ اهو صرف اسڪوٽر تي اضافي چيڪن ذريعي طئي ٿي سگهي ٿو،
    ۽ مسئلي کي حل ڪرڻ لاء جيترو جلدي ممڪن ٿي سگهي مدد کي اطلاع ڏيو

۽ آخر ۾: سافٽ ويئر جي چڪاس، او ايس ۽ پروسيسر سان شروع ٿيندڙ، نيٽ ورڪ ۽ ڊسڪ لوڊ، اسان جي پنهنجي ماڊلز جي چڪاس سان ختم ٿيڻ جيڪي اسان لاءِ وڌيڪ مخصوص آهن (جولوڪوم, چاٻي).

هارڊويئر

اسان جو "لوهه" حصو ڇا هو؟

گھٽ ۾ گھٽ وقت جي فريم ۽ تيز پروٽوٽائپ جي ضرورت کي نظر ۾ رکندي، اسان اجزاء جي عمل درآمد ۽ چونڊ لاءِ آسان ترين آپشن چونڊيو - Raspberry Pi.
پاڻ Rpi کان علاوه، اسان وٽ هڪ ڪسٽم بورڊ هو (جنهن کي اسان پاڻ ٺاهيو هو ۽ چين مان آرڊر ڏنو هو ته جيئن حتمي حل جي اسيمبليءَ جي عمل کي تيز ڪري سگهجي) ۽ اجزاء جو هڪ سيٽ - هڪ رلي (اسڪوٽر کي آن/بند ڪرڻ)، هڪ بيٽري چارج ريڊر، هڪ موڊيم، اينٽينا. هي سڀ هڪ خاص "xRide باڪس" ۾ ٺهيل هئي.

اهو پڻ نوٽ ڪيو وڃي ٿو ته سڄو باڪس هڪ اضافي پاور بئنڪ طرفان هلائي وئي هئي، جنهن جي نتيجي ۾ اسڪوٽر جي مکيه بيٽري طرفان طاقتور هئي.

ان ڪري مانيٽرنگ استعمال ڪرڻ ۽ سفر جي پڄاڻيءَ کان پوءِ به اسڪوٽر کي چالو ڪرڻ ممڪن ٿي ويو، ڇاڪاڻ ته مين بيٽري فوري طور تي بند ٿي وئي هئي ان کان پوءِ اگنيشن ڪيئي کي ”آف“ پوزيشن ڏانهن ڦيرايو.

ڊڪر؟ سادي لينڪس؟ ۽ تعیناتي

اچو ته مانيٽرنگ ڏانھن موٽون، پوء Raspberry - اسان وٽ ڇا آھي؟

پهرين شين مان هڪ جنهن کي اسان استعمال ڪرڻ چاهيون ٿا تيز ڪرڻ جي عمل کي تيز ڪرڻ، اپڊيٽ ڪرڻ ۽ پهچائڻ جي اجزاء کي فزيڪل ڊوائيسز تي ڊڪر.

بدقسمتي سان، اهو جلدي واضح ٿي ويو ته RPi تي Docker، جيتوڻيڪ اهو ڪم ڪري ٿو، تمام گهڻو مٿي آهي، خاص طور تي توانائي جي استعمال جي لحاظ کان.

فرق "ملي" OS استعمال ڪندي، جيتوڻيڪ ايترو مضبوط نه آهي، اڃا به اسان لاء ڪافي هو ته اسان کي تمام جلدي چارج وڃائڻ جي امڪان کان محتاط رهڻ لاء.

ٻيو سبب Node.js (sic!) تي اسان جي پارٽنر لائبريرين مان هڪ هئي - سسٽم جو واحد جزو جيڪو Go/C/C++ ۾ لکيل نه هو.

لائبريريءَ جي ليکڪن وٽ وقت نه هو ته هو ڪنهن به ”مادي“ ٻولين ۾ ڪم ڪندڙ نسخو مهيا ڪن.

نه رڳو نوڊ پاڻ کي گهٽ ڪارڪردگي ڊوائيسز لاء سڀ کان وڌيڪ خوبصورت حل نه آهي، پر لائبريري پاڻ تمام وسيلن جي بکيو هئي.

اسان محسوس ڪيو ته، جيتوڻيڪ اسان چاهيون ٿا، ڊڪر استعمال ڪرڻ اسان لاء تمام گهڻو مٿي هوندو. چونڊ اصلي او ايس جي حق ۾ ڪيو ويو ۽ سڌو سنئون ان جي تحت ڪم ڪري رهيو هو.

OS

نتيجي طور، اسان، ٻيهر، OS جي طور تي آسان ترين اختيار چونڊيو ۽ استعمال ڪيو Raspbian (Pi لاءِ ديبين تعمير).

اسان پنهنجا سڀئي سافٽ ويئر گو ۾ لکون ٿا، تنهنڪري اسان گو ۾ پنهنجي سسٽم ۾ مکيه هارڊويئر ايجنٽ ماڊل پڻ لکيو.

اھو اھو آھي جيڪو GPS سان ڪم ڪرڻ، بلوٽوت، چارج پڙھڻ، اسڪوٽر کي ڦيرايو وغيره وغيره.

مقرر ڪرڻ

سوال فوري طور تي ڊوائيسز (OTA) کي اپڊيٽ پهچائڻ لاءِ هڪ ميکانيزم تي عمل ڪرڻ جي ضرورت جي باري ۾ پيدا ٿيو - ٻئي تازه ڪاريون اسان جي ايجنٽ/ايپليڪيشن کي پاڻ، ۽ تازه ڪاريون پاڻ OS/فرم ویئر کي (جڏهن ته ايجنٽ جي نئين ورزن لاءِ تازه ڪاري جي ضرورت ٿي سگهي ٿي ڪرنل ۾ يا سسٽم جا حصا، لائبريريون، وغيره).

مارڪيٽ جي هڪ ڊگهي تجزيي کان پوء، اهو ظاهر ٿيو ته ڊوائيس تي تازه ڪاري پهچائڻ لاء ڪافي حل آهن.

نسبتاً سادو، گهڻو ڪري تازه ڪاري/ڊبل بوٽ تي مبني افاديت جهڙوڪ swupd/SWUpdate/OSTree مڪمل پليٽ فارمن جهڙوڪ مينڈر ۽ بالينا تائين.

سڀ کان پهريان، اسان اهو فيصلو ڪيو ته اسان کي آخر کان آخر تائين حل ۾ دلچسپي هئي، تنهنڪري چونڊ فوري طور تي پليٽ فارم تي ٿي ويو.

خودڪار بالينا خارج ڪيو ويو ان حقيقت جي ڪري ته اهو اصل ۾ ساڳيو ڊاکر استعمال ڪري ٿو ان جي بيلنا انجين اندر.

پر مون کي ياد آهي ته ان جي باوجود، اسان انهن جي پيداوار کي مسلسل استعمال ڪندي ختم ڪيو بيلينا آچرچ SD ڪارڊ تي فليش firmware لاء - هن لاء هڪ سادي ۽ انتهائي آسان افاديت.

تنهن ڪري، آخر ۾ چونڊ تي ڪري پيو مينڊر. Mender هڪ مڪمل پليٽ فارم آهي جمع ڪرڻ، پهچائڻ ۽ انسٽال ڪرڻ لاءِ فرم ویئر.

مجموعي طور تي پليٽ فارم تمام سٺو لڳندو آهي، پر اهو اسان کي تقريبا هڪ هفتي ۽ اڌ ورتو صرف اسان جي فرم ويئر جو صحيح ورزن ٺاهڻ لاء مينڈر بلڊر استعمال ڪندي.
۽ جيترو اسان پاڻ کي ان جي استعمال جي پيچيدگين ۾ غرق ڪيو، اوترو وڌيڪ اهو واضح ٿي ويو ته ان کي مڪمل طور تي ترتيب ڏيڻ لاء اسان کي اسان جي ڀيٽ ۾ وڌيڪ وقت جي ضرورت پوندي.

افسوس، اسان جي تنگ ڊيڊ لائنن جو مطلب اهو هو ته اسان کي مجبور ڪيو ويو ته مينڈر جي استعمال کي ڇڏي ڏيو ۽ هڪ کان وڌيڪ آسان چونڊيو.

ناھي

اسان جي صورتحال ۾ آسان حل جوابي استعمال ڪرڻ هو. شروع ڪرڻ لاءِ چند پلي بڪ ڪافي هئا.

انهن جو خلاصو اهو هو ته اسان صرف ميزبان (سي آءِ سرور) کان ssh ذريعي اسان جي راسبرري ڏانهن ڳنڍيو ۽ انهن کي اپڊيٽ ورهايو.

شروعات ۾، سڀڪنھن شيء کي سادو هو - توهان ڊوائيسز سان هڪ ئي نيٽ ورڪ تي هجڻ ضروري آهي، وجھڻ وائي فائي ذريعي ڪيو ويو.

آفيس ۾ صرف هڪ درجن ٽيسٽ رسبري ساڳي نيٽ ورڪ سان ڳنڍيل هئا، هر ڊوائيس وٽ هڪ جامد IP پتو پڻ هوندو هو جوابي فهرست ۾ بيان ڪيل.

اهو جواب ڏيڻ وارو هو جيڪو اسان جي نگراني ايجنٽ کي آخري ڊوائيسز تائين پهچايو

3G / LTE

بدقسمتي سان، جواب ڏيڻ لاء هي استعمال ڪيس صرف ترقياتي موڊ ۾ ڪم ڪري سگهي ٿو ان کان اڳ اسان وٽ حقيقي اسڪوٽر هئا.

ڇاڪاڻ ته اسڪوٽر، جيئن توهان سمجھو ٿا، هڪ وائي فائي روٽر سان ڳنڍيل نه ويهڻ، مسلسل نيٽ ورڪ تي اپڊيٽ جي انتظار ۾.

حقيقت ۾، اسڪوٽرن جو موبائل 3G/LTE کان سواءِ ٻيو ڪوبه ڪنيڪشن نٿو ٿي سگھي (۽ پوءِ به هر وقت نه).

اهو فوري طور تي ڪيترن ئي مسئلن ۽ حدن کي لاڳو ڪري ٿو، جهڙوڪ گهٽ ڪنيڪشن جي رفتار ۽ غير مستحڪم مواصلات.

پر سڀ کان اهم شيء اها آهي ته هڪ 3G / LTE نيٽ ورڪ ۾ اسان صرف هڪ مستحڪم IP تي ڀروسو نٿا ڪري سگهون جيڪو نيٽ ورڪ تي لڳايو ويو آهي.

اهو جزوي طور ڪجهه سم ڪارڊ فراهم ڪندڙن طرفان حل ڪيو ويو آهي؛ اتي به خاص سم ڪارڊ آهن جيڪي IoT ڊوائيسز لاءِ جامد IP پتي سان ٺهيل آهن. پر اسان وٽ اهڙن سم ڪارڊن تائين رسائي نه هئي ۽ IP پتي استعمال نٿا ڪري سگهون.

يقينن، ڪجهه خيال هئا IP پتي جي رجسٽريشن يا ڪنسل وانگر ڪنهن به هنڌ سروس دريافت ڪرڻ، پر اسان کي اهڙن خيالن کي ڇڏڻو پيو، ڇو ته اسان جي تجربن ۾ IP پتو گهڻو ڪري تبديل ٿي سگهي ٿو، جنهن جي ڪري وڏي عدم استحڪام جو سبب بڻيو.

انهي سبب لاء، ميٽرڪس پهچائڻ لاء سڀ کان وڌيڪ آسان استعمال پل ماڊل استعمال نه ڪيو ويندو، جتي اسان ضروري ميٽرڪس لاء ڊوائيسز ڏانهن ويندا هئاسين، پر دٻايو، ميٽرس کي ڊوائيس کان سڌو سرور ڏانهن پهچائڻ.

VPN

هن مسئلي جي حل جي طور تي، اسان چونڊيو VPN - خاص طور تي تار وارو.

ڪلائنٽ (اسڪوٽر) سسٽم جي شروعات ۾ VPN سرور سان ڳنڍيل آهن ۽ انهن سان ڳنڍڻ جي قابل هئا. هي سرنگ تازه ڪاري پهچائڻ لاءِ استعمال ڪيو ويو.

نظريي ۾، هڪ ئي سرنگ مانيٽرنگ لاءِ استعمال ٿي سگهي ٿي، پر اهڙو ڪنيڪشن سادو ڌڪ کان وڌيڪ پيچيده ۽ گهٽ قابل اعتماد هو.

بادل وسيلن

آخر ۾، اسان جي ڪلائوڊ سروسز ۽ ڊيٽابيس جي نگراني ڪرڻ ضروري آهي، ڇاڪاڻ ته اسان انهن لاء ڪبرنيٽس استعمال ڪندا آهيون، مثالي طور تي ته جيئن ڪلستر ۾ نگراني کي ترتيب ڏيڻ ممڪن آهي جيترو آسان آهي. مثالي طور، استعمال ڪندي هيلمٽ، ڇاڪاڻ ته تعیناتي لاءِ، اسان ان کي اڪثر ڪيسن ۾ استعمال ڪندا آهيون. ۽، يقينا، بادل جي نگراني ڪرڻ لاء، توهان کي ساڳيو حل استعمال ڪرڻ جي ضرورت آهي جيئن ته اسڪوٽر پاڻ لاء.

ڏنو

ڀائو، لڳي ٿو ته اسان وضاحت کي ترتيب ڏئي ڇڏيو آهي، اچو ته هڪ فهرست ٺاهيو جيڪو اسان کي آخر ۾ گهربل آهي:

• هڪ تڪڙو حل، ڇو ته مانيٽرنگ ضروري آهي اڳ ۾ ئي ترقي جي عمل دوران
• حجم / مقدار - گھڻن ميٽرڪ جي ضرورت آھي
• لاگ گڏ ڪرڻ جي ضرورت آهي
• اعتماد - ڊيٽا ڪاميابي کي شروع ڪرڻ لاء اهم آهي
• توهان پل ماڊل استعمال نٿا ڪري سگهو - توهان کي ڌڪ جي ضرورت آهي
• اسان کي نه رڳو هارڊويئر جي متحد نگراني جي ضرورت آهي، پر بادل پڻ

آخري تصوير ڪجهه هن طرح نظر آئي

اسٽيڪ جي چونڊ

تنهن ڪري، اسان کي هڪ مانيٽرنگ اسٽيڪ چونڊڻ جي سوال سان منهن ڪيو ويو.

سڀ کان پهريان، اسان سڀ کان وڌيڪ مڪمل حل ڳولي رهيا هئاسين جيڪو هڪ ئي وقت ۾ اسان جي سڀني ضرورتن کي پورو ڪري، پر ساڳئي وقت اسان جي ضرورتن مطابق ان جي استعمال کي ترتيب ڏيڻ لاء ڪافي لچڪدار هجي. تڏهن به، اسان تي هارڊويئر، آرڪيٽيڪچر ۽ ڊيڊ لائنز جون ڪيتريون ئي پابنديون لڳل هيون.

مانيٽرنگ حل جو هڪ وڏو قسم آهن، مڪمل سسٽم سان شروع ٿيندڙ جهڙوڪ Nagios, آئڪن يا انهييڪ ۽ فليٽ مئنيجمينٽ لاءِ تيار ڪيل حلن سان ختم.

شروعات ۾، بعد ۾ اسان لاءِ هڪ مثالي حل نظر آيو، پر ڪجهه وٽ مڪمل نگراني نه هئي، ٻين وٽ مفت نسخن جون سخت صلاحيتون محدود هيون، ۽ ٻيا رڳو اسان جي ”خواهش“ کي نه ڍڪيندا هئا يا اسان جي منظرنامي کي پورو ڪرڻ لاءِ ڪافي لچڪدار نه هئا. ڪجهه صرف پراڻا آهن.

ڪيترن ئي ساڳين حلن جو تجزيو ڪرڻ کان پوءِ، اسان جلدي ان نتيجي تي پهتاسين ته اهو آسان ۽ تيز هوندو ته هڪ جهڙي اسٽيڪ پاڻ کي گڏ ڪرڻ. ها، اهو مڪمل طور تي تيار ٿيل فليٽ مئنيجمينٽ پليٽ فارم کي ترتيب ڏيڻ کان ٿورو وڌيڪ پيچيده هوندو، پر اسان کي سمجھوتا ​​ڪرڻ جي ضرورت ناهي.

تقريبن يقيني طور تي، حل جي تمام وڏي گهڻائي ۾، اڳ ۾ ئي هڪ تيار ڪيل آهي جيڪو مڪمل طور تي اسان کي پورو ڪري ٿو، پر اسان جي صورت ۾ اهو گهڻو تيز هو ته هڪ خاص اسٽيڪ کي گڏ ڪرڻ ۽ ان کي ترتيب ڏيڻ جي بدران "پنهنجي لاء" تيار ڪيل شين جي جانچ.

ان سان گڏ، اسان پاڻ کي مڪمل مانيٽرنگ پليٽ فارم گڏ ڪرڻ جي ڪوشش نه ڪئي، پر سڀ کان وڌيڪ فعال "تيار ٿيل" اسٽيڪ ڳولي رهيا هئاسين، صرف انهن کي لچڪدار انداز سان ترتيب ڏيڻ جي صلاحيت سان.

(ب) ايل ڪي؟

پهريون حل جيڪو اصل ۾ سمجهيو ويو هو مشهور ELK اسٽيڪ.
حقيقت ۾، ان کي BELK سڏيو وڃي ٿو، ڇاڪاڻ ته اهو سڀ ڪجهه بيٽس سان شروع ٿئي ٿو - https://www.elastic.co/what-is/elk-stack

يقينن، ELK مانيٽرنگ جي ميدان ۾ سڀ کان وڌيڪ مشهور ۽ طاقتور حلن مان هڪ آهي، ۽ اڃا به وڌيڪ گڏ ڪرڻ ۽ پروسيسنگ لاگز ۾.

اسان ارادو ڪيو ته ELK لاگ گڏ ڪرڻ لاءِ استعمال ڪيو ويندو ۽ انهي سان گڏ پروميٿيس مان حاصل ڪيل ميٽرڪ جي ڊگهي مدت.

بصري لاء توهان گرافان استعمال ڪري سگهو ٿا.

حقيقت ۾، نئين ELK اسٽيڪ کي آزاديء سان ميٽرڪ گڏ ڪري سگھي ٿو (ميٽرڪ بيٽ)، ۽ ڪبانا پڻ انھن کي ڏيکاري سگھي ٿو.

پر اڃا تائين، ELK شروعاتي طور تي لاگن مان وڌيو ۽ اڃا تائين ميٽرڪ جي ڪارڪردگي ۾ ڪيترائي سنگين خرابيون آهن:

• Prometheus کان خاص طور تي سست
• Prometheus جي ڀيٽ ۾ تمام گهٽ هنڌن تي ضم ٿي
• انهن لاءِ الرٽ قائم ڪرڻ ڏکيو آهي
• ميٽرڪ تمام گهڻو جاء وٺندو آهي
• ڪيبن ۾ ميٽرڪس سان ڊيش بورڊ قائم ڪرڻ گرافان جي ڀيٽ ۾ وڌيڪ پيچيده آهي

عام طور تي، ELK ۾ ميٽرڪس ڳري آهن ۽ اڃا تائين آسان نه آهن جيئن ٻين حلن ۾، جن مان هاڻي صرف Prometheus کان وڌيڪ آهن: TSDB، Victoria Metrics، Cortex، وغيره وغيره. يقينن، مان واقعي چاهيان ٿو ته هڪ مڪمل طور تي هڪ مڪمل حل آهي، پر ميٽرڪ بيٽ جي صورت ۾ تمام گهڻا سمجھوتا ​​هئا.

۽ ELK اسٽيڪ پاڻ وٽ ڪيترائي ڏکيا لمحا آهن:

• اهو ڳري آهي، ڪڏهن ڪڏهن تمام ڳري آهي جيڪڏهن توهان ڊيٽا جي وڏي مقدار کي گڏ ڪيو
• توهان کي "ڄاڻڻ جي ضرورت آهي ته ڪيئن پچائڻ" - توهان کي ان کي ماپڻ جي ضرورت آهي، پر اهو ڪرڻ معمولي ناهي
• مفت ورزن کي ختم ڪيو ويو - مفت ورزن ۾ عام خبرداري نه آهي، ۽ چونڊ جي وقت تي ڪا به تصديق نه هئي

مون کي ضرور چوڻ گهرجي ته تازو آخري نقطو بهتر ٿي چڪو آهي ۽ اضافي طور تي اوپن سورس X-pack ۾ پيداوار (تصديق سميت) قيمت جي ماڊل پاڻ کي تبديل ڪرڻ شروع ڪيو.

پر ان وقت جڏهن اسان هن حل کي ترتيب ڏيڻ وارا هئاسين، اتي ڪو به خبردار نه هو.
شايد اسان ElastAlert يا ٻين ڪميونٽي حلن کي استعمال ڪندي ڪجهه ٺاهڻ جي ڪوشش ڪري سگهون ها، پر اسان اڃا تائين ٻين متبادلن تي غور ڪرڻ جو فيصلو ڪيو آهي.

لوڪي - گرافانا - پروميٿيوس

هن وقت، هڪ سٺو حل اهو ٿي سگهي ٿو ته هڪ مانيٽرنگ اسٽيڪ ٺاهيو وڃي خالص طور تي پروميٿيوس جي بنياد تي ميٽرڪس فراهم ڪندڙ جي طور تي، لوڪي لاءِ لاگ، ۽ ڏسڻ لاءِ توهان ساڳيو گرافانا استعمال ڪري سگهو ٿا.

بدقسمتي سان، پروجيڪٽ جي سيلز پائلٽ جي شروعات جي وقت (سيپٽمبر-آڪٽوبر 19)، لوڪي اڃا تائين بيٽا ورزن 0.3-0.4 ۾ هو، ۽ ترقي جي شروعات جي وقت تي اهو هڪ پيداوار حل جي طور تي سمجهي نه سگهيو. بلڪل.

مون کي اڃا تائين تجربو نه آهي اصل ۾ لوڪي کي سنجيده منصوبن ۾ استعمال ڪرڻ ۾، پر مان اهو چئي سگهان ٿو ته Promtail (لاگ گڏ ڪرڻ لاء هڪ ايجنٽ) ڪبرنيٽس ۾ بيئر ميٽيل ۽ پوڊ ٻنهي لاء بهترين ڪم ڪري ٿو.

ٽيڪ

شايد سڀ کان وڌيڪ لائق (صرف؟) مڪمل خصوصيت وارو متبادل ELK اسٽيڪ کي هاڻي صرف TICK اسٽيڪ سڏيو وڃي ٿو - Telegraf، InfluxDB، Chronograf، Kapacitor.

آئون هيٺ ڏنل سڀني جزن کي وڌيڪ تفصيل سان بيان ڪندس، پر عام خيال هي آهي:

• ٽيليگراف - ميٽرڪ گڏ ڪرڻ لاءِ ايجنٽ
• InfluxDB - ميٽرڪس ڊيٽابيس
• Kapacitor - خبردار ڪرڻ لاء حقيقي وقت ميٽرڪس پروسيسر
• ڪرونوگراف - ويب پينل بصري لاءِ

InfluxDB، Kapacitor ۽ Chronograf لاءِ سرڪاري ھيلم چارٽ آھن جيڪي اسان انھن کي مقرر ڪندا ھئاسين.

اهو ياد رکڻ گهرجي ته انفلوڪس 2.0 (بيٽا) جي تازي ورزن ۾، ڪيپيسيٽر ۽ ڪرونوگراف انفلڪس ڊي بي جو حصو بڻجي ويا ۽ هاڻي الڳ الڳ موجود نه آهن.

ٽيليگراف

ٽيليگراف رياستي مشين تي ميٽرڪ گڏ ڪرڻ لاءِ تمام ہلڪو وزن وارو ايجنٽ آهي.

هن هر شيء جي هڪ وڏي رقم مانيٽر ڪري سگهو ٿا, کان نگنڪس ڪرڻ
سرور مائين.

ان ۾ ڪيترائي سٺا فائدا آھن:

• تيز ۽ هلڪو وزن (Go ۾ لکيل)
  • گھٽ ۾ گھٽ وسيلا کائي ٿو
• ڊفالٽ طور پش ميٽرڪ
• گڏ ڪري ٿو تمام ضروري ميٽرڪ
  • سسٽم ميٽرڪ بغير ڪنهن سيٽنگون
  • هارڊويئر ميٽرڪس جهڙوڪ سينسر کان معلومات
  • اهو توهان جي پنهنجي ميٽرڪ شامل ڪرڻ تمام آسان آهي
• دٻي مان ڪيترائي پلگ ان
• لاگ گڏ ڪري ٿو

جيئن ته پش ميٽرڪس اسان لاءِ ضروري هئا، ٻيا سڀئي فائدا خوشگوار اضافو کان وڌيڪ هئا.

ايجنٽ پاران لاگن جو مجموعو پڻ تمام آسان آهي، ڇاڪاڻ ته لاگ ان لاگ ان لاء اضافي افاديت کي ڳنڍڻ جي ڪا ضرورت ناهي.

Influx پيش ڪري ٿو سڀ کان وڌيڪ آسان تجربو لاگز سان ڪم ڪرڻ لاءِ جيڪڏهن توهان استعمال ڪريو ٿا syslog.

Telegraf عام طور تي ميٽرڪ گڏ ڪرڻ لاءِ هڪ بهترين ايجنٽ آهي، جيتوڻيڪ جيڪڏهن توهان باقي ICK اسٽيڪ استعمال نٿا ڪريو.

ڪيترائي ماڻهو ان کي پار ڪن ٿا ELK ۽ ٻين مختلف وقت جي سيريز ڊيٽابيس سان سهولت لاءِ، ڇاڪاڻ ته اهو تقريبن ڪٿي به ميٽرڪس لکي سگهي ٿو.

InfluxDB

InfluxDB TICK اسٽيڪ جو بنيادي مرڪز آهي، يعني ميٽرڪس لاءِ ٽائيم سيريز ڊيٽابيس.
ميٽرڪس کان علاوه، انفلوڪس لاگز کي پڻ ذخيرو ڪري سگھي ٿو، جيتوڻيڪ، جوهر ۾، لاگ ان لاء صرف ساڳيا ميٽرڪس آهن، صرف عام عددي اشارن جي بدران، مکيه فنڪشن لاگ ٽيڪسٽ جي لائن ذريعي ڪيو ويندو آهي.

InfluxDB پڻ Go ۾ لکيو ويو آهي ۽ لڳي ٿو ته ELK جي مقابلي ۾ اسان جي (سڀ کان وڌيڪ طاقتور نه) ڪلستر تي.

Influx جي بهترين فائدن مان هڪ ۾ ڊيٽا جي سوالن لاءِ هڪ تمام آسان ۽ ڀرپور API به شامل هوندو، جنهن کي اسان تمام گهڻو استعمال ڪيو.

نقصانات - $$$ يا اسڪيلنگ؟

TICK اسٽيڪ ۾ صرف ھڪڙي خرابي آھي جيڪا اسان دريافت ڪئي آھي - اھو پيارا. اڃان وڌيڪ.

ادا ڪيل ورزن ۾ ڇا آهي جيڪو مفت ورزن ۾ نه آهي؟

جيتري قدر اسان سمجھڻ جي قابل هئاسين، TICK اسٽيڪ جي ادا ڪيل ورزن جي وچ ۾ صرف فرق ۽ مفت ھڪڙو اسڪيلنگ صلاحيتون آھي.

يعني، توهان صرف اعلي دستيابي سان گڏ ڪلستر وڌائي سگهو ٿا انٽرپرائز ورزن.

جيڪڏھن توھان چاھيو ٿا مڪمل HA، توھان کي يا ته ادا ڪرڻ جي ضرورت آھي يا ڪجھ ڪچھري استعمال ڪريو. اتي ڪجھ ڪميونٽي حل آھن - مثال طور influxdb-ha هڪ قابل حل وانگر ڏسڻ ۾ اچي ٿو، پر اهو لکيل آهي ته اهو پيداوار لاء مناسب ناهي، انهي سان گڏ
آمد و رفت - NATS ذريعي ڊيٽا پمپنگ سان گڏ هڪ سادي حل (ان کي پڻ اسڪيل ڪرڻو پوندو، پر اهو حل ٿي سگهي ٿو).

اها افسوس جي ڳالهه آهي، پر انهن ٻنهي کي ڇڏي ڏنو ويو آهي - ڪو به تازو ڪم نه آهي، مان سمجهان ٿو ته اهو مسئلو آهي جلد ئي متوقع رليز جو نئون نسخو Influx 2.0، جنهن ۾ ڪيتريون شيون مختلف هونديون (ان بابت ڪا ڄاڻ ناهي. اڃا تائين ان ۾ اسڪيلنگ).

سرڪاري طور تي هڪ مفت نسخو آهي رلي - حقيقت ۾، هي هڪ ابتدائي HA آهي، پر صرف توازن ذريعي،
ڇاڪاڻ ته سڀ ڊيٽا سڀني InfluxDB مثالن تي لکيو ويندو لوڊ بيلنس جي پويان.
هن وٽ ڪجهه آهي نقصان جهڙوڪ اوور رائٽنگ پوائنٽن سان امڪاني مسئلا ۽ اڳ ۾ ميٽرڪس لاءِ بنياد ٺاهڻ جي ضرورت
(جيڪو InfluxDB سان عام ڪم دوران خودڪار ٿئي ٿو).

ان کان سواء ڇڪڻ جي حمايت نه ڪئي وئي آهي, ان جو مطلب آهي اضافي اوور هيڊ نقلي ميٽرڪس لاءِ (ٻئي پروسيسنگ ۽ اسٽوريج) جنهن جي شايد توهان کي ضرورت نه هجي، پر انهن کي الڳ ڪرڻ جو ڪو طريقو ناهي.

وڪٽوريا ميٽرڪ؟

نتيجي طور، ان حقيقت جي باوجود ته اسان ادا ڪيل اسڪيلنگ کان سواءِ هر شي ۾ TICK اسٽيڪ سان مڪمل طور تي مطمئن هئاسين، اسان اهو ڏسڻ جو فيصلو ڪيو ته ڇا ڪي مفت حل آهن جيڪي InfluxDB ڊيٽابيس کي تبديل ڪري سگھن ٿا، جڏهن ته باقي T_CK اجزاء کي ڇڏي ڏيو.

اتي تمام گھڻا ٽائم-سيريز ڊيٽابيس آھن، پر سڀ کان وڌيڪ واعدو ڪندڙ آھي وڪٽوريا ميٽرڪس، ان جا ڪيترائي فائدا آھن:

• تيز ۽ آسان، گهٽ ۾ گهٽ نتيجن جي مطابق معيار
• هتي هڪ ڪلستر نسخو آهي، جنهن جي باري ۾ اڃا به سٺا تبصرا آهن
  • هوءَ کٽي سگهي ٿي
• InfluxDB پروٽوڪول کي سپورٽ ڪري ٿو

اسان وڪٽوريا جي بنياد تي مڪمل طور تي ڪسٽم اسٽيڪ ٺاهڻ جو ارادو نه ڪيو ۽ بنيادي اميد اها هئي ته اسان ان کي انفلوڪس ڊي بي لاءِ ڊراپ ان متبادل طور استعمال ڪري سگهون ٿا.

بدقسمتي سان، اهو ممڪن ناهي، ان حقيقت جي باوجود ته InfluxDB پروٽوڪول جي حمايت ڪئي وئي آهي، اهو صرف ڪم ڪري ٿو ميٽرڪ کي رڪارڊ ڪرڻ لاء - صرف Prometheus API موجود آهي "ٻاهر"، جنهن جو مطلب آهي ته اهو ممڪن نه ٿيندو ته ان تي Chronograph سيٽ ڪرڻ.

ان کان علاوه، صرف عددي قدرن جي مدد ڪئي وئي آھي ميٽرڪس لاءِ (اسان استعمال ڪيو اسٽرنگ ويلز لاءِ ڪسٽم ميٽرڪس - ان تي وڌيڪ سيڪشن ۾ منتظم پينل).

ظاهر آهي، ساڳئي سبب لاء، VM لاگ ان کي ذخيرو نٿو ڪري سگهي جيئن انفلوڪس ڪندو آهي.

اهو پڻ ياد رکڻ گهرجي ته بهترين حل ڳولڻ جي وقت، وڪٽوريا ميٽرڪس اڃا تائين مشهور نه هئي، دستاويز تمام ننڍا هئا ۽ ڪارڪردگي ڪمزور هئي.
(مون کي ڪلستر ورزن ۽ شارڊنگ جي تفصيلي وضاحت ياد ناهي).

بنيادي چونڊ

نتيجي طور، اهو فيصلو ڪيو ويو ته پائلٽ لاء اسان اڃا تائين پاڻ کي هڪ واحد InfluxDB نوڊ تائين محدود ڪنداسين.

هن چونڊ لاء ڪيترائي مکيه سبب هئا:

• اسان واقعي پسند ڪيو TICK اسٽيڪ جي پوري ڪارڪردگي
• اسان اڳ ۾ ئي ان کي ترتيب ڏيڻ جو انتظام ڪيو ۽ اهو عظيم ڪم ڪيو
• آخري وقت ختم ٿي رهيا هئا ۽ ٻين اختيارن کي جانچڻ لاءِ گهڻو وقت نه بچيو هو.
• اسان کي اهڙي ڳري بار جي اميد نه هئي

اسان وٽ پائلٽ جي پهرئين مرحلي لاءِ ڪيترائي اسڪوٽر نه ھئا، ۽ ترقيءَ جي دوران جاچ پڌرو نه ڪيو ويو ته ڪارڪردگيءَ جا ڪي به مسئلا.

تنهن ڪري، اسان فيصلو ڪيو ته هن منصوبي لاءِ هڪ انفلوڪس نوڊ اسان لاءِ ڪافي هوندو بغير اسڪيلنگ جي (ڏسو آخر ۾ نتيجو).

اسان اسٽيڪ ۽ بنياد تي فيصلو ڪيو آھي - ھاڻي TICK اسٽيڪ جي باقي حصن بابت.

ڪيپيسيٽر

Kapacitor TICK اسٽيڪ جو حصو آهي، هڪ خدمت جيڪا حقيقي وقت ۾ ڊيٽابيس ۾ داخل ٿيندڙ ميٽرڪ مانيٽر ڪري سگهي ٿي ۽ ضابطن جي بنياد تي مختلف ڪارناما انجام ڏئي ٿي.

عام طور تي، ان کي پوزيشن ۾ رکيل آهي هڪ اوزار جي طور تي امڪاني انمولي ٽريڪنگ ۽ مشين لرننگ (مون کي پڪ ناهي ته اهي فنڪشن گهربل آهن)، پر ان جي استعمال جو سڀ کان وڌيڪ مشهور ڪيس وڌيڪ عام آهي - خبردار ڪرڻ.

انهي طريقي سان اسان ان کي اطلاعن لاءِ استعمال ڪيو. اسان Slack الرٽ قائم ڪيو جڏهن هڪ خاص اسڪوٽر آف لائن ٿي ويو، ۽ اهو ئي سمارٽ چارجرز ۽ اهم انفراسٽرڪچر حصن لاءِ ڪيو ويو.

اهو ممڪن آهي ته جلدي جلدي مسئلن جو جواب ڏيڻ، انهي سان گڏ نوٽيفڪيشن حاصل ڪريو ته هر شيء معمول تي واپس آئي.

هڪ سادو مثال: اسان جي ”باڪس“ کي طاقت ڏيڻ لاءِ هڪ اضافي بيٽري ٽٽي وئي آهي يا ڪنهن سبب جي ڪري پاور ختم ٿي وئي آهي؛ بس هڪ نئين انسٽال ڪرڻ سان، ٿوري دير کان پوءِ اسان کي اطلاع ملي ته اسڪوٽر جي ڪارڪردگي بحال ٿي وئي آهي.

Influx 2.0 Kapacitor DB جو حصو بڻجي ويو

ڪرنوگراف

مون ڏٺو آهي ڪيترن ئي مختلف UI حل مانيٽرنگ لاءِ، پر مان چئي سگهان ٿو ته ڪارڪردگي ۽ UX جي لحاظ کان، ڪجهه به نه آهي ڪرنگراف جي مقابلي ۾.

اسان TICK اسٽيڪ استعمال ڪرڻ شروع ڪيو، عجيب طور تي، گرافن سان گڏ ويب انٽرفيس جي طور تي.
مان ان جي ڪارڪردگي کي بيان نه ڪندس؛ هرڪو ڄاڻي ٿو ان جي وسيع امڪانن کي ترتيب ڏيڻ لاءِ.

بهرحال، گرافانا اڃا تائين مڪمل طور تي آفاقي اوزار آهي، جڏهن ته ڪرونوگراف بنيادي طور تي انفلوڪس سان استعمال لاء ٺهيل آهي.

۽ يقينا، هن جي مهرباني، Chronograf گهڻو وڌيڪ هوشيار يا آسان ڪارڪردگي برداشت ڪري سگهي ٿو.

شايد Chronograph سان ڪم ڪرڻ جي بنيادي سهولت اها آهي ته توهان پنهنجي InfluxDB جي اندرين کي ڏسي سگهو ٿا ايڪسپلور ذريعي.

اهو لڳي ٿو ته گرافانا ۾ تقريبن هڪجهڙائي واري ڪارڪردگي آهي، پر حقيقت ۾، ڪرونگرافي ۾ ڊيش بورڊ قائم ڪري سگهجي ٿو چند ماؤس ڪلڪن سان (ساڳئي وقت اتي ڏسڻ ۾ اچي رهيو آهي)، جڏهن ته گرافانا ۾ توهان اڃا تائين جلدي يا دير سان هوندا. JSON ترتيب ۾ ترميم ڪرڻ لاءِ (يقينا Chronograf اجازت ڏئي ٿو توهان جي هٿ سان ترتيب ڏنل ڊيشاز کي اپلوڊ ڪريو ۽ جيڪڏهن ضروري هجي ته انهن کي JSON طور ايڊٽ ڪيو - پر مون کي انهن کي UI تي ٺاهڻ کان پوءِ ڪڏهن به هٿ ڪرڻ نه ڏنو).

ڪيبانا وٽ ڊيش بورڊ ٺاهڻ ۽ انهن لاءِ ڪنٽرول ڪرڻ لاءِ تمام گهڻيون صلاحيتون آهن، پر اهڙن عملن لاءِ UX تمام پيچيده آهي.

اهو هڪ آسان ڊيش بورڊ ٺاهڻ لاء ڪجهه سٺي سمجھ وٺندو. ۽ جيتوڻيڪ ڪرنوگراف ڊيش بورڊ جي ڪارڪردگي گهٽ آهي، انهن کي ٺاهڻ ۽ ترتيب ڏيڻ تمام آسان آهي.

ڊيش بورڊ پاڻ، خوشگوار بصري انداز کان سواء، اصل ۾ ڊيش بورڊ کان مختلف ناهي Grafana يا Kibana:

هي اهو آهي جيڪو سوال ونڊو وانگر ڏسڻ ۾ اچي ٿو:

اهو نوٽ ڪرڻ ضروري آهي، ٻين شين جي وچ ۾، اهو ڄاڻڻ آهي ته InfluxDB ڊيٽابيس ۾ شعبن جا قسم، ڪرنگراف پاڻ ڪڏهن ڪڏهن خودڪار طريقي سان توهان جي مدد ڪري سگهي ٿو سوال لکڻ ۾ يا صحيح مجموعي فنڪشن کي چونڊڻ ۾ جيئن مطلب.

۽ يقينا، Chronograf لاگ ڏسڻ لاء ممڪن طور تي آسان آهي. اهو هن طرح نظر اچي ٿو:

ڊفالٽ طور، Influx لاگز syslog استعمال ڪرڻ لاءِ تيار ڪيا ويا آھن ۽ تنھنڪري انھن وٽ ھڪڙو اھم پيٽرول آھي - شدت.

مٿي تي گراف خاص طور تي مفيد آهي؛ ان تي توهان ڏسي سگهو ٿا غلطيون جيڪي ٿينديون آهن ۽ رنگ فوري طور تي واضح طور تي ظاهر ڪري ٿو ته شدت وڌيڪ آهي.

ٻه ڀيرا اسان هن طريقي سان اهم ڪيڙا پڪڙيا، گذريل هفتي جا لاگ ڏسڻ ۽ هڪ ڳاڙهي اسپائڪ ڏسڻ لاءِ.

يقينن، مثالي طور تي اهڙين غلطين لاء الرٽ قائم ڪرڻ لاء، ڇو ته اسان وٽ اڳ ۾ ئي هن لاء سڀ ڪجهه هو.

اسان ان کي ٿوري دير لاءِ آن پڻ ڪيو، پر پائلٽ تيار ڪرڻ جي عمل ۾، اهو معلوم ٿيو ته اسان کي ڪافي غلطيون ملي رهيون هيون (بشمول سسٽم جهڙوڪ LTE نيٽ ورڪ جي دستيابي)، جنهن سلیک چينل کي ”اسپام“ ڪيو. تمام گهڻو، بغير ڪنهن پريشاني جي، وڏو فائدو.

صحيح حل اهو هوندو ته انهن غلطين جي اڪثر قسمن کي سنڀاليو، انهن جي شدت کي ترتيب ڏيو، ۽ صرف ان کان پوء خبرداري کي فعال ڪريو.

هن طريقي سان، صرف نيون يا اهم غلطيون پوسٽ ڪيون وينديون Slack ڏانهن. اهڙي سيٽ اپ لاءِ ڪافي وقت نه هو جنهن کي تنگ ڊيڊ لائنون ڏنيون ويون.

تصديق

اهو پڻ قابل ذڪر آهي ته Chronograph OAuth ۽ OIDC کي تصديق جي طور تي سپورٽ ڪري ٿو.

اهو تمام آسان آهي، جيئن اهو توهان کي آساني سان توهان جي سرور سان ڳنڍڻ ۽ مڪمل ايس ايس او ٺاهڻ جي اجازت ڏئي ٿو.

اسان جي حالت ۾، سرور هو چاٻي - اهو مانيٽرنگ سان ڳنڍڻ لاءِ استعمال ڪيو ويو، پر ساڳيو سرور پڻ استعمال ڪيو ويو اسڪوٽرن جي تصديق ڪرڻ ۽ درخواستن جي پٺڀرائي ڪرڻ لاءِ.

”ايڊمن“

آخري جزو جنهن کي مان بيان ڪندس اهو آهي اسان جو خود لکيل ”ايڊمن پينل“ Vue ۾.
بنيادي طور تي اها صرف هڪ اسٽائل سروس آهي جيڪا ڏيکاري ٿي اسڪوٽر جي معلومات اسان جي پنهنجي ڊيٽابيس، مائڪرو سروسز، ۽ ميٽرڪس ڊيٽا انفلوڪس ڊي بي کان هڪ ئي وقت ۾.

ان کان علاوه، ڪيترائي انتظامي ڪم اتي منتقل ڪيا ويا، جهڙوڪ ايمرجنسي ريبوٽ يا ريموٽ طور تي سپورٽ ٽيم لاءِ تالا کولڻ.

نقشا به هئا. مون اڳ ۾ ئي ذڪر ڪيو آهي ته اسان ڪرونوگراف جي بدران گرافانا سان شروع ڪيو - ڇاڪاڻ ته گرافانا نقشا پلگ ان جي صورت ۾ موجود آهن، جن تي اسان اسڪوٽرن جي همراهن کي ڏسي سگهون ٿا. بدقسمتي سان، گرافانا لاءِ نقشي جي ويجٽ جون صلاحيتون تمام محدود آهن، ۽ نتيجي طور، نقشن سان پنهنجي ويب ايپليڪيشن کي ڪجهه ڏينهن ۾ لکڻ تمام آسان ٿي ويو، انهي لاءِ ته هن وقت نه رڳو همراهن کي ڏسڻ لاءِ، پر ڊسپلي پڻ. رستو جيڪو اسڪوٽر طرفان ورتو ويو، نقشي تي ڊيٽا کي فلٽر ڪرڻ جي قابل ٿي وڃو، وغيره.

Influx جي اڳ ۾ ئي ذڪر ڪيل فائدن مان هڪ آهي آساني سان توهان جي پنهنجي ميٽرڪ ٺاهڻ جي صلاحيت.
اهو اجازت ڏئي ٿو ته ان کي مختلف قسم جي منظرنامي لاءِ استعمال ڪيو وڃي.

اسان اتي تمام مفيد معلومات رڪارڊ ڪرڻ جي ڪوشش ڪئي: بيٽري چارج، لاڪ اسٽيٽس، سينسر ڪارڪردگي، بلوٽوٿ، GPS، ۽ ٻيا ڪيترائي صحت جا چيڪ.
اسان اهو سڀ ڪجهه ايڊمن پينل تي ڏيکاريو.

يقينن، اسان لاء سڀ کان اهم معيار اسڪوٽر جي آپريٽنگ حالت هئي - حقيقت ۾، انفلوڪس پاڻ کي چيڪ ڪري ٿو ۽ ان کي ڏيکاري ٿو "سبز روشني" سان نوڊس سيڪشن ۾.

اهو فنڪشن طرفان ڪيو ويندو آهي مئل - اسان ان کي استعمال ڪيو اسان جي باڪس جي ڪارڪردگي کي سمجھڻ ۽ Slack ڏانهن اهي ساڳيون الرٽ موڪلڻ لاءِ.

رستي ۾، اسان اسڪوٽرن جو نالو سمپسن جي ڪردارن جي نالن تي رکيو آهي - اهو ايترو آسان هو ته انهن کي هڪ ٻئي کان ڌار ڪرڻ لاء.

۽ عام طور تي هن طريقي سان وڌيڪ مزو هو. جملا جيئن ته "گائيز، سمٿرز مري ويو آهي!" مسلسل ٻڌي رهيا هئا.

اسٽرنگ ميٽرڪس

اهو ضروري آهي ته InfluxDB توهان کي صرف عددي قدرن کي ذخيرو ڪرڻ جي اجازت ڏئي ٿي، جيئن وڪٽوريا ميٽرڪس جي صورت ۾ آهي.

اهو لڳي ٿو ته اهو ايترو اهم ناهي - سڀ کان پوء، لاگ ان کان سواء، ڪنهن به ميٽرڪ نمبرن جي صورت ۾ ذخيرو ٿي سگهي ٿو (صرف ڄاڻايل رياستن لاء نقشي شامل ڪريو - هڪ قسم جو اينيم)؟

اسان جي صورت ۾، اتي گهٽ ۾ گهٽ هڪ منظر هو جتي string metrics تمام مفيد هئا.
بس ائين ئي ٿيو آهي ته اسان جي ”سمارٽ چارجرز“ جو سپلائر هڪ ٽين ڌر هئي، اسان وٽ ترقي جي عمل ۽ معلومات تي ڪو به ڪنٽرول نه هو ته اهي چارجرز فراهم ڪري سگھن.

نتيجي طور، چارجنگ API مثالي کان پري هئي، پر بنيادي مسئلو اهو هو ته اسان هميشه انهن جي حالت کي سمجهي نٿا سگهون.

اهو آهي جتي انفلوڪس بچاء لاء آيو. اسان صرف اسٽرنگ اسٽيٽس لکيو آهي جيڪو اسان وٽ آيو آهي InfluxDB ڊيٽابيس فيلڊ ۾ بغير تبديلين جي.

ڪجهه وقت لاءِ، صرف قدرن جهڙوڪ ”آن لائن“ ۽ ”آف لائن“ اتي مليا، جن جي بنياد تي معلومات اسان جي ايڊمن پينل ۾ ڏيکاري وئي، ۽ نوٽيفڪيشن Slack ڏانهن موڪليا ويا. بهرحال، ڪجهه نقطي تي، قدرن جهڙوڪ "منقطع" پڻ اتي ظاهر ٿيڻ شروع ڪيو.

جيئن ته اهو بعد ۾ ظاهر ٿيو، اها حيثيت هڪ ڀيرو موڪلي وئي هئي ڪنيڪشن جي نقصان کان پوء، جيڪڏهن چارجر ڪجهه ڪوششن کان پوء سرور سان ڪنيڪشن قائم نه ڪري سگهيو.

اهڙيء طرح، جيڪڏهن اسان صرف قدرن جو هڪ مقرر ڪيل سيٽ استعمال ڪيو، اسان شايد اهي تبديليون صحيح وقت تي firmware ۾ نه ڏسي سگهون.

۽ عام طور تي، اسٽرنگ ميٽرڪ استعمال لاءِ تمام گهڻو امڪان مهيا ڪن ٿا؛ توهان انهن ۾ تقريبن ڪنهن به معلومات کي رڪارڊ ڪري سگهو ٿا. جيتوڻيڪ، يقينا، توهان کي پڻ هن اوزار کي احتياط سان استعمال ڪرڻ جي ضرورت آهي.

عام ميٽرڪس کان علاوه، اسان پڻ رڪارڊ ڪيو GPS جي جڳھ جي معلومات InfluxDB ۾. اهو اسان جي منتظم پينل ۾ اسڪوٽر جي مقام جي نگراني ڪرڻ لاء ناقابل اعتبار حد تائين مفيد هو.
حقيقت ۾، اسان هميشه ڄاڻون ٿا ته ڪٿي ۽ ڪهڙي اسڪوٽر جي ضرورت هئي ان وقت.

اهو اسان لاءِ تمام مفيد هو جڏهن اسان هڪ اسڪوٽر ڳولي رهيا هئاسين (ڏسو آخر ۾ نتيجو).

انفراسٹرڪچر جي نگراني

خود سکوٽرن کان علاوه، اسان کي پڻ اسان جي پوري (بلڪه وسيع) انفراسٽرڪچر جي نگراني ڪرڻ جي ضرورت آهي.

هڪ تمام عام فن تعمير هن طرح ڪجهه ڏٺو:

جيڪڏهن اسان هڪ خالص مانيٽرنگ اسٽيڪ کي اجاگر ڪيو، اهو هن طرح نظر اچي ٿو:

جيڪو اسان بادل ۾ چيڪ ڪرڻ چاهيون ٿا اهو آهي:

• ڊيٽابيس
• چاٻي
• Microservices

جيئن ته اسان جون سڀئي بادل خدمتون ڪبرنيٽس ۾ واقع آهن، ان جي رياست بابت معلومات گڏ ڪرڻ سٺو لڳندو.

خوشقسمتيءَ سان، دٻي مان ٽيليگراف ڪبرنيٽس ڪلستر جي حالت بابت وڏي تعداد ۾ ميٽرڪ گڏ ڪري سگهي ٿو، ۽ ڪرونوگراف فوري طور تي ان لاءِ خوبصورت ڊيش بورڊ پيش ڪري ٿو.

اسان خاص طور تي پوڊ جي ڪارڪردگي ۽ ياداشت جي استعمال جي نگراني ڪئي. زوال جي صورت ۾، Slack ۾ الرٽ.

ڪبرنيٽس ۾ پوڊ کي ٽريڪ ڪرڻ جا ٻه طريقا آهن: DaemonSet ۽ Sidecar.
ٻئي طريقا تفصيل سان بيان ڪيا ويا آهن هن بلاگ پوسٽ ۾.

اسان استعمال ڪيو Telegraf Sidecar ۽، ميٽرڪس کان علاوه، گڏ ڪيل پوڊ لاگ.

اسان جي حالت ۾، اسان کي لاگن سان ٽڪرائڻو پوندو. ان حقيقت جي باوجود ته Telegraf Docker API مان لاگز کي ڇڪي سگھي ٿو، اسان چاهيون ٿا ته لاگز جو هڪ يونيفارم مجموعو اسان جي آخري ڊوائيسز سان ۽ ترتيب ڏنل syslog لاء ڪنٽينرز لاء. شايد اهو حل خوبصورت نه هو، پر ان جي ڪم جي باري ۾ ڪا به شڪايت نه هئي ۽ لاگز Chronograf ۾ چڱي طرح ڏيکاريل هئا.

مانيٽرنگ جي نگراني؟؟؟

آخر ۾، مانيٽرنگ سسٽم جي نگراني جي پراڻي سوال پيدا ٿيو، پر خوش قسمت، يا بدقسمتي سان، اسان وٽ صرف ان لاء ڪافي وقت نه هو.

جيتوڻيڪ Telegraf آساني سان پنهنجي ميٽرڪ موڪلي سگهي ٿو يا انفلوڪس ڊي بي ڊيٽابيس مان ميٽرڪ گڏ ڪري سگهي ٿو يا ته ساڳئي انفلوڪس ڏانهن موڪلڻ لاءِ يا ڪنهن ٻئي هنڌ.

پهچڻ

پائلٽ جي نتيجن مان اسان ڪهڙا نتيجا ڪڍيا؟

توهان ڪيئن نگراني ڪري سگهو ٿا؟

سڀ کان پهريان، TICK اسٽيڪ مڪمل طور تي اسان جي اميدن کي پورو ڪيو ۽ اسان کي ان کان به وڌيڪ موقعا ڏنائين جيڪي اسان شروعاتي طور تي توقع ڪئي هئي.

اسان کي گهربل سڀ ڪارڪردگي موجود هئي. ان سان گڏ اسان سڀ ڪجھ ڪم ڪيو بغير مسئلن جي.

پيداوار

مفت ورزن ۾ TICK اسٽيڪ سان بنيادي مسئلو اسڪيلنگ صلاحيتن جي کوٽ آهي. اهو اسان لاء ڪو مسئلو نه هو.

اسان صحيح لوڊ ڊيٽا / انگ اکر گڏ نه ڪيو، پر اسان هڪ وقت ۾ اٽڪل 30 اسڪوٽرن کان ڊيٽا گڏ ڪيو.

انهن مان هر هڪ ٽن درجن کان وڌيڪ ميٽرڪ گڏ ڪيو. ساڳئي وقت، ڊوائيسز مان لاگ گڏ ڪيا ويا. ڊيٽا گڏ ڪرڻ ۽ موڪلڻ هر 10 سيڪنڊن ۾ ٿيو.

اهو نوٽ ڪرڻ ضروري آهي ته پائلٽ جي هڪ اڌ هفتي کان پوء، جڏهن "ننڍپڻ جي مسئلن" جو وڏو حصو درست ڪيو ويو ۽ سڀ کان اهم مسئلا اڳ ۾ ئي حل ٿي چڪا هئا، اسان کي سرور ڏانهن ڊيٽا موڪلڻ جي تعدد کي گهٽائڻو پوندو. 30 سيڪنڊ. اهو ضروري ٿي ويو ڇو ته اسان جي LTE سم ڪارڊ تي ٽرئفڪ جلدي غائب ٿيڻ شروع ڪيو.

ٽريفڪ جو وڏو حصو لاگز ذريعي استعمال ڪيو ويو؛ ميٽرڪ پاڻ، جيتوڻيڪ 10-سيڪنڊ وقف سان، عملي طور تي ان کي ضايع نه ڪيو.

نتيجي طور، ڪجهه وقت کان پوء اسان مڪمل طور تي ڊوائيسز تي لاگ ان جي گڏ ڪرڻ کي بند ڪري ڇڏيو، ڇاڪاڻ ته مخصوص مسئلا اڳ ۾ ئي واضح هئا جيتوڻيڪ مسلسل گڏ ڪرڻ کان سواء.

ڪجهه حالتن ۾، جيڪڏهن لاگز ڏسڻ اڃا به ضروري هو، اسان صرف وائر گارڊ ذريعي وي پي اين ذريعي ڳنڍيو.

مان اهو به شامل ڪندس ته هر هڪ الڳ ماحول جيڪو اسان وٽ هوندو هو هڪ ٻئي کان الڳ هو، ۽ مٿي بيان ڪيل لوڊ صرف پيداوار واري ماحول لاءِ لاڳاپيل هو.

ترقي جي ماحول ۾، اسان هڪ الڳ InfluxDB مثال قائم ڪيو جيڪو هر 10 سيڪنڊن ۾ ڊيٽا گڏ ڪرڻ جاري رکي ۽ اسان ڪنهن به ڪارڪردگي جي مسئلن ۾ نه هليا.

TICK - ننڍي ۽ وچولي منصوبن لاءِ مثالي

هن معلومات جي بنياد تي، مان اهو نتيجو ڪندس ته TICK اسٽيڪ نسبتا ننڍن منصوبن يا منصوبن لاء مثالي آهي جيڪي يقيني طور تي ڪنهن به هاء لوڊ جي اميد نٿا ڪن.

جيڪڏھن توھان وٽ ھزارين پوڊ يا سوين مشينون نه آھن، جيتوڻيڪ ھڪڙو InfluxDB مثال صرف لوڊ کي سنڀاليندو.

ڪجھ ڪيسن ۾، توھان مطمئن ٿي سگھوٿا Influx Relay کان ھڪ پرائمو هاءِ دستيابي حل جي طور تي.

۽، يقينا، ڪو به توهان کي "عمودي" اسڪيلنگ قائم ڪرڻ ۽ صرف مختلف قسم جي ميٽرڪس لاء مختلف سرورز کي مختص ڪرڻ کان روڪي رهيو آهي.

جيڪڏهن توهان مانيٽرنگ سروسز تي متوقع لوڊ جي باري ۾ پڪ ناهي، يا توهان کي ضمانت ڏني وئي آهي ته توهان وٽ هڪ تمام گهڻو "ڀاري" فن تعمير هوندو، مان TICK اسٽيڪ جو مفت نسخو استعمال ڪرڻ جي سفارش نه ڪندس.

يقينن، هڪ سادي حل خريد ڪرڻ لاء هوندو InfluxDB Enterprise - پر هتي مان ڪنهن به طرح تبصرو نه ٿو ڪري سگهان، ڇاڪاڻ ته مان پاڻ به ان جي نزاڪت کان واقف نه آهيان. ان کان علاوه حقيقت اها آهي ته اهو تمام قيمتي آهي ۽ يقيني طور تي ننڍن ڪمپنين لاء مناسب ناهي.

انهي صورت ۾، اڄ، مان وڪٽوريا ميٽرڪس ذريعي ميٽرڪ گڏ ڪرڻ جي صلاح ڏيندس ۽ لوڪ استعمال ڪندي لاگس.

سچ، مان ٻيهر هڪ رزرويشن ڪندس ته لوڪي / گرافانا تمام گهٽ آسان آهن (انهن جي وڏي استحڪام جي ڪري) تيار ٿيل TICK کان، پر اهي مفت آهن.

اهم: هتي بيان ڪيل سموري معلومات ورزن انفلڪس 1.8 لاءِ لاڳاپيل آهي، هن وقت انفلوڪس 2.0 جاري ٿيڻ وارو آهي.

جڏهن ته مون کي جنگي حالتن ۾ ڪوشش ڪرڻ جو موقعو نه مليو آهي ۽ بهتري جي باري ۾ نتيجو ڪڍڻ ڏکيو آهي، انٽرفيس ضرور بهتر ٿي چڪو آهي، فن تعمير کي آسان ڪيو ويو آهي (ڪيپيسيٽر ۽ ڪرونگراف کان سواء)،
ٽيمپليٽ ظاهر ٿيو ("قاتل خصوصيت" - توهان Fortnite ۾ رانديگرن کي ٽريڪ ڪري سگهو ٿا ۽ نوٽيفڪيشن حاصل ڪري سگهو ٿا جڏهن توهان جو پسنديده رانديگر راند کٽي ٿو). پر، بدقسمتي سان، هن وقت، نسخو 2 ۾ اهم شيء نه آهي جنهن لاء اسان پهريون نسخو چونڊيو آهي - ڪو به لاگ جمع نه آهي.

اها ڪارڪردگي به ظاهر ٿيندي Influx 2.0 ۾، پر اسان ڪا به آخري تاريخ نه ڳولي سگهيا آهيون، ايتري قدر جو لڳ ڀڳ.

IoT پليٽ فارم ڪيئن نه ٺاهيو (هاڻي)

آخر ۾، پائلٽ شروع ڪرڻ کان پوء، اسان پاڻ کي گڏ ڪيو، اسان جي معيار جي مطابق مناسب متبادل جي غير موجودگي ۾، اسان جي پنهنجي مڪمل IoT اسٽيڪ کي گڏ ڪيو.

بهرحال، تازو اهو بيٽا ورزن ۾ موجود آهي اوپن بالينا - اها افسوس جي ڳالهه آهي ته هوءَ اتي نه هئي جڏهن اسان پروجيڪٽ ٺاهڻ شروع ڪيو.

اسان مڪمل طور تي مطمئن آهيون آخري نتيجو ۽ پليٽ فارم تي ٻڌل جوابي + TICK + وائر گارڊ جيڪو اسان پاڻ کي گڏ ڪيو. پر اڄ، مان سفارش ڪندس بلينا تي هڪ ويجھو نظر وجهڻ کان پهريان توهان جي پنهنجي IoT پليٽ فارم ٺاهڻ جي ڪوشش ڪرڻ کان پهريان.

ڇو ته آخرڪار اهو ڪري سگهي ٿو گهڻو ڪري جيڪو اسان ڪيو، ۽ OpenBalena مفت ۽ کليل ذريعو آهي.

اهو اڳ ۾ ئي ڄاڻي ٿو ته ڪيئن نه صرف تازه ڪاريون موڪلڻ، پر پڻ هڪ VPN اڳ ۾ ئي ٺهيل آهي ۽ هڪ IoT ماحول ۾ استعمال لاء ٺهيل آهي.

۽ تازو ئي، انهن کي پڻ آزاد ڪيو ويو آهي هارڊويئر، جيڪو آساني سان انهن جي ماحولياتي نظام سان ڳنڍيندو آهي.

اي، گم ٿيل اسڪوٽر بابت ڇا؟

تنهنڪري اسڪوٽر، "رالف" بغير ڪنهن نشان جي غائب ٿي ويو.

اسان فوري طور تي اسان جي ”ايڊمن پينل“ ۾ نقشي کي ڏسڻ لاءِ ڊوڙيا، InfluxDB کان GPS ميٽرڪس ڊيٽا سان.

مانيٽرنگ ڊيٽا جي مهرباني، اسان آسانيءَ سان اهو طئي ڪيو ته اسڪوٽر گذريل ڏينهن 21:00 جي لڳ ڀڳ پارڪنگ واري جاءِ مان نڪري، اڌ ڪلاڪ تائين ڪنهن علائقي ڏانهن هليو ۽ ڪجهه جرمن گهر جي اڳيان صبح 5 وڳي تائين پارڪ ڪيو ويو.

صبح 5 وڳي کان پوءِ، ڪا به مانيٽرنگ ڊيٽا نه ملي هئي- ان جو مطلب هو ته يا ته اضافي بيٽري مڪمل طور تي ڊسچارج ٿي وئي هئي، يا حملي آور آخرڪار اهو سمجهي ورتو ته اسڪوٽر مان سمارٽ هارڊويئر کي ڪيئن هٽايو وڃي.
ان جي باوجود پوليس کي اڃا تائين ان پتي تي سڏيو ويو جتي اسڪوٽر موجود هو. اسڪوٽر به نه هئي.

پر گهر جو مالڪ به ان ڳالهه تي حيران ٿي ويو، ڇاڪاڻ ته هو واقعي هن اسڪوٽر تي گذريل رات آفيس مان گهر پهتو.

جيئن ئي ٿيو ته، هڪ سهارو سهارو آيو ۽ اسڪوٽر کي کنيو، ڏٺو ته ان جي اضافي بيٽري مڪمل طور تي ڊسچارج ٿي چڪي هئي ۽ ان کي (پير تي) پارڪنگ لاٽ ڏانهن وٺي ويو. ۽ اضافي بيٽري نمي جي ڪري ناڪام ٿي.

اسان پاڻ کان اسڪوٽر چوري ڪيو. رستي ۾، مون کي خبر ناهي ته ڪيئن ۽ ڪنهن پوليس ڪيس سان مسئلو حل ڪيو، پر مانيٽرنگ مڪمل طور تي ڪم ڪيو ...

جو ذريعو: www.habr.com