16 modemer, 4 mobiloperatører = udgående hastighed 933.45 Mbit/s
Indledning
Hej! Denne artikel handler om, hvordan vi skrev et nyt overvågningssystem til os selv. Den adskiller sig fra eksisterende ved sin evne til at opnå højfrekvente synkrone metrikker og meget lavt ressourceforbrug. Pollinghastigheden kan nå op på 0.1 millisekunder med en synkroniseringsnøjagtighed mellem metrikker på 10 nanosekunder. Alle binære filer optager 6 megabyte.
cirka
Vi har et ret specifikt produkt. Vi producerer en omfattende løsning til at opsummere datatransmissionskanalernes gennemløb og fejltolerance. Dette er, når der er flere kanaler, lad os sige Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Noget andet (5 Mbit/s), resultatet er en stabil og hurtig kanal, hvis hastighed vil være noget i retning af dette: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Sådanne løsninger er efterspurgte, hvor kapaciteten af en enkelt kanal er utilstrækkelig. For eksempel transport, videoovervågningssystemer og videostreaming i realtid, udsendelse af direkte tv- og radioudsendelser, eventuelle forstadsfaciliteter, hvor der blandt teleoperatørerne kun er repræsentanter for de fire store, og hastigheden på et modem/kanal ikke er nok .
For hvert af disse områder producerer vi en separat linje af enheder, men deres softwaredel er næsten den samme, og et overvågningssystem af høj kvalitet er et af dets hovedmoduler, uden den korrekte implementering, som produktet ikke ville være muligt.
I løbet af flere år lykkedes det os at skabe et multi-level, hurtigt, cross-platform og let overvågningssystem. Det er det, vi ønsker at dele med vores respekterede samfund.
Formulering af problemet
Overvågningssystemet giver målinger af to fundamentalt forskellige klasser: realtidsmålinger og alle andre. Overvågningssystemet havde kun følgende krav:
- Højfrekvent synkron indsamling af realtidsmålinger og deres overførsel til kommunikationsstyringssystemet uden forsinkelse.
Høj frekvens og synkronisering af forskellige metrikker er ikke bare vigtigt, det er afgørende for at analysere entropien af datatransmissionskanaler. Hvis den gennemsnitlige forsinkelse i én datatransmissionskanal er 30 millisekunder, så vil en fejl i synkroniseringen mellem de resterende målinger på kun et millisekund føre til en forringelse af hastigheden af den resulterende kanal med ca. 5 %. Hvis vi mistimerer timingen med 1 millisekund på tværs af 4 kanaler, kan hastighedsforringelsen let falde til 30 %. Derudover ændres entropi i kanaler meget hurtigt, så hvis vi måler det mindre end én gang hvert 0.5 millisekund, vil vi på hurtige kanaler med en lille forsinkelse få højhastighedsnedbrydning. En sådan nøjagtighed er naturligvis ikke nødvendig for alle målinger og ikke under alle forhold. Når forsinkelsen i kanalen er 500 millisekunder, og vi arbejder med sådanne, så vil en fejl på 1 millisekund næsten ikke kunne mærkes. Også for livsstøttesystem-metrikker har vi nok polling- og synkroniseringshastigheder på 2 sekunder, men selve overvågningssystemet skal kunne arbejde med ultrahøje polling-rater og ultrapræcis synkronisering af metrikker. - Minimalt ressourceforbrug og en enkelt stak.
Slutenheden kan enten være et kraftfuldt ombord-kompleks, der kan analysere situationen på vejen eller foretage biometrisk optagelse af mennesker, eller en håndfladestørrelse singleboard-computer, som en specialstyrkesoldat bærer under sin panser for at overføre video i realtid under dårlige kommunikationsforhold. På trods af så mange forskellige arkitekturer og computerkraft vil vi gerne have den samme softwarestak. - Paraply arkitektur
Metrics skal indsamles og aggregeres på slutenheden, gemmes lokalt og visualiseres i realtid og retrospektivt. Hvis der er forbindelse, overføres data til det centrale overvågningssystem. Når der ikke er nogen forbindelse, bør afsenderkøen akkumulere og ikke forbruge RAM. - API til integration i kundens overvågningssystem, for ingen har brug for mange overvågningssystemer. Kunden skal indsamle data fra alle enheder og netværk til en enkelt overvågning.
Hvad skete der
For ikke at belaste den allerede imponerende longread, vil jeg ikke give eksempler og målinger af alle overvågningssystemer. Dette vil føre til en anden artikel. Jeg vil bare sige, at vi ikke var i stand til at finde et overvågningssystem, der er i stand til at tage to målinger samtidigt med en fejl på mindre end 1 millisekund, og som fungerer lige effektivt både på ARM-arkitektur med 64 MB RAM og på x86_64-arkitektur med 32 GB RAM. Derfor besluttede vi at skrive vores egen, som kan alt dette. Her er hvad vi fik:
Opsummering af gennemløbet af tre kanaler for forskellige netværkstopologier
Visualisering af nogle nøglemålinger
arkitektur
Vi bruger Golang som hovedprogrammeringssprog, både på enheden og i datacentret. Det forenklede livet i høj grad med sin implementering af multitasking og evnen til at få en statisk forbundet eksekverbar binær fil for hver tjeneste. Som et resultat sparer vi betydeligt i ressourcer, metoder og trafik til implementering af tjenesten til at afslutte enheder, udviklingstid og kodefejlretning.
Systemet er implementeret efter det klassiske modulprincip og indeholder flere delsystemer:
- Metrik registrering.
Hver metrik betjenes af sin egen tråd og synkroniseres på tværs af kanaler. Vi var i stand til at opnå synkroniseringsnøjagtighed på op til 10 nanosekunder. - Opbevaring af metrics
Vi valgte mellem at skrive vores eget lager til tidsserier eller bruge noget, der allerede var tilgængeligt. Databasen er nødvendig for retrospektive data, der er genstand for efterfølgende visualisering, det vil sige, at den ikke indeholder data om forsinkelser i kanalen hvert 0.5 millisekund eller fejllæsninger i transportnetværket, men der er hastighed på hvert interface hvert 500 millisekund. Udover de høje krav til cross-platform og lavt ressourceforbrug, er det ekstremt vigtigt for os at kunne bearbejde. data er der, hvor de er gemt. Dette sparer enorme computerressourcer. Vi har brugt Tarantool DBMS i dette projekt siden 2016, og indtil videre ser vi ikke en erstatning for det i horisonten. Fleksibel, med optimalt ressourceforbrug, mere end tilstrækkelig teknisk support. Tarantool implementerer også et GIS-modul. Det er selvfølgelig ikke så kraftfuldt som PostGIS, men det er nok til vores opgaver med at gemme nogle lokationsrelaterede målinger (relevante for transport). - Visualisering af metrikker
Alt er relativt enkelt her. Vi tager data fra lageret og viser dem enten i realtid eller retrospektivt. - Synkronisering af data med det centrale overvågningssystem.
Det centrale overvågningssystem modtager data fra alle enheder, gemmer dem med en specificeret historik og sender dem til kundens overvågningssystem via API. I modsætning til klassiske overvågningssystemer, hvor "hovedet" går rundt og samler data, har vi den modsatte ordning. Enhederne sender selv data, når der er forbindelse. Dette er et meget vigtigt punkt, da det giver dig mulighed for at modtage data fra enheden i de perioder, hvor den ikke var tilgængelig, og ikke indlæse kanaler og ressourcer, mens enheden ikke er tilgængelig. Vi bruger Influx overvågningsserver som et centralt overvågningssystem. I modsætning til dets analoger kan den importere retrospektive data (dvs. med et tidsstempel, der er forskelligt fra det øjeblik, metrikken blev modtaget).De indsamlede metrics visualiseres af Grafana, modificeret med en fil. Denne standardstak blev også valgt, fordi den har færdige API-integrationer med næsten ethvert kundeovervågningssystem. - Datasynkronisering med et centralt enhedsadministrationssystem.
Enhedsstyringssystemet implementerer Zero Touch Provisioning (opdatering af firmware, konfiguration osv.) og modtager i modsætning til overvågningssystemet kun problemer pr. enhed. Disse er triggere for driften af indbyggede hardware-watchdog-tjenester og alle målene for livsstøttesystemer: CPU- og SSD-temperatur, CPU-belastning, ledig plads og SMART-sundhed på diske. Undersystemets lager er også bygget på Tarantool. Dette giver os betydelig hastighed i at aggregere tidsserier på tværs af tusindvis af enheder og løser også fuldstændigt problemet med at synkronisere data med disse enheder. Tarantool har et fremragende kø- og garanteret leveringssystem. Vi fik denne vigtige funktion ud af kassen, fantastisk!
Netværksstyringssystem
Hvad er næste
Indtil videre er vores svageste led det centrale overvågningssystem. Det er implementeret 99.9% på en standardstack og har en række ulemper:
- InfluxDB mister data, når strømmen afbrydes. Som regel indsamler Kunden omgående alt, hvad der kommer fra enhederne, og selve databasen indeholder ikke data, der er ældre end 5 minutter, men i fremtiden kan dette blive en smerte.
- Grafana har en række problemer med dataaggregering og synkronisering af sin visning. Det mest almindelige problem er, når databasen indeholder en tidsserie med et interval på 2 sekunder startende fra f.eks. 00:00:00, og Grafana begynder at vise data i aggregering fra +1 sekund. Som et resultat ser brugeren en dansende graf.
- Overdreven mængde kode til API-integration med tredjeparts overvågningssystemer. Det kan gøres meget mere kompakt og selvfølgelig omskrives i Go)
Jeg tror, at I alle har set perfekt, hvordan Grafana ser ud og kender sine problemer uden mig, så jeg vil ikke overbelaste indlægget med billeder.
Konklusion
Jeg beskrev bevidst ikke de tekniske detaljer, men beskrev kun det grundlæggende design af dette system. For det første, for teknisk fuldt ud at beskrive systemet, kræves der en anden artikel. For det andet vil ikke alle være interesserede i dette. Skriv i kommentarerne, hvilke tekniske detaljer du gerne vil vide.
Hvis nogen har spørgsmål uden for rammerne af denne artikel, kan du skrive til mig på a.rodin @ qedr.com
Kilde: www.habr.com