Ein weiteres Überwachungssystem

16 Modems, 4 Mobilfunkanbieter = ausgehende Geschwindigkeit 933.45 Mbit/s

Einführung

Hallo! In diesem Artikel geht es darum, wie wir ein neues Überwachungssystem für uns selbst geschrieben haben. Es unterscheidet sich von bestehenden durch seine Fähigkeit, hochfrequente synchrone Metriken zu erhalten und einen sehr geringen Ressourcenverbrauch. Die Abfragerate kann 0.1 Millisekunden erreichen, mit einer Synchronisationsgenauigkeit zwischen Metriken von 10 Nanosekunden. Alle Binärdateien belegen 6 Megabyte.

Über das Projekt

Wir haben ein ziemlich spezifisches Produkt. Wir erstellen eine umfassende Lösung zur Zusammenfassung des Durchsatzes und der Fehlertoleranz von Datenübertragungskanälen. Wenn es mehrere Kanäle gibt, sagen wir Operator1 (40 Mbit/s) + Operator2 (30 Mbit/s)+ Etwas anderes (5 Mbit/s), ergibt sich ein stabiler und schneller Kanal, dessen Geschwindigkeit ungefähr so ​​hoch ist dies: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

Solche Lösungen sind dort gefragt, wo die Kapazität eines einzelnen Kanals nicht ausreicht. Zum Beispiel Transport, Videoüberwachungssysteme und Echtzeit-Videostreaming, Übertragung von Live-Fernseh- und Radiosendungen, alle Vorstadteinrichtungen, in denen es unter den Telekommunikationsbetreibern nur Vertreter der Big Four gibt und die Geschwindigkeit auf einem Modem/Kanal nicht ausreicht .
Für jeden dieser Bereiche produzieren wir eine eigene Gerätelinie, deren Softwareteil jedoch nahezu gleich ist und ein hochwertiges Überwachungssystem eines seiner Hauptmodule ist, ohne dessen korrekte Implementierung das Produkt nicht möglich wäre.

Im Laufe mehrerer Jahre ist es uns gelungen, ein mehrstufiges, schnelles, plattformübergreifendes und leichtes Überwachungssystem zu schaffen. Das ist es, was wir mit unserer angesehenen Community teilen möchten.

Formulierung des Problems

Das Überwachungssystem stellt Metriken zweier grundsätzlich unterschiedlicher Klassen bereit: Echtzeitmetriken und alle anderen. An das Überwachungssystem wurden lediglich folgende Anforderungen gestellt:

1. Hochfrequente synchrone Erfassung von Echtzeitmetriken und deren verzögerungsfreie Übertragung an das Kommunikationsmanagementsystem.
   Eine hohe Frequenz und Synchronisierung verschiedener Metriken ist nicht nur wichtig, sondern auch für die Analyse der Entropie von Datenübertragungskanälen von entscheidender Bedeutung. Wenn in einem Datenübertragungskanal die durchschnittliche Verzögerung 30 Millisekunden beträgt, führt ein Synchronisationsfehler zwischen den verbleibenden Metriken von nur einer Millisekunde zu einer Verschlechterung der Geschwindigkeit des resultierenden Kanals um etwa 5 %. Wenn wir das Timing über 1 Kanäle hinweg um 4 Millisekunde verfehlen, kann der Geschwindigkeitsabfall leicht auf 30 % sinken. Darüber hinaus ändert sich die Entropie in Kanälen sehr schnell. Wenn wir sie also weniger als einmal alle 0.5 Millisekunden messen, kommt es bei schnellen Kanälen mit einer kleinen Verzögerung zu einer starken Geschwindigkeitsverschlechterung. Natürlich ist eine solche Genauigkeit nicht für alle Metriken und nicht unter allen Bedingungen erforderlich. Wenn die Verzögerung im Kanal 500 Millisekunden beträgt und wir damit arbeiten, ist ein Fehler von 1 Millisekunde fast nicht wahrnehmbar. Auch für die Metriken von Lebenserhaltungssystemen verfügen wir über ausreichende Abfrage- und Synchronisierungsraten von 2 Sekunden, aber das Überwachungssystem selbst muss in der Lage sein, mit extrem hohen Abfrageraten und einer äußerst präzisen Synchronisierung der Metriken zu arbeiten.
2. Minimaler Ressourcenverbrauch und ein einziger Stapel.
   Das Endgerät kann entweder ein leistungsstarker Bordkomplex sein, der die Situation auf der Straße analysieren oder biometrische Personenerfassungen durchführen kann, oder ein handtellergroßer Einplatinencomputer, den ein Spezialeinheitssoldat unter seiner Körperpanzerung trägt, um Videos zu übertragen Echtzeit bei schlechten Kommunikationsbedingungen. Trotz dieser Vielfalt an Architekturen und Rechenleistung hätten wir gerne den gleichen Software-Stack.
3. Regenschirmarchitektur
   Metriken müssen auf dem Endgerät erfasst und aggregiert, lokal gespeichert und in Echtzeit sowie im Nachhinein visualisiert werden. Wenn eine Verbindung besteht, übertragen Sie die Daten an das zentrale Überwachungssystem. Wenn keine Verbindung besteht, sollte sich die Sendewarteschlange ansammeln und keinen RAM verbrauchen.
4. API zur Integration in das Überwachungssystem des Kunden, da niemand viele Überwachungssysteme benötigt. Der Kunde muss Daten von beliebigen Geräten und Netzwerken in einer einzigen Überwachung sammeln.

Was ist passiert

Um den bereits beeindruckenden Longread nicht zu überfordern, werde ich nicht für alle Überwachungssysteme Beispiele und Messungen nennen. Dies führt zu einem weiteren Artikel. Ich möchte nur sagen, dass wir kein Überwachungssystem finden konnten, das in der Lage ist, zwei Metriken gleichzeitig mit einem Fehler von weniger als 1 Millisekunde zu erfassen, und das sowohl auf der ARM-Architektur mit 64 MB RAM als auch auf der x86_64-Architektur mit 32 MB gleichermaßen effektiv funktioniert GB RAM. Deshalb haben wir beschlossen, unser eigenes zu schreiben, das all dies kann. Das haben wir bekommen:

Zusammenfassung des Durchsatzes von drei Kanälen für verschiedene Netzwerktopologien

Visualisierung einiger wichtiger Kennzahlen

Architektur

Wir verwenden Golang als Hauptprogrammiersprache, sowohl auf dem Gerät als auch im Rechenzentrum. Durch die Implementierung von Multitasking und die Möglichkeit, für jeden Dienst eine statisch verknüpfte ausführbare Binärdatei zu erhalten, hat es das Leben erheblich vereinfacht. Dadurch sparen wir erheblich Ressourcen, Methoden und Datenverkehr für die Bereitstellung des Dienstes auf Endgeräten, Entwicklungszeit und Code-Debugging.

Das System ist nach dem klassischen Baukastenprinzip implementiert und enthält mehrere Subsysteme:

1. Metrikregistrierung.
   Jede Metrik wird von einem eigenen Thread bereitgestellt und kanalübergreifend synchronisiert. Wir konnten eine Synchronisationsgenauigkeit von bis zu 10 Nanosekunden erreichen.
2. Speicherung von Metriken
   Wir hatten die Wahl, unseren eigenen Speicher für Zeitreihen zu schreiben oder etwas zu verwenden, das bereits verfügbar war. Die Datenbank wird für retrospektive Daten benötigt, die einer anschließenden Visualisierung unterliegen. Das heißt, sie enthält keine Daten über Verzögerungen im Kanal alle 0.5 Millisekunden oder Fehlerwerte im Transportnetzwerk, sondern es gibt Geschwindigkeiten auf jeder Schnittstelle alle 500 Millisekunden. Neben den hohen Anforderungen an Cross-Plattform und geringem Ressourcenverbrauch ist für uns die Verarbeitungsfähigkeit enorm wichtig. Daten sind dort, wo sie gespeichert werden. Das spart enorme Rechenressourcen. Wir nutzen das Tarantool DBMS in diesem Projekt seit 2016 und sehen bisher keinen Ersatz dafür in Sicht. Flexibel, mit optimalem Ressourcenverbrauch, mehr als ausreichender technischer Support. Tarantool implementiert auch ein GIS-Modul. Natürlich ist es nicht so leistungsfähig wie PostGIS, aber für unsere Aufgaben, einige standortbezogene Metriken (relevant für den Transport) zu speichern, reicht es aus.
3. Visualisierung von Metriken
   Hier ist alles relativ einfach. Wir entnehmen Daten aus dem Lager und zeigen sie entweder in Echtzeit oder im Nachhinein an.
4. Synchronisierung der Daten mit dem zentralen Überwachungssystem.
   Das zentrale Überwachungssystem empfängt Daten von allen Geräten, speichert sie mit einer festgelegten Historie und sendet sie per API an das Überwachungssystem des Kunden. Im Gegensatz zu klassischen Überwachungssystemen, bei denen der „Kopf“ herumläuft und Daten sammelt, haben wir das umgekehrte Schema. Die Geräte selbst senden Daten, wenn eine Verbindung besteht. Dies ist ein sehr wichtiger Punkt, da Sie so Daten vom Gerät für die Zeiträume empfangen können, in denen es nicht verfügbar war, und keine Kanäle und Ressourcen laden können, während das Gerät nicht verfügbar ist. Wir verwenden den Influx-Überwachungsserver als zentrales Überwachungssystem. Im Gegensatz zu seinen Gegenstücken kann es retrospektive Daten importieren (d. h. mit einem Zeitstempel, der sich vom Zeitpunkt des Empfangs der Metriken unterscheidet). Die gesammelten Metriken werden von Grafana visualisiert und mit einer Datei modifiziert. Dieser Standard-Stack wurde auch deshalb ausgewählt, weil er über vorgefertigte API-Integrationen mit nahezu jedem Kundenüberwachungssystem verfügt.
5. Datensynchronisation mit einem zentralen Geräteverwaltungssystem.
   Das Geräteverwaltungssystem implementiert Zero Touch Provisioning (Aktualisierung von Firmware, Konfiguration usw.) und empfängt im Gegensatz zum Überwachungssystem nur Probleme pro Gerät. Dabei handelt es sich um Auslöser für den Betrieb integrierter Hardware-Watchdog-Dienste und aller Kennzahlen lebenserhaltender Systeme: CPU- und SSD-Temperatur, CPU-Auslastung, freier Speicherplatz und SMART-Zustand auf Festplatten. Der Subsystemspeicher basiert ebenfalls auf Tarantool. Dies ermöglicht uns eine erhebliche Geschwindigkeit bei der Aggregation von Zeitreihen über Tausende von Geräten hinweg und löst außerdem das Problem der Datensynchronisierung mit diesen Geräten vollständig. Tarantool verfügt über ein ausgezeichnetes Warteschlangen- und garantiertes Liefersystem. Wir haben diese wichtige Funktion sofort einsatzbereit, großartig!

Netzwerkmanagementsystem

Was weiter

Bisher ist unser schwächstes Glied das zentrale Überwachungssystem. Es ist zu 99.9 % auf einem Standard-Stack implementiert und weist eine Reihe von Nachteilen auf:

1. InfluxDB verliert Daten, wenn die Stromversorgung unterbrochen wird. In der Regel sammelt der Kunde zeitnah alles ein, was von den Geräten kommt und die Datenbank selbst enthält keine Daten, die älter als 5 Minuten sind, aber in Zukunft kann dies mühsam werden.
2. Grafana hat eine Reihe von Problemen mit der Datenaggregation und der Synchronisierung seiner Anzeige. Das häufigste Problem besteht darin, dass die Datenbank eine Zeitreihe mit einem Intervall von 2 Sekunden enthält, die beispielsweise bei 00:00:00 beginnt, und Grafana ab +1 Sekunde mit der Aggregation der Daten beginnt. Als Ergebnis sieht der Benutzer ein tanzendes Diagramm.
3. Zu viel Code für die API-Integration mit Überwachungssystemen von Drittanbietern. Es kann viel kompakter gemacht und natürlich in Go umgeschrieben werden)

Ich denke, Sie alle haben perfekt gesehen, wie Grafana aussieht, und kennen seine Probleme ohne mich, deshalb werde ich den Beitrag nicht mit Bildern überladen.

Abschluss

Ich habe bewusst nicht auf die technischen Details eingegangen, sondern nur den grundsätzlichen Aufbau dieses Systems beschrieben. Um das System technisch vollständig zu beschreiben, ist zunächst ein weiterer Artikel erforderlich. Zweitens wird nicht jeder daran interessiert sein. Schreiben Sie in die Kommentare, welche technischen Details Sie wissen möchten.

Wenn jemand Fragen hat, die über den Rahmen dieses Artikels hinausgehen, können Sie mir unter a.rodin @ qedr.com schreiben

Source: habr.com