16 modems, 4 mobiele operators = Uitgaande snelheid 933.45 Mbit/s
Introductie
Hallo! Dit artikel gaat over hoe we een nieuw monitoringsysteem voor onszelf hebben geschreven. Het verschilt van de bestaande door zijn vermogen om hoogfrequente synchrone meetgegevens te verkrijgen en een zeer laag verbruik van hulpbronnen. De pollingsnelheid kan 0.1 milliseconden bereiken met een synchronisatienauwkeurigheid tussen de metrieken van 10 nanoseconden. Alle binaire bestanden beslaan 6 megabytes.
Over het project
Wij hebben een vrij specifiek product. Wij produceren een alomvattende oplossing voor het samenvatten van de doorvoer en fouttolerantie van datatransmissiekanalen. Dit is wanneer er meerdere kanalen zijn, laten we zeggen Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Iets anders (5 Mbit/s), het resultaat is één stabiel en snel kanaal, waarvan de snelheid ongeveer zo zal zijn dit: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Er is vraag naar dergelijke oplossingen wanneer de capaciteit van een bepaald kanaal onvoldoende is. Bijvoorbeeld transport, videobewakingssystemen en realtime videostreaming, uitzending van live televisie- en radio-uitzendingen, alle faciliteiten in de voorsteden waar onder de telecomoperatoren alleen vertegenwoordigers van de Big Four zijn en de snelheid op één modem/kanaal niet voldoende is .
Voor elk van deze gebieden produceren we een aparte lijn apparaten, maar hun softwaregedeelte is vrijwel hetzelfde en een hoogwaardig monitoringsysteem is een van de belangrijkste modules, zonder de juiste implementatie waarvan het product niet mogelijk zou zijn.
In de loop van een aantal jaren zijn we erin geslaagd een multi-level, snel, platformonafhankelijk en lichtgewicht monitoringsysteem te creëren. Dit is wat we willen delen met onze gerespecteerde gemeenschap.
Formulering van het probleem
Het monitoringsysteem biedt statistieken van twee fundamenteel verschillende klassen: realtime statistieken en alle andere. Het monitoringsysteem had alleen de volgende vereisten:
- Hoogfrequente synchrone verwerving van real-time meetgegevens en hun overdracht naar het communicatiebeheersysteem zonder vertraging.
Hoge frequentie en synchronisatie van verschillende metrieken zijn niet alleen belangrijk, het is ook van vitaal belang voor het analyseren van de entropie van datatransmissiekanalen. Als in één datatransmissiekanaal de gemiddelde vertraging 30 milliseconden bedraagt, dan zal een fout in de synchronisatie tussen de resterende metrieken van slechts één milliseconde leiden tot een verslechtering van de snelheid van het resulterende kanaal met ongeveer 5%. Als we de timing over 1 kanalen 4 milliseconde verkeerd inschatten, kan de snelheidsvermindering gemakkelijk dalen tot 30%. Bovendien verandert de entropie in kanalen zeer snel, dus als we deze minder dan eens per 0.5 milliseconde meten, zullen we op snelle kanalen met een kleine vertraging een hoge snelheidsdegradatie ervaren. Uiteraard is een dergelijke nauwkeurigheid niet voor alle meetgegevens en niet onder alle omstandigheden nodig. Als de vertraging in het kanaal 500 milliseconden bedraagt, en we werken daarmee, dan zal een fout van 1 milliseconde bijna niet merkbaar zijn. Ook voor levensondersteunende systeemstatistieken hebben we voldoende polling- en synchronisatiesnelheden van 2 seconden, maar het monitoringsysteem zelf moet in staat zijn om te werken met ultrahoge pollingsnelheden en ultranauwkeurige synchronisatie van statistieken. - Minimaal verbruik van hulpbronnen en een enkele stapel.
Het eindapparaat kan een krachtig boordcomplex zijn dat de situatie onderweg kan analyseren of biometrische opnames van mensen kan uitvoeren, of een computer ter grootte van een handpalm die een soldaat van de speciale strijdkrachten onder zijn kogelvrije vesten draagt om videobeelden uit te zenden. realtime in slechte communicatieomstandigheden. Ondanks zo’n verscheidenheid aan architecturen en rekenkracht zouden we graag dezelfde softwarestack willen hebben. - Paraplu-architectuur
Metrieken moeten worden verzameld en geaggregeerd op het eindapparaat, lokaal worden opgeslagen en in realtime en achteraf worden gevisualiseerd. Als er een verbinding is, verzendt u gegevens naar het centrale monitoringsysteem. Als er geen verbinding is, moet de verzendwachtrij zich ophopen en geen RAM verbruiken. - API voor integratie in het monitoringsysteem van de klant, omdat niemand veel monitoringsystemen nodig heeft. De klant moet gegevens van alle apparaten en netwerken verzamelen in één enkele monitoring.
Wat is er gebeurd
Om de toch al indrukwekkende longread niet te belasten, zal ik niet van alle monitoringsystemen voorbeelden en metingen geven. Dit zal leiden tot een ander artikel. Ik wil alleen zeggen dat we er niet in zijn geslaagd een monitoringsysteem te vinden dat twee statistieken tegelijk kan meten met een fout van minder dan 1 milliseconde en dat even effectief werkt op zowel de ARM-architectuur met 64 MB RAM als op de x86_64-architectuur met 32 MB RAM. GB RAM. Daarom hebben we besloten om onze eigen te schrijven, die dit allemaal kan doen. Dit is wat we hebben:
Een samenvatting van de doorvoer van drie kanalen voor verschillende netwerktopologieën
Visualisatie van enkele belangrijke statistieken
Architectuur
We gebruiken Golang als de belangrijkste programmeertaal, zowel op het apparaat als in het datacenter. Het heeft het leven enorm vereenvoudigd door de implementatie van multitasking en de mogelijkheid om voor elke service één statisch gekoppeld uitvoerbaar binair bestand te krijgen. Als gevolg hiervan besparen we aanzienlijk op middelen, methoden en verkeer voor het inzetten van de service op eindapparaten, ontwikkelingstijd en foutopsporing in code.
Het systeem is geïmplementeerd volgens het klassieke modulaire principe en bevat verschillende subsystemen:
- Registratie van statistieken.
Elke statistiek wordt bediend door een eigen thread en gesynchroniseerd tussen kanalen. We konden een synchronisatienauwkeurigheid tot 10 nanoseconden bereiken. - Opslag van statistieken
We kozen tussen het schrijven van onze eigen opslag voor tijdreeksen of het gebruiken van iets dat al beschikbaar was. De database is nodig voor retrospectieve gegevens die vervolgens worden gevisualiseerd, dat wil zeggen dat deze geen gegevens bevat over vertragingen in het kanaal elke 0.5 milliseconden of foutlezingen in het transportnetwerk, maar er is snelheid op elke interface elke 500 milliseconden. Naast de hoge eisen aan platformonafhankelijk en laag verbruik van hulpbronnen, is het voor ons uiterst belangrijk om te kunnen verwerken. gegevens zijn waar ze worden opgeslagen. Dit bespaart enorme computerbronnen. We gebruiken het Tarantool DBMS in dit project sinds 2016 en tot nu toe zien we geen vervanging ervoor aan de horizon. Flexibel, met optimaal hulpbronnengebruik, meer dan voldoende technische ondersteuning. Tarantool implementeert ook een GIS-module. Het is natuurlijk niet zo krachtig als PostGIS, maar het is voldoende voor onze taken van het opslaan van enkele locatiegerelateerde statistieken (relevant voor transport). - Visualisatie van statistieken
Alles is hier relatief eenvoudig. We halen gegevens uit het magazijn en geven deze in realtime of achteraf weer. - Synchronisatie van gegevens met het centrale monitoringsysteem.
Het centrale monitoringsysteem ontvangt gegevens van alle apparaten, slaat deze op met een gespecificeerde geschiedenis en stuurt deze via API naar het monitoringsysteem van de Klant. In tegenstelling tot klassieke monitoringsystemen, waarbij het ‘hoofd’ rondloopt en gegevens verzamelt, hebben we het tegenovergestelde schema. De apparaten versturen zelf data als er verbinding is. Dit is een heel belangrijk punt, omdat u hiermee gegevens van het apparaat kunt ontvangen gedurende de perioden waarin het niet beschikbaar was, en u geen kanalen en bronnen kunt laden terwijl het apparaat niet beschikbaar is. Wij gebruiken de Instroommonitoringserver als centraal monitoringsysteem. In tegenstelling tot zijn analogen kan het retrospectieve gegevens importeren (dat wil zeggen met een tijdstempel die verschilt van het moment waarop de statistieken werden ontvangen). De verzamelde statistieken worden gevisualiseerd door Grafana, aangepast met een bestand. Er is ook voor deze standaardstack gekozen omdat deze kant-en-klare API-integraties heeft met vrijwel elk klantmonitoringsysteem. - Gegevenssynchronisatie met een centraal apparaatbeheersysteem.
Het device management systeem implementeert Zero Touch Provisioning (updaten van firmware, configuratie etc.) en krijgt, in tegenstelling tot het monitoringsysteem, alleen problemen per device binnen. Dit zijn triggers voor de werking van ingebouwde hardware-watchdog-services en alle statistieken van levensondersteunende systemen: CPU- en SSD-temperatuur, CPU-belasting, vrije ruimte en SMART-gezondheid op schijven. De opslag van het subsysteem is ook gebouwd op Tarantool. Dit geeft ons een aanzienlijke snelheid bij het aggregeren van tijdreeksen over duizenden apparaten, en lost ook het probleem van het synchroniseren van gegevens met deze apparaten volledig op. Tarantool heeft een uitstekend wachtrij- en gegarandeerd bezorgsysteem. We hebben deze belangrijke functie uit de doos gehaald, geweldig!
Netwerkbeheersysteem
What's Next
Tot nu toe is onze zwakste schakel het centrale monitoringsysteem. Het is voor 99.9% geïmplementeerd op een standaardstack en heeft een aantal nadelen:
- InfluxDB verliest gegevens wanneer de stroom uitvalt. In de regel verzamelt de Klant onmiddellijk alles wat van de apparaten komt en bevat de database zelf geen gegevens ouder dan 5 minuten, maar in de toekomst kan dit lastig worden.
- Grafana heeft een aantal problemen met de gegevensaggregatie en synchronisatie van de weergave. Het meest voorkomende probleem is wanneer de database een tijdreeks bevat met een interval van 2 seconden, beginnend bij bijvoorbeeld 00:00:00, en Grafana gegevens in aggregatie begint weer te geven vanaf +1 seconde. Als resultaat ziet de gebruiker een dansende grafiek.
- Overmatige hoeveelheid code voor API-integratie met monitoringsystemen van derden. Het kan veel compacter worden gemaakt en uiteraard herschreven in Go)
Ik denk dat jullie allemaal perfect hebben gezien hoe Grafana eruit ziet en de problemen kennen zonder mij, dus ik zal de post niet overladen met foto's.
Conclusie
Ik heb bewust niet de technische details beschreven, maar alleen het basisontwerp van dit systeem. Ten eerste is er een ander artikel nodig om het systeem technisch volledig te beschrijven. Ten tweede zal niet iedereen hierin geïnteresseerd zijn. Schrijf in de opmerkingen welke technische details u wilt weten.
Als iemand vragen heeft die buiten het bestek van dit artikel vallen, kunt u mij schrijven op [email protected]
Bron: www.habr.com