Ett annat övervakningssystem

16 modem, 4 mobiloperatörer = Utgående hastighet 933.45 Mbit/s

Inledning

Hallå! Den här artikeln handlar om hur vi skrev ett nytt övervakningssystem för oss själva. Den skiljer sig från befintliga i sin förmåga att erhålla högfrekventa synkrona mått och mycket låg resursförbrukning. Pollingsfrekvensen kan nå 0.1 millisekunder med en synkroniseringsnoggrannhet mellan mätvärden på 10 nanosekunder. Alla binära filer upptar 6 megabyte.

О проекте

Vi har en ganska specifik produkt. Vi tar fram en heltäckande lösning för att sammanfatta genomströmningen och feltoleransen för dataöverföringskanaler. Detta är när det finns flera kanaler, låt oss säga Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Något annat (5 Mbit/s), resultatet är en stabil och snabb kanal, vars hastighet kommer att vara ungefär som detta: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

Sådana lösningar är efterfrågade där kapaciteten för en kanal är otillräcklig. Till exempel transporter, videoövervakningssystem och realtidsvideoströmning, direktsändning av tv- och radiosändningar, alla förortsanläggningar där det bland teleoperatörerna bara finns representanter för de fyra stora och hastigheten på ett modem/kanal inte räcker till. .
För vart och ett av dessa områden producerar vi en separat linje av enheter, men deras mjukvarudel är nästan densamma och ett högkvalitativt övervakningssystem är en av dess huvudmoduler, utan den korrekta implementeringen av vilken produkten inte skulle vara möjlig.

Under flera år lyckades vi skapa ett snabbt, plattformsoberoende och lätt övervakningssystem på flera nivåer. Detta är vad vi vill dela med vår respekterade gemenskap.

Problem uttalande

Övervakningssystemet tillhandahåller mätvärden för två fundamentalt olika klasser: mätvärden i realtid och alla andra. Övervakningssystemet hade endast följande krav:

1. Högfrekvent synkron insamling av mätvärden i realtid och deras överföring till kommunikationshanteringssystemet utan dröjsmål.
   Hög frekvens och synkronisering av olika mått är inte bara viktigt, det är avgörande för att analysera entropin i dataöverföringskanaler. Om medelfördröjningen i en dataöverföringskanal är 30 millisekunder, kommer ett fel i synkroniseringen mellan de återstående måtten på bara en millisekund att leda till en försämring av hastigheten för den resulterande kanalen med ungefär 5 %. Om vi ​​tar bort timingen med 1 millisekund över 4 kanaler, kan hastighetsförsämringen lätt sjunka till 30 %. Dessutom ändras entropin i kanaler väldigt snabbt, så om vi mäter den mindre än en gång var 0.5 millisekund, på snabba kanaler med en liten fördröjning kommer vi att få höghastighetsnedbrytning. Naturligtvis behövs inte sådan noggrannhet för alla mätvärden och inte under alla förhållanden. När fördröjningen i kanalen är 500 millisekunder, och vi arbetar med sådana, kommer ett fel på 1 millisekund nästan inte att märkas. Dessutom, för livsuppehållande systemmått, har vi tillräckligt med polling- och synkroniseringshastigheter på 2 sekunder, men själva övervakningssystemet måste kunna arbeta med ultrahöga pollinghastigheter och ultraexakt synkronisering av mätvärden.
2. Minimal resursförbrukning och en enda stack.
   Slutenheten kan antingen vara ett kraftfullt ombordkomplex som kan analysera situationen på vägen eller utföra biometrisk inspelning av människor, eller en dator med en handflata som en specialsoldat bär under sin kroppsrustning för att överföra video i realtid under dåliga kommunikationsförhållanden. Trots en sådan variation av arkitekturer och datorkraft skulle vi vilja ha samma mjukvarustack.
3. Paraplyarkitektur
   Mätvärden måste samlas in och aggregeras på slutenheten, lagras lokalt och visualiseras i realtid och i efterhand. Om det finns en anslutning, överför data till det centrala övervakningssystemet. När det inte finns någon anslutning bör sändningskön ackumuleras och inte förbruka RAM.
4. API för integration i kundens övervakningssystem, eftersom ingen behöver många övervakningssystem. Kunden måste samla in data från alla enheter och nätverk till en enda övervakning.

Vad hände

För att inte belasta den redan imponerande longreaden kommer jag inte att ge exempel och mätningar av alla övervakningssystem. Detta kommer att leda till en annan artikel. Jag vill bara säga att vi inte kunde hitta ett övervakningssystem som kan ta två mätvärden samtidigt med ett fel på mindre än 1 millisekund och som fungerar lika effektivt både på ARM-arkitektur med 64 MB RAM och på x86_64-arkitektur med 32 GB RAM. Därför bestämde vi oss för att skriva vår egen, som kan göra allt detta. Här är vad vi fick:

Sammanfattning av genomströmningen av tre kanaler för olika nätverkstopologier

Visualisering av några nyckeltal

Arkitektur

Vi använder Golang som huvudprogrammeringsspråk, både på enheten och i datacentret. Det förenklade livet avsevärt med sin implementering av multitasking och möjligheten att få en statiskt länkad körbar binär fil för varje tjänst. Som ett resultat sparar vi avsevärt i resurser, metoder och trafik för att distribuera tjänsten till slutenheter, utvecklingstid och kodfelsökning.

Systemet är implementerat enligt den klassiska modulprincipen och innehåller flera delsystem:

1. Mätvärdesregistrering.
   Varje mätvärde betjänas av sin egen tråd och synkroniseras över kanaler. Vi kunde uppnå en synkroniseringsnoggrannhet på upp till 10 nanosekunder.
2. Lagring av mätvärden
   Vi valde mellan att skriva vår egen lagring för tidsserier eller att använda något som redan fanns tillgängligt. Databasen behövs för retrospektiv data som är föremål för efterföljande visualisering, det vill säga att den inte innehåller data om fördröjningar i kanalen var 0.5 millisekund eller felavläsningar i transportnätet utan det är hastighet på varje gränssnitt var 500:e millisekund. Förutom de höga kraven på plattformsoberoende och låg resursförbrukning är det oerhört viktigt för oss att kunna bearbeta. data är där den lagras. Detta sparar enorma datorresurser. Vi har använt Tarantool DBMS i detta projekt sedan 2016 och än så länge ser vi ingen ersättning för det vid horisonten. Flexibel, med optimal resursförbrukning, mer än tillräcklig teknisk support. Tarantool implementerar även en GIS-modul. Det är naturligtvis inte lika kraftfullt som PostGIS, men det räcker för våra uppgifter att lagra en del platsrelaterade mätvärden (relevant för transport).
3. Visualisering av mått
   Allt är relativt enkelt här. Vi tar data från lagret och visar det antingen i realtid eller i efterhand.
4. Synkronisering av data med det centrala övervakningssystemet.
   Det centrala övervakningssystemet tar emot data från alla enheter, lagrar det med en specificerad historik och skickar den till kundens övervakningssystem via API. Till skillnad från klassiska övervakningssystem, där "huvudet" går runt och samlar in data, har vi det motsatta schemat. Enheterna själva skickar data när det finns en anslutning. Detta är en mycket viktig punkt, eftersom det låter dig ta emot data från enheten under de tidsperioder som den inte var tillgänglig och inte ladda kanaler och resurser medan enheten är otillgänglig. Vi använder inflödesövervakningsserver som ett centralt övervakningssystem. Till skillnad från dess analoger kan den importera retrospektiv data (det vill säga med en tidsstämpel som skiljer sig från det ögonblick då mätvärdena togs emot) De insamlade mätvärdena visualiseras av Grafana, modifierade med en fil. Denna standardstack valdes också eftersom den har färdiga API-integrationer med nästan alla kundövervakningssystem.
5. Datasynkronisering med ett centralt enhetshanteringssystem.
   Enhetshanteringssystemet implementerar Zero Touch Provisioning (uppdatering av firmware, konfiguration, etc.) och får, till skillnad från övervakningssystemet, endast problem per enhet. Dessa är triggers för driften av inbyggda hårdvaruövervakningstjänster och alla mätvärden för livsuppehållande system: CPU- och SSD-temperatur, CPU-belastning, ledigt utrymme och SMART-hälsa på diskar. Delsystemlagringen är också byggd på Tarantool. Detta ger oss betydande snabbhet i att aggregera tidsserier över tusentals enheter, och löser också helt problemet med att synkronisera data med dessa enheter. Tarantool har ett utmärkt kö- och garanterat leveranssystem. Vi fick den här viktiga funktionen ur lådan, bra!

Nätverkshanteringssystem

Vad är nästa

Hittills är vår svagaste länk det centrala övervakningssystemet. Det är implementerat 99.9% på en standardstack och har ett antal nackdelar:

1. InfluxDB förlorar data när strömmen bryts. Som regel samlar Kunden snabbt in allt som kommer från enheterna och själva databasen innehåller inte data som är äldre än 5 minuter, men i framtiden kan detta bli jobbigt.
2. Grafana har ett antal problem med dataaggregering och synkronisering av dess display. Det vanligaste problemet är när databasen innehåller en tidsserie med ett intervall på 2 sekunder från t.ex. 00:00:00 och Grafana börjar visa data i aggregering från +1 sekund. Som ett resultat ser användaren en dansande graf.
3. Överdriven mängd kod för API-integration med tredjeparts övervakningssystem. Det kan göras mycket mer kompakt och naturligtvis skrivas om i Go)

Jag tror att ni alla har sett perfekt hur Grafana ser ut och känner till dess problem utan mig, så jag kommer inte att överbelasta inlägget med bilder.

Slutsats

Jag beskrev medvetet inte de tekniska detaljerna, utan beskrev bara den grundläggande designen av detta system. För det första, för att tekniskt fullständigt beskriva systemet, kommer en annan artikel att krävas. För det andra kommer inte alla att vara intresserade av detta. Skriv i kommentarerna vilka tekniska detaljer du vill veta.

Om någon har frågor utanför den här artikeln kan du skriva till mig på a.rodin @ qedr.com

Källa: will.com