Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Pirms gada mēs uzsākām reklāmas projekta izmēģinājuma versiju decentralizēta elektrisko skrejriteņu noma.

Sākotnēji projekts saucās Road-To-Barcelona, ā€‹ā€‹vēlāk tas kļuva par Road-To-Berlin (tātad R2B ekrānuzņēmumos), un beigās to sauca par xRide.

Projekta galvenā ideja bija Ŕāda: tā vietā, lai nodroÅ”inātu centralizētu automaŔīnu vai motorolleru nomas pakalpojumu (mēs runājam par skrejriteņiem jeb elektriskajiem motocikliem, nevis skrejriteņiem/motorolleriem), mēs vēlējāmies izveidot platformu decentralizētai nomai. Par grÅ«tÄ«bām, ar kurām saskārāmies jau rakstÄ«ju iepriekÅ”.

Sākotnēji projekts bija vērsts uz automaŔīnām, taču, ņemot vērā termiņus, ārkārtÄ«gi ilgu saziņu ar ražotājiem un milzÄ«gu skaitu droŔības ierobežojumu, pilotam tika izvēlēti elektriskie skrejriteņi.

Lietotājs tālrunī instalēja iOS vai Android aplikāciju, piegāja pie viņam tīkamā skrejriteņa, pēc kā telefons un skrejritenis izveidoja peer-to-peer savienojumu, notika ETH apmaiņa un lietotājs varēja uzsākt braucienu, ieslēdzot skrejriteni, izmantojot telefons. Ceļojuma beigās bija iespēja arī apmaksāt braucienu, izmantojot Ethereum no lietotāja maka telefonā.

Papildus skrejriteņiem lietotājs aplikācijā ieraudzÄ«ja ā€œviedos lādētājusā€, kurus apmeklējot, lietotājs pats varēja nomainÄ«t esoÅ”o akumulatoru, ja tas bija zems.

Kopumā Ŕādi izskatÄ«jās mÅ«su pilots, kas tika palaists pagājuŔā gada septembrÄ« divās Vācijas pilsētās: Bonnā un BerlÄ«nē.

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Un tad kādu dienu Bonnā agri no rīta mūsu atbalsta komanda (kas atradās uz vietas, lai uzturētu motorollerus darba kārtībā) tika brīdināta: viens no motorolleriem bija pazudis bez vēsts.

Kā to atrast un atgriezt?

Å ajā rakstā es runāŔu par to, bet vispirms par to, kā mēs izveidojām savu IoT platformu un kā mēs to uzraudzÄ«jām.

Kas un kāpēc jāuzrauga: skrejriteņi, infrastruktūra, uzlādes stacijas?

Tātad, ko mēs vēlējāmies uzraudzīt savā projektā?

Pirmkārt, tie ir paÅ”i skrejriteņi - paÅ”i elektriskie skrejriteņi ir diezgan dārgi, bez pietiekamas sagatavoÅ”anās Ŕādu projektu uzsākt nevar, ja iespējams, gribas savākt pēc iespējas vairāk informācijas par skrejriteņiem: par to atraÅ”anās vietu, uzlādes lÄ«meni. utt.

Turklāt es vēlētos uzraudzÄ«t mÅ«su paÅ”u IT infrastruktÅ«ras stāvokli - datu bāzes, servisi un viss, kas tiem nepiecieÅ”ams, lai tie darbotos. Tāpat bija jāuzrauga ā€œviedo lādētājuā€ statuss, ja tie sabojājas vai beigsies pilni akumulatori.

Motorolleri

Kādi bija mūsu skrejriteņi un ko mēs vēlējāmies par tiem uzzināt?

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Pirmā un vissvarīgākā lieta ir GPS koordinātas, jo, pateicoties tām, mēs varam saprast, kur tās atrodas un kur tās pārvietojas.

Tālāk seko akumulatora uzlāde, pateicoties kurai varam noteikt, ka skrejriteņu uzlāde tuvojas beigām un nosūtīt sulu spiedi vai vismaz brīdināt lietotāju.

Protams, ir arÄ« jāpārbauda, ā€‹ā€‹kas notiek ar mÅ«su aparatÅ«ras komponentiem:

  • vai bluetooth darbojas?
  • vai pats GPS modulis strādā?
    • Mums bija arÄ« problēma ar to, ka GPS varēja nosÅ«tÄ«t nepareizas koordinātas un iestrēgt, un to varēja noteikt tikai ar skrejriteņa papildu pārbaudēm,
      un pēc iespējas ātrāk paziņojiet atbalsta dienestam, lai atrisinātu problēmu

Un visbeidzot: programmatÅ«ras pārbaudes, sākot ar OS un procesoru, tÄ«kla un diska slodzi, beidzot ar mÅ«su paÅ”u moduļu pārbaudēm, kas mums ir raksturÄ«gākas (Jolocom, atslēgas apmetnis).

detaļas

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Kāda bija mÅ«su ā€œdzelzsā€ daļa?

Ņemot vērā iespējami Ä«sāko laika posmu un nepiecieÅ”amÄ«bu pēc ātras prototipÄ“Å”anas, mēs izvēlējāmies vieglāko variantu ievieÅ”anai un komponentu atlasei - Raspberry Pi.
Papildus paÅ”am Rpi mums bija pielāgots dēlis (kuru mēs paÅ”i izstrādājām un pasÅ«tÄ«jām no Ķīnas, lai paātrinātu gala risinājuma montāžas procesu) un sastāvdaļu komplekts - relejs (lai ieslēgtu/izslēgtu skrejriteni), akumulatora uzlādes lasÄ«tājs, modems, antenas. Tas viss tika kompakti iepakots Ä«paŔā ā€œxRide kastēā€.

Jāpiebilst arī, ka visa kaste tika darbināta ar papildu jaudas banku, kas savukārt tika darbināta no motorollera galvenā akumulatora.

Tas ļāva izmantot uzraudzÄ«bu un ieslēgt motorolleru pat pēc brauciena beigām, jo ā€‹ā€‹galvenais akumulators tika izslēgts uzreiz pēc aizdedzes atslēgas pagrieÅ”anas pozÄ«cijā ā€œoffā€.

Dokeris? VienkārŔs Linux? un izvietoŔanu

Atgriezīsimies pie monitoringa, tātad Avene - kas mums ir?

Viena no pirmajām lietām, ko vēlējāmies izmantot, lai paātrinātu komponentu izvietoÅ”anas, atjaunināŔanas un piegādes procesu fiziskajās ierÄ«cēs, bija Docker.

Diemžēl ātri kļuva skaidrs, ka Docker uz RPi, lai gan tas darbojas, ir daudz pieskaitāmu, jo Ä«paÅ”i enerÄ£ijas patēriņa ziņā.

AtŔķirÄ«ba, izmantojot ā€œvietējoā€ OS, lai arÄ« ne tik spēcÄ«ga, tomēr bija pietiekama, lai mēs bÅ«tu piesardzÄ«gi par iespēju pārāk ātri zaudēt uzlādi.

Otrs iemesls bija viena no mūsu partneru bibliotēkām vietnē Node.js (sic!) - vienīgā sistēmas sastāvdaļa, kas nebija rakstīta Go/C/C++.

Bibliotēkas autoriem nebija laika nodroÅ”ināt darba versiju nevienā no ā€œdzimtajāmā€ valodām.

Pats mezgls ne tikai nav elegantākais risinājums zemas veiktspējas ierīcēm, bet arī pati bibliotēka bija ļoti resursietilpīga.

Mēs sapratām, ka, pat ja mēs vēlētos, Docker izmantoÅ”ana mums bÅ«tu pārāk liela pieskaitāma. Izvēle tika izdarÄ«ta par labu vietējai OS un darbam tieÅ”i zem tās.

OS

Rezultātā mēs atkal izvēlējāmies vienkārŔāko opciju kā OS un izmantojām Raspbian (Debian build for Pi).

Mēs rakstām visu savu programmatūru programmā Go, tāpēc mēs arī ierakstījām galveno aparatūras aģenta moduli mūsu sistēmā Go.

TieÅ”i viņŔ ir atbildÄ«gs par darbu ar GPS, Bluetooth, uzlādes nolasÄ«Å”anu, skrejriteņa ieslēgÅ”anu utt.

Izvietot

Uzreiz radās jautājums par nepiecieÅ”amÄ«bu ieviest mehānismu atjauninājumu piegādei ierÄ«cēm (OTA) - gan mÅ«su aÄ£enta/programmas atjauninājumus, gan paÅ”as OS/programmaparatÅ«ras atjauninājumus (jo jaunās aÄ£enta versijās var bÅ«t nepiecieÅ”ami kodola atjauninājumi vai sistēmas komponenti, bibliotēkas utt.) .

Pēc diezgan ilgas tirgus analīzes izrādījās, ka ir diezgan daudz risinājumu ierīces atjauninājumu piegādei.

No salÄ«dzinoÅ”i vienkārŔām, galvenokārt uz atjaunināŔanu/dubultā sāknÄ“Å”anas orientētām utilÄ«tprogrammām, piemēram, swupd/SWUpdate/OSTree, lÄ«dz pilnvērtÄ«gām platformām, piemēram, Mender un Balena.

Pirmkārt, nolēmām, ka mÅ«s interesē visaptveroÅ”i risinājumi, tāpēc izvēle uzreiz krita uz platformām.

Ä»oti Balēna tika izslēgts, jo tas faktiski izmanto to paÅ”u Docker savā balenaEngine.

Bet es atzÄ«mēju, ka, neskatoties uz to, mēs pastāvÄ«gi izmantojām viņu produktu Balena Etcher zibatmiņas programmaparatÅ«rai SD kartēs - vienkārÅ”a un ārkārtÄ«gi ērta utilÄ«ta.

Tāpēc galu galā izvēle krita Menders. Mender ir pilnÄ«ga platforma programmaparatÅ«ras montāžai, piegādei un instalÄ“Å”anai.

Kopumā platforma izskatās lieliski, taču mums vajadzēja apmēram pusotru nedēļu, lai izveidotu pareizo mūsu programmaparatūras versiju, izmantojot labotāju veidotāju.
Un jo vairāk mēs iedziļinājāmies tā izmantoÅ”anas sarežģītÄ«bā, jo vairāk kļuva skaidrs, ka, lai to pilnÄ«bā izmantotu, mums bÅ«s nepiecieÅ”ams daudz vairāk laika, nekā mums bija.

Diemžēl mÅ«su stingrie termiņi nozÄ«mēja, ka bijām spiesti atteikties no Mender lietoÅ”anas un izvēlēties vēl vienkārŔāku.

Iespējams

VienkārŔākais risinājums mÅ«su situācijā bija izmantot Ansible. Lai sāktu, pietika ar pāris spēļu grāmatām.

Viņu bÅ«tÄ«ba bija tāda, ka mēs vienkārÅ”i izveidojām savienojumu no resursdatora (CI servera), izmantojot ssh, ar mÅ«su avenēm un izplatÄ«jām tiem atjauninājumus.

PaŔā sākumā viss bija vienkārÅ”i ā€“ bija jābÅ«t vienā tÄ«klā ar ierÄ«cēm, lieÅ”ana notika caur Wi-Fi.

Birojā bija vienkārÅ”i ducis testa aveņu, kas pieslēgti vienam tÄ«klam, katrai ierÄ«cei bija statiska IP adrese, kas norādÄ«ta arÄ« Ansible Inventory.

Tas bija Ansible, kas nogādāja mūsu uzraudzības aģentu gala ierīcēm

3G / LTE

Diemžēl Å”is Ansible lietoÅ”anas gadÄ«jums varēja darboties tikai izstrādes režīmā, pirms mums bija faktiski skrejriteņi.

Jo motorolleri, kā jÅ«s saprotat, nesēž savienoti ar vienu Wi-Fi marÅ”rutētāju, nepārtraukti gaidot atjauninājumus tÄ«klā.

Patiesībā motorolleriem nevar būt nekāda cita savienojuma, izņemot mobilo 3G/LTE (un pat tad ne visu laiku).

Tas nekavējoties rada daudzas problēmas un ierobežojumus, piemēram, zemu savienojuma ātrumu un nestabilu saziņu.

Bet vissvarÄ«gākais ir tas, ka 3G/LTE tÄ«klā mēs nevaram vienkārÅ”i paļauties uz tÄ«klam pieŔķirto statisko IP.

To daļēji atrisina daži SIM karÅ”u nodroÅ”inātāji; ir pat Ä«paÅ”as SIM kartes, kas paredzētas IoT ierÄ«cēm ar statiskām IP adresēm. Bet mums nebija piekļuves Ŕādām SIM kartēm un nevarējām izmantot IP adreses.

Protams, bija idejas veikt kaut kādu IP adreÅ”u reÄ£istrāciju jeb pakalpojumu atklāŔanu kaut kur, piemēram, Consul, bet mums nācās atteikties no Ŕādām idejām, jo ā€‹ā€‹mÅ«su testos IP adrese varēja mainÄ«ties pārāk bieži, kas izraisÄ«ja lielu nestabilitāti.

Å Ä« iemesla dēļ visērtāk izmantot metrikas piegādi bÅ«tu nevis pull modeļa izmantoÅ”ana, kur mēs dotos uz ierÄ«cēm, lai meklētu nepiecieÅ”amos rādÄ«tājus, bet gan push, nogādājot metriku no ierÄ«ces tieÅ”i uz serveri.

VPN

Kā Ŕīs problēmas risinājumu mēs izvēlējāmies VPN ā€” Ä«paÅ”i Stiepļu sargs.

Klienti (motorolleri) sistēmas darbības sākumā izveidoja savienojumu ar VPN serveri un varēja ar tiem izveidot savienojumu. Šis tunelis tika izmantots atjauninājumu piegādei.

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Teorētiski vienu un to paÅ”u tuneli varētu izmantot uzraudzÄ«bai, taču Ŕāds savienojums bija sarežģītāks un mazāk uzticams nekā vienkārÅ”a stumÅ”ana.

Mākoņu resursi

Visbeidzot, ir jāuzrauga mÅ«su mākoņpakalpojumi un datu bāzes, jo mēs tiem izmantojam Kubernetes, ideālā gadÄ«jumā, lai uzraudzÄ«bas izvietoÅ”ana klasterÄ« bÅ«tu pēc iespējas vienkārŔāka. Ideālā gadÄ«jumā, izmantojot StÅ«re, jo izvietoÅ”anai mēs to izmantojam vairumā gadÄ«jumu. Un, protams, lai uzraudzÄ«tu mākoni, jāizmanto tie paÅ”i risinājumi, kas paÅ”iem skrejriteņiem.

Ņemot vērā

Fu, Ŕķiet, esam sakārtojuŔi aprakstu, beigās izveidosim vajadzīgo sarakstu:

  • Ātrs risinājums, jo uzraudzÄ«ba ir nepiecieÅ”ama jau izstrādes procesā
  • Apjoms/daudzums ā€” nepiecieÅ”ami daudzi rādÄ«tāji
  • NepiecieÅ”ama baļķu savākÅ”ana
  • UzticamÄ«ba ā€” datiem ir izŔķiroÅ”a nozÄ«me, lai uzsāktu panākumus
  • JÅ«s nevarat izmantot vilkÅ”anas modeli - jums ir nepiecieÅ”ams push
  • Mums ir nepiecieÅ”ama vienota ne tikai aparatÅ«ras, bet arÄ« mākoņa uzraudzÄ«ba

GalÄ«gais attēls izskatÄ«jās apmēram Ŕādi

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Stack atlase

Tātad, mēs saskārāmies ar jautājumu par uzraudzības steka izvēli.

Pirmkārt, mēs meklējām vispilnÄ«gāko all-in-one risinājumu, kas vienlaikus aptvertu visas mÅ«su prasÄ«bas, bet tajā paŔā laikā bÅ«tu pietiekami elastÄ«gs, lai pielāgotu tā izmantoÅ”anu mÅ«su vajadzÄ«bām. Tomēr mums bija daudz ierobežojumu, ko mums uzlika aparatÅ«ra, arhitektÅ«ra un termiņi.

Ir ļoti daudz dažādu uzraudzības risinājumu, sākot ar pilnvērtīgām sistēmām, piemēram Nagios, icinga vai zabbix un beidzot ar gataviem Flotes pārvaldības risinājumiem.

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Sākotnēji pēdējais mums Ŕķita ideāls risinājums, taču dažiem nebija pilnÄ«gas uzraudzÄ«bas, citiem bija ļoti ierobežotas bezmaksas versiju iespējas, un citi vienkārÅ”i neaptvēra mÅ«su "vēlmes" vai nebija pietiekami elastÄ«gi, lai atbilstu mÅ«su scenārijiem. Daži vienkārÅ”i ir novecojuÅ”i.

Izanalizējot vairākus lÄ«dzÄ«gus risinājumus, mēs ātri nonācām pie secinājuma, ka vieglāk un ātrāk bÅ«tu paÅ”iem salikt lÄ«dzÄ«gu skursteni. Jā, tas bÅ«s nedaudz sarežģītāk nekā ieviest pilnÄ«bā gatavu Flotes pārvaldÄ«bas platformu, taču mums nebÅ«s jāiet uz kompromisiem.

GandrÄ«z noteikti visā milzÄ«gajā risinājumu pārpilnÄ«bā jau ir kāds gatavs, kas mums pilnÄ«bā atbilstu, taču mÅ«su gadÄ«jumā daudz ātrāk bija paÅ”iem salikt noteiktu kaudzi un pielāgot to ā€œpaÅ”amā€, nevis gatavu produktu testÄ“Å”ana.

Ar visu Å”o mēs necentāmies paÅ”i salikt visu uzraudzÄ«bas platformu, bet meklējām funkcionālākos ā€œgatavusā€ stekus, tikai ar iespēju tos elastÄ«gi konfigurēt.

(B)ELK?

Pirmais risinājums, kas faktiski tika apsvērts, bija plaÅ”i pazÄ«stamā ELK kaudze.
Patiesībā to vajadzētu saukt par BELK, jo viss sākas ar Beats Sākot no https://www.elastic.co/what-is/elk-stack

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Protams, ELK ir viens no slavenākajiem un jaudÄ«gākajiem risinājumiem monitoringa jomā un vēl jo vairāk žurnālu vākÅ”anā un apstrādē.

Bijām iecerējuÅ”i, ka ELK tiks izmantots baļķu savākÅ”anai, kā arÄ« no Prometheus iegÅ«to metriku ilgstoÅ”ai glabāŔanai.

Vizualizācijai varat izmantot Grafan.

Faktiski jaunā ELK kaudze var apkopot metriku neatkarīgi (metricbeat), un Kibana var arī tos parādīt.

Tomēr ELK sākotnēji izauga no apaļkokiem, un lÄ«dz Å”im metrikas funkcionalitātei ir vairāki nopietni trÅ«kumi:

  • Ievērojami lēnāks nekā Prometejs
  • Integrējas daudz mazākās vietās nekā Prometejs
  • Viņiem ir grÅ«ti iestatÄ«t brÄ«dinājumus
  • Metrika aizņem daudz vietas
  • Informācijas paneļu iestatÄ«Å”ana ar metriku programmā Kiban ir daudz sarežģītāka nekā Grafan

Kopumā ELK metrika ir smaga un vēl nav tik ērta kā citos risinājumos, no kuriem tagad ir daudz vairāk nekā tikai Prometheus: TSDB, Victoria Metrics, Cortex utt., utt. Protams, ļoti gribētos uzreiz pilnvērtīgu all-in-one risinājumu, taču metricbeat gadījumā bija pārāk daudz kompromisu.

Un paŔai ELK kaudzei ir vairāki sarežģīti brīži:

  • Tas ir smags, dažreiz pat ļoti smags, ja tiek savākts diezgan liels datu apjoms
  • Jums tas ir "jāprot gatavot" - jums tas ir jāmēro, bet tas nav triviāli izdarÄ«t
  • Noņemta bezmaksas versija - bezmaksas versijai nav parastu brÄ«dinājumu, un atlases brÄ«dÄ« nebija autentifikācijas

Man jāsaka, ka pēdējā laikā pēdējais punkts ir kļuvis labāks un papildus izvade atvērtā koda X-pack (ieskaitot autentifikāciju) sāka mainÄ«ties pats cenu noteikÅ”anas modelis.

Bet laikā, kad mēs plānojām izvietot Å”o risinājumu, brÄ«dinājums vispār netika saņemts.
Iespējams, mēs bÅ«tu varējuÅ”i mēģināt kaut ko izveidot, izmantojot ElastAlert vai citus kopienas risinājumus, taču mēs tomēr nolēmām apsvērt citas alternatÄ«vas.

Loki - Grafana - Prometejs

Å obrÄ«d labs risinājums varētu bÅ«t uzraudzÄ«bas steka izveide, pamatojoties tikai uz Prometheus kā metrikas nodroÅ”inātāju, Loki žurnāliem, un vizualizācijai varat izmantot to paÅ”u Grafana.

Diemžēl projekta pārdoÅ”anas pilota darbÄ«bas uzsākÅ”anas brÄ«dÄ« (19. gada septembris-oktobris) Loki vēl bija beta versijā 0.3-0.4, un izstrādes uzsākÅ”anas brÄ«dÄ« to nevarēja uzskatÄ«t par ražoÅ”anas risinājumu. pavisam.

Man vēl nav pieredzes Loki izmantoÅ”anā nopietnos projektos, taču varu teikt, ka Promtail (baļķu savākÅ”anas aÄ£ents) lieliski darbojas gan plikmetāla, gan kubernetes podiem.

CENU

Iespējams, ka cienīgākā (vienīgā?) pilnvērtīgā alternatīva ELK stekam tagad var saukt tikai par TICK steku - Telegraf, InfluxDB, Chronograf, Kapacitor.

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Tālāk es aprakstīŔu visus komponentus sīkāk, bet vispārīgā ideja ir Ŕāda:

  • Telegraf - aÄ£ents metriku apkopoÅ”anai
  • InfluxDB - metriku datu bāze
  • Kapacitor - reāllaika metrikas procesors brÄ«dināŔanai
  • Chronograf - tÄ«mekļa panelis vizualizācijai

AttiecÄ«bā uz InfluxDB, Kapacitor un Chronograf ir oficiālas stÅ«res diagrammas, kuras mēs izmantojām to izvietoÅ”anai.

Jāpiebilst, ka jaunākajā Influx 2.0 (beta) versijā Kapacitor un Chronograf kļuva par InfluxDB daļu un vairs nepastāv atseviŔķi

Telegrāfs

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Telegrāfs ir ļoti viegls līdzeklis rādītāju apkopoŔanai stāvokļa maŔīnā.

ViņŔ var uzraudzÄ«t milzÄ«gu daudzumu visa, sākot no nginx lÄ«dz
serveris Minecraft.

Tam ir vairākas lieliskas priekŔrocības:

  • Ātrs un viegls (rakstÄ«ts Go)
    • Ēd minimālu resursu daudzumu
  • Push metrika pēc noklusējuma
  • Apkopo visus nepiecieÅ”amos rādÄ«tājus
    • Sistēmas rādÄ«tāji bez iestatÄ«jumiem
    • AparatÅ«ras metrika, piemēram, informācija no sensoriem
    • Ir ļoti vienkārÅ”i pievienot savus rādÄ«tājus
  • Daudz spraudņu no kastes
  • Savāc baļķus

Tā kā push metrika mums bija nepiecieÅ”ama, visas pārējās priekÅ”rocÄ«bas bija vairāk nekā patÄ«kami papildinājumi.

ArÄ« paÅ”a aÄ£enta veiktā žurnālu savākÅ”ana ir ļoti ērta, jo žurnālu reÄ£istrÄ“Å”anai nav jāpievieno papildu utilÄ«tas.

Influx piedāvā visērtāko pieredzi darbam ar apaļkokiem, ja to izmantojat syslog.

Telegraf parasti ir lielisks lÄ«dzeklis metriku apkopoÅ”anai, pat ja jÅ«s neizmantojat pārējo ICK steku.

Daudzi cilvēki to izmanto ELK un dažādām citām laikrindu datu bāzēm ērtības labad, jo tā var ierakstīt metriku gandrīz jebkurā vietā.

InfluxDB

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

InfluxDB ir galvenais TICK steka kodols, proti, metrikas laikrindu datubāze.
Papildus metrikām Influx var glabāt arī žurnālus, lai gan būtībā žurnāli tam ir tikai tie paŔi rādītāji, tikai parasto skaitlisko rādītāju vietā galveno funkciju veic žurnāla teksta rinda.

InfluxDB ir rakstÄ«ts arÄ« programmā Go, un Ŕķiet, ka tas darbojas daudz ātrāk, salÄ«dzinot ar ELK mÅ«su (ne visspēcÄ«gākajā) klasterÄ«.

Viena no lieliskajām Influx priekÅ”rocÄ«bām bÅ«tu arÄ« ļoti ērta un bagātÄ«ga API datu vaicājumiem, ko mēs ļoti aktÄ«vi izmantojām.

TrÅ«kumi - $$$ vai mērogoÅ”ana?

TICK kaudzei ir tikai viens trūkums, ko mēs atklājām - tas Dārgi. Pat vairāk.

Kas ir maksas versijai, kas nav bezmaksas versijai?

Cik mēs varējām saprast, vienÄ«gā atŔķirÄ«ba starp TICK steka maksas versiju un bezmaksas versiju ir mērogoÅ”anas iespējas.

Proti, jÅ«s varat izveidot klasteru ar augstu pieejamÄ«bu tikai iekŔā Uzņēmuma versijas.

Ja vēlaties pilnvērtÄ«gu HA, jums vai nu jāmaksā, vai jāizmanto daži kruÄ·i. Ir daži kopienas risinājumi ā€“ piemēram influxdb-ha izskatās pēc kompetenta risinājuma, bet rakstÄ«ts, ka neder ražoÅ”anai, kā arÄ«
pieplÅ«duma snÄ«pis - vienkārÅ”s risinājums ar datu pārsÅ«knÄ“Å”anu caur NATS (tas arÄ« bÅ«s jāmēro, bet to var atrisināt).

Žēl, bet Ŕķiet, ka abas ir pamestas - jaunu commit nav, pieņemu, ka problēma ir drÄ«zumā gaidāmā jaunās Influx 2.0 versijas iznākÅ”ana, kurā daudz kas bÅ«s savādāk (nav informācijas par mērogoÅ”ana tajā vēl).

Oficiāli ir bezmaksas versija relejs - patiesībā Ŕī ir primitīva HA, bet tikai ar līdzsvaroŔanu,
jo visi dati tiks rakstīti visos InfluxDB gadījumos aiz slodzes balansētāja.
Viņam ir daži trÅ«kumi piemēram, iespējamās problēmas ar punktu pārrakstÄ«Å”anu un nepiecieÅ”amÄ«bu iepriekÅ” izveidot metrikas bāzi
(kas notiek automātiski parastajā darbā ar InfluxDB).

Papildus sadalÄ«Å”ana netiek atbalstÄ«ta, tas nozÄ«mē papildu pieskaitāmās izmaksas par dublikātu metriku (gan apstrādi, gan glabāŔanu), kas jums var nebÅ«t vajadzÄ«gas, taču nav iespējas tos atdalÄ«t.

Viktorijas metrika?

Rezultātā, neskatoties uz to, ka bijām pilnÄ«bā apmierināti ar TICK steku visā, izņemot maksas mērogoÅ”anu, mēs nolēmām pārbaudÄ«t, vai ir kādi bezmaksas risinājumi, kas varētu aizstāt InfluxDB datu bāzi, atstājot atlikuÅ”os T_CK komponentus.

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Ir daudz laikrindu datu bāzu, bet visdaudzsoloŔākā ir Victoria Metrics, kurai ir vairākas priekŔrocības:

  • Ātri un vienkārÅ”i, vismaz pēc rezultātiem etaloniem
  • Ir klastera versija, par kuru tagad ir pat labas atsauksmes
    • Viņa var saŔķelt
  • Atbalsta InfluxDB protokolu

Mēs nedomājām izveidot pilnībā pielāgotu steku, pamatojoties uz Viktoriju, un galvenā cerība bija, ka mēs varētu to izmantot kā InfluxDB aizstājēju.

Diemžēl tas nav iespējams, neskatoties uz to, ka tiek atbalstÄ«ts InfluxDB protokols, tas darbojas tikai metrikas ierakstÄ«Å”anai - tikai Prometheus API ir pieejama ā€œÄrpusā€, kas nozÄ«mē, ka tajā nevarēs iestatÄ«t Chronograf.

Turklāt metrikai tiek atbalstÄ«tas tikai skaitliskās vērtÄ«bas (pielāgotajiem rādÄ«tājiem mēs izmantojām virkņu vērtÄ«bas ā€” vairāk par to sadaļā admin panelis).

AcÄ«mredzot tā paÅ”a iemesla dēļ VM nevar saglabāt žurnālus, kā to dara Influx.

Tāpat jāatzÄ«mē, ka optimālā risinājuma meklÄ“Å”anas brÄ«dÄ« Victoria Metrics vēl nebija tik populārs, dokumentācija bija daudz mazāka un funkcionalitāte vājāka
(Es neatceros detalizētu klastera versijas un sadalÄ«Å”anas aprakstu).

Bāzes izvēle

Rezultātā tika nolemts, ka pilotam mēs tomēr aprobežosimies ar vienu InfluxDB mezglu.

Šai izvēlei bija vairāki galvenie iemesli:

  • Mums ļoti patika visa TICK kaudzes funkcionalitāte
  • Mums jau izdevās to izvietot, un tas darbojās lieliski
  • Termiņi tuvojās beigām, un nebija palicis daudz laika, lai pārbaudÄ«tu citas iespējas.
  • Nebijām gaidÄ«juÅ”i tik lielu slodzi

Mums nebija daudz skrejriteņu izmēģinājuma pirmajai fāzei, un testÄ“Å”ana izstrādes laikā neatklāja nekādas veiktspējas problēmas.

Tāpēc mēs nolēmām, ka Å”im projektam mums pietiks ar vienu Influx mezglu bez mērogoÅ”anas (skat. secinājumus beigās).

Mēs esam izlēmuÅ”i par kaudzÄ«ti un bāzi ā€” tagad par atlikuÅ”ajām TICK steka sastāvdaļām.

Kondensators

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Kapacitor ir daļa no TICK steka ā€” pakalpojuma, kas var reāllaikā pārraudzÄ«t datubāzē ienākoÅ”os rādÄ«tājus un veikt dažādas darbÄ«bas, kuru pamatā ir noteikumi.

Kopumā tas tiek pozicionēts kā rÄ«ks iespējamu anomāliju izsekoÅ”anai un maŔīnmācÄ«bai (es neesmu pārliecināts, ka Ŕīs funkcijas ir pieprasÄ«tas), taču visizplatÄ«tākais ir tā lietoÅ”anas veids - brÄ«dināŔana.

Tādā veidā mēs to izmantojām paziņojumiem. Mēs iestatījām Slack brīdinājumus, kad konkrēts skrejritenis pārgāja bezsaistē, un tas pats tika darīts ar viedajiem lādētājiem un svarīgiem infrastruktūras komponentiem.

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Tas ļāva ātri reaģēt uz problēmām, kā arī saņemt paziņojumus, ka viss ir atgriezies normālā stāvoklī.

VienkārÅ”s piemērs: ir sabojājies vai kāda iemesla dēļ ir izlādējies papildu akumulators mÅ«su ā€œkastesā€ baroÅ”anai; vienkārÅ”i uzstādot jaunu, pēc kāda laika mums vajadzētu saņemt paziņojumu, ka skrejriteņa funkcionalitāte ir atjaunota.

Influx 2.0 Kapacitor kļuva par daļu no DB

Hronogrāfs

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Esmu redzējis daudz dažādu UI risinājumu monitoringam, taču varu teikt, ka funkcionalitātes un UX ziņā nekas nav salīdzināms ar Chronograf.

Mēs sākām izmantot TICK steku, dīvainā kārtā, ar Grafan kā tīmekļa saskarni.
Es neaprakstÄ«Å”u tā funkcionalitāti; visi zina tās plaŔās iespējas jebko iestatÄ«t.

Tomēr Grafana joprojām ir pilnÄ«gi universāls instruments, savukārt Chronograf galvenokārt paredzēts lietoÅ”anai ar Influx.

Un, protams, pateicoties tam, Chronograf var atļauties daudz gudrāku vai ērtāku funkcionalitāti.

Iespējams, galvenā ērtÄ«ba, strādājot ar Chronograf, ir tāda, ka varat skatÄ«t sava InfluxDB iekÅ”pusi, izmantojot funkciju Explore.

Å Ä·iet, ka Grafānai ir gandrÄ«z identiska funkcionalitāte, taču patiesÄ«bā Chronograf informācijas paneli var iestatÄ«t ar dažiem peles klikŔķiem (vienlaikus apskatot tur esoÅ”o vizualizāciju), savukārt Grafānā agri vai vēlu bÅ«s lai rediģētu JSON konfigurāciju (protams, Chronograf ļauj augÅ”upielādēt jÅ«su manuāli konfigurētās domas un vajadzÄ«bas gadÄ«jumā rediģēt tās kā JSON ā€” bet man nekad nebija tām nācies pieskarties pēc to izveidoÅ”anas lietotāja saskarnē).

Kibana ir daudz bagātākas informācijas paneļu un vadÄ«bas ierīču izveides iespējas, taču Ŕādu darbÄ«bu UX ir ļoti sarežģīta.

Lai izveidotu ērtu informācijas paneli, bÅ«s nepiecieÅ”ama laba izpratne. Un, lai gan Chronograf informācijas paneļu funkcionalitāte ir mazāka, to izgatavoÅ”ana un pielāgoÅ”ana ir daudz vienkārŔāka.

PaÅ”i informācijas paneļi, izņemot patÄ«kamo vizuālo stilu, faktiski neatŔķiras no Grafana vai Kibana informācijas paneļiem:

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Lūk, kā izskatās vaicājuma logs:

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Cita starpā ir svarÄ«gi atzÄ«mēt, ka, zinot InfluxDB datubāzes lauku veidus, pats hronogrāfs dažkārt var automātiski palÄ«dzēt jums rakstÄ«t vaicājumu vai izvēlēties pareizo apkopoÅ”anas funkciju, piemēram, vidējo.

Un, protams, Chronograf ir pēc iespējas ērtāks žurnālu apskatei. Tas izskatās Ŕādi:

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Pēc noklusējuma Influx žurnāli ir pielāgoti syslog lietoÅ”anai, un tāpēc tiem ir svarÄ«gs parametrs - smaguma pakāpe.

ÄŖpaÅ”i noderÄ«gs ir augÅ”pusē esoÅ”ais grafiks, kurā var redzēt raduŔās kļūdas un krāsa uzreiz skaidri parāda, vai nopietnÄ«ba ir augstāka.

Pāris reizes mēs Ŕādā veidā noķērām svarÄ«gas kļūdas, ejot apskatÄ«t pēdējās nedēļas baļķus un redzot sarkanu smaili.

Protams, ideālā gadÄ«jumā bÅ«tu jāiestata brÄ«dinājumi par Ŕādām kļūdām, jo ā€‹ā€‹mums jau bija viss, kas nepiecieÅ”ams.

Mēs pat kādu laiku to ieslēdzām, bet pilota sagatavoÅ”anas procesā izrādÄ«jās, ka saņemam diezgan daudz kļūdu (tostarp sistēmas kļūdas, piemēram, LTE tÄ«kla nepieejamÄ«ba), kas "spamo" Slack kanālu. pārāk daudz, neradot nekādas problēmas.liels ieguvums.

Pareizais risinājums bÅ«tu apstrādāt lielāko daļu Ŕāda veida kļūdu, pielāgot to nopietnÄ«bu un tikai pēc tam iespējot brÄ«dinājumus.

Tādā veidā pakalpojumā Slack tiks publicētas tikai jaunas vai svarÄ«gas kļūdas. Ņemot vērā saspringtos termiņus, Ŕādai iestatÄ«Å”anai vienkārÅ”i nebija pietiekami daudz laika.

Autentifikācija

Ir arī vērts pieminēt, ka Chronograf atbalsta OAuth un OIDC kā autentifikāciju.

Tas ir ļoti ērti, jo ļauj to viegli pievienot savam serverim un izveidot pilnvērtīgu SSO.

MÅ«su gadÄ«jumā serveris bija atslēgas apmetnis ā€” tas tika izmantots, lai izveidotu savienojumu ar uzraudzÄ«bu, bet tas pats serveris tika izmantots arÄ« motorolleru un pieprasÄ«jumu autentifikācijai aizmugurē.

"Administrators"

Pēdējais komponents, ko es aprakstÄ«Å”u, ir mÅ«su paÅ”u rakstÄ«tais ā€œadmin panelisā€ Vue.
BÅ«tÄ«bā tas ir tikai atseviŔķs pakalpojums, kas vienlaikus parāda skrejriteņa informāciju no mÅ«su paÅ”u datu bāzēm, mikropakalpojumiem un metrikas datus no InfluxDB.

Turklāt tur tika pārvietotas daudzas administratÄ«vās funkcijas, piemēram, avārijas atsāknÄ“Å”ana vai attālināta slēdzenes atvērÅ”ana atbalsta komandai.

Bija arÄ« kartes. Jau minēju, ka sākām ar Grafana nevis Chronograf - jo priekÅ” Grafana ir pieejamas kartes spraudņu veidā, uz kurām varēja apskatÄ«t motorolleru koordinātes. Diemžēl Grafana karÅ”u logrÄ«ku iespējas ir ļoti ierobežotas, un rezultātā dažu dienu laikā bija daudz vieglāk uzrakstÄ«t savu tÄ«mekļa aplikāciju ar kartēm, lai Å”obrÄ«d ne tikai redzētu koordinātas, bet arÄ« parādÄ«tu skrejriteņa veiktais marÅ”ruts, jāspēj filtrēt datus kartē utt. (visa tā funkcionalitāte, ko nevarējām konfigurēt vienkārŔā informācijas panelÄ«).

Viena no jau minētajām Influx priekÅ”rocÄ«bām ir iespēja ērti izveidot savus rādÄ«tājus.
Tas ļauj to izmantot ļoti dažādiem scenārijiem.

Mēs centāmies tur ierakstÄ«t visu noderÄ«go informāciju: akumulatora uzlādes lÄ«meni, bloÄ·Ä“Å”anas statusu, sensora darbÄ«bu, Bluetooth, GPS un daudzas citas veselÄ«bas pārbaudes.
Mēs to visu parādījām administratora panelī.

Protams, mums svarÄ«gākais kritērijs bija skrejriteņa darbÄ«bas stāvoklis - patiesÄ«bā Influx pats to pārbauda un rāda ar ā€œzaļajām gaismāmā€ sadaļā Nodes.

To veic funkcija nāve ā€” mēs to izmantojām, lai izprastu mÅ«su kastes veiktspēju un nosÅ«tÄ«tu tos paÅ”us brÄ«dinājumus Slack.

Starp citu, skrejriteņus nosaucām pēc Simpsonu varoņu vārdiem - bija tik ērti tos atŔķirt vienu no otra

Un vispār Ŕādā veidā bija jautrāk. PastāvÄ«gi tika dzirdētas tādas frāzes kā ā€œPuiÅ”i, Smiters ir miris!ā€.

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Virknes metrika

Ir svarīgi, lai InfluxDB ļautu saglabāt ne tikai skaitliskās vērtības, kā tas ir Victoria Metrics gadījumā.

Å Ä·iet, ka tas nav tik svarÄ«gi - galu galā, izņemot žurnālus, jebkuru metriku var saglabāt skaitļu veidā (vienkārÅ”i pievienojiet kartÄ“Å”anu zināmiem stāvokļiem - sava veida enum)?

Mūsu gadījumā bija vismaz viens scenārijs, kurā virknes metrika bija ļoti noderīga.
SagadÄ«jās, ka mÅ«su ā€œviedo lādētājuā€ piegādātājs bija treŔā puse, mums nebija nekādas kontroles pār izstrādes procesu un informāciju, ko Å”ie lādētāji varētu sniegt.

Rezultātā uzlādes API bija tālu no ideāla, taču galvenā problēma bija tā, ka mēs ne vienmēr varējām saprast to stāvokli.

Å eit palÄ«gā nāca Influx. Mēs vienkārÅ”i ierakstÄ«jām InfluxDB datu bāzes laukā virknes statusu bez izmaiņām.

Kādu laiku tur nokļuva tikai tādas vērtÄ«bas kā ā€œtieÅ”saisteā€ un ā€œbezsaistēā€, pamatojoties uz kurām informācija tika parādÄ«ta mÅ«su administratora panelÄ«, un paziņojumi tika nosÅ«tÄ«ti uz Slack. Tomēr kādā brÄ«dÄ« tur sāka parādÄ«ties arÄ« tādas vērtÄ«bas kā ā€œatvienotsā€.

Kā vēlāk izrādÄ«jās, Å”is statuss tika nosÅ«tÄ«ts vienu reizi pēc savienojuma zaudÄ“Å”anas, ja lādētājs pēc noteikta mēģinājumu skaita nevarēja izveidot savienojumu ar serveri.

Tādējādi, ja mēs izmantotu tikai fiksētu vērtÄ«bu kopu, mēs, iespējams, neredzēsim Ŕīs programmaparatÅ«ras izmaiņas Ä«stajā laikā.

Un vispār virkņu metrika sniedz daudz plaŔākas izmantoÅ”anas iespējas, tajās var ierakstÄ«t praktiski jebkuru informāciju. Lai gan, protams, jums arÄ« rÅ«pÄ«gi jāizmanto Å”is rÄ«ks.

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Papildus parastajiem rādÄ«tājiem mēs ierakstÄ«jām arÄ« GPS atraÅ”anās vietas informāciju InfluxDB. Tas bija neticami noderÄ«gi, lai uzraudzÄ«tu motorolleru atraÅ”anās vietu mÅ«su administratora panelÄ«.
PatiesÄ«bā mēs vienmēr zinājām, kur un kurÅ” skrejritenis atrodas mums vajadzÄ«gajā brÄ«dÄ«.

Tas mums ļoti noderēja, kad meklējām skrejriteni (skat. secinājumus beigās).

Infrastruktūras uzraudzība

Papildus paÅ”iem skrejriteņiem mums bija jāuzrauga arÄ« visa mÅ«su (diezgan plaŔā) infrastruktÅ«ra.

Ä»oti vispārÄ«ga arhitektÅ«ra izskatÄ«jās apmēram Ŕādi:

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Ja mēs izceļam tÄ«ru uzraudzÄ«bas steku, tas izskatās Ŕādi:

Atgrieziet pazuduŔo skrejriteni vai stāstu par vienu IoT uzraudzību

Tas, ko mēs vēlētos pārbaudīt mākonī, ir:

  • Datu bāzes
  • atslēgas apmetnis
  • Mikropakalpojumi

Tā kā visi mūsu mākoņpakalpojumi atrodas Kubernetes, būtu jauki apkopot informāciju par tā stāvokli.

Par laimi, Telegraf no kastes var savākt milzīgu skaitu metrikas par Kubernetes klastera stāvokli, un Chronograf tam nekavējoties piedāvā skaistus informācijas paneļus.

Mēs galvenokārt uzraudzījām podziņu veiktspēju un atmiņas patēriņu. Kritiena gadījumā brīdina Slack.

Ir divi veidi, kā izsekot podi Kubernetes: DaemonSet un Sidecar.
Abas metodes ir sīki aprakstītas Ŕajā emuāra ierakstā.

Mēs izmantojām Telegraf Sidecar un papildus metrikām savācām pod žurnālus.

MÅ«su gadÄ«jumā mums bija jāmācās ar baļķiem. Neskatoties uz to, ka Telegraf var izvilkt žurnālus no Docker API, mēs vēlējāmies, lai mÅ«su gala ierÄ«cēm bÅ«tu vienota žurnālu kolekcija un Å”im nolÅ«kam bÅ«tu konfigurēti konteineri. VarbÅ«t Å”is risinājums nebija skaists, bet par tā darbÄ«bu sÅ«dzÄ«bu nebija un žurnāli Chronografā bija labi attēloti.

Monitoru uzraudzību???

Galu galā radās mūžsenais jautājums par monitoringa sistēmu monitoringu, bet par laimi vai diemžēl mums tam vienkārÅ”i nepietika laika.

Lai gan Telegraf var viegli nosūtīt savus rādītājus vai savākt rādītājus no InfluxDB datu bāzes, lai tos nosūtītu uz to paŔu Influx vai kaut kur citur.

Atzinumi

Kādus secinājumus izdarījām no izmēģinājuma rezultātiem?

Kā jūs varat veikt monitoringu?

Pirmkārt, TICK steks pilnībā attaisnoja mūsu cerības un deva mums vēl vairāk iespēju nekā sākotnēji gaidījām.

Bija klāt visa vajadzīgā funkcionalitāte. Viss, ko ar to darījām, darbojās bez problēmām.

ŠŸŃ€Š¾ŠøŠ·Š²Š¾Š“ŠøтŠµŠ»ŃŒŠ½Š¾ŃŃ‚ŃŒ

Galvenā problēma ar TICK steku bezmaksas versijā ir mērogoÅ”anas iespēju trÅ«kums. Tā mums nebija problēma.

Mēs neievācām precīzus slodzes datus/skaitļus, taču mēs ievācām datus no aptuveni 30 motorolleriem vienlaikus.

Katrs no viņiem savāca vairāk nekā trÄ«s desmitus rādÄ«tāju. Tajā paŔā laikā tika savākti žurnāli no ierÄ«cēm. Datu vākÅ”ana un nosÅ«tÄ«Å”ana notika ik pēc 10 sekundēm.

SvarÄ«gi atzÄ«mēt, ka pēc pusotras nedēļas izmēģinājuma, kad lielākā daļa ā€œbērnÄ«bas čūluā€ tika novērstas un svarÄ«gākās problēmas jau bija atrisinātas, nācās samazināt datu sÅ«tÄ«Å”anas uz serveri biežumu. 30 sekundes. Tas kļuva nepiecieÅ”ams, jo trafiks mÅ«su LTE SIM kartēs sāka ātri izzust.

Lielāko daļu satiksmes patērēja žurnāli, paÅ”i rādÄ«tāji pat ar 10 sekunžu intervālu to praktiski netērēja.

Rezultātā pēc kāda laika mēs pilnÄ«bā atspējojām žurnālu vākÅ”anu ierÄ«cēs, jo konkrētas problēmas jau bija acÄ«mredzamas pat bez pastāvÄ«gas vākÅ”anas.

Dažos gadÄ«jumos, ja žurnālu apskate joprojām bija nepiecieÅ”ama, mēs vienkārÅ”i izveidojām savienojumu, izmantojot WireGuard, izmantojot VPN.

PiebildīŔu arī to, ka katra atseviŔķa vide tika atdalīta viena no otras, un iepriekŔ aprakstītā slodze attiecās tikai uz ražoŔanas vidi.

Izstrādes vidē mēs izveidojām atseviŔķu InfluxDB instanci, kas turpināja vākt datus ik pēc 10 sekundēm, un mēs nesaskārāmies ar veiktspējas problēmām.

TICK ā€” ideāli piemērots maziem un vidējiem projektiem

Pamatojoties uz Å”o informāciju, es varētu secināt, ka TICK kaudze ir ideāli piemērota salÄ«dzinoÅ”i maziem projektiem vai projektiem, kas noteikti negaida HighLoad.

Ja jums nav tÅ«kstoÅ”iem podziņu vai simtiem iekārtu, pat viens InfluxDB gadÄ«jums lieliski tiks galā ar slodzi.

Dažos gadījumos jūs varat būt apmierināts ar Influx Relay kā primitīvu augstas pieejamības risinājumu.

Un, protams, neviens neliedz jums iestatÄ«t ā€œvertikāloā€ mērogoÅ”anu un vienkārÅ”i pieŔķirt dažādus serverus dažāda veida metrikām.

Ja neesat pārliecināts par paredzamo monitoringa pakalpojumu noslodzi vai jums ir garantēta/bÅ«s ļoti ā€œsmagaā€ arhitektÅ«ra, es neieteiktu izmantot TICK steka bezmaksas versiju.

Protams, vienkārÅ”s risinājums bÅ«tu iegādāties InfluxDB Enterprise - bet Å”eit es nevaru kaut kā komentēt, jo es pats neesmu pazÄ«stams ar smalkumiem. Turklāt tas ir ļoti dārgs un noteikti nav piemērots maziem uzņēmumiem.

Å ajā gadÄ«jumā Å”odien es ieteiktu meklēt metriku apkopoÅ”anu, izmantojot Victoria Metrics un žurnālus, izmantojot Loki.

Tiesa, es atkal izdarÄ«Å”u atrunu, ka Loki/Grafana ir daudz mazāk ērti (lielākas daudzpusÄ«bas dēļ) nekā gatavā TICK, bet tie ir bez maksas.

Tas ir svarīgi: visa Ŕeit aprakstītā informācija attiecas uz versiju Influx 1.8, Ŕobrīd Influx 2.0 drīzumā tiks izlaista.

Lai gan man nav bijusi iespēja to izmēģināt kaujas apstākļos un ir grÅ«ti izdarÄ«t secinājumus par uzlabojumiem, interfeiss noteikti ir kļuvis vēl labāks, arhitektÅ«ra ir vienkārÅ”ota (bez kapacitora un hronogrāfa),
parādÄ«jās veidnes (ā€œkiller funkcijaā€ - varat izsekot spēlētājiem Fortnite un saņemt paziņojumus, kad jÅ«su iecienÄ«tākais spēlētājs uzvar spēlē). Bet diemžēl Å”obrÄ«d 2. versijai nav galvenās lietas, par kurām mēs izvēlējāmies pirmo versiju - nav žurnālu kolekcijas.

Šī funkcionalitāte parādīsies arī Influx 2.0, taču mēs nevarējām atrast nekādus termiņus, pat aptuvenus.

Kā neveidot IoT platformas (tagad)

Galu galā, palaižot izmēģinājumu, mēs paÅ”i salikām savu pilnvērtÄ«go IoT steku, ja nebija mÅ«su standartiem piemērotas alternatÄ«vas.

Tomēr nesen tas ir pieejams beta versijā OpenBalena ā€” žēl, ka viņa nebija, kad sākām veidot projektu.

Esam pilnÄ«bā apmierināti ar gala rezultātu un platformu, kuras pamatā ir Ansible + TICK + WireGuard un kuru salikām paÅ”i. Bet Å”odien es ieteiktu tuvāk apskatÄ«t Balena, pirms mēģināt pats izveidot savu IoT platformu.

Tā kā galu galā tas var paveikt lielāko daļu tā, ko mēs darījām, un OpenBalena ir bezmaksas un atvērtā koda.

Tas jau zina, kā ne tikai nosÅ«tÄ«t atjauninājumus, bet arÄ« VPN jau ir iebÅ«vēts un pielāgots lietoÅ”anai IoT vidē.

Un pavisam nesen viņi pat izlaida savu detaļas, kas viegli savienojas ar viņu ekosistēmu.

Hei, kā ar pazuduŔo skrejriteni?

Tā motorollers "Ralfs" pazuda bez vēsts.

Mēs nekavējoties skrējām apskatÄ«t karti savā ā€œadmin panelÄ«ā€ ar GPS metrikas datiem no InfluxDB.

Pateicoties monitoringa datiem, viegli noskaidrojām, ka motorollers pagājuÅ”ajā diennaktÄ« ap 21:00 izbrauca no stāvlaukuma, kādu pusstundu nobrauca lÄ«dz kādai teritorijai un lÄ«dz 5 no rÄ«ta stāvēja pie kādas vācu mājas.

Pēc pulksten 5:XNUMX nekādi uzraudzÄ«bas dati netika saņemti ā€” tas nozÄ«mēja, ka vai nu papildu akumulators bija pilnÄ«bā izlādējies, vai arÄ« uzbrucējs beidzot izdomāja, kā no motorollera noņemt viedo aparatÅ«ru.
Neskatoties uz to, policija joprojām tika izsaukta uz adresi, kur atradās motorollers. Motorollera tur nebija.

Taču arÄ« mājas saimnieks par to bijis pārsteigts, jo viņŔ Å”onakt ar motorolleri tieŔām braucis mājās no biroja.

Kā izrādījās, viens no atbalsta darbiniekiem ieradās agri no rīta un paņēma skrejriteni, redzot, ka tā papildu akumulators ir pilnībā izlādējies, un nogādāja to (kājām) uz stāvvietu. Un papildu akumulators neizdevās mitruma dēļ.

Mēs paÅ”i nozagām motorolleri. Starp citu, es nezinu, kā un kas tad atrisināja jautājumu ar policijas lietu, bet uzraudzÄ«ba darbojās lieliski...

Avots: www.habr.com

Pievieno komentāru