🥇En annan övervakningssystem

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

Introduktion

Hej! Det här är en artikel om hur vi skapade ett nytt övervakningssystem för oss själva. Det skiljer sig från befintliga genom möjligheten till högfrekvent, synkroniserad hämtning av mätvärden och mycket låg resursförbrukning. Frågefrekvensen kan nå 0,1 millisekunder med synkroniseringsnoggrannhet mellan mätvärden på 10 nanosekunder. Alla binära filer tar upp 6 megabyte.

Om projektet

Vi har en ganska specifik produkt. Vi tillverkar en helhetslösning för summan av bandbredd och redundans i datatransmissonskanaler. Det innebär att det finns flera kanaler, till exempel Operatör1 (40Mbit/s) + Operatör2 (30Mbit/s) + Något annat (5 Mbit/s), vilket resulterar i en stabil och snabb kanal, vars hastighet blir ungefär så här: (40+30+5)x0.92=75x0.92=69 Mbit/s.

Sådana lösningar efterfrågas där kapaciteten för någon enda kanal är otillräcklig. Till exempel transport, videosystem och livestreaming i realtid, sändning av direktsändningar av TV- och radio, alla lantliga objekt där det bara finns representanter för de stora fyra operatörerna och hastigheten på en modem/kanal är otillräcklig.
För varje av dessa områden släpper vi en separat serie enheter, men den programvara de använder är nästan identisk och ett kvalitativt övervakningssystem är en av dess huvudmoduler, utan en korrekt implementering av vilken produkten skulle vara omöjlig.

Under flera år har vi lyckats skapa ett mångfaldigt, snabbt, plattformsoberoende och lättviktigt övervakningssystem. Detta vill vi dela med det respektabla samfundet.

Uppgiftsställande

Övervakningssystemet möjliggör insamling av mätvärden i två principiellt olika klasser: realtidsmätvärden och alla andra. Övervakningssystemet hade följande krav:

Högfrekvent, synkroniserad insamling av realtidsmätvärden och överföring till kommunikationshanteringssystemet utan fördröjning.
Hög frekvens och synkronisering av olika metrik är inte bara viktigt, utan livsnödvändigt för att analysera entropin i datakanaler. Om den genomsnittliga fördröjningen i en datakanal är 30 millisekunder, kommer en synkroniseringsfel på bara en millisekund mellan övriga metrika att leda till en nedgradering av hastigheten i den resulterande kanalen med ungefär 5%. Om vi gör ett synkroniseringsfel på 1 millisekund i 4 kanaler kan hastighetsnedgraderingen lätt falla till 30%. Dessutom förändras entropin i kanalerna mycket snabbt, så om vi mäter den mindre ofta än en gång på 0,5 millisekunder, kommer vi på snabba kanaler med låg fördröjning att få en hög nedgradering av hastigheten. Naturligtvis är inte sådan noggrannhet nödvändig för alla metrik och under alla förhållanden. När fördröjningen i kanalen är 500 millisekunder och vi arbetar med sådana, kommer en felmarginal på 1 millisekund knappt att märkas. För metrik av livsnödvändiga system räcker det med en uppdateringsfrekvens och synkronisering på 2 sekunder, men själva övervakningssystemet bör kunna arbeta med extremt hög uppdateringsfrekvens och extremt noggrann synkronisering av metrik.
Minimalt resursutnyttjande och en enhetlig stack.
Den slutliga enheten kan vara såväl en kraftfull bordsenhet som kan analysera trafikförhållanden eller utföra biometrisk registrering av människor, som en enbrädrig dator i handstorlek, som en specialstyrka bär under en skottsäker väst för att sända video i realtid under dåliga kommunikationsförhållanden. Trots den stora variationen i arkitektur och beräkningskapacitet, skulle vi vilja ha en gemensam mjukvarustack.
Övergripande arkitektur
Metrix måste samlas in och aggregeras på den slutliga enheten, ha ett lokalt lagringssystem och visualisering i realtid och retrospektivt. I händelse av kommunikation bör data överföras till det centrala övervakningssystemet. När det inte finns någon kommunikation bör köen för sändning ackumuleras och inte använda operativt minne.
API för integration i kundens övervakningssystem, eftersom ingen behöver många övervakningssystem. Kunden bör kunna samla in data från alla enheter och nätverk i en enda övervakning.

Vad som blev resultatet

För att inte belasta den redan omfattande texten, kommer jag inte att ge exempel och mätningar från alla övervakningssystem. Det skulle ta ytterligare en artikel. Jag kan bara säga att vi inte lyckades hitta ett övervakningssystem som kan ta två metrik samtidigt med en felmarginal 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 beslutade vi oss för att skriva vårt eget, som klarar av allt detta. Så här blev det:

Summan av bandbredden för tre kanaler för olika nätverkstopologier

Visualisering av några nyckelmetrik

Arkitektur

Som huvudspråk för programmering, både på enheten och i datacentret, använder vi Golang. Det har avsevärt förenklat livet med sin implementering av multitrådadhet och möjligheten att få en statiskt länkad körbar binärfil för varje tjänst. Som ett resultat sparar vi betydligt på resurser, metoder och trafik för distribuerad tjänst på slutgiltiga enheter, samt tid för utveckling och koddebugging.

Systemet är implementerat enligt den klassiska modulära principen och innehåller flera delsystem:

Registrering av metrik.
Varje metrik hanteras av en egen tråd och synkroniseras via kanaler. Vi lyckades uppnå synkroniseringsnoggrannhet på ner till 10 nanosekunder.
Lagring av metrik
Vi valde mellan att skapa vårt eget lagringssystem för tidsserier eller använda något befintligt. Databasen behövs för retrospektiv data som ska visualiseras senare. Det vill säga, den har inte data om fördröjningar i kanalen var 0,5 millisekund eller felmeddelanden i transportsystemet, men den har hastighet på varje gränssnitt var 500 millisekund. Förutom höga krav på plattformsoberoende och lågt resursutnyttjande är det extremt viktigt för oss att kunna behandla data där den lagras. Detta sparar enormt mycket beräkningsresurser. Sedan 2016 har vi använt databasen Tarantool i det här projektet och vi ser för tillfället ingen ersättning för den i horisonten. Flexibel, med optimalt resursutnyttjande, och med mer än tillräcklig teknisk support. Dessutom har Tarantool en GIS-modul. Den är självklart inte så kraftfull som PostGIS, men den räcker för våra behov av att lagra vissa mätvärden kopplade till plats (relevant för transport).
Visualisering av mätvärden
Här är allt relativt enkelt. Vi tar data från lagringen och visar dem antingen i realtid eller retroaktivt.
Synkronisering av data med det centrala övervakningssystemet.
Det centrala övervakningssystemet tar emot data från alla enheter, lagrar dem med en given retrospektiv och via API skickar dem till kundens övervakningssystem. Till skillnad från klassiska övervakningssystem, där "huvudet" går och samlar data - har vi en omvänd struktur. Enheterna skickar själva data när de är anslutna. Detta är en mycket viktig punkt, eftersom den tillåter oss att få data från enheten under de tidsperioder då den var otillgänglig, utan att belasta kanaler och resurser när enheten är otillgänglig. Som centralt övervakningssystem använder vi Influx monitoring server. Till skillnad från analoger, kan den importera retrospektiv data (dvs med tidsstämpel som är olika från tidpunkten då mätvärdet tagits) De samlade mätvärdena visualiseras med den förbättrade Grafana. Denna standardstack valdes också eftersom den har färdiga API-integrationer med praktiskt taget alla kundens övervakningssystem.
Synkronisering av data med det centrala enhetshanteringssystemet.
Enheten som hanterar device management implementerar Zero Touch Provisioning (uppgradering av firmware, konfiguration etc.) och skiljer sig från övervakningssystemet genom att den endast fångar upp problem med enheterna. Dessa fungerar som triggar för de ombordvarande hårdvarutjänsterna och alla livsviktig systemetriker: temperatur på CPU och SSD, CPU-belastning, ledigt utrymme och S.M.A.R.T hälsostatus på diskar. Lagringen av subsystemet är också byggd på Tarantool. Detta ger oss betydande hastighet vid aggregering av tidsserier över tusentals enheter och löser helt synkroniseringsfrågor med dessa enheter. Tarantool har ett utmärkt kö- och garanterat leveranssystem. Denna viktiga funktion fick vi direkt ur lådan, toppen!

Nätverkshanteringssystem

Vad händer härnäst

För närvarande är den svagaste länken vår centrala övervakningssystem. Den är byggd till 99,9 % på en standardstack och har en rad nackdelar:

InfluxDB förlorar data vid strömavbrott. Vanligtvis hämtar kunden snabbt allt som kommer från enheterna och databasen har inga data äldre än 5 minuter, men i framtiden kan detta bli ett problem.
Grafana har en rad problem med aggregering av data och synkronisering av deras visning. Det vanligaste problemet är när det finns en tidsserie i databasen med ett intervall på 2 sekunder som börjar exempelvis från 00:00:00, medan Grafana börjar visa data med aggregation från +1 sekund. Resultatet blir att användaren ser ett flackande diagram.
Överflödig kod för API-integration med externa övervakningssystem. Det kan göras mycket mer kompakt, och självklart skriva om det i Go.

Jag har medvetet valt att inte beskriva tekniska detaljer, utan har endast skissat på den bärande designen av detta system. För det första, för att tekniskt beskriva systemet fullständigt skulle en ytterligare artikel behövas. För det andra, långt ifrån alla kommer att vara intresserade av det. Skriv i kommentarerna vilka tekniska detaljer ni skulle vilja veta mer om.