För ett år sedan lanserade vi en pilotversion av ett PR-projekt för .
Från början hette projektet Road-To-Barcelona, senare blev det Road-To-Berlin (därav R2B i skärmdumparna), och till slut hette det xRide.
Huvudtanken med projektet var denna: istället för att ha en centraliserad bil- eller skoteruthyrningstjänst (vi pratar om skotrar aka elektriska motorcyklar, inte sparkcyklar/skotrar) ville vi skapa en plattform för decentraliserad uthyrning. Om de svårigheter vi stött på .
Till en början fokuserade projektet på bilar, men på grund av deadlines, extremt långa kommunikationer med tillverkare och ett stort antal säkerhetsrestriktioner valdes elskotrar för piloten.
Användaren installerade en iOS- eller Android-applikation på telefonen, gick fram till den skoter han gillade, varefter telefonen och skotern etablerade en peer-to-peer-anslutning, ETH byttes ut och användaren kunde starta åkturen genom att slå på skotern via telefonen. I slutet av resan var det också möjligt att betala för resan med Ethereum från användarens plånbok på telefonen.
Förutom skotrar såg användaren "smarta laddare" i applikationen, genom att besöka där användaren själv kunde byta nuvarande batteri om det var lågt.
Så här såg vår pilot ut, som lanserades i september förra året i två tyska städer: Bonn och Berlin.
Och så, en dag, i Bonn, tidigt på morgonen, larmades vårt supportteam (som finns på plats för att underhålla skotrar i fungerande skick): en av skotrarna hade försvunnit spårlöst.
Hur hittar man den och returnerar den?
I den här artikeln kommer jag att prata om detta, men först - om hur vi byggde vår egen IoT-plattform och hur vi övervakade den.
Vad och varför ska man övervaka: skotrar, infrastruktur, laddstationer?
Så vad ville vi övervaka i vårt projekt?
Först och främst är det här skotrarna själva - elektriska skotrar i sig är ganska dyra, du kan inte starta ett sådant projekt utan att vara tillräckligt förberedd; om möjligt vill du samla in så mycket information som möjligt om skotrarna: om deras plats, laddningsnivå , etc.
Dessutom skulle jag vilja övervaka tillståndet för vår egen IT-infrastruktur – databaser, tjänster och allt de behöver för att fungera. Det var också nödvändigt att övervaka statusen för de "smarta laddarna", ifall de gick sönder eller tog slut på fulla batterier.
Skotrar
Vilka var våra skotrar och vad ville vi veta om dem?
Det första och viktigaste är GPS-koordinater, eftersom vi tack vare dem kan förstå var de är och vart de rör sig.
Nästa är batteriladdningen, tack vare vilken vi kan fastställa att laddningen av skotrarna närmar sig sitt slut och skicka en juicepress eller åtminstone varna användaren.
Naturligtvis är det också nödvändigt att kontrollera vad som händer med våra hårdvarukomponenter:
- fungerar bluetooth?
- fungerar själva GPS-modulen?
- Vi hade också problem med att GPS:en kunde skicka felaktiga koordinater och fastna, och detta kunde bara fastställas genom ytterligare kontroller på skotern,
och meddela supporten så snart som möjligt för att lösa problemet
- Vi hade också problem med att GPS:en kunde skicka felaktiga koordinater och fastna, och detta kunde bara fastställas genom ytterligare kontroller på skotern,
Och sist: kontroller av programvaran, som börjar med OS och processor, nätverks- och diskbelastning, slutar med kontroller av våra egna moduler som är mer specifika för oss (, ).
hårdvara
Vad var vår "järndel"?
Med hänsyn till kortast möjliga tidsram och behovet av snabb prototyping, valde vi det enklaste alternativet för implementering och val av komponenter - Raspberry Pi.
Förutom själva Rpi hade vi ett specialkort (som vi själva utvecklat och beställt från Kina för att påskynda monteringsprocessen av den slutliga lösningen) och en uppsättning komponenter - ett relä (för att slå på/stänga av skotern), en batteriladdningsläsare, ett modem, antenner. Allt detta var kompakt förpackat i en speciell "xRide-låda".
Det bör också noteras att hela lådan drevs av en extra powerbank, som i sin tur drevs av skoterns huvudbatteri.
Detta gjorde det möjligt att använda övervakning och slå på skotern även efter slutet av resan, eftersom huvudbatteriet stängdes av direkt efter att du vridit tändningsnyckeln till "av"-läget.
Hamnarbetare? Vanligt Linux? och utplacering
Låt oss återgå till övervakningen, så Hallon - vad har vi?
En av de första sakerna vi ville använda för att påskynda processen med att distribuera, uppdatera och leverera komponenter till fysiska enheter var Docker.
Tyvärr blev det snabbt klart att Docker på RPi, även om det fungerar, har en hel del omkostnader, särskilt när det gäller energiförbrukning.
Skillnaden med att använda det "native" operativsystemet, även om det inte var så starkt, var fortfarande tillräckligt för att vi skulle vara försiktiga med möjligheten att tappa laddningen för snabbt.
Den andra anledningen var ett av våra partnerbibliotek på Node.js (sic!) - den enda komponenten i systemet som inte var skriven i Go/C/C++.
Författarna till biblioteket hade inte tid att tillhandahålla en fungerande version på något av de "inhemska" språken.
Inte nog med att själva noden inte är den mest eleganta lösningen för enheter med låg prestanda, utan själva biblioteket var mycket resurshungrigt.
Vi insåg att, även om vi ville, att använda Docker skulle bli för mycket av en overhead för oss. Valet gjordes till förmån för det ursprungliga operativsystemet och att arbeta direkt under det.
OS
Som ett resultat valde vi, återigen, det enklaste alternativet som OS och använde Raspbian (Debian build för Pi).
Vi skriver all vår mjukvara i Go, så vi skrev även huvudmodulen för hårdvaruagent i vårt system i Go.
Det är han som ansvarar för att jobba med GPS, Bluetooth, läsa av laddningen, slå på skotern osv.
Distribuera
Frågan uppstod omedelbart om behovet av att implementera en mekanism för att leverera uppdateringar till enheter (OTA) - både uppdateringar till vår agent/applikation i sig och uppdateringar av själva operativsystemet/firmware (eftersom nya versioner av agenten kan kräva uppdateringar av kärnan eller systemkomponenter, bibliotek, etc.).
Efter en ganska lång analys av marknaden visade det sig att det finns ganska många lösningar för att leverera uppdateringar till enheten.
Från relativt enkla, mestadels uppdaterings-/dualbootorienterade verktyg som swupd/SWUpdate/OSTree till fullfjädrade plattformar som Mender och Balena.
Först och främst bestämde vi oss för att vi var intresserade av end-to-end-lösningar, så valet föll direkt på plattformar.
Självklart uteslöts på grund av att den faktiskt använder samma Docker i sin balenaEngine.
Men jag noterar att trots detta slutade vi med att vi ständigt använde deras produkt för flash-firmware på SD-kort - ett enkelt och extremt bekvämt verktyg för detta.
Därför föll valet till slut på . Mender är en komplett plattform för montering, leverans och installation av firmware.
Överlag ser plattformen bra ut, men det tog oss ungefär en och en halv vecka att bygga den korrekta versionen av vår firmware med hjälp av mender-byggaren.
Och ju mer vi fördjupade oss i krångligheterna med dess användning, desto mer blev det tydligt att vi skulle behöva mycket mer tid än vi hade för att implementera det fullt ut.
Tyvärr, våra snäva deadlines innebar att vi var tvungna att överge användningen av Mender och välja en ännu enklare.
Ansible
Den enklaste lösningen i vår situation var att använda Ansible. Ett par spelböcker räckte för att komma igång.
Deras kärna var att vi helt enkelt kopplade från värden (CI-server) via ssh till våra rasberries och distribuerade uppdateringar till dem.
I början var allt enkelt - du var tvungen att vara på samma nätverk med enheterna, hällning skedde via Wi-Fi.
På kontoret fanns helt enkelt ett dussin testhallon kopplade till samma nätverk, varje enhet hade en statisk IP-adress som också anges i Ansible Inventory.
Det var Ansible som levererade vår övervakningsagent till slutenheter
3G / LTE
Tyvärr kunde detta användningsfall för Ansible bara fungera i utvecklingsläge innan vi hade riktiga skotrar.
Eftersom skotrar, som du förstår, inte sitter anslutna till en Wi-Fi-router och ständigt väntar på uppdateringar över nätverket.
I verkligheten kan skotrar inte ha någon uppkoppling alls förutom mobil 3G/LTE (och inte ens då hela tiden).
Detta medför omedelbart många problem och begränsningar, såsom låg anslutningshastighet och instabil kommunikation.
Men det viktigaste är att i ett 3G/LTE-nätverk kan vi inte bara förlita oss på en statisk IP som är tilldelad nätverket.
Detta löses delvis av vissa SIM-kortsleverantörer; det finns till och med speciella SIM-kort designade för IoT-enheter med statiska IP-adresser. Men vi hade inte tillgång till sådana SIM-kort och kunde inte använda IP-adresser.
Naturligtvis fanns det idéer om att göra någon form av registrering av IP-adresser aka service discovery någonstans som Consul, men vi var tvungna att överge sådana idéer, eftersom IP-adressen i våra tester kunde ändras för ofta, vilket ledde till stor instabilitet.
Av denna anledning skulle den mest bekväma användningen för att leverera mätvärden inte vara att använda pull-modellen, där vi skulle gå till enheter för nödvändiga mätvärden, utan push, leverera mätvärden från enheten direkt till servern
VPN
Som en lösning på detta problem valde vi VPN – specifikt .
Klienter (skotrar) i början av systemet kopplade till VPN-servern och kunde ansluta till dem. Denna tunnel användes för att leverera uppdateringar.
I teorin skulle samma tunnel kunna användas för övervakning, men en sådan anslutning var mer komplicerad och mindre tillförlitlig än enkel push.
Molnresurser
Slutligen är det nödvändigt att övervaka våra molntjänster och databaser, eftersom vi använder Kubernetes för dem, helst så att implementeringen av övervakning i klustret är så enkel som möjligt. Helst använder , eftersom vi använder det i de flesta fall för distribution. Och, naturligtvis, för att övervaka molnet måste du använda samma lösningar som för skotrarna själva.
Given
Puh, vi verkar ha sorterat beskrivningen, låt oss göra en lista över vad vi behövde till slut:
- En snabb lösning eftersom övervakning är nödvändig redan under utvecklingsprocessen
- Volym/kvantitet – många mätvärden behövs
- Logginsamling krävs
- Tillförlitlighet – data är avgörande för att lansera framgång
- Du kan inte använda pull-modellen - du behöver push
- Vi behöver enhetlig övervakning av inte bara hårdvara utan även moln
Den sista bilden såg ut ungefär så här
Stackval
Så vi stod inför frågan om att välja en övervakningsstack.
Först och främst letade vi efter den mest kompletta allt-i-ett-lösningen som samtidigt skulle täcka alla våra krav, men samtidigt vara tillräckligt flexibel för att skräddarsy användningen efter våra behov. Ändå hade vi många restriktioner påtvingade av hårdvara, arkitektur och deadlines.
Det finns ett stort utbud av övervakningslösningar, som börjar med fullfjädrade system som , eller och avslutas med färdiga lösningar för Fleet Management.
Till en början verkade det senare som en idealisk lösning för oss, men vissa hade inte full övervakning, andra hade kraftigt begränsade möjligheter för gratisversionerna, och andra täckte helt enkelt inte våra "önskningar" eller var inte tillräckligt flexibla för att passa våra scenarier. Vissa är helt enkelt föråldrade.
Efter att ha analyserat ett antal liknande lösningar kom vi snabbt fram till att det skulle vara enklare och snabbare att själva montera en liknande stack. Ja, det kommer att vara lite mer komplicerat än att distribuera en helt färdig Fleet Management-plattform, men vi behöver inte göra kompromisser.
Nästan säkert, i allt det enorma överflöd av lösningar, finns det redan en färdig som skulle passa oss helt, men i vårt fall var det mycket snabbare att montera en viss stapel på egen hand och anpassa den "för oss själva" snarare än testa färdiga produkter.
Med allt detta strävade vi inte efter att själva montera en hel övervakningsplattform, utan letade efter de mest funktionella "färdiga" stackarna, bara med möjligheten att flexibelt konfigurera dem.
(B)ELK?
Den första lösningen som faktiskt övervägdes var den välkända ELK-stacken.
Egentligen borde det heta BELK, för allt börjar med Beats -
Naturligtvis är ELK en av de mest kända och kraftfulla lösningarna inom övervakningsområdet, och ännu mer inom insamling och bearbetning av loggar.
Vi hade för avsikt att ELK skulle användas för att samla in stockar och samt långtidslagring av mätvärden som erhållits från Prometheus.
För visualisering kan du använda Grafan.
Faktum är att den nya ELK-stacken kan samla in mätvärden oberoende (metricbeat), och Kibana kan också visa dem.
Men ändå växte ELK till en början ur loggar och hittills har funktionaliteten hos mätvärdena ett antal allvarliga nackdelar:
- Betydligt långsammare än Prometheus
- Integreras på mycket färre platser än Prometheus
- Det är svårt att ställa in varningar för dem
- Mätvärden tar mycket plats
- Att sätta upp instrumentpaneler med mätvärden i Kiban är mycket mer komplicerat än i Grafan
Generellt sett är måtten i ELK tunga och ännu inte lika bekväma som i andra lösningar, som det nu finns mycket mer av än bara Prometheus: TSDB, Victoria Metrics, Cortex, etc etc. etc. Naturligtvis skulle jag verkligen vilja ha en fullfjädrad allt-i-ett-lösning direkt, men i fallet med metricbeat blev det för många kompromisser.
Och själva ELK-stacken har ett antal svåra ögonblick:
- Det är tungt, ibland till och med väldigt tungt om man samlar in en ganska stor mängd data
- Du måste "veta hur man lagar mat" det - du måste skala det, men det är inte trivialt att göra
- Avskalad gratisversion - gratisversionen har inte normal varning, och vid tidpunkten för valet fanns det ingen autentisering
Jag måste säga att den sista punkten nyligen har blivit bättre och dessutom (inklusive autentisering) började själva prismodellen att förändras.
Men vid den tidpunkt då vi skulle distribuera den här lösningen fanns det ingen varning alls.
Vi kanske kunde ha försökt bygga något med ElastAlert eller andra community-lösningar, men vi bestämde oss ändå för att överväga andra alternativ.
Loke - Grafana - Prometheus
För tillfället kan en bra lösning vara att bygga en övervakningsstack baserad enbart på Prometheus som mätvärdeleverantör, Loki för loggar, och för visualisering kan du använda samma Grafana.
Tyvärr, vid tiden för projektets försäljningspilot (september-oktober 19), var Loki fortfarande i betaversion 0.3-0.4, och vid tidpunkten för utvecklingsstart kunde den inte betraktas som en produktionslösning alls.
Jag har ännu inte erfarenhet av att faktiskt använda Loki i seriösa projekt, men jag kan säga att Promtail (en agent för att samla stockar) fungerar utmärkt för både barmetall och kubernetes-skidor.
BOCK
Det kanske mest värdiga (det enda?) fullfjädrade alternativet till ELK-stacken kan nu bara kallas TICK-stacken - Telegraf, InfluxDB, Chronograf, Kapacitor.
Jag kommer att beskriva alla komponenter nedan mer i detalj, men den allmänna idén är denna:
- Telegraf - agent för insamling av mått
- InfluxDB - mätdatabas
- Kapacitor - realtidsmätningsprocessor för larm
- Chronograf - webbpanel för visualisering
För InfluxDB, Kapacitor och Chronograf finns det officiella styrdiagram som vi använde för att distribuera dem.
Det bör noteras att i den senaste versionen av Influx 2.0 (beta) blev Kapacitor och Chronograf en del av InfluxDB och existerar inte längre separat
telegraf
är ett mycket lätt medel för att samla in mått på en tillståndsmaskin.
Han kan övervaka en enorm mängd av allt, från до
server .
Den har ett antal coola fördelar:
- Snabb och lätt (skriven i Go)
- Äter en minimal mängd resurser
- Push-statistik som standard
- Samlar in alla nödvändiga mätvärden
- Systemstatistik utan några inställningar
- Hårdvarumått som information från sensorer
- Det är väldigt enkelt att lägga till egna mätvärden
- Många plugins ur lådan
- Samlar stockar
Eftersom push-mått var nödvändigt för oss var alla andra fördelar mer än trevliga tillägg.
Insamling av loggar av agenten själv är också mycket bekvämt, eftersom det inte finns något behov av att ansluta ytterligare verktyg för att logga loggar.
Influx erbjuder den mest bekväma upplevelsen för att arbeta med loggar om du använder .
Telegraf är generellt sett en utmärkt agent för att samla in mätvärden, även om du inte använder resten av ICK-stacken.
Många människor korsar det med ELK och olika andra tidsseriedatabaser för enkelhetens skull, eftersom det kan skriva mätvärden nästan var som helst.
InfluxDB
InfluxDB är huvudkärnan i TICK-stacken, nämligen en tidsseriedatabas för mått.
Förutom mätvärden kan Influx också lagra loggar, även om loggar för det i huvudsak bara är samma mätvärden, men istället för de vanliga numeriska indikatorerna utförs huvudfunktionen av en rad med loggtext.
InfluxDB är också skrivet i Go och verkar köra mycket snabbare jämfört med ELK på vårt (inte det mest kraftfulla) kluster.
En av de coola fördelarna med Influx skulle också inkludera ett mycket bekvämt och rikt API för datafrågor, som vi använde mycket aktivt.
Nackdelar - $$$ eller skalning?
TICK-stacken har bara en nackdel som vi upptäckte - den käre. Ännu mer.
Vad har den betalda versionen som gratisversionen inte har?
Så vitt vi kunde förstå är den enda skillnaden mellan den betalda versionen av TICK-stacken och den gratis skalningsmöjligheterna.
Du kan nämligen höja ett kluster med hög tillgänglighet endast i .
Om du vill ha fullfjädrad HA måste du antingen betala eller använda några kryckor. Det finns ett par gemenskapslösningar – till exempel ser ut som en kompetent lösning, men det skrivs att den inte lämpar sig för produktion, liksom
- en enkel lösning med datapumpning genom NATS (det kommer också att behöva skalas, men det går att lösa).
Det är synd, men båda verkar vara övergivna - det finns inga nya åtaganden, jag antar att problemet är den snart förväntade utgåvan av den nya versionen av Influx 2.0, där många saker kommer att vara annorlunda (det finns ingen information om skalning i den ännu).
Officiellt finns det en gratisversion - i själva verket är detta en primitiv HA, men bara genom att balansera,
eftersom all data kommer att skrivas till alla InfluxDB-instanser bakom lastbalanseraren.
Han har några som potentiella problem med att skriva över punkter och behovet av att skapa baser för mätvärden i förväg
(vilket sker automatiskt under normalt arbete med InfluxDB).
Dessutom , innebär detta ytterligare omkostnader för duplicerade mätvärden (både bearbetning och lagring) som du kanske inte behöver, men det finns inget sätt att separera dem.
Victoria Metrics?
Som ett resultat, trots att vi var helt nöjda med TICK-stacken i allt annat än betald skalning, bestämde vi oss för att se om det fanns några gratislösningar som kunde ersätta InfluxDB-databasen, samtidigt som de återstående T_CK-komponenterna lämnades.
Det finns många tidsseriedatabaser, men den mest lovande är Victoria Metrics, den har ett antal fördelar:
- Snabbt och enkelt, åtminstone enligt resultaten
- Det finns en klusterversion, som det till och med finns bra recensioner om nu
- Hon kan skära
- Stöder InfluxDB-protokoll
Vi hade inte för avsikt att bygga en helt anpassad stack baserad på Victoria och huvudförhoppningen var att vi kunde använda den som en drop-in ersättare för InfluxDB.
Tyvärr är detta inte möjligt, trots att InfluxDB-protokollet stöds fungerar det bara för inspelning av mätvärden - bara Prometheus API är tillgängligt "utanför", vilket innebär att det inte kommer att vara möjligt att ställa in Chronograf på det.
Dessutom stöds endast numeriska värden för mätvärden (vi använde strängvärden för anpassade mätvärden - mer om det i avsnittet ).
Uppenbarligen, av samma anledning, kan den virtuella datorn inte lagra loggar som Influx gör.
Det bör också noteras att Victoria Metrics vid tidpunkten för sökningen efter den optimala lösningen ännu inte var så populär, dokumentationen var mycket mindre och funktionaliteten var svagare
(Jag kommer inte ihåg en detaljerad beskrivning av klusterversionen och skärningen).
Basval
Som ett resultat beslutades det att för piloten skulle vi fortfarande begränsa oss till en enda InfluxDB-nod.
Det fanns flera huvudskäl till detta val:
- Vi gillade verkligen hela funktionaliteten i TICK-stacken
- Vi har redan lyckats distribuera det och det fungerade utmärkt
- Tidsfristerna rann ut och det fanns inte mycket tid kvar att testa andra alternativ.
- Vi förväntade oss inte en så tung belastning
Vi hade inte många skotrar för den första fasen av piloten, och tester under utvecklingen avslöjade inga prestandaproblem.
Därför beslutade vi att för detta projekt skulle en inflödesnod räcka för oss utan behov av skalning (se slutsatserna i slutet).
Vi har bestämt oss för stapeln och basen - nu om de återstående komponenterna i TICK-stacken.
Kapacitor
Kapacitor är en del av TICK-stacken, en tjänst som kan övervaka mätvärden som kommer in i databasen i realtid och utföra olika åtgärder baserat på regler.
I allmänhet är det placerat som ett verktyg för potentiell avvikelsespårning och maskininlärning (jag är inte säker på att dessa funktioner är efterfrågade), men det mest populära fallet med dess användning är vanligare - varning.
Det är så vi använde det för aviseringar. Vi satte upp Slack-varningar när en viss skoter gick offline, och samma sak gjordes för smarta laddare och viktiga infrastrukturkomponenter.
Detta gjorde det möjligt att snabbt svara på problem, samt få meddelanden om att allt var tillbaka till det normala.
Ett enkelt exempel: ett extra batteri för att driva vår "box" har gått sönder eller av någon anledning har tagit slut; helt enkelt genom att installera ett nytt, bör vi efter ett tag få ett meddelande om att skoterns funktionalitet har återställts.
I Influx 2.0 blev Kapacitor en del av DB
Kronograf
Jag har sett många olika UI-lösningar för övervakning, men jag kan säga att när det gäller funktionalitet och UX är inget att jämföra med Chronograf.
Vi började använda TICK-stacken, konstigt nog, med Grafan som webbgränssnitt.
Jag kommer inte att beskriva dess funktionalitet; alla känner till dess breda möjligheter att ställa in vad som helst.
Grafana är dock fortfarande ett helt universellt instrument, medan Chronograf främst är designad för användning med Influx.
Och naturligtvis, tack vare detta, har Chronograf råd med mycket smartare eller bekvämare funktionalitet.
Den kanske främsta bekvämligheten med att arbeta med Chronograf är att du kan se insidan av din InfluxDB genom Explore.
Det verkar som att Grafana har nästan identisk funktionalitet, men i verkligheten går det att sätta upp en instrumentpanel i Chronograf med några musklick (samtidigt som man tittar på visualiseringen där), medan man i Grafana fortfarande förr eller senare har för att redigera JSON-konfigurationen (naturligtvis låter Chronograf ladda upp dina handkonfigurerade dashas och redigera dem som JSON om det behövs - men jag behövde aldrig röra dem efter att ha skapat dem i användargränssnittet).
Kibana har mycket rikare möjligheter för att skapa instrumentpaneler och kontroller för dem, men UX för sådana operationer är mycket komplext.
Det kommer att krävas en god förståelse för att skapa en bekväm instrumentpanel. Och även om funktionaliteten hos Chronograf instrumentpaneler är mindre, är det mycket enklare att tillverka och anpassa dem.
Själva instrumentbrädorna, förutom den trevliga visuella stilen, skiljer sig faktiskt inte från instrumentbrädorna i Grafana eller Kibana:
Så här ser frågefönstret ut:
Det är viktigt att notera, bland annat, att när du känner till typerna av fält i InfluxDB-databasen, kan kronografen själv ibland automatiskt hjälpa dig med att skriva en fråga eller välja rätt aggregeringsfunktion som medelvärde.
Och naturligtvis är Chronograf så bekvämt som möjligt för att visa loggar. Det ser ut så här:
Som standard är Influx-loggar skräddarsydda för att använda syslog och därför har de en viktig parameter - allvarlighetsgrad.
Grafen överst är särskilt användbar, på den kan du se de fel som uppstår och färgen visar direkt tydligt om svårighetsgraden är högre.
Ett par gånger fångade vi viktiga buggar på det här sättet, när vi tittade på loggarna för den senaste veckan och såg en röd spik.
Naturligtvis skulle det idealiskt vara att ställa in varningar för sådana fel, eftersom vi redan hade allt för detta.
Vi slog till och med på detta ett tag, men i processen med att förbereda piloten visade det sig att vi fick ganska många fel (inklusive system som otillgängligheten i LTE-nätverket), som "spammade" Slack-kanalen för mycket, utan att orsaka några problem, stor nytta.
Den korrekta lösningen skulle vara att hantera de flesta av dessa typer av fel, justera svårighetsgraden för dem och först därefter aktivera larm.
På så sätt skulle bara nya eller viktiga fel läggas upp på Slack. Det fanns helt enkelt inte tillräckligt med tid för ett sådant upplägg med tanke på de snäva deadlines.
autentisering
Det är också värt att nämna att Chronograf stöder OAuth och OIDC som autentisering.
Detta är väldigt bekvämt, eftersom det gör att du enkelt kan koppla den till din server och skapa fullfjädrad SSO.
I vårt fall var servern — den användes för att ansluta till övervakning, men samma server användes också för att autentisera skotrar och förfrågningar till back-end.
"Administration"
Den sista komponenten som jag kommer att beskriva är vår självskrivna "adminpanel" i Vue.
I grund och botten är det bara en fristående tjänst som visar skoterinformation från våra egna databaser, mikrotjänster och mätdata från InfluxDB samtidigt.
Dessutom flyttades många administrativa funktioner dit, som en nödstart eller fjärröppning av ett lås för supportteamet.
Det fanns också kartor. Jag har redan nämnt att vi började med Grafana istället för Chronograf - för för Grafana finns kartor tillgängliga i form av plugins, där vi kan se koordinaterna för skotrar. Tyvärr är kapaciteten för kartwidgets för Grafana mycket begränsad, och som ett resultat var det mycket lättare att skriva din egen webbapplikation med kartor på några dagar, för att inte bara se koordinaterna för tillfället, utan också visa rutten som skotern tagit, kunna filtrera data på kartor etc. (all den där funktionaliteten som vi inte kunde konfigurera i en enkel instrumentpanel).
En av de redan nämnda fördelarna med Influx är möjligheten att enkelt skapa dina egna mätvärden.
Detta gör att den kan användas för en mängd olika scenarier.
Vi försökte registrera all användbar information där: batteriladdning, låsstatus, sensorprestanda, bluetooth, GPS och många andra hälsokontroller.
Vi visade allt detta på adminpanelen.
Naturligtvis var det viktigaste kriteriet för oss skoterns drifttillstånd - i själva verket kontrollerar Influx detta själv och visar det med "gröna lampor" i avsnittet Nodes.
Detta görs av funktionen — vi använde den för att förstå prestandan hos vår box och skicka samma varningar till Slack.
Förresten, vi döpte skotrarna efter namnen på karaktärer från The Simpsons - det var så bekvämt att skilja dem från varandra
Och i allmänhet var det roligare på det här sättet. Fraser som "killar, Smithers är död!" hördes ständigt.
Strängmått
Det är viktigt att InfluxDB låter dig lagra inte bara numeriska värden, som är fallet med Victoria Metrics.
Det verkar som att detta inte är så viktigt - trots allt, bortsett från loggar, kan alla mätvärden lagras i form av siffror (lägg bara till mappning för kända tillstånd - ett slags enum)?
I vårt fall fanns det åtminstone ett scenario där strängmått var mycket användbara.
Det råkade bara vara så att leverantören av våra "smarta laddare" var en tredje part, vi hade ingen kontroll över utvecklingsprocessen och den information som dessa laddare kunde leverera.
Som ett resultat var laddnings-API:t långt ifrån idealiskt, men huvudproblemet var att vi inte alltid kunde förstå deras tillstånd.
Det var här Influx kom till undsättning. Vi skrev helt enkelt strängstatusen som kom till oss i InfluxDB-databasfältet utan ändringar.
Under en tid kom bara värden som "online" och "offline" dit, baserat på vilken information som visades i vår adminpanel och aviseringar skickades till Slack. Men vid någon tidpunkt började också värden som "disconnected" dyka upp där.
Som det visade sig senare skickades denna status en gång efter att anslutningen förlorats, om laddaren inte kunde upprätta en anslutning till servern efter ett visst antal försök.
Således, om vi bara använde en fast uppsättning värden, kanske vi inte ser dessa förändringar i firmware vid rätt tidpunkt.
Och i allmänhet ger strängmått mycket fler möjligheter att använda; du kan spela in praktiskt taget all information i dem. Även om du naturligtvis också måste använda detta verktyg noggrant.
Utöver de vanliga mätvärdena registrerade vi även GPS-platsinformation i InfluxDB. Detta var otroligt användbart för att övervaka platsen för skotrar i vår adminpanel.
Faktum är att vi alltid visste var och vilken skoter var för tillfället vi behövde.
Detta var mycket användbart för oss när vi letade efter en skoter (se slutsatser i slutet).
Infrastrukturövervakning
Förutom själva skotrarna behövde vi också övervaka hela vår (ganska omfattande) infrastruktur.
En mycket allmän arkitektur såg ut ungefär så här:
Om vi lyfter fram en ren övervakningsstack ser det ut så här:
Det vi skulle vilja kontrollera i molnet är:
- Databas
- nyckelmantel
- Mikrotjänster
Eftersom alla våra molntjänster finns i Kubernetes skulle det vara trevligt att samla information om dess tillstånd.
Lyckligtvis kan Telegraf ur lådan samla ett stort antal mätvärden om tillståndet för Kubernetes-klustret, och Chronograf erbjuder omedelbart vackra instrumentpaneler för detta.
Vi övervakade huvudsakligen prestanda för poddarna och minnesförbrukning. Vid ett fall, larmar i Slack.
Det finns två sätt att spåra pods i Kubernetes: DaemonSet och Sidecar.
Båda metoderna beskrivs i detalj .
Vi använde Telegraf Sidecar och samlade, förutom mätvärden, podloggar.
I vårt fall fick vi mixtra med stockarna. Trots att Telegraf kan dra loggar från Docker API, ville vi ha en enhetlig samling av loggar med våra slutenheter och konfigurerad syslog för containrar för detta. Kanske var den här lösningen inte vacker, men det fanns inga klagomål på dess arbete och loggarna visades väl i Chronograf.
Övervaka övervakning???
Till slut uppstod den urgamla frågan om övervakning av övervakningssystem, men lyckligtvis, eller tyvärr, hade vi helt enkelt inte tillräckligt med tid för detta.
Även om Telegraf enkelt kan skicka sina egna mätvärden eller samla in mätvärden från InfluxDB-databasen för att skicka antingen till samma Influx eller någon annanstans.
Resultat
Vilka slutsatser drog vi av resultaten från piloten?
Hur kan du göra övervakning?
Först och främst motsvarade TICK-stacken våra förväntningar och gav oss ännu fler möjligheter än vad vi först förväntade oss.
All funktionalitet vi behövde fanns. Allt vi gjorde med den fungerade utan problem.
Производительность
Det största problemet med TICK-stacken i gratisversionen är bristen på skalningsmöjligheter. Detta var inget problem för oss.
Vi samlade inte in exakta lastdata/siffror, men vi samlade in data från ett 30-tal skotrar åt gången.
Var och en av dem samlade in mer än tre dussin mätvärden. Samtidigt samlades loggar från enheterna. Datainsamling och sändning skedde var tionde sekund.
Det är viktigt att notera att efter en och en halv vecka av piloten, när huvuddelen av "barndomssåren" korrigerades och de viktigaste problemen redan var lösta, var vi tvungna att minska frekvensen av att skicka data till servern för att 30 sekunder. Detta blev nödvändigt eftersom trafiken på våra LTE SIM-kort snabbt började försvinna.
Huvuddelen av trafiken förbrukades av stockar, själva måtten, även med ett 10-sekundersintervall, slösade praktiskt taget inte bort det.
Som ett resultat avaktiverade vi efter en tid helt insamlingen av loggar på enheter, eftersom specifika problem redan var uppenbara även utan konstant insamling.
I vissa fall, om det fortfarande var nödvändigt att se loggarna, ansluter vi helt enkelt via WireGuard via VPN.
Jag ska också tillägga att varje separat miljö var separerad från varandra, och belastningen som beskrivs ovan var endast relevant för produktionsmiljön.
I utvecklingsmiljön tog vi upp en separat InfluxDB-instans som fortsatte att samla in data var 10:e sekund och vi stötte inte på några prestandaproblem.
TICK - idealisk för små till medelstora projekt
Baserat på denna information skulle jag dra slutsatsen att TICK-stacken är idealisk för relativt små projekt eller projekt som definitivt inte förväntar sig någon HighLoad.
Om du inte har tusentals pods eller hundratals maskiner, kommer till och med en InfluxDB-instans att hantera belastningen bra.
I vissa fall kan du vara nöjd med Influx Relay som en primitiv lösning med hög tillgänglighet.
Och, naturligtvis, ingen hindrar dig från att ställa in "vertikal" skalning och helt enkelt allokera olika servrar för olika typer av mätvärden.
Om du inte är säker på den förväntade belastningen på övervakningstjänsterna, eller om du garanterat har/kommer att ha en väldigt "tung" arkitektur, skulle jag inte rekommendera att använda gratisversionen av TICK-stacken.
Naturligtvis skulle en enkel lösning vara att köpa – men här kan jag inte kommentera på något sätt, eftersom jag själv inte är insatt i finesserna. Förutom att det är väldigt dyrt och definitivt inte lämpar sig för små företag.
I det här fallet skulle jag idag rekommendera att man tittar på att samla in mätvärden genom Victoria Metrics och loggar med Loki.
Det är sant att jag återigen reserverar mig för att Loki/Grafana är mycket mindre bekväma (på grund av sin större mångsidighet) än den färdiga TICK, men de är gratis.
Det är viktigt: all information som beskrivs här är relevant för version Influx 1.8, just nu är Influx 2.0 på väg att släppas.
Även om jag inte har haft en chans att prova det i stridsförhållanden och det är svårt att dra slutsatser om förbättringar, har gränssnittet definitivt blivit ännu bättre, arkitekturen har förenklats (utan kapacitor och kronograf),
mallar dök upp ("killer feature" - ). Men tyvärr, för tillfället, har version 2 inte nyckeln som vi valde den första versionen för - det finns ingen loggsamling.
Denna funktion kommer också att dyka upp i Influx 2.0, men vi kunde inte hitta några deadlines, inte ens ungefärliga.
Hur man inte gör IoT-plattformar (nu)
Till slut, efter att ha lanserat piloten, satte vi själva ihop vår egen fullfjädrade IoT-stack, i avsaknad av ett alternativ som var lämpligt enligt våra standarder.
Men nyligen är den tillgänglig i betaversion – det är synd att hon inte var där när vi började göra projektet.
Vi är helnöjda med slutresultatet och plattformen baserad på Ansible + TICK + WireGuard som vi själva monterade. Men idag skulle jag rekommendera att ta en närmare titt på Balena innan du försöker bygga din egen IoT-plattform själv.
För i slutändan kan det göra det mesta av det vi gjorde, och OpenBalena är gratis och öppen källkod.
Den vet redan hur man inte bara skickar uppdateringar, utan även en VPN är redan inbyggd och skräddarsydd för användning i en IoT-miljö.
Och alldeles nyligen släppte de till och med sina , som lätt ansluter till deras ekosystem.
Hej, hur är det med den saknade skotern?
Så skotern, "Ralph", försvann spårlöst.
Vi sprang omedelbart för att titta på kartan i vår "adminpanel", med GPS-data från InfluxDB.
Tack vare övervakningsdata kunde vi enkelt konstatera att skotern lämnade parkeringen runt 21:00 förra dagen, körde ungefär en halvtimme till något område och stod parkerad till klockan 5 bredvid något tyskt hus.
Efter klockan 5 mottogs inga övervakningsdata – detta betydde antingen att det extra batteriet var helt urladdat eller så kom angriparen äntligen på hur han skulle ta bort den smarta hårdvaran från skotern.
Trots det kallades polisen ändå till adressen där skotern befann sig. Skotern var inte där.
Ägaren till huset blev dock också förvånad över detta, eftersom han faktiskt åkte med den här skotern hem från kontoret igår kväll.
Det visade sig att en av supportmedarbetarna kom tidigt på morgonen och hämtade skotern, och såg att dess extra batteri var helt urladdat och tog den (till fots) till parkeringen. Och extrabatteriet misslyckades på grund av fukt.
Vi stal skotern från oss själva. Förresten, jag vet inte hur och vem som sedan löste problemet med polisfallet, men övervakningen fungerade perfekt...
Källa: will.com