Bir il əvvəl biz promosyon layihəsinin pilot versiyasını işə saldıq .
Əvvəlcə layihə Road-to-Barselona adlanırdı, sonradan Road-to-Berlin oldu (buna görə də ekran görüntülərində R2B) və sonda xRide adlandırıldı.
Layihənin əsas ideyası belə idi: mərkəzləşdirilmiş avtomobil və ya skuter icarəsi xidmətinə sahib olmaq əvəzinə (biz skuterlər, aka elektrik motosiklləri haqqında danışırıq, skuterlər/skuterlər deyil) mərkəzləşdirilməmiş icarə üçün platforma yaratmaq istədik. Qarşılaşdığımız çətinliklər haqqında .
Əvvəlcə layihə avtomobillərə diqqət yetirdi, lakin son tarixlər, istehsalçılarla son dərəcə uzun ünsiyyət və çoxlu sayda təhlükəsizlik məhdudiyyətləri səbəbindən pilot üçün elektrikli skuterlər seçildi.
İstifadəçi telefonuna iOS və ya Android proqramı quraşdırdı, bəyəndiyi skuterə yaxınlaşdı, bundan sonra telefon və skuter arasında həmyaşıd əlaqə quruldu, ETH mübadiləsi aparıldı və istifadəçi skuteri işə salaraq sürməyə başlaya bilər. telefon. Səfərin sonunda istifadəçinin telefondakı pul kisəsindən Ethereum istifadə edərək səyahət haqqını da ödəmək mümkün idi.
Skuterlərə əlavə olaraq, istifadəçi tətbiqdə “ağıllı şarj cihazları” gördü, ona baxaraq istifadəçi cari akkumulyatoru aşağı olarsa özü dəyişə bilər.
Keçən ilin sentyabrında Almaniyanın iki şəhərində: Bonn və Berlində istifadəyə verilmiş pilotumuz ümumiyyətlə belə görünürdü.
Və sonra, bir gün, Bonnda, səhər tezdən dəstək komandamız (skuterləri işlək vəziyyətdə saxlamaq üçün saytda yerləşir) xəbərdar edildi: skuterlərdən biri iz qoymadan yoxa çıxdı.
Onu necə tapmaq və geri qaytarmaq olar?
Bu yazıda mən bu barədə danışacağam, amma əvvəlcə öz IoT platformamızı necə qurduğumuz və onu necə izlədiyimiz haqqında danışacağam.
Nə və nə üçün monitorinq edilməlidir: skuterlər, infrastruktur, şarj stansiyaları?
Beləliklə, layihəmizdə nəyi izləmək istədik?
Əvvəla, bunlar skuterlərin özləridir - elektrikli skuterlərin özləri olduqca bahadır, kifayət qədər hazırlaşmadan belə bir layihəyə başlaya bilməzsiniz; mümkünsə, skuterlər haqqında mümkün qədər çox məlumat toplamaq istəyirsiniz: onların yeri, şarj səviyyəsi haqqında və s.
Bundan əlavə, mən öz İT infrastrukturumuzun - məlumat bazalarının, xidmətlərin və onların işləməsi üçün lazım olan hər şeyin vəziyyətinə nəzarət etmək istərdim. Həm də "ağıllı şarj cihazları" xarab olduqda və ya tam batareyaları bitdikdə onların vəziyyətinə nəzarət etmək lazım idi.
Skuterlər
Skuterlərimiz nə idi və onlar haqqında nə bilmək istəyirdik?
Birinci və ən vacib şey GPS koordinatlarıdır, çünki onların sayəsində onların harada olduğunu və harada hərəkət etdiyini başa düşə bilərik.
Sonrakı akkumulyatorun doldurulmasıdır, bunun sayəsində biz skuterlərin doldurulmasının sona çatdığını müəyyən edə və şirəçəkən göndərə və ya heç olmasa istifadəçini xəbərdar edə bilərik.
Əlbəttə ki, bizim Avadanlıq komponentlərimizlə nə baş verdiyini yoxlamaq lazımdır:
- bluetooth işləyir?
- GPS modulu özü işləyir?
- GPS-in səhv koordinatlar göndərə və ilişib qala bilməsi ilə bağlı problemimiz də var idi və bunu yalnız skuterdə əlavə yoxlamalarla müəyyən etmək olar,
və problemi həll etmək üçün dəstəyi mümkün qədər tez xəbərdar edin
- GPS-in səhv koordinatlar göndərə və ilişib qala bilməsi ilə bağlı problemimiz də var idi və bunu yalnız skuterdə əlavə yoxlamalarla müəyyən etmək olar,
Və nəhayət: OS və prosessordan başlayaraq, şəbəkə və disk yükündən başlayaraq, bizə daha çox xas olan öz modullarımızın yoxlanılması ilə bitən proqram təminatının yoxlanılması (, ).
Hardware
Bizim “dəmir” hissəmiz nə idi?
Mümkün olan ən qısa vaxt çərçivəsini və sürətli prototipləşdirmə ehtiyacını nəzərə alaraq, komponentlərin həyata keçirilməsi və seçilməsi üçün ən asan variantı - Raspberry Pi-ni seçdik.
Rpi-nin özündən əlavə, bizdə xüsusi bir lövhə (son həllin yığılması prosesini sürətləndirmək üçün özümüz hazırladıq və Çindən sifariş etdik) və bir sıra komponentlər - rele (skuteri yandırmaq / söndürmək üçün), batareya doldurma oxuyucusu, modem, antenalar. Bütün bunlar yığcam şəkildə xüsusi “xRide qutusuna” yığılmışdı.
Onu da qeyd etmək lazımdır ki, bütün qutu əlavə güc bankı ilə təchiz edilib, o da öz növbəsində skuterin əsas akkumulyatoru ilə təchiz edilib.
Bu, alov açarını "söndürmə" vəziyyətinə çevirdikdən dərhal sonra əsas batareya söndürüldüyü üçün səfər bitdikdən sonra da monitorinqdən istifadə etməyə və skuteri işə salmağa imkan verdi.
Doker? Düz Linux? və yerləşdirmə
Gəlin monitorinqə qayıdaq, buna görə də Moruq - nəyimiz var?
Komponentlərin fiziki cihazlara yerləşdirilməsi, yenilənməsi və çatdırılması prosesini sürətləndirmək üçün istifadə etmək istədiyimiz ilk şeylərdən biri Docker idi.
Təəssüf ki, tez bir zamanda məlum oldu ki, RPi-də Docker işləsə də, xüsusilə enerji istehlakı baxımından çox yükə malikdir.
"Doğma" OS-dən istifadə fərqi, o qədər də güclü olmasa da, şarjı çox tez itirmək ehtimalından ehtiyatlı olmaq üçün kifayət idi.
İkinci səbəb, Go/C/C++-da yazılmayan sistemin yeganə komponenti olan Node.js (sic!) üzərindəki tərəfdaş kitabxanalarımızdan biri idi.
Kitabxana müəlliflərinin heç bir “doğma” dildə işlək versiyanı təqdim etməyə vaxtı yox idi.
Nəinki qovşağın özü aşağı performanslı cihazlar üçün ən zərif həll deyil, həm də kitabxananın özü çox resursa ehtiyac duyur.
Anladıq ki, hətta istəsək də, Docker-dən istifadə etmək bizim üçün çox yük olacaq. Seçim yerli OS-nin lehinə edildi və birbaşa onun altında işləyir.
OS
Nəticədə, biz yenə də ƏS kimi ən sadə variantı seçdik və Raspbian (Pi üçün Debian quruluşu) istifadə etdik.
Biz bütün proqram təminatımızı Go-da yazırıq, buna görə də sistemimizdəki əsas aparat agent modulunu Go-da yazdıq.
GPS, Bluetooth ilə işləmək, şarjı oxumaq, skuteri işə salmaq və s.
Yerləşdirmək
Sual dərhal cihazlara yeniləmələrin (OTA) çatdırılması mexanizminin həyata keçirilməsi zərurəti ilə bağlı yarandı - həm agentimizin/tətbiqimizin özünə, həm də OS/firmware-in özünə yeniliklər (çünki agentin yeni versiyaları nüvəyə yeniləmələr tələb edə bilər). və ya sistem komponentləri, kitabxanalar və s.) .
Bazarın kifayət qədər uzun təhlilindən sonra məlum oldu ki, cihaza yeniləmələrin çatdırılması üçün kifayət qədər çoxlu həll variantları var.
Swupd/SWUpdate/OSTree kimi nisbətən sadə, əsasən yeniləmə/ikili yükləmə yönümlü kommunal proqramlardan Mender və Balena kimi tam hüquqlu platformalara qədər.
Hər şeydən əvvəl, biz başa çatan həllərlə maraqlandığımıza qərar verdik, buna görə seçim dərhal platformalara düşdü.
Çox balenaEngine daxilində eyni Docker-dən istifadə etdiyinə görə istisna edildi.
Ancaq qeyd edirəm ki, buna baxmayaraq, biz onların məhsulundan daim istifadə etdik SD kartlarda flash proqram təminatı üçün - bunun üçün sadə və olduqca rahat bir yardım proqramı.
Ona görə də sonda seçim üzərinə düşdü . Mender proqram təminatının yığılması, çatdırılması və quraşdırılması üçün tam platformadır.
Ümumilikdə platforma əla görünür, lakin mender qurucusundan istifadə edərək proqram təminatımızın düzgün versiyasını qurmaq bizə təxminən bir həftə yarım vaxt apardı.
Və biz onun istifadəsinin incəliklərinə nə qədər çox qərq olsaq, bir o qədər aydın oldu ki, onu tam tətbiq etmək üçün bizə olduğundan daha çox vaxt lazımdır.
Təəssüf ki, bizim sıx müddətlərimiz Menderin istifadəsindən imtina etməyə və daha sadə birini seçməyə məcbur olduq.
Yoxdur
Bizim vəziyyətimizdə ən sadə həll Ansible-dan istifadə etmək idi. Başlamaq üçün bir neçə oyun kitabı kifayət idi.
Onların mahiyyəti ondan ibarət idi ki, biz sadəcə olaraq hostdan (CI server) ssh vasitəsilə moruqlarımıza qoşulduq və onlara yeniləmələri payladıq.
Əvvəlcə hər şey sadə idi - cihazlarla eyni şəbəkədə olmalısan, tökmə Wi-Fi vasitəsilə həyata keçirilirdi.
Ofisdə eyni şəbəkəyə qoşulmuş bir çox test moruqu var idi, hər bir cihazın Ansible Inventory-də də göstərilən statik IP ünvanı var idi.
Monitorinq agentimizi son cihazlara çatdıran Ansible idi
3G / LTE
Təəssüf ki, Ansible üçün bu istifadə halı yalnız faktiki skuterlərimizə malik olmamışdan əvvəl inkişaf rejimində işləyə bilərdi.
Çünki skuterlər, başa düşdüyünüz kimi, bir Wi-Fi marşrutlaşdırıcısına qoşulmuş oturmurlar, daim şəbəkə üzərindən yeniləmələri gözləyirlər.
Reallıqda, skuterlərin mobil 3G/LTE-dən başqa heç bir əlaqəsi ola bilməz (hətta hər zaman deyil).
Bu, dərhal aşağı əlaqə sürəti və qeyri-sabit rabitə kimi bir çox problem və məhdudiyyətlər qoyur.
Amma ən əsası odur ki, 3G/LTE şəbəkəsində biz sadəcə olaraq şəbəkəyə təyin edilmiş statik IP-yə etibar edə bilmərik.
Bu, bəzi SİM kart provayderləri tərəfindən qismən həll edilir; hətta statik IP ünvanları olan IoT cihazları üçün nəzərdə tutulmuş xüsusi SİM kartlar da var. Amma bizim belə SİM kartlara çıxışımız yox idi və İP ünvanlardan istifadə edə bilmirdik.
Əlbəttə, konsul kimi bir yerdə IP ünvanlarının bir növ qeydiyyatı, yəni xidmət kəşfi ilə məşğul olmaq ideyaları var idi, lakin biz bu cür fikirlərdən imtina etməli olduq, çünki testlərimizdə IP ünvanı çox tez-tez dəyişə bilərdi, bu da böyük qeyri-sabitliyə səbəb olurdu.
Bu səbəbdən, ölçüləri çatdırmaq üçün ən əlverişli istifadə, lazımi ölçülər üçün cihazlara getdiyimiz çəkmə modelindən istifadə etmək deyil, ölçüləri cihazdan birbaşa serverə çatdırmaq üçün itələmək olardı.
VPN
Bu problemin həlli olaraq biz VPN-i seçdik - xüsusilə .
Sistemin başlanğıcında müştərilər (skuterlər) VPN serverinə qoşuldular və onlara qoşula bildilər. Bu tunel yeniləmələri çatdırmaq üçün istifadə edilmişdir.
Teorik olaraq, eyni tunel monitorinq üçün istifadə edilə bilər, lakin belə bir əlaqə sadə təkandan daha mürəkkəb və daha az etibarlı idi.
Bulud resursları
Nəhayət, bulud xidmətlərimizi və verilənlər bazalarımızı izləmək lazımdır, çünki biz onlar üçün Kubernetes-dən istifadə edirik, ideal olaraq çoxluqda monitorinqin yerləşdirilməsi mümkün qədər sadə olsun. İdeal olaraq istifadə edin , yerləşdirmə üçün biz əksər hallarda ondan istifadə edirik. Və əlbəttə ki, buludları izləmək üçün skuterlərin özləri ilə eyni həllərdən istifadə etməlisiniz.
verilmiş
Phew, deyəsən təsviri sıraladıq, sonda ehtiyacımız olanların siyahısını tərtib edək:
- Tez həll, çünki monitorinq artıq inkişaf prosesində lazımdır
- Həcm/kəmiyyət – çoxlu ölçülər tələb olunur
- Günlüklərin toplanması tələb olunur
- Etibarlılıq - məlumatlar uğurun işə salınması üçün vacibdir
- Siz çəkmə modelindən istifadə edə bilməzsiniz - itələmək lazımdır
- Bizə təkcə aparatın deyil, həm də buludun vahid monitorinqinə ehtiyacımız var
Son görüntü belə bir şeyə bənzəyirdi
Yığın seçimi
Beləliklə, monitorinq yığını seçmək məsələsi ilə qarşılaşdıq.
Hər şeydən əvvəl, biz eyni zamanda bütün tələblərimizi əhatə edəcək, lakin eyni zamanda onun istifadəsini ehtiyaclarımıza uyğunlaşdırmaq üçün kifayət qədər çevik olan ən tam, hamısı bir yerdə həll axtarırdıq. Yenə də texniki vasitələr, arxitektura və son tarixlərə görə bizə bir çox məhdudiyyətlər qoyduq.
kimi tam hüquqlu sistemlərdən başlayaraq çox sayda monitorinq həlləri var , və ya və Donanmanın idarə edilməsi üçün hazır həllər ilə bitən.
Əvvəlcə, sonuncu bizim üçün ideal bir həll kimi görünürdü, lakin bəzilərinin tam monitorinqi yox idi, digərlərinin pulsuz versiyaların imkanları ciddi şəkildə məhdud idi, digərləri isə sadəcə olaraq bizim “istəklərimizi” qarşılamırdı və ya ssenarilərimizə uyğunlaşmaq üçün kifayət qədər çevik deyildi. Bəziləri sadəcə köhnəlib.
Bir sıra oxşar həlləri təhlil etdikdən sonra tez bir zamanda belə bir nəticəyə gəldik ki, oxşar yığını özümüz yığmaq daha asan və daha sürətli olacaq. Bəli, bu, tamamilə hazır Donanma idarəetmə platformasını yerləşdirməkdən bir az daha mürəkkəb olacaq, lakin biz güzəştə getməməliyik.
Demək olar ki, bütün həllər bolluğunda bizə tamamilə uyğun gələn hazır bir həll var, lakin bizim vəziyyətimizdə müəyyən bir yığını özümüz toplamaq və onu "özümüz üçün" fərdiləşdirməkdən daha sürətli idi. hazır məhsulların sınaqdan keçirilməsi.
Bütün bunlarla, biz bütöv bir monitorinq platformasını özümüz yığmağa çalışmadıq, ancaq onları çevik şəkildə konfiqurasiya etmək imkanı ilə ən funksional "hazır" yığınları axtarırdıq.
(B) ELK?
Əslində nəzərdən keçirilən ilk həll tanınmış ELK yığını idi.
Əslində bunun adı BELK olmalıdır, çünki hər şey Beats ilə başlayır -
Əlbəttə ki, ELK monitorinq sahəsində ən məşhur və güclü həllərdən biridir və daha çox logların toplanması və işlənməsidir.
Biz nəzərdə tutmuşduq ki, ELK jurnalları toplamaq və həmçinin Prometeydən əldə edilmiş ölçülərin uzunmüddətli saxlanması üçün istifadə ediləcək.
Vizuallaşdırma üçün Grafan istifadə edə bilərsiniz.
Əslində, yeni ELK yığını ölçüləri müstəqil şəkildə toplaya bilər (metricbeat) və Kibana da onları göstərə bilər.
Ancaq yenə də ELK əvvəlcə jurnallardan çıxdı və bu günə qədər ölçülərin funksionallığı bir sıra ciddi çatışmazlıqlara malikdir:
- Prometeydən əhəmiyyətli dərəcədə yavaş
- Prometeydən daha az yerə inteqrasiya edir
- Onlar üçün siqnallar qurmaq çətindir
- Metriklər çox yer tutur
- Kiban-da ölçülər ilə tablosunun qurulması Grafan-dan daha mürəkkəbdir
Ümumiyyətlə, ELK-dakı ölçülər ağırdır və hələ də digər həllərdəki kimi rahat deyil, bunlardan indi sadəcə Prometeydən daha çox şey var: TSDB, Victoria Metrics, Cortex və s. və s.. Əlbətdə ki, mən dərhal tam hüquqlu bir həllə sahib olmaq istərdim, lakin metricbeat vəziyyətində çoxlu kompromislər var idi.
Və ELK yığınının özündə bir sıra çətin məqamlar var:
- Kifayət qədər böyük miqdarda məlumat toplasanız, ağır, bəzən hətta çox ağırdır
- Onu "bişirməyi" bilməlisən - miqyasını artırmalısan, amma bunu etmək heç də əhəmiyyətsiz deyil.
- Pulsuz versiya ləğv edildi - pulsuz versiyada normal xəbərdarlıq yoxdur və seçim zamanı identifikasiya yox idi
Deməliyəm ki, son vaxtlar son nöqtə daha yaxşı və əlavə oldu (autentifikasiya daxil olmaqla) qiymət modelinin özü dəyişməyə başladı.
Ancaq bu həlli tətbiq edəcəyimiz vaxt heç bir xəbərdarlıq yox idi.
Ola bilsin ki, biz ElastAlert və ya digər icma həllərindən istifadə edərək nəsə qurmağa cəhd edə bilərdik, lakin yenə də başqa alternativləri nəzərdən keçirməyə qərar verdik.
Loki - Qrafana - Prometey
Hal-hazırda, yaxşı bir həll, ölçülər təminatçısı kimi sırf Prometheus, loglar üçün Loki və vizuallaşdırma üçün eyni Grafana-dan istifadə edə biləcəyiniz bir monitorinq yığını qurmaq ola bilər.
Təəssüf ki, layihənin satış pilotu başlayanda (sentyabr-oktyabr 19) Loki hələ də 0.3-0.4 beta versiyasında idi və inkişafın başlanğıcı zamanı onu istehsal həlli hesab etmək mümkün deyildi. bütün.
Hələ ciddi layihələrdə Loki-dən istifadə etmək təcrübəm yoxdur, amma deyə bilərəm ki, Promtail (logların toplanması üçün agent) kubernetlərdə həm çılpaq metal, həm də podlar üçün əla işləyir.
GİT
Bəlkə də ELK yığınına ən layiqli (yeganə?) tam funksiyalı alternativi indi yalnız TICK yığını adlandırmaq olar - Teleqraf, InfluxDB, Chronograf, Kapacitor.
Aşağıdakı bütün komponentləri daha ətraflı təsvir edəcəyəm, lakin ümumi fikir belədir:
- Teleqraf - ölçüləri toplamaq üçün agent
- InfluxDB - ölçülər bazası
- Kapacitor - xəbərdarlıq üçün real vaxt ölçmə prosessoru
- Chronoqraf - vizuallaşdırma üçün veb panel
InfluxDB, Kapacitor və Chronograf üçün onları yerləşdirmək üçün istifadə etdiyimiz rəsmi sükan cədvəlləri var.
Qeyd etmək lazımdır ki, Influx 2.0-ın (beta) son versiyasında Kapacitor və Chronograf InfluxDB-nin bir hissəsi oldu və artıq ayrıca mövcud deyil.
Teleqraf
dövlət maşınında ölçüləri toplamaq üçün çox yüngül agentdir.
O, hər şeyi böyük məbləğdə nəzarət edə bilər üzrə
server .
Bir sıra gözəl üstünlüklərə malikdir:
- Sürətli və yüngül (Go-da yazılmışdır)
- Minimum miqdarda resurs yeyir
- Defolt olaraq ölçüləri itələyin
- Bütün lazımi ölçüləri toplayır
- Heç bir parametr olmadan sistem ölçüləri
- Sensorlardan gələn məlumatlar kimi aparat ölçüləri
- Öz ölçülərinizi əlavə etmək çox asandır
- Qutudan çoxlu plaginlər
- Günlükləri toplayır
Təkan ölçüləri bizim üçün lazım olduğundan, bütün digər üstünlüklər xoş əlavələrdən daha çox idi.
Agentin özü tərəfindən qeydlərin toplanması da çox rahatdır, çünki qeydləri qeyd etmək üçün əlavə yardım proqramlarını bağlamağa ehtiyac yoxdur.
Influx, istifadə etdiyiniz halda qeydlərlə işləmək üçün ən rahat təcrübə təklif edir .
Teleqraf, ümumiyyətlə, ICK yığınının qalan hissəsini istifadə etməsəniz belə, ölçüləri toplamaq üçün əla agentdir.
Bir çox insanlar onu rahatlıq üçün ELK və müxtəlif vaxt seriyası verilənlər bazaları ilə keçir, çünki o, demək olar ki, hər yerdə ölçüləri yaza bilir.
InfluxDB
InfluxDB, TICK yığınının əsas nüvəsidir, yəni ölçülər üçün vaxt seriyası verilənlər bazasıdır.
Ölçülərə əlavə olaraq, Influx jurnalları da saxlaya bilər, baxmayaraq ki, onun üçün qeydlər əslində eyni ölçülərdir, yalnız adi ədədi göstəricilər əvəzinə əsas funksiya log mətni xətti ilə həyata keçirilir.
InfluxDB də Go-da yazılmışdır və bizim (ən güclü deyil) klasterimizdəki ELK ilə müqayisədə daha sürətli işləyir.
Influx-un gözəl üstünlüklərindən biri də çox aktiv istifadə etdiyimiz məlumat sorğuları üçün çox rahat və zəngin API-ni əhatə edəcəkdir.
Dezavantajlar - $$$ və ya miqyas?
TICK yığınının aşkar etdiyimiz yalnız bir çatışmazlığı var - o sevgilim. Daha da çox.
Ödənişli versiyada pulsuz versiyada olmayan nə var?
Anlaya bildiyimiz qədər, TICK yığınının ödənişli versiyası ilə pulsuz versiya arasındakı yeganə fərq miqyaslandırma imkanlarıdır.
Məhz, yalnız yüksək əlçatanlığı olan bir klaster yarada bilərsiniz .
Tam hüquqlu HA istəyirsinizsə, ya pul ödəməli, ya da bir neçə qoltuqağacı istifadə etməlisiniz. Bir neçə icma həlli var - məsələn səriştəli həll kimi görünür, lakin onun istehsal üçün uyğun olmadığı yazılır, eləcə də
- NATS vasitəsilə məlumatların ötürülməsi ilə sadə bir həll (o da miqyaslanmalı olacaq, lakin bu həll edilə bilər).
Təəssüf ki, amma hər ikisi tərk edilmiş kimi görünür - təzə öhdəliklər yoxdur, güman edirəm ki, məsələ çox şeyin fərqli olacağı Influx 2.0-ın yeni versiyasının tezliklə gözlənilən buraxılışındadır (haqqında heç bir məlumat yoxdur) hələ miqyası).
Rəsmi olaraq pulsuz versiya var - əslində, bu ibtidai bir HA-dır, ancaq balanslaşdırma yolu ilə,
çünki bütün məlumatlar yük balanslaşdırıcısının arxasındakı bütün InfluxDB instansiyalarına yazılacaq.
Onun bəziləri var balların üzərinə yazılması ilə bağlı potensial problemlər və əvvəlcədən ölçülər üçün əsaslar yaratmaq ehtiyacı kimi
(InfluxDB ilə normal iş zamanı avtomatik olaraq baş verir).
Bundan əlavə , bu, sizə lazım olmaya biləcək təkrarlanan ölçülər (həm emal, həm də saxlama) üçün əlavə xərc deməkdir, lakin onları ayırmaq üçün heç bir yol yoxdur.
Victoria Metrics?
Nəticədə, ödənişli miqyasdan başqa hər şeydə TICK yığınından tamamilə razı olmağımıza baxmayaraq, qalan T_CK komponentlərini tərk edərkən InfluxDB verilənlər bazasını əvəz edə biləcək hər hansı pulsuz həllərin olub olmadığını görmək qərarına gəldik.
Çox vaxt seriyası verilənlər bazası var, lakin ən perspektivlisi Victoria Metricsdir, onun bir sıra üstünlükləri var:
- Tez və asan, ən azı nəticələrə görə
- Çoxluq versiyası var, onun haqqında indi hətta yaxşı rəylər var
- O, parçalaya bilər
- InfluxDB protokolunu dəstəkləyir
Viktoriya əsasında tamamilə fərdi bir yığın qurmaq niyyətində deyildik və əsas ümid ondan ibarət idi ki, onu InfluxDB üçün açılan əvəz kimi istifadə edə bilərik.
Təəssüf ki, bu mümkün deyil, InfluxDB protokolunun dəstəklənməsinə baxmayaraq, o, yalnız ölçüləri qeyd etmək üçün işləyir - yalnız Prometheus API "xaricdə" mövcuddur, yəni Chronograf-ı quraşdırmaq mümkün olmayacaq.
Üstəlik, ölçülər üçün yalnız rəqəmli dəyərlər dəstəklənir (xüsusi ölçülər üçün sətir dəyərlərindən istifadə etdik - bu barədə daha çox bölmədə ).
Aydındır ki, eyni səbəbdən, VM Influx kimi qeydləri saxlaya bilməz.
Həm də qeyd etmək lazımdır ki, optimal həllin axtarışı zamanı Victoria Metrics hələ o qədər də populyar deyildi, sənədlər daha kiçik idi və funksionallıq daha zəif idi.
(Klaster versiyasının və parçalanmanın ətraflı təsvirini xatırlamıram).
Baza seçimi
Nəticədə qərara alındı ki, pilot üçün hələ də özümüzü tək bir InfluxDB qovşağı ilə məhdudlaşdıracağıq.
Bu seçimin bir neçə əsas səbəbi var idi:
- TICK yığınının bütün funksionallığını çox bəyəndik
- Biz artıq onu yerləşdirməyi bacardıq və o, əla işlədi
- Son tarixlər tükənirdi və digər variantları sınaqdan keçirmək üçün çox vaxt qalmadı.
- Bu qədər ağır yük gözləmirdik
Pilotun ilk mərhələsi üçün çoxlu skuterimiz yox idi və inkişaf zamanı sınaq heç bir performans problemini aşkar etmədi.
Buna görə də qərara gəldik ki, bu layihə üçün bir Influx node miqyasına ehtiyac olmadan bizim üçün kifayət edəcəkdir (sonda nəticələrə baxın).
Biz yığına və bazaya qərar verdik - indi TICK yığınının qalan komponentləri haqqında.
Kondansatör
Kapacitor real vaxt rejimində verilənlər bazasına daxil olan metriklərə nəzarət edə və qaydalar əsasında müxtəlif hərəkətləri yerinə yetirə bilən TICK stekinin bir hissəsidir.
Ümumiyyətlə, o, potensial anomaliyaların izlənməsi və maşın öyrənməsi üçün bir vasitə kimi yerləşdirilib (bu funksiyaların tələb olunduğuna əmin deyiləm), lakin onun istifadəsinin ən populyar halı daha çox yayılmışdır - xəbərdarlıq.
Bildirişlər üçün belə istifadə etdik. Müəyyən bir skuter oflayn olduqda Slack xəbərdarlıqlarını quraşdırdıq və eyni şey ağıllı şarj cihazları və vacib infrastruktur komponentləri üçün edildi.
Bu, problemlərə tez cavab verməyə, həmçinin hər şeyin normala döndüyü barədə bildirişlər almağa imkan verdi.
Sadə bir misal: "qutumuzu" gücləndirmək üçün əlavə batareya sıradan çıxdı və ya nədənsə enerjisi bitdi; sadəcə olaraq yenisini quraşdırmaqla, bir müddət sonra skuterin funksionallığının bərpa edildiyi barədə bildiriş almalıyıq.
Influx 2.0-da Kapasitor DB-nin bir hissəsi oldu
Xronoqraf
Monitorinq üçün çoxlu müxtəlif UI həlləri görmüşəm, lakin deyə bilərəm ki, funksionallıq və UX baxımından heç nə Chronograf ilə müqayisə olunmur.
Qəribədir ki, biz veb interfeysi kimi Grafan ilə TICK yığınından istifadə etməyə başladıq.
Onun funksionallığını təsvir etməyəcəyəm, hər kəs hər şeyi qurmaq üçün geniş imkanlarını bilir.
Bununla belə, Grafana hələ də tamamilə universal alətdir, Chronograf isə əsasən Influx ilə istifadə üçün nəzərdə tutulub.
Və təbii ki, bunun sayəsində Chronograf daha ağıllı və ya rahat funksionallıq əldə edə bilər.
Bəlkə də Chronograf ilə işləməyin əsas rahatlığı, Explore vasitəsilə InfluxDB-nin içərisinə baxa bilməyinizdir.
Deyəsən, Grafana demək olar ki, eyni funksionallığa malikdir, lakin əslində, Chronoqraf-da tablosunu qurmaq bir neçə siçan ilə edilə bilər (eyni zamanda oradakı vizualizasiyaya baxarkən), Grafana-da siz hələ də gec-tez olacaqsınız. JSON konfiqurasiyasını redaktə etmək üçün (əlbəttə ki, Chronoqraf əl ilə konfiqurasiya edilmiş tirelərinizi yükləməyə və lazım gələrsə, onları JSON kimi redaktə etməyə imkan verir - lakin mən onları UI-də yaratdıqdan sonra heç vaxt onlara toxunmaq məcburiyyətində qalmadım).
Kibana tablolar və onlar üçün nəzarət yaratmaq üçün daha zəngin imkanlara malikdir, lakin bu cür əməliyyatlar üçün UX çox mürəkkəbdir.
Rahat tablosunu yaratmaq üçün yaxşı bir anlayış tələb olunacaq. Chronograf tablosunun funksionallığı daha az olsa da, onları hazırlamaq və fərdiləşdirmək daha sadədir.
İdarə panellərinin özləri, xoş vizual üslubdan başqa, əslində Grafana və ya Kibanadakı tablolardan heç bir fərqi yoxdur:
Sorğu pəncərəsi belə görünür:
Digər şeylər arasında qeyd etmək vacibdir ki, InfluxDB verilənlər bazasındakı sahələrin növlərini bilməklə, xronoqrafın özü bəzən sorğu yazmaqda və ya ortalama kimi düzgün toplama funksiyasını seçməkdə avtomatik olaraq sizə kömək edə bilər.
Və əlbəttə ki, Chronograf jurnallara baxmaq üçün mümkün qədər rahatdır. Bu belə görünür:
Varsayılan olaraq, Influx qeydləri syslog-dan istifadə etmək üçün uyğunlaşdırılmışdır və buna görə də onların vacib bir parametri var - ciddilik.
Yuxarıdakı qrafik xüsusilə faydalıdır, onun üzərində baş verən səhvləri görə bilərsiniz və şiddətin daha yüksək olub olmadığını dərhal aydın şəkildə rəng göstərir.
Bir neçə dəfə bu yolla mühüm səhvləri tutduq, son həftənin qeydlərinə baxmağa getdik və qırmızı sünbül gördük.
Əlbəttə ki, ideal olaraq bu cür səhvlər üçün xəbərdarlıqlar qurmaq olardı, çünki bunun üçün artıq hər şeyimiz var idi.
Hətta bir müddət bunu aktiv etdik, lakin pilotu hazırlayarkən məlum oldu ki, Slack kanalını da “spam” edən çoxlu səhvlər (o cümlədən LTE şəbəkəsinin olmaması kimi sistem xətaları) əldə edirik. çox, böyük fayda gətirmədən.
Düzgün həll yolu bu cür səhvlərin əksəriyyətini idarə etmək, onların şiddətini tənzimləmək və yalnız bundan sonra xəbərdarlığı işə salmaq olardı.
Bu yolla, yalnız yeni və ya vacib səhvlər Slack-ə göndəriləcək. Sıx son tarixləri nəzərə alaraq belə bir quraşdırma üçün sadəcə kifayət qədər vaxt yox idi.
İdentifikasiyası
Həmçinin qeyd etmək lazımdır ki, Chronograf autentifikasiya kimi OAuth və OIDC-ni dəstəkləyir.
Bu, çox rahatdır, çünki onu asanlıqla serverinizə əlavə etməyə və tam hüquqlu SSO yaratmağa imkan verir.
Bizim vəziyyətimizdə server idi — monitorinqə qoşulmaq üçün istifadə olunurdu, lakin eyni server skuterləri və arxa tərəfə sorğuların autentifikasiyası üçün də istifadə olunurdu.
"Admin"
Təsvir edəcəyim son komponent Vue-də özümüz tərəfindən yazılmış “admin panelimiz”dir.
Əsasən bu, eyni vaxtda öz verilənlər bazamızdan, mikroservislərimizdən və InfluxDB-dən metrik məlumatlardan skuter məlumatlarını göstərən müstəqil bir xidmətdir.
Bundan əlavə, təcili reboot və ya dəstək komandası üçün uzaqdan kilid açmaq kimi bir çox inzibati funksiyalar ora köçürüldü.
Xəritələr də var idi. Artıq qeyd etdim ki, biz Chronograf əvəzinə Grafana ilə başladıq - çünki Grafana üçün xəritələr skuterlərin koordinatlarına baxa biləcəyimiz plaginlər şəklində mövcuddur. Təəssüf ki, Grafana üçün xəritə vidcetlərinin imkanları çox məhduddur və nəticədə bu anda nəinki koordinatları görmək, həm də göstərmək üçün bir neçə gün ərzində xəritələrlə öz veb tətbiqinizi yazmaq çox asan oldu. skuterin keçdiyi marşrut, xəritədə məlumatları süzgəcdən keçirə bilmək və s. (sadə bir tablosunda konfiqurasiya edə bilmədiyimiz bütün funksiyalar).
Influx-un artıq qeyd olunan üstünlüklərindən biri asanlıqla öz ölçülərinizi yaratmaq imkanıdır.
Bu, onu müxtəlif ssenarilər üçün istifadə etməyə imkan verir.
Biz orada bütün faydalı məlumatları qeyd etməyə çalışdıq: batareyanın doldurulması, kilid vəziyyəti, sensorun performansı, bluetooth, GPS və bir çox digər sağlamlıq yoxlamaları.
Bütün bunları admin panelində göstərdik.
Əlbəttə ki, bizim üçün ən vacib meyar skuterin işləmə vəziyyəti idi - əslində Influx bunu özü yoxlayır və Düyünlər bölməsində "yaşıl işıqlar" ilə göstərir.
Bu funksiya tərəfindən edilir — biz ondan qutumuzun performansını başa düşmək və eyni xəbərdarlıqları Slack-ə göndərmək üçün istifadə etdik.
Yeri gəlmişkən, biz skuterləri Simpsonlardakı personajların adlarına görə adlandırdıq - onları bir-birindən ayırmaq çox rahat idi.
Və ümumiyyətlə, bu şəkildə daha əyləncəli idi. “Uşaqlar, Smithers öldü!” kimi ifadələr daim eşidilirdi.
String ölçüləri
InfluxDB-nin Victoria Metrics-də olduğu kimi təkcə rəqəmli dəyərləri saxlamağa imkan verməsi vacibdir.
Görünür ki, bu o qədər də vacib deyil - axır ki, qeydlərdən başqa, hər hansı bir ölçü rəqəmlər şəklində saxlanıla bilər (sadəcə məlum dövlətlər üçün xəritə əlavə edin - bir növ enum)?
Bizim vəziyyətimizdə simli ölçülərin çox faydalı olduğu ən azı bir ssenari var idi.
Elə oldu ki, bizim “ağıllı şarj cihazları”mızın təchizatçısı üçüncü tərəf idi, bizim inkişaf prosesinə və bu doldurucuların təmin edə biləcəyi məlumatlara nəzarətimiz yox idi.
Nəticədə, şarj API idealdan uzaq idi, lakin əsas problem o idi ki, biz həmişə onların vəziyyətini başa düşə bilmirik.
Influx köməyə gəldiyi yerdir. Biz sadəcə olaraq bizə gələn sətir statusunu dəyişmədən InfluxDB verilənlər bazası sahəsinə yazdıq.
Bir müddətdir ki, orada yalnız "onlayn" və "oflayn" kimi dəyərlər var idi, buna əsasən məlumat idarəetmə panelimizdə göstərilir və Slack-ə bildirişlər göndərilirdi. Bununla belə, müəyyən bir nöqtədə orada "əlaqə kəsildi" kimi dəyərlər də görünməyə başladı.
Sonradan məlum olduğu kimi, şarj cihazı müəyyən sayda cəhddən sonra serverlə əlaqə yarada bilmədikdə, bu status əlaqə kəsildikdən sonra bir dəfə göndərilib.
Beləliklə, əgər biz yalnız sabit dəyərlər dəstindən istifadə etsək, bu dəyişiklikləri lazımi anda proqram təminatında görə bilməyəcəyik.
Və ümumiyyətlə, sətir ölçüləri istifadə üçün daha çox imkanlar təmin edir; siz onlarda faktiki olaraq istənilən məlumatı qeyd edə bilərsiniz. Baxmayaraq ki, əlbəttə ki, siz də bu vasitədən diqqətlə istifadə etməlisiniz.
Adi ölçülərə əlavə olaraq, InfluxDB-də GPS yeri məlumatını da qeyd etdik. Bu, idarəetmə panelimizdə skuterlərin yerini izləmək üçün olduqca faydalı oldu.
Əslində, biz həmişə harada və hansı skuterin lazım olduğunu bilirdik.
Skuter axtararkən bu, bizim üçün çox faydalı oldu (sonda nəticələrə baxın).
İnfrastruktur monitorinqi
Skuterlərin özləri ilə yanaşı, bütün (kifayət qədər geniş) infrastrukturumuza da nəzarət etməli idik.
Çox ümumi bir memarlıq belə görünürdü:
Təmiz monitorinq yığınını vurğulasaq, bu belə görünür:
Buludda yoxlamaq istədiyimiz şey:
- Verilənlər bazası
- açar paltarı
- Mikroservislər
Bütün bulud xidmətlərimiz Kubernetesdə yerləşdiyi üçün onun vəziyyəti haqqında məlumat toplamaq yaxşı olardı.
Xoşbəxtlikdən, Teleqraf qutudan kənarda Kubernetes klasterinin vəziyyəti haqqında çoxlu sayda ölçü toplaya bilər və Chronograf dərhal bunun üçün gözəl tablolar təklif edir.
Biz əsasən podların işinə və yaddaş istehlakına nəzarət etdik. Düşmə halında, Slack-də xəbərdarlıqlar.
Kubernetes-də podları izləməyin iki yolu var: DaemonSet və Sidecar.
Hər iki üsul ətraflı təsvir edilmişdir .
Biz Teleqraf Sidecar-dan istifadə etdik və ölçülərə əlavə olaraq pod jurnalları topladıq.
Bizim vəziyyətimizdə loglarla işləməli olduq. Teleqrafın Docker API-dən jurnallar çəkə bilməsinə baxmayaraq, biz son cihazlarımızla vahid jurnal kolleksiyasına sahib olmaq və bunun üçün konteynerlər üçün konfiqurasiya edilmiş sistem qeydinə sahib olmaq istəyirdik. Bəlkə də bu həll gözəl deyildi, amma onun işi ilə bağlı heç bir şikayət yox idi və loglar Chronograf-da yaxşı nümayiş etdirildi.
Monitor monitorinqi???
Nəhayət, monitorinq sistemləri ilə bağlı köhnə sual yarandı, amma xoşbəxtlikdən və ya təəssüf ki, bunun üçün kifayət qədər vaxtımız yox idi.
Baxmayaraq ki, Teleqraf asanlıqla öz ölçülərini göndərə və ya eyni Influx-a və ya başqa yerə göndərmək üçün InfluxDB verilənlər bazasından ölçüləri toplaya bilər.
Tapıntılar
Pilotun nəticələrindən hansı nəticələr çıxardıq?
Monitorinqi necə edə bilərsiniz?
Əvvəla, TICK yığını gözləntilərimizi tam şəkildə qarşıladı və bizə əvvəlcə gözlədiyimizdən daha çox imkanlar verdi.
Bizə lazım olan bütün funksiyalar mövcud idi. Onunla etdiyimiz hər şey problemsiz işləyirdi.
Məhsuldarlıq
Pulsuz versiyada TICK yığını ilə bağlı əsas problem miqyaslaşdırma imkanlarının olmamasıdır. Bu, bizim üçün problem deyildi.
Biz dəqiq yük məlumatı/rəqəmləri toplamışdıq, lakin bir anda təxminən 30 skuterdən məlumat topladıq.
Onların hər biri üçdən çox metrik topladı. Eyni zamanda, cihazlardan loglar toplanıb. Məlumatların toplanması və göndərilməsi hər 10 saniyədən bir həyata keçirilirdi.
Qeyd etmək vacibdir ki, pilotun bir həftə yarımdan sonra "uşaqlıq problemlərinin" böyük hissəsi düzəldildikdə və ən vacib problemlər artıq həll edildikdə, serverə məlumat göndərmə tezliyini azaltmalı olduq. 30 saniyə. Bu, LTE SİM kartlarımızda trafik tez bir zamanda yox olmağa başladığı üçün zəruri oldu.
Trafikin əsas hissəsi loglar tərəfindən istehlak edildi; ölçülərin özləri, hətta 10 saniyəlik fasilə ilə belə, praktiki olaraq boşa getmədi.
Nəticədə, bir müddət sonra biz cihazlarda qeydlərin toplanması prosesini tamamilə dayandırdıq, çünki daimi toplanmadan belə konkret problemlər artıq aydın idi.
Bəzi hallarda, qeydlərə baxmaq hələ də lazım idisə, biz sadəcə WireGuard vasitəsilə VPN vasitəsilə qoşulduq.
Onu da əlavə edəcəyəm ki, hər bir ayrı mühit bir-birindən ayrılıb və yuxarıda təsvir edilən yük yalnız istehsal mühiti üçün aktual idi.
İnkişaf mühitində biz hər 10 saniyədən bir məlumat toplamağa davam edən ayrıca InfluxDB nümunəsi qaldırdıq və heç bir performans problemi yaşamadıq.
TICK - kiçik və orta layihələr üçün idealdır
Bu məlumatlara əsaslanaraq belə bir nəticəyə gələrdim ki, TICK yığını nisbətən kiçik layihələr və ya heç bir HighLoad gözləməyən layihələr üçün idealdır.
Minlərlə pod və ya yüzlərlə maşınınız yoxdursa, hətta bir InfluxDB nümunəsi yükü yaxşı idarə edəcək.
Bəzi hallarda ibtidai Yüksək Əlçatımlılıq həlli kimi Influx Relay sizi qane edə bilər.
Və əlbəttə ki, heç kim sizə “şaquli” miqyaslaşdırma qurmağınıza və sadəcə müxtəlif növ ölçülər üçün müxtəlif serverlər ayırmağınıza mane olmur.
Əgər siz monitorinq xidmətlərində gözlənilən yükə əmin deyilsinizsə və ya çox “ağır” arxitekturaya malik olduğunuza / olacağına zəmanət verilirsə, mən TICK yığınının pulsuz versiyasından istifadə etməyi məsləhət görməzdim.
Əlbəttə ki, sadə bir həll satın almaq olardı - amma burada nəsə şərh verə bilmərəm, çünki özüm də incəliklərə bələd deyiləm. Bundan əlavə, çox bahalı və kiçik şirkətlər üçün qətiliklə uyğun deyil.
Bu halda, bu gün mən Loki istifadə edərək Victoria Metrics və loglar vasitəsilə ölçüləri toplamağa baxmağı tövsiyə edərdim.
Düzdür, mən yenidən qeyd edəcəyəm ki, Loki/Grafana hazır TICK-dən daha az rahatdır (daha çox yönlü olduğuna görə), lakin onlar pulsuzdur.
Vacibdir: burada təsvir edilən bütün məlumatlar Influx 1.8 versiyası üçün aktualdır, hazırda Influx 2.0 buraxılmaq üzrədir.
Döyüş şəraitində sınaqdan keçirmək şansım olmasa və təkmilləşdirmələr haqqında nəticə çıxarmaq çətin olsa da, interfeys mütləq daha da yaxşılaşdı, arxitektura sadələşdirildi (kapasitor və xronoqraf olmadan),
şablonlar meydana çıxdı (“qatil xüsusiyyət” - ). Ancaq təəssüf ki, hazırda 2-ci versiyada birinci versiyanı seçdiyimiz əsas şey yoxdur - heç bir jurnal kolleksiyası yoxdur.
Bu funksionallıq Influx 2.0-da da görünəcək, lakin biz heç bir son tarix, hətta təxmini olanlar da tapa bilmədik.
IoT platformalarını necə etməmək olar (indi)
Nəhayət, pilotu işə saldıqdan sonra standartlarımıza uyğun alternativ olmadığı halda özümüz tam hüquqlu IoT yığınımızı yığdıq.
Ancaq bu yaxınlarda Beta versiyada mövcuddur - Təəssüf ki, layihəni hazırlamağa başlayanda o, orada deyildi.
Biz son nəticədən və özümüz yığdığımız Ansible + TICK + WireGuard-a əsaslanan platformadan tamamilə razıyıq. Ancaq bu gün öz IoT platformanızı yaratmağa çalışmazdan əvvəl Balena ilə daha yaxından tanış olmağı məsləhət görərdim.
Çünki son nəticədə gördüyümüz işlərin çoxunu edə bilər və OpenBalena pulsuz və açıq mənbədir.
O, artıq nəinki yeniləmələri göndərəcəyini bilir, həm də VPN artıq quraşdırılıb və IoT mühitində istifadə üçün uyğunlaşdırılıb.
Və yalnız bu yaxınlarda, hətta buraxdılar , onların ekosisteminə asanlıqla qoşulur.
Hey, itkin skuter haqqında nə demək olar?
Beləliklə, "Ralph" adlı skuter izsiz yoxa çıxdı.
Dərhal InfluxDB-dən GPS metrik məlumatları ilə “admin panelimizdə” xəritəyə baxmaq üçün qaçdıq.
Monitorinq məlumatları sayəsində biz asanlıqla müəyyən etdik ki, skuter ötən gün saat 21:00 radələrində dayanacaqdan çıxıb, hansısa əraziyə təxminən yarım saat yol gedib və səhər saat 5-ə qədər hansısa alman evinin yanında park edilib.
Səhər saat 5-dən sonra heç bir monitorinq məlumatı alınmadı - bu, ya əlavə batareyanın tamamilə boşaldılması deməkdir, ya da təcavüzkar nəhayət, skuterdən ağıllı aparatı necə çıxaracağını anladı.
Buna baxmayaraq, hələ də skuterin yerləşdiyi ünvana polis çağırılıb. Skuter orada yox idi.
Ancaq ev sahibi də buna təəccübləndi, çünki o, həqiqətən də dünən axşam ofisdən evə bu skuterə minib.
Məlum olduğu kimi, dəstək işçilərindən biri səhər tezdən gəlib və skuterin əlavə akkumulyatorunun tam boşaldığını görərək onu (piyada) dayanacağa aparıb. Və əlavə batareya nəmlik səbəbindən uğursuz oldu.
Skuteri özümüzdən oğurladıq. Yeri gəlmişkən, polis işi ilə bağlı məsələni necə və sonra kimin həll etdiyini bilmirəm, amma monitorinq mükəmməl işlədi...
Mənbə: www.habr.com