Bir yil oldin biz reklama loyihasining pilot versiyasini ishga tushirdik .
Dastlab, loyiha "Road-To-Barselona" deb nomlangan, keyinchalik u "Road-To-Berlin" (shuning uchun skrinshotlarda R2B) bo'lib, oxirida xRide deb nomlangan.
Loyihaning asosiy g'oyasi shundan iborat edi: markazlashtirilgan avtomobil yoki skuterlarni ijaraga berish xizmatiga ega bo'lish o'rniga (biz skuterlar/skuterlar haqida emas, balki elektr mototsikllari haqida gapiramiz) markazlashtirilmagan ijara uchun platforma yaratmoqchi edik. Biz duch kelgan qiyinchiliklar haqida .
Dastlab, loyiha avtomobillarga e'tibor qaratdi, ammo muddatlar, ishlab chiqaruvchilar bilan juda uzoq aloqalar va ko'plab xavfsizlik cheklovlari tufayli uchuvchi uchun elektr skuterlar tanlangan.
Foydalanuvchi telefonga iOS yoki Android ilovasini oʻrnatdi, oʻziga yoqqan skuterga yaqinlashdi, shundan soʻng telefon va skuter oʻrtasida tengdosh aloqasi oʻrnatildi, ETH almashildi va foydalanuvchi skuterni yoqish orqali sayohatni boshlashi mumkin edi. telefon. Sayohat yakunida, shuningdek, telefondagi foydalanuvchi hamyonidan Ethereum yordamida sayohat haqini to'lash mumkin edi.
Skuterlardan tashqari, foydalanuvchi ilovada "aqlli zaryadlovchilar" ni ko'rdi, unga tashrif buyurib, agar u kam bo'lsa, joriy batareyani o'zi o'zgartirishi mumkin edi.
Umuman olganda, bizning uchuvchimiz o'tgan yilning sentabr oyida Germaniyaning ikki shahrida: Bonn va Berlinda ishga tushirilgan.
Va keyin, bir kuni, Bonnda, erta tongda, bizning qo'llab-quvvatlash guruhimiz (skuterlarni ish holatida saqlash uchun saytda joylashgan) ogohlantirildi: skuterlardan biri izsiz g'oyib bo'ldi.
Uni qanday topish va qaytarish kerak?
Ushbu maqolada men bu haqda gaplashaman, lekin birinchi navbatda - biz o'z IoT platformamizni qanday qurganimiz va uni qanday kuzatganimiz haqida.
Nima va nima uchun monitoring qilish kerak: skuterlar, infratuzilma, zaryadlash stantsiyalari?
Xo'sh, biz loyihamizda nimani kuzatmoqchi edik?
Birinchidan, bu skuterlarning o'zi - elektr skuterlarning o'zi juda qimmat, siz bunday loyihani etarlicha tayyorlanmasdan boshlay olmaysiz; iloji bo'lsa, skuterlar haqida iloji boricha ko'proq ma'lumot to'plashni xohlaysiz: ularning joylashuvi, zaryad darajasi haqida. , va boshqalar.
Bundan tashqari, men o'zimizning IT infratuzilmamiz - ma'lumotlar bazalari, xizmatlar va ularning ishlashi uchun zarur bo'lgan barcha narsalarning holatini kuzatib borishni istardim. Shuningdek, agar ular buzilgan yoki to'liq batareyalari tugasa, "aqlli zaryadlovchilar" holatini kuzatish kerak edi.
Skuterlar
Bizning skuterlarimiz nima edi va ular haqida nimani bilmoqchi edik?
Birinchi va eng muhimi - bu GPS koordinatalari, chunki ular tufayli biz ular qayerda va qayerda harakatlanayotganini tushunishimiz mumkin.
Keyingi - batareya zaryadi, buning yordamida biz skuterlarni zaryadlash tugashini aniqlashimiz va sharbat chiqargichni yuborishimiz yoki hech bo'lmaganda foydalanuvchini ogohlantirishimiz mumkin.
Albatta, bizning apparat komponentlarimiz bilan nima sodir bo'layotganini tekshirish kerak:
- bluetooth ishlaydimi?
- GPS modulining o'zi ishlaydimi?
- GPS noto'g'ri koordinatalarni yuborishi va tiqilib qolishi bilan bog'liq muammoga duch keldik va buni faqat skuterda qo'shimcha tekshirishlar orqali aniqlash mumkin edi,
va muammoni hal qilish uchun imkon qadar tezroq qo'llab-quvvatlash xizmatiga xabar bering
- GPS noto'g'ri koordinatalarni yuborishi va tiqilib qolishi bilan bog'liq muammoga duch keldik va buni faqat skuterda qo'shimcha tekshirishlar orqali aniqlash mumkin edi,
Va nihoyat: operatsion tizim va protsessordan boshlab, tarmoq va disk yuklanishidan boshlab, o'zimizning modullarimizni tekshirish bilan yakunlangan dasturiy ta'minotni tekshirish (, ).
Uskuna
Bizning "temir" qismimiz nima edi?
Eng qisqa vaqt oralig'ini va tezkor prototiplash zarurligini hisobga olgan holda, biz amalga oshirish va komponentlarni tanlashning eng oson variantini tanladik - Raspberry Pi.
Rpi-ning o'ziga qo'shimcha ravishda bizda maxsus taxta (yakuniy yechimni yig'ish jarayonini tezlashtirish uchun o'zimiz ishlab chiqdik va Xitoydan buyurtma qildik) va komponentlar to'plami - o'rni (skuterni yoqish / o'chirish uchun), batareya zaryadini o'quvchi, modem, antennalar. Bularning barchasi maxsus "xRide qutisiga" ixcham tarzda qadoqlangan.
Shuni ham ta'kidlash kerakki, butun quti qo'shimcha quvvat banki tomonidan quvvatlangan, u o'z navbatida skuterning asosiy akkumulyatoridan quvvat olgan.
Bu sayohat tugagandan so'ng ham monitoringdan foydalanish va skuterni yoqish imkonini berdi, chunki kontaktni kalitini "o'chirish" holatiga o'girgandan so'ng darhol asosiy batareya o'chirilgan.
Docker? Oddiy Linuxmi? va joylashtirish
Keling, monitoringga qaytaylik, shuning uchun Raspberry - bizda nima bor?
Komponentlarni jismoniy qurilmalarga joylashtirish, yangilash va etkazib berish jarayonini tezlashtirish uchun biz foydalanmoqchi bo'lgan birinchi narsalardan biri bu Docker edi.
Afsuski, RPi-da Docker ishlayotgan bo'lsa ham, ayniqsa energiya iste'moli nuqtai nazaridan juda ko'p xarajatlarga ega ekanligi tezda ma'lum bo'ldi.
"Mahalliy" operatsion tizimdan foydalanishdagi farq unchalik kuchli bo'lmasa ham, zaryadni juda tez yo'qotish ehtimolidan ehtiyot bo'lish uchun etarli edi.
Ikkinchi sabab Node.js (sic!) dagi hamkor kutubxonalarimizdan biri edi - tizimning Go/C/C++ da yozilmagan yagona komponenti.
Kutubxona mualliflari biron bir "ona" tilda ishlaydigan versiyani taqdim etishga vaqtlari yo'q edi.
Tugunning o'zi nafaqat unumdorligi past bo'lgan qurilmalar uchun eng oqlangan yechim emas, balki kutubxonaning o'zi ham resurslarga juda och edi.
Biz shuni tushundikki, agar xohlasak ham, Docker-dan foydalanish biz uchun juda katta yuk bo'ladi. Tanlov mahalliy OS foydasiga qilingan va to'g'ridan-to'g'ri uning ostida ishlaydi.
OS
Natijada, biz yana OS sifatida eng oddiy variantni tanladik va Raspbian (Pi uchun Debian qurish) dan foydalandik.
Biz barcha dasturiy ta'minotimizni Go'da yozamiz, shuning uchun tizimimizda asosiy apparat agent modulini ham Go'da yozdik.
Aynan u GPS, Bluetooth bilan ishlash, zaryadni o'qish, skuterni yoqish va hokazolar uchun javobgardir.
Joylashtirish
Qurilmalarga yangilanishlarni (OTA) etkazib berish mexanizmini joriy qilish zarurati haqida savol darhol paydo bo'ldi - bizning agentimiz/ilovaning o'ziga ham, OS/proshivkaning o'ziga yangilanishlar (chunki agentning yangi versiyalari yadro yangilanishini talab qilishi mumkin) yoki tizim komponentlari, kutubxonalar va boshqalar).
Bozorni uzoq tahlil qilgandan so'ng, qurilmaga yangilanishlarni etkazib berish uchun juda ko'p echimlar mavjudligi ma'lum bo'ldi.
Supd/SWUpdate/OSTree kabi nisbatan oddiy, asosan yangilash/ikki yuklashga yo'naltirilgan yordamchi dasturlardan Mender va Balena kabi to'liq huquqli platformalargacha.
Avvalo, biz yakuniy echimlarga qiziqamiz, deb qaror qildik, shuning uchun tanlov darhol platformalarga tushdi.
Juda ham BalenaEngine ichida aslida bir xil Dockerdan foydalanganligi sababli chiqarib tashlandi.
Ammo shuni ta'kidlaymanki, shunga qaramay, biz ularning mahsulotidan doimiy ravishda foydalandik SD-kartalardagi flesh-proshivka uchun - buning uchun oddiy va juda qulay yordamchi dastur.
Shuning uchun, oxir-oqibat, tanlov tushdi . Mender - bu mikrodasturlarni yig'ish, etkazib berish va o'rnatish uchun to'liq platforma.
Umuman olganda, platforma ajoyib ko'rinadi, ammo mender builder yordamida proshivkamizning to'g'ri versiyasini yaratish uchun bizga bir yarim hafta vaqt ketdi.
Biz undan foydalanishning nozik jihatlariga qanchalik ko'p sho'ng'ilsak, uni to'liq ishga tushirish uchun bizdan ko'ra ko'proq vaqt kerak bo'lishi aniq bo'ldi.
Afsuski, bizning qattiq muddatlarimiz Menderdan foydalanishdan voz kechishga va undan ham oddiyroqni tanlashga majbur bo'lganimizni anglatardi.
E'tirof etiladi
Bizning vaziyatimizda eng oddiy yechim Ansible-dan foydalanish edi. Boshlash uchun bir nechta o'yin kitoblari etarli edi.
Ularning mohiyati shundan iborat ediki, biz oddiygina xostdan (CI server) ssh orqali malinalarimizga ulandik va ularga yangilanishlarni tarqatdik.
Eng boshida hamma narsa oddiy edi - siz qurilmalar bilan bir tarmoqda bo'lishingiz kerak edi, quyish Wi-Fi orqali amalga oshirildi.
Ofisda bir xil tarmoqqa ulangan o'nlab sinov malinalari mavjud edi, har bir qurilma Ansible Inventory-da ko'rsatilgan statik IP-manzilga ega edi.
Bizning monitoring agentimizni oxirgi qurilmalarga yetkazib bergan Ansible edi
3G / LTE
Afsuski, Ansible uchun ushbu foydalanish holati bizda haqiqiy skuterlarga ega bo'lgunga qadar faqat ishlab chiqish rejimida ishlashi mumkin edi.
Chunki skuterlar, siz tushunganingizdek, doimiy ravishda tarmoq orqali yangilanishlarni kutib, bitta Wi-Fi routerga ulangan holda o'tirmaydi.
Aslida, skuterlar mobil 3G/LTE-dan boshqa hech qanday aloqaga ega bo'lolmaydi (va hatto har doim ham emas).
Bu darhol past ulanish tezligi va beqaror aloqa kabi ko'plab muammolar va cheklovlarni keltirib chiqaradi.
Lekin eng muhimi shundaki, 3G/LTE tarmog'ida biz tarmoqqa tayinlangan statik IP-ga shunchaki tayanolmaymiz.
Bu qisman ba'zi SIM-karta provayderlari tomonidan hal qilinadi; hatto statik IP-manzilli IoT qurilmalari uchun mo'ljallangan maxsus SIM-kartalar ham mavjud. Ammo bizda bunday SIM-kartalarga kirish imkoni yo'q edi va IP manzillardan foydalana olmadik.
Albatta, IP-manzillarni ro'yxatdan o'tkazish yoki konsul kabi bir joyda xizmatlarni ochish g'oyalari bor edi, ammo biz bunday g'oyalardan voz kechishga majbur bo'ldik, chunki bizning testlarimizda IP-manzil juda tez-tez o'zgarishi mumkin edi, bu esa katta beqarorlikka olib keldi.
Shu sababli, ko'rsatkichlarni etkazib berishda eng qulay foydalanish biz kerakli ko'rsatkichlar uchun qurilmalarga o'tadigan tortish modelidan foydalanish emas, balki ko'rsatkichlarni qurilmadan to'g'ridan-to'g'ri serverga etkazib berish bo'ladi.
VPN
Ushbu muammoni hal qilish uchun biz VPN-ni tanladik - xususan .
Mijozlar (skuterlar) tizimning boshida VPN serveriga ulangan va ularga ulanish imkoniga ega bo'lgan. Ushbu tunnel yangilanishlarni etkazish uchun ishlatilgan.
Nazariy jihatdan, xuddi shu tunnel monitoring uchun ishlatilishi mumkin edi, ammo bunday ulanish oddiy surishdan ko'ra murakkabroq va kamroq ishonchli edi.
Bulutli manbalar
Nihoyat, bulut xizmatlarimiz va ma'lumotlar bazalarimizni kuzatishimiz kerak, chunki biz ular uchun Kubernetes-dan foydalanamiz, bu klasterda monitoringni o'rnatish imkon qadar sodda bo'lishi uchun. Ideal holda, foydalanish , chunki joylashtirish uchun biz ko'p hollarda foydalanamiz. Va, albatta, bulutni kuzatish uchun siz skuterlarning o'zlari kabi echimlardan foydalanishingiz kerak.
Berilgan
Oh, biz tavsifni saralab oldik, keling, oxir-oqibat bizga kerak bo'lgan narsalar ro'yxatini tuzamiz:
- Tez yechim, chunki ishlab chiqish jarayonida monitoring allaqachon zarur
- Hajmi/miqdori - ko'plab ko'rsatkichlar kerak
- Jurnallarni yig'ish talab qilinadi
- Ishonchlilik - muvaffaqiyatli ishga tushirish uchun ma'lumotlar juda muhimdir
- Siz tortish modelini ishlata olmaysiz - sizga surish kerak
- Bizga nafaqat apparat, balki bulutning ham yagona monitoringi kerak
Yakuniy rasm shunga o'xshash edi
Stak tanlash
Shunday qilib, biz monitoring stekini tanlash masalasiga duch keldik.
Avvalo, biz bir vaqtning o'zida barcha talablarimizni qoplaydigan, lekin ayni paytda undan foydalanishni ehtiyojlarimizga moslashtira oladigan darajada moslashuvchan bo'lgan eng to'liq all-in-one yechimni qidirdik. Shunga qaramay, bizda apparat, arxitektura va muddatlar bo'yicha ko'plab cheklovlar mavjud edi.
To'liq huquqli tizimlardan boshlab juda ko'p monitoring echimlari mavjud , yoki va Filo boshqaruvi uchun tayyor echimlar bilan yakunlanadi.
Dastlab, ikkinchisi biz uchun ideal echim bo'lib tuyuldi, ammo ba'zilarida to'liq monitoring yo'q edi, boshqalari bepul versiyalarning imkoniyatlarini keskin cheklangan, boshqalari esa bizning "istaklarimizni" qondira olmadi yoki bizning stsenariylarimizga mos keladigan darajada moslashuvchan emas edi. Ba'zilar shunchaki eskirgan.
Bir qator shunga o'xshash echimlarni tahlil qilib, biz tezda shunga o'xshash stekni o'zimiz yig'ish osonroq va tezroq bo'ladi degan xulosaga keldik. Ha, bu butunlay tayyor Fleet boshqaruv platformasini joylashtirishdan ko'ra biroz murakkabroq bo'ladi, ammo biz murosaga kelishimiz shart emas.
Deyarli shubhasiz, echimlarning juda ko'p ko'pligida bizga to'liq mos keladigan tayyor echim bor, ammo bizning holatlarimizda ma'lum bir stekni o'zimiz yig'ish va uni "o'zimiz uchun" sozlashdan ko'ra tezroq bo'ldi. tayyor mahsulotlarni sinovdan o'tkazish.
Bularning barchasi bilan biz butun monitoring platformasini o'zimiz yig'ishga intilmadik, lekin ularni moslashuvchan tarzda sozlash qobiliyatiga ega bo'lgan eng funktsional "tayyor" steklarni qidirdik.
(B) ELK?
Aslida ko'rib chiqilgan birinchi yechim taniqli ELK stek edi.
Aslida uni BELK deb atash kerak, chunki hammasi Beatsdan boshlanadi -
Albatta, ELK - monitoring sohasidagi eng mashhur va kuchli echimlardan biri va undan ham ko'proq jurnallarni yig'ish va qayta ishlash.
Biz ELK jurnallarini to'plash va Prometeydan olingan o'lchovlarni uzoq muddatli saqlash uchun ishlatilishini maqsad qilgan edik.
Vizualizatsiya uchun siz Grafan-dan foydalanishingiz mumkin.
Aslida, yangi ELK stek o'lchovlarni mustaqil ravishda to'plashi mumkin (metricbeat) va Kibana ham ularni ko'rsatishi mumkin.
Shunga qaramay, ELK dastlab jurnallardan o'sdi va hozirgacha ko'rsatkichlarning funksionalligi bir qator jiddiy kamchiliklarga ega:
- Prometeydan sezilarli darajada sekinroq
- Prometeyga qaraganda ancha kamroq joylarga integratsiyalashgan
- Ular uchun ogohlantirishlarni o'rnatish qiyin
- Ko'rsatkichlar juda ko'p joy egallaydi
- Kibanda ko'rsatkichlar bilan asboblar panelini o'rnatish Grafanga qaraganda ancha murakkab
Umuman olganda, ELK-dagi ko'rsatkichlar og'ir va boshqa echimlardagi kabi qulay emas, ulardan hozirda Prometeydan ko'proq narsa bor: TSDB, Victoria Metrics, Cortex va boshqalar. Albatta, men zudlik bilan to'laqonli yaxlit yechimga ega bo'lishni juda xohlardim, lekin metrik beat holatida juda ko'p murosalar bor edi.
Va ELK stekining o'zi bir qator qiyin daqiqalarga ega:
- Agar siz juda katta hajmdagi ma'lumotlarni to'plasangiz, bu og'ir, ba'zan hatto juda og'ir
- Siz uni "qanday pishirishni bilishingiz" kerak - siz uni o'lchashingiz kerak, lekin buni qilish ahamiyatsiz emas.
- Bepul versiya olib tashlangan - bepul versiyada oddiy ogohlantirish mavjud emas va tanlash vaqtida autentifikatsiya yo'q edi.
Aytishim kerakki, yaqinda oxirgi nuqta yaxshilandi va qo'shimcha ravishda (autentifikatsiyani o'z ichiga olgan holda) narxlash modelining o'zi o'zgara boshladi.
Ammo biz ushbu yechimni ishlatmoqchi bo'lganimizda, hech qanday ogohlantirish yo'q edi.
Ehtimol, biz ElastAlert yoki boshqa jamoat echimlari yordamida biror narsa yaratishga harakat qilgan bo'lardik, ammo biz hali ham boshqa alternativalarni ko'rib chiqishga qaror qildik.
Loki - Grafana - Prometey
Ayni paytda, yaxshi yechim faqat Prometeyga asoslangan monitoring to'plamini o'lchash provayderi sifatida, loglar uchun Loki va vizualizatsiya uchun bir xil Grafana-dan foydalanishingiz mumkin.
Afsuski, loyihaning sotuv sinovi boshlanganda (19 yil sentyabr-oktyabr) Loki hali ham 0.3-0.4 beta-versiyasida edi va ishlab chiqish boshlanganda uni ishlab chiqarish yechimi deb hisoblash mumkin emas edi. umuman.
Hali jiddiy loyihalarda Loki-dan foydalanish tajribasiga ega emasman, lekin aytishim mumkinki, Promtail (jurnallarni yig'ish agenti) kubernetlarda ham yalang'och metall, ham podalar uchun juda yaxshi ishlaydi.
BELK
Ehtimol, ELK stekiga eng munosib (yagona?) to'liq xususiyatli alternativni endi faqat TICK stek deb atash mumkin - Telegraf, InfluxDB, Chronograf, Kapacitor.
Men quyida barcha komponentlarni batafsilroq tasvirlab beraman, lekin umumiy fikr quyidagicha:
- Telegraf - ko'rsatkichlarni yig'ish agenti
- InfluxDB - ko'rsatkichlar ma'lumotlar bazasi
- Kapacitor - ogohlantirish uchun real vaqtda ko'rsatkichlar protsessor
- Chronograf - vizualizatsiya uchun veb-panel
InfluxDB, Kapacitor va Chronograf uchun biz ularni joylashtirgan rasmiy rul jadvallari mavjud.
Shuni ta'kidlash kerakki, Influx 2.0 (beta) ning so'nggi versiyasida Kapacitor va Chronograf InfluxDB tarkibiga kirdi va endi alohida mavjud emas.
telegraf
davlat mashinasida ko'rsatkichlarni yig'ish uchun juda engil agent.
U hamma narsani katta miqdorda kuzatishi mumkin, dan uchun
server .
U bir qator ajoyib afzalliklarga ega:
- Tez va engil (Go-da yozilgan)
- Minimal miqdordagi resurslarni iste'mol qiladi
- Sukut bo'yicha ko'rsatkichlarni surish
- Barcha kerakli ko'rsatkichlarni to'playdi
- Hech qanday sozlamalarsiz tizim ko'rsatkichlari
- Sensorlardan olingan ma'lumotlar kabi apparat ko'rsatkichlari
- O'z ko'rsatkichlaringizni qo'shish juda oson
- Ko'plab plaginlar qutidan chiqdi
- Jurnallarni to'playdi
Push ko'rsatkichlari biz uchun zarur bo'lganligi sababli, boshqa barcha afzalliklar yoqimli qo'shimchalardan ko'proq edi.
Agentning o'zi tomonidan jurnallarni yig'ish ham juda qulay, chunki jurnallarni yozish uchun qo'shimcha yordam dasturlarini ulashning hojati yo'q.
Influx, agar foydalansangiz, jurnallar bilan ishlash uchun eng qulay tajribani taklif qiladi .
Telegraf, odatda, ICK stekining qolgan qismini ishlatmasangiz ham, ko'rsatkichlarni yig'ish uchun ajoyib agentdir.
Ko'pchilik uni qulaylik uchun ELK va boshqa turli xil vaqt seriyali ma'lumotlar bazalari bilan kesib o'tadi, chunki u deyarli hamma joyda ko'rsatkichlarni yozishi mumkin.
InfluxDB
InfluxDB - bu TICK stekining asosiy yadrosi, ya'ni ko'rsatkichlar uchun vaqt seriyali ma'lumotlar bazasi.
Ko'rsatkichlarga qo'shimcha ravishda, Influx jurnallarni ham saqlashi mumkin, garchi u uchun jurnallar aslida bir xil ko'rsatkichlar bo'lsa-da, faqat odatiy raqamli ko'rsatkichlar o'rniga asosiy funktsiya jurnal matni qatori tomonidan amalga oshiriladi.
InfluxDB ham Go-da yozilgan va bizning (eng kuchli emas) klasterimizdagi ELK-ga qaraganda ancha tezroq ishlaydi.
Influx-ning ajoyib afzalliklaridan biri, shuningdek, biz juda faol foydalangan ma'lumotlar so'rovlari uchun juda qulay va boy APIni o'z ichiga oladi.
Kamchiliklari - $$$ yoki masshtablashmi?
TICK stekida biz aniqlagan bitta kamchilik bor - bu qimmat. Bundan ham ko'proq.
Pulli versiyada bepul versiyada yo'q nima bor?
Biz tushunganimizdek, TICK stekining pullik versiyasi va bepul versiyasi o'rtasidagi yagona farq bu masshtablash qobiliyatidir.
Ya'ni, siz faqat mavjud bo'lgan klasterni yaratishingiz mumkin .
Agar siz to'liq huquqli HAni xohlasangiz, siz pul to'lashingiz yoki ba'zi tayoqchalardan foydalanishingiz kerak. Bir nechta jamoat echimlari mavjud - masalan vakolatli yechim kabi ko'rinadi, lekin u ishlab chiqarish uchun mos emas, deb yozilgan, shuningdek
- NATS orqali ma'lumotlarni uzatish bilan oddiy yechim (uni ham o'lchash kerak, ammo buni hal qilish mumkin).
Afsuski, ikkalasi ham tashlab ketilganga o'xshaydi - yangi majburiyatlar yo'q, menimcha, muammo Influx 2.0 ning yangi versiyasining yaqinda kutilayotgan chiqarilishi bo'lib, unda ko'p narsalar boshqacha bo'ladi (bu haqida hech qanday ma'lumot yo'q) unda hali masshtablash).
Rasmiy ravishda bepul versiyasi mavjud - aslida, bu ibtidoiy HA, lekin faqat muvozanat orqali,
chunki barcha ma'lumotlar yuk balansi orqasidagi barcha InfluxDB nusxalariga yoziladi.
Uning bir oz bor qayta yozish nuqtalari bilan bog'liq mumkin bo'lgan muammolar va o'lchovlar uchun asoslarni oldindan yaratish zarurati kabi
(InfluxDB bilan normal ish paytida avtomatik ravishda sodir bo'ladi).
Buning ustiga , bu sizga kerak bo'lmasligi mumkin bo'lgan takroriy ko'rsatkichlar (ham qayta ishlash, ham saqlash) uchun qo'shimcha xarajatlarni bildiradi, lekin ularni ajratishning hech qanday usuli yo'q.
Viktoriya ko'rsatkichlari?
Natijada, biz pullik masshtabdan tashqari hamma narsada TICK stekidan to'liq qoniqqanimizga qaramay, qolgan T_CK komponentlarini qoldirib, InfluxDB ma'lumotlar bazasini almashtira oladigan bepul echimlar mavjudligini ko'rishga qaror qildik.
Vaqt seriyali ma'lumotlar bazalari juda ko'p, ammo eng istiqbollii Victoria Metrics bo'lib, u bir qator afzalliklarga ega:
- Tez va oson, hech bo'lmaganda natijalarga ko'ra
- Klaster versiyasi mavjud, u haqida hozir ham yaxshi sharhlar mavjud
- U parchalashi mumkin
- InfluxDB protokolini qo'llab-quvvatlaydi
Biz Viktoriya asosida to'liq moslashtirilgan stek yaratish niyatimiz yo'q edi va asosiy umid biz uni InfluxDB uchun ochiladigan almashtirish sifatida ishlatishimiz mumkin edi.
Afsuski, bu mumkin emas, InfluxDB protokoli qo'llab-quvvatlansa ham, u faqat ko'rsatkichlarni yozib olish uchun ishlaydi - faqat Prometey API "tashqarida" mavjud, ya'ni unga Chronografni o'rnatib bo'lmaydi.
Bundan tashqari, ko'rsatkichlar uchun faqat raqamli qiymatlar qo'llab-quvvatlanadi (biz maxsus ko'rsatkichlar uchun satr qiymatlaridan foydalandik - bu haqda batafsil bo'limda ).
Shubhasiz, xuddi shu sababga ko'ra, VM Influx kabi jurnallarni saqlay olmaydi.
Shuni ham ta'kidlash kerakki, optimal echimni izlash vaqtida Victoria Metrics hali unchalik mashhur emas edi, hujjatlar ancha kichikroq va funksionallik zaifroq edi.
(Klaster versiyasi va shardingning batafsil tavsifini eslay olmayman).
Asosiy tanlov
Natijada, uchuvchi uchun biz hali ham bitta InfluxDB tuguniga chek qo'yishga qaror qilindi.
Ushbu tanlovning bir nechta asosiy sabablari bor edi:
- Bizga TICK stekining butun funksiyasi juda yoqdi
- Biz allaqachon uni joylashtirishga muvaffaq bo'ldik va u juda yaxshi ishladi
- Muddatlar tugaydi va boshqa variantlarni sinab ko'rish uchun ko'p vaqt qolmadi.
- Bunday og'ir yukni kutmagan edik
Uchuvchining birinchi bosqichi uchun bizda ko'plab skuterlar yo'q edi va ishlab chiqish jarayonida sinovlar unumdorlik bilan bog'liq muammolarni aniqlamadi.
Shuning uchun, biz ushbu loyiha uchun bitta Influx tugunini masshtablashtirmasdan etarli bo'lishiga qaror qildik (oxiridagi xulosalarga qarang).
Biz stek va asos haqida qaror qildik - endi TICK stekining qolgan komponentlari haqida.
Kondensator
Kapacitor TICK stekining bir qismi bo‘lib, real vaqt rejimida ma’lumotlar bazasiga kiradigan ko‘rsatkichlarni kuzatib borishi va qoidalar asosida turli amallarni bajarishi mumkin bo‘lgan xizmatdir.
Umuman olganda, u potentsial anomaliyalarni kuzatish va mashinani o'rganish uchun vosita sifatida joylashtirilgan (bu funktsiyalar talabga ega ekanligiga ishonchim komil emas), lekin undan foydalanishning eng keng tarqalgan holati - ogohlantirish.
Biz undan bildirishnomalar uchun foydalanganmiz. Muayyan skuter oflayn rejimga o'tganda biz Slack ogohlantirishlarini o'rnatdik va xuddi shu narsa aqlli zaryadlovchilar va muhim infratuzilma komponentlari uchun ham amalga oshirildi.
Bu muammolarga tezda javob berish, shuningdek, hamma narsa normal holatga qaytganligi haqida bildirishnomalarni olish imkonini berdi.
Oddiy misol: "quti"mizni quvvatlantirish uchun qo'shimcha batareya ishlamay qoldi yoki biron sababga ko'ra quvvati tugadi; shunchaki yangisini o'rnatish orqali, bir muncha vaqt o'tgach, biz skuterning ishlashi tiklanganligi haqida xabar olishimiz kerak.
Influx 2.0 da Kapasitor JB tarkibiga kirdi
Xronograf
Men monitoring uchun juda ko'p turli xil UI echimlarini ko'rdim, lekin shuni aytishim mumkinki, funksionallik va UX nuqtai nazaridan hech narsa Chronograf bilan taqqoslanmaydi.
Biz TICK stekidan, g'alati, veb-interfeys sifatida Grafan bilan foydalanishni boshladik.
Men uning funksionalligini ta'riflamayman, hamma narsa o'rnatish uchun keng imkoniyatlarni biladi.
Biroq, Grafana hali ham butunlay universal asbob bo'lib, Chronograf asosan Influx bilan foydalanish uchun mo'ljallangan.
Va, albatta, bu tufayli Chronograf ancha aqlli va qulay funksionallikni ta'minlay oladi.
Ehtimol, Chronograf bilan ishlashning asosiy qulayligi shundaki, siz Explore orqali InfluxDB-ning ichki qismini ko'rishingiz mumkin.
Aftidan, Grafana deyarli bir xil funktsiyaga ega, ammo aslida Chronograf-da asboblar panelini o'rnatish sichqonchani bir necha marta bosish bilan amalga oshirilishi mumkin (bir vaqtning o'zida u yerdagi vizualizatsiyaga qarang), Grafana-da esa ertami-kechmi siz hali ham shunday bo'lasiz. JSON konfiguratsiyasini tahrirlash uchun (albatta Chronograf qo'lda sozlangan dashalarni yuklash va kerak bo'lganda ularni JSON sifatida tahrirlash imkonini beradi - lekin ularni UIda yaratganimdan so'ng ularga hech qachon tegmasligim kerak edi).
Kibana boshqaruv paneli va ular uchun boshqaruv elementlarini yaratish uchun ancha boy imkoniyatlarga ega, ammo bunday operatsiyalar uchun UX juda murakkab.
Qulay boshqaruv panelini yaratish uchun yaxshi tushunish kerak bo'ladi. Va Chronograf asboblar panelining funksionalligi kamroq bo'lsa-da, ularni yaratish va sozlash ancha sodda.
Boshqaruv panellarining o'zlari, yoqimli vizual uslubdan tashqari, Grafana yoki Kibanadagi asboblar panelidan farq qilmaydi:
So'rov oynasi shunday ko'rinadi:
Shuni ta'kidlash kerakki, InfluxDB ma'lumotlar bazasidagi maydonlar turlarini bilish, xronografning o'zi ba'zan avtomatik ravishda so'rov yozishda yoki o'rtacha kabi to'g'ri yig'ish funktsiyasini tanlashda yordam berishi mumkin.
Va, albatta, Chronograf jurnallarni ko'rish uchun imkon qadar qulaydir. Bu shunday ko'rinadi:
Odatiy bo'lib, Influx jurnallari syslog-dan foydalanishga moslashtirilgan va shuning uchun ular muhim parametrga ega - jiddiylik.
Yuqoridagi grafik ayniqsa foydalidir, unda siz sodir bo'lgan xatolarni ko'rishingiz mumkin va rang jiddiylik darajasi yuqoriroq ekanligini darhol aniq ko'rsatadi.
Bir necha marta biz muhim xatolarni shu tarzda aniqladik, oxirgi haftadagi jurnallarni ko'rib chiqdik va qizil boshoqni ko'rdik.
Albatta, bunday xatolar uchun ogohlantirishlarni o'rnatish ideal bo'lar edi, chunki bizda buning uchun hamma narsa bor edi.
Biz buni hatto bir muncha vaqt yoqdik, lekin uchuvchini tayyorlash jarayonida biz juda ko'p xatolarga yo'l qo'yganimiz (shu jumladan, LTE tarmog'ining mavjud emasligi kabi tizim xatolari) Slack kanalini ham "spam" qilgani ma'lum bo'ldi. ko'p, hech qanday muammosiz. katta foyda.
To'g'ri yechim bu turdagi xatolarning ko'pchiligini hal qilish, ular uchun jiddiylikni sozlash va shundan keyingina ogohlantirishni yoqish bo'ladi.
Shunday qilib, faqat yangi yoki muhim xatolar Slack-ga joylashtiriladi. Qattiq muddatlarni hisobga olgan holda, bunday sozlash uchun etarli vaqt yo'q edi.
Autentifikatsiya
Shuni ham ta'kidlash kerakki, Chronograf autentifikatsiya sifatida OAuth va OIDC-ni qo'llab-quvvatlaydi.
Bu juda qulay, chunki uni serveringizga osongina biriktirish va to'liq huquqli SSO yaratish imkonini beradi.
Bizning holatda, server edi — u monitoringga ulanish uchun ishlatilgan, biroq xuddi shu server skuterlarni autentifikatsiya qilish va orqa tomonga so'rovlarni tekshirish uchun ham ishlatilgan.
"Admin"
Men tasvirlab beradigan oxirgi komponent bu Vue-da o'zimiz yozgan "administrator panelimiz".
Asosan, bu shunchaki mustaqil xizmat bo'lib, u bir vaqtning o'zida o'z ma'lumotlar bazalarimiz, mikroservislarimiz va InfluxDB ko'rsatkichlari ma'lumotlaridan skuter ma'lumotlarini namoyish etadi.
Bundan tashqari, u erga favqulodda qayta ishga tushirish yoki qo'llab-quvvatlash jamoasi uchun masofadan turib qulfni ochish kabi ko'plab ma'muriy funktsiyalar ko'chirildi.
Xaritalar ham bor edi. Men allaqachon Chronograf o'rniga Grafana bilan boshlaganimizni aytib o'tdim - chunki Grafana uchun xaritalar plaginlar ko'rinishida mavjud bo'lib, ularda biz skuterlarning koordinatalarini ko'rishimiz mumkin edi. Afsuski, Grafana uchun xarita vidjetlarining imkoniyatlari juda cheklangan va natijada hozirgi vaqtda nafaqat koordinatalarni ko'rish, balki ko'rsatish uchun bir necha kun ichida o'z veb-ilovangizni xaritalar bilan yozish ancha osonlashdi. skuter tomonidan bosib o'tilgan marshrut, xaritadagi ma'lumotlarni filtrlash imkoniyati va boshqalar (biz oddiy asboblar panelida sozlay olmagan barcha funktsiyalar).
Influxning yuqorida aytib o'tilgan afzalliklaridan biri bu o'z ko'rsatkichlaringizni osongina yaratish qobiliyatidir.
Bu uni turli xil stsenariylar uchun ishlatishga imkon beradi.
Biz u erda barcha foydali ma'lumotlarni yozib olishga harakat qildik: batareya zaryadi, qulf holati, sensorning ishlashi, bluetooth, GPS va boshqa ko'plab sog'liq tekshiruvlari.
Bularning barchasini administrator panelida ko'rsatdik.
Albatta, biz uchun eng muhim mezon skuterning ish holati edi - aslida Influx buni o'zi tekshiradi va tugunlar bo'limida "yashil chiroqlar" bilan ko'rsatadi.
Bu funktsiya tomonidan amalga oshiriladi - biz undan qutimizning ishlashini tushunish va xuddi shu ogohlantirishlarni Slack-ga yuborish uchun foydalandik.
Aytgancha, biz skuterlarni Simpsonlar qahramonlarining ismlari bilan nomladik - ularni bir-biridan ajratish juda qulay edi.
Va umuman olganda, bu yanada qiziqarli edi. "Yigitlar, Smiters o'ldi!" kabi iboralar doimo eshitildi.
String ko'rsatkichlari
InfluxDB sizga Victoria Metrics bilan bo'lgani kabi nafaqat raqamli qiymatlarni saqlashga imkon berishi muhim.
Bu unchalik muhim emasdek tuyuladi - axir, jurnallardan tashqari, har qanday ko'rsatkichlar raqamlar shaklida saqlanishi mumkin (faqat ma'lum davlatlar uchun xaritalashni qo'shing - bir turdagi enum)?
Bizning holatda, string ko'rsatkichlari juda foydali bo'lgan kamida bitta stsenariy mavjud edi.
Shunday qilib, bizning "aqlli zaryadlovchilar" yetkazib beruvchisi uchinchi tomon edi, biz ishlab chiqish jarayonini va ushbu zaryadlovchilar taqdim etishi mumkin bo'lgan ma'lumotlarni nazorat qila olmadik.
Natijada, zaryadlovchi API idealdan uzoq edi, ammo asosiy muammo shundaki, biz ularning holatini har doim ham tushuna olmadik.
Bu erda Influx yordamga keldi. Biz oddiygina InfluxDB ma'lumotlar bazasi maydoniga bizga kelgan string holatini o'zgartirmasdan yozdik.
Bir muncha vaqt davomida u erga faqat "onlayn" va "oflayn" kabi qiymatlar keldi, ular asosida ma'lumotlar bizning boshqaruv panelimizda ko'rsatildi va Slack-ga bildirishnomalar yuborildi. Biroq, bir nuqtada, u erda "ajratilgan" kabi qadriyatlar ham paydo bo'la boshladi.
Keyinchalik ma'lum bo'lishicha, agar zaryadlovchi ma'lum miqdordagi urinishlardan keyin server bilan aloqa o'rnatolmasa, bu holat ulanish uzilganidan keyin bir marta yuborilgan.
Shunday qilib, agar biz faqat belgilangan qiymatlar to'plamidan foydalansak, biz ushbu o'zgarishlarni proshivkada o'z vaqtida ko'rmasligimiz mumkin.
Va umuman olganda, string ko'rsatkichlari foydalanish uchun ko'proq imkoniyatlarni taqdim etadi, ularda deyarli har qanday ma'lumotni yozib olishingiz mumkin. Garchi, albatta, siz ushbu vositadan ehtiyotkorlik bilan foydalanishingiz kerak.
Odatdagi ko'rsatkichlarga qo'shimcha ravishda biz InfluxDB-da GPS joylashuv ma'lumotlarini ham yozib oldik. Bu bizning boshqaruv panelimizdagi skuterlarning joylashuvini kuzatish uchun juda foydali bo'ldi.
Darhaqiqat, biz har doim qaerda va qaysi skuter kerakligini bilardik.
Bu biz uchun skuter qidirayotganimizda juda foydali bo'ldi (oxiridagi xulosalarga qarang).
Infratuzilma monitoringi
Skuterlarning o'zlariga qo'shimcha ravishda, biz butun (anchalik keng) infratuzilmamizni kuzatishimiz kerak edi.
Juda umumiy arxitektura shunday ko'rinardi:
Agar biz sof monitoring to'plamini ajratib ko'rsatsak, u quyidagicha ko'rinadi:
Biz bulutda tekshirmoqchi bo'lgan narsamiz:
- Ma'lumotlar bazalari
- kalit plash
- Mikroservislar
Bizning barcha bulut xizmatlarimiz Kubernetesda joylashganligi sababli, uning holati haqida ma'lumot to'plash yaxshi bo'lar edi.
Yaxshiyamki, Telegraf qutidan tashqarida Kubernetes klasterining holati haqida juda ko'p ko'rsatkichlarni to'plashi mumkin va Chronograf darhol buning uchun chiroyli asboblar panelini taklif qiladi.
Biz asosan podkastlarning ishlashi va xotira sarfini kuzatdik. Yiqilish holatida Slack-da ogohlantirishlar.
Kubernetes-da podlarni kuzatishning ikki yo'li mavjud: DaemonSet va Sidecar.
Ikkala usul ham batafsil tavsiflangan .
Biz Telegraf Sidecar-dan foydalandik va ko'rsatkichlarga qo'shimcha ravishda pod jurnallarini to'pladik.
Bizning holatlarimizda, biz jurnallar bilan tinker qilishimiz kerak edi. Telegraf Docker API-dan jurnallarni tortib olishiga qaramay, biz oxirgi qurilmalarimiz bilan yagona jurnallar to'plamiga ega bo'lishni va buning uchun konteynerlar uchun tizim sozlanganligini xohladik. Ehtimol, bu yechim chiroyli emas edi, lekin uning ishi haqida hech qanday shikoyatlar yo'q edi va jurnallar Chronografda yaxshi ko'rsatildi.
Monitor monitoringi???
Oxir-oqibat, monitoring tizimlarini monitoring qilish bo'yicha asriy savol tug'ildi, ammo xayriyatki, yoki afsuski, bizda bunga etarli vaqt yo'q edi.
Telegraf osongina o'z ko'rsatkichlarini yuborishi yoki InfluxDB ma'lumotlar bazasidan o'sha Influxga yoki boshqa joyga yuborish uchun ko'rsatkichlarni to'plashi mumkin.
topilmalar
Uchuvchi natijalaridan qanday xulosalar chiqardik?
Qanday qilib monitoring o'tkazishingiz mumkin?
Birinchidan, TICK stek bizning taxminlarimizga to‘liq javob berdi va biz kutganimizdan ham ko‘proq imkoniyatlar berdi.
Bizga kerak bo'lgan barcha funksiyalar mavjud edi. Biz u bilan qilgan hamma narsa muammosiz ishladi.
unumdorlik
Bepul versiyada TICK stekidagi asosiy muammo - bu masshtablash imkoniyatlarining yo'qligi. Bu biz uchun muammo emas edi.
Biz aniq yuk ma'lumotlarini/raqamlarini to'plamadik, biroq biz bir vaqtning o'zida 30 ga yaqin skuterdan ma'lumotlarni to'pladik.
Ularning har biri uch o'ndan ortiq ko'rsatkichlarni to'pladi. Shu bilan birga, qurilmalardan jurnallar yig'ildi. Ma'lumotlarni yig'ish va yuborish har 10 soniyada amalga oshirildi.
Shuni ta'kidlash kerakki, uchuvchidan bir yarim hafta o'tgach, "bolalik muammolari" ning asosiy qismi tuzatilgan va eng muhim muammolar allaqachon hal qilinganida, biz serverga ma'lumotlarni yuborish chastotasini kamaytirishimiz kerak edi. 30 soniya. Bu zarur bo'ldi, chunki bizning LTE SIM-kartalarimizdagi trafik tezda yo'qola boshladi.
Trafikning asosiy qismi jurnallar tomonidan iste'mol qilingan; ko'rsatkichlarning o'zi, hatto 10 soniyalik interval bilan ham, uni deyarli behuda sarflamadi.
Natijada, bir muncha vaqt o'tgach, biz qurilmalarda jurnallarni to'plashni butunlay o'chirib qo'ydik, chunki doimiy yig'ilmasdan ham muayyan muammolar allaqachon aniq edi.
Ba'zi hollarda, agar jurnallarni ko'rish hali ham zarur bo'lsa, biz WireGuard orqali VPN orqali ulandik.
Shuni ham qo'shimcha qilamanki, har bir alohida muhit bir-biridan ajratilgan va yuqorida tavsiflangan yuk faqat ishlab chiqarish muhitiga tegishli edi.
Rivojlanish muhitida biz har 10 soniyada ma'lumot to'plashni davom ettiradigan alohida InfluxDB nusxasini yaratdik va biz ishlashda hech qanday muammoga duch kelmadik.
TICK - kichik va o'rta loyihalar uchun ideal
Ushbu ma'lumotlarga asoslanib, men TICK to'plami nisbatan kichik loyihalar yoki hech qanday HighLoadni kutmaydigan loyihalar uchun ideal degan xulosaga kelgan bo'lardim.
Agar sizda minglab podkastlar yoki yuzlab mashinalaringiz bo'lmasa, hatto bitta InfluxDB nusxasi ham yukni juda yaxshi bajara oladi.
Ba'zi hollarda, Influx Relay ibtidoiy High Availability yechimi sifatida sizni qoniqtiradi.
Va, albatta, hech kim sizni "vertikal" masshtabni o'rnatishga va turli xil ko'rsatkichlar uchun turli xil serverlarni ajratishga to'sqinlik qilmaydi.
Agar siz monitoring xizmatlariga kutilayotgan yuk haqida ishonchingiz komil bo'lmasa yoki sizga juda "og'ir" arxitekturaga ega bo'lishingiz kafolatlangan bo'lsa, men TICK stekining bepul versiyasidan foydalanishni tavsiya etmayman.
Albatta, oddiy yechim sotib olish bo'ladi - lekin bu erda qandaydir izoh berolmayman, chunki men o'zimning nozik tomonlarini bilmayman. Bundan tashqari, bu juda qimmat va, albatta, kichik kompaniyalar uchun mos emas.
Bunday holda, bugungi kunda men Loki-dan foydalangan holda Victoria Metrics va jurnallar orqali ko'rsatkichlarni to'plashni maslahat beraman.
To'g'ri, men yana bir bor eslatib o'tamanki, Loki/Grafana tayyor TICK-ga qaraganda ancha qulayroq (ularning ko'p qirraliligi tufayli), lekin ular bepul.
Muhim: bu erda tasvirlangan barcha ma'lumotlar Influx 1.8 versiyasiga tegishli, hozirda Influx 2.0 chiqarilish arafasida.
Men buni jangovar sharoitlarda sinab ko'rish imkoniyatiga ega bo'lmaganman va yaxshilanishlar haqida xulosa chiqarish qiyin bo'lsa-da, interfeys shubhasiz yanada yaxshilandi, arxitektura soddalashtirilgan (kapasitor va xronografsiz),
andozalar paydo bo'ldi ("qotil xususiyat" - ). Ammo, afsuski, hozirda 2-versiyada biz birinchi versiyani tanlagan asosiy narsa yo'q - jurnallar to'plami yo'q.
Bu funksiya Influx 2.0 da ham paydo bo‘ladi, lekin biz hech qanday muddatlarni, hatto taxminiylarini ham topa olmadik.
Qanday qilib IoT platformalarini yaratmaslik kerak (hozir)
Oxir-oqibat, uchuvchini ishga tushirib, biz standartlarimizga mos keladigan alternativa yo'qligi sababli o'zimiz to'liq IoT stekini yig'dik.
Biroq, yaqinda u Beta versiyasida mavjud — achinarlisi, biz loyihani boshlaganimizda u yo'q edi.
Biz yakuniy natijadan va o'zimiz yig'gan Ansible + TICK + WireGuard asosidagi platformadan to'liq qoniqdik. Ammo bugun men o'z IoT platformangizni yaratishga urinishdan oldin Balena bilan yaqindan tanishishni tavsiya qilaman.
Chunki oxir-oqibat u biz qilgan ishlarning ko'pini qila oladi va OpenBalena bepul va ochiq manbadir.
U nafaqat yangilanishlarni yuborishni biladi, balki VPN allaqachon o'rnatilgan va IoT muhitida foydalanish uchun moslashtirilgan.
Va yaqinda ular hatto o'zlarini ham chiqardilar , bu ularning ekotizimiga osongina ulanadi.
Hey, yo'qolgan skuter haqida nima deyish mumkin?
Shunday qilib, "Ralf" skuteri izsiz g'oyib bo'ldi.
Biz darhol InfluxDB-dan GPS ko'rsatkichlari ma'lumotlari bilan "administrator panelimizdagi" xaritani ko'rish uchun yugurdik.
Monitoring ma'lumotlari tufayli biz skuter o'tgan kuni soat 21:00 atrofida to'xtash joyidan chiqib ketganini, qaysidir hududga yarim soatcha yo'l borganini va ertalab soat 5 ga qadar nemis uyi yonida turganini aniqladik.
Ertalab soat 5 dan keyin hech qanday monitoring ma'lumotlari olinmadi - bu qo'shimcha batareyaning to'liq zaryadsizlanganligini yoki tajovuzkor nihoyat skuterdan aqlli uskunani qanday olib tashlashni aniqladi.
Shunga qaramay, politsiya hali ham skuter joylashgan manzilga chaqirilgan. Skuter u erda yo'q edi.
Biroq, uy egasi ham bundan hayratda qoldi, chunki u kecha ofisdan uyiga bu skuterni minib kelgan.
Ma’lum bo‘lishicha, yordam xodimlaridan biri erta tongda yetib kelgan va skuterni ko‘tarib, uning qo‘shimcha akkumulyatori to‘liq zaryadsizlanganini ko‘rib, uni (piyoda) to‘xtash joyiga olib ketgan. Va qo'shimcha batareya namlik tufayli ishlamay qoldi.
Skuterni o'zimizdan o'g'irlab oldik. Aytgancha, men politsiya ishi bilan muammoni qanday va kim hal qilganini bilmayman, ammo monitoring juda yaxshi ishladi ...
Manba: www.habr.com