Et annet overvåkingssystem

16 modemer, 4 mobiloperatører = Utgående hastighet 933.45 Mbit/s

Innledning

Hallo! Denne artikkelen handler om hvordan vi skrev et nytt overvåkingssystem for oss selv. Den skiller seg fra eksisterende i sin evne til å oppnå høyfrekvente synkrone beregninger og svært lavt ressursforbruk. Avstemningsfrekvensen kan nå 0.1 millisekunder med en synkroniseringsnøyaktighet mellom metrikker på 10 nanosekunder. Alle binære filer opptar 6 megabyte.

О проекте

Vi har et ganske spesifikt produkt. Vi produserer en omfattende løsning for å oppsummere gjennomstrømningen og feiltoleransen til dataoverføringskanaler. Dette er når det er flere kanaler, la oss si Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Noe annet (5 Mbit/s), resultatet er en stabil og rask kanal, hvis hastighet vil være noe sånt som dette: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

Slike løsninger er etterspurt der kapasiteten til en enkelt kanal er utilstrekkelig. For eksempel transport, videoovervåkingssystemer og sanntids videostrømming, sending av direkte TV- og radiosendinger, eventuelle forstadsanlegg der det blant teleoperatørene kun er representanter for de fire store og hastigheten på ett modem/kanal ikke er nok .
For hvert av disse områdene produserer vi en egen linje med enheter, men programvaredelen deres er nesten den samme, og et overvåkingssystem av høy kvalitet er en av hovedmodulene, uten riktig implementering som produktet ikke ville vært mulig.

I løpet av flere år klarte vi å lage et multi-level, raskt, kryssplattform og lett overvåkingssystem. Dette er hva vi ønsker å dele med vårt respekterte fellesskap.

Formulering av problemet

Overvåkingssystemet gir beregninger for to fundamentalt forskjellige klasser: sanntidsmålinger og alle andre. Overvåkingssystemet hadde bare følgende krav:

1. Høyfrekvent synkron innhenting av sanntidsmålinger og deres overføring til kommunikasjonsstyringssystemet uten forsinkelse.
   Høy frekvens og synkronisering av ulike metrikker er ikke bare viktig, det er avgjørende for å analysere entropien til dataoverføringskanaler. Hvis den gjennomsnittlige forsinkelsen i én dataoverføringskanal er 30 millisekunder, vil en feil i synkronisering mellom de gjenværende metrikkene på bare ett millisekund føre til en forringelse av hastigheten til den resulterende kanalen med omtrent 5 %. Hvis vi feiltimerer timingen med 1 millisekund over 4 kanaler, kan hastighetsdegraderingen lett falle til 30 %. I tillegg endres entropi i kanaler veldig raskt, så hvis vi måler den mindre enn én gang hvert 0.5 millisekund, vil vi på raske kanaler med en liten forsinkelse få høyhastighetsdegradering. Selvfølgelig er slik nøyaktighet ikke nødvendig for alle beregninger og ikke under alle forhold. Når forsinkelsen i kanalen er 500 millisekunder, og vi jobber med slike, så vil en feil på 1 millisekund nesten ikke være merkbar. For livsstøttesystemmålinger har vi også nok polling- og synkroniseringshastigheter på 2 sekunder, men selve overvåkingssystemet må kunne jobbe med ultrahøye pollingfrekvenser og ultrapresis synkronisering av beregninger.
2. Minimalt ressursforbruk og en enkelt stabel.
   Sluttenheten kan enten være et kraftig ombord-kompleks som kan analysere situasjonen på veien eller utføre biometrisk opptak av mennesker, eller en håndflatestørrelse enbordsdatamaskin som en spesialstyrkesoldat bærer under kroppsrustningen for å overføre video i sanntid under dårlige kommunikasjonsforhold. Til tross for en slik variasjon av arkitekturer og datakraft, vil vi gjerne ha samme programvarestabel.
3. Paraplyarkitektur
   Beregninger må samles inn og aggregeres på sluttenheten, lagres lokalt og visualiseres i sanntid og retrospektivt. Hvis det er en forbindelse, overføre data til det sentrale overvåkingssystemet. Når det ikke er noen forbindelse, bør sendekøen samle seg og ikke forbruke RAM.
4. API for integrering i kundens overvåkingssystem, fordi ingen trenger mange overvåkingssystemer. Kunden må samle data fra alle enheter og nettverk til en enkelt overvåking.

Hva skjedde

For ikke å belaste den allerede imponerende longreaden, vil jeg ikke gi eksempler og målinger av alle overvåkingssystemer. Dette vil føre til en annen artikkel. Jeg vil bare si at vi ikke klarte å finne et overvåkingssystem som er i stand til å ta to beregninger samtidig med en feil på mindre enn 1 millisekund og som fungerer like effektivt både på ARM-arkitektur med 64 MB RAM og på x86_64-arkitektur med 32 GB RAM. Derfor bestemte vi oss for å skrive vår egen, som kan gjøre alt dette. Her er hva vi fikk:

Oppsummerer gjennomstrømningen til tre kanaler for forskjellige nettverkstopologier

Visualisering av noen nøkkelberegninger

arkitektur

Vi bruker Golang som hovedprogrammeringsspråk, både på enheten og i datasenteret. Det forenklet livet kraftig med implementeringen av multitasking og muligheten til å få en statisk koblet kjørbar binær fil for hver tjeneste. Som et resultat sparer vi betydelig i ressurser, metoder og trafikk for å distribuere tjenesten til sluttenheter, utviklingstid og kodefeilsøking.

Systemet er implementert i henhold til det klassiske modulprinsippet og inneholder flere delsystemer:

1. Metrikkregistrering.
   Hver beregning betjenes av sin egen tråd og synkroniseres på tvers av kanaler. Vi var i stand til å oppnå synkroniseringsnøyaktighet på opptil 10 nanosekunder.
2. Lagring av beregninger
   Vi valgte mellom å skrive vår egen lagring for tidsserier eller å bruke noe som allerede var tilgjengelig. Databasen er nødvendig for retrospektive data som er gjenstand for påfølgende visualisering, det vil si at den ikke inneholder data om forsinkelser i kanalen hvert 0.5 millisekund eller feillesninger i transportnettet, men det er hastighet på hvert grensesnitt hvert 500. millisekund. I tillegg til de høye kravene til tverrplattform og lavt ressursforbruk er det ekstremt viktig for oss å kunne behandle. data er der de lagres. Dette sparer enorme dataressurser. Vi har brukt Tarantool DBMS i dette prosjektet siden 2016 og så langt ser vi ingen erstatning for det i horisonten. Fleksibel, med optimalt ressursforbruk, mer enn tilstrekkelig teknisk støtte. Tarantool implementerer også en GIS-modul. Den er selvfølgelig ikke like kraftig som PostGIS, men den er nok for våre oppgaver med å lagre noen stedsrelaterte beregninger (relevant for transport).
3. Visualisering av beregninger
   Alt er relativt enkelt her. Vi tar data fra lageret og viser dem enten i sanntid eller retrospektivt.
4. Synkronisering av data med det sentrale overvåkingssystemet.
   Det sentrale overvåkingssystemet mottar data fra alle enheter, lagrer det med en spesifisert historikk og sender det til kundens overvåkingssystem via API. I motsetning til klassiske overvåkingssystemer, der «hodet» går rundt og samler data, har vi det motsatte opplegget. Enhetene sender selv data når det er en tilkobling. Dette er et veldig viktig poeng, siden det lar deg motta data fra enheten i de periodene hvor den ikke var tilgjengelig og ikke laste kanaler og ressurser mens enheten er utilgjengelig. Vi bruker Influx overvåkingsserver som et sentralt overvåkingssystem. I motsetning til sine analoger, kan den importere retrospektive data (det vil si med et tidsstempel som er forskjellig fra det øyeblikket metrikken ble mottatt) De innsamlede beregningene blir visualisert av Grafana, modifisert med en fil. Denne standardstabelen ble også valgt fordi den har ferdiglagde API-integrasjoner med nesten alle kundeovervåkingssystem.
5. Datasynkronisering med et sentralt enhetsadministrasjonssystem.
   Enhetsadministrasjonssystemet implementerer Zero Touch Provisioning (oppdatering av fastvare, konfigurasjon osv.) og mottar, i motsetning til overvåkingssystemet, kun problemer per enhet. Dette er triggere for driften av innebygde maskinvareovervåkningstjenester og alle beregningene til livsstøttesystemer: CPU- og SSD-temperatur, CPU-belastning, ledig plass og SMART-helse på disker. Undersystemlagringen er også bygget på Tarantool. Dette gir oss betydelig hastighet i å samle tidsserier på tvers av tusenvis av enheter, og løser også problemet med å synkronisere data med disse enhetene fullstendig. Tarantool har et utmerket kø- og garantert leveringssystem. Vi fikk denne viktige funksjonen ut av esken, flott!

Nettverksstyringssystem

Hva er neste

Så langt er vårt svakeste ledd det sentrale overvåkingssystemet. Den er implementert 99.9% på en standardstabel og har en rekke ulemper:

1. InfluxDB mister data når strømmen går. Som regel samler Kunden raskt inn alt som kommer fra enhetene og selve databasen inneholder ikke data som er eldre enn 5 minutter, men i fremtiden kan dette bli en smerte.
2. Grafana har en rekke problemer med dataaggregering og synkronisering av skjermen. Det vanligste problemet er når databasen inneholder en tidsserie med et intervall på 2 sekunder fra for eksempel 00:00:00, og Grafana begynner å vise data i aggregering fra +1 sekund. Som et resultat ser brukeren en dansende graf.
3. Overdreven mengde kode for API-integrasjon med tredjeparts overvåkingssystemer. Den kan gjøres mye mer kompakt og selvfølgelig skrives om i Go)

Jeg tror dere alle har sett perfekt hvordan Grafana ser ut og kjenner problemene uten meg, så jeg vil ikke overbelaste innlegget med bilder.

Konklusjon

Jeg beskrev bevisst ikke de tekniske detaljene, men beskrev kun den grunnleggende utformingen av dette systemet. For det første, for teknisk fullstendig beskrivelse av systemet, vil en annen artikkel være nødvendig. For det andre vil ikke alle være interessert i dette. Skriv i kommentarfeltet hvilke tekniske detaljer du ønsker å vite.

Hvis noen har spørsmål utenfor rammen av denne artikkelen, kan du skrive til meg på a.rodin @ qedr.com

Kilde: www.habr.com