Geschwindigkeitssummierung auf 16 Modems von 4 Mobilfunkbetreibern. Ausgehende Geschwindigkeit in einem Stream - 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 den bestehenden durch die Möglichkeit einer hochfrequenten synchronen Erfassung von Metriken und einen sehr geringen Ressourcenverbrauch. Die Abfragefrequenz kann 0,1 Millisekunden mit einer Synchronisationsgenauigkeit zwischen Metriken von 10 Nanosekunden erreichen. Alle Binärdateien belegen 6 Megabyte.
Über das Projekt
Wir haben ein ziemlich spezifisches Produkt. Wir erstellen eine umfassende Lösung, um den Durchsatz und die Fehlertoleranz von Datenkanälen zusammenzufassen. Wenn mehrere Kanäle vorhanden sind, z. B. Operator1 (40 Mbit / s) + Operator2 (30 Mbit / s) + Etwas anderes (5 Mbit / s), ist das Ergebnis ein stabiler und schneller Kanal, dessen Geschwindigkeit ungefähr so lautet: (40+) 30 + 5) x 0,92 = 75 x 0,92 = 69 Mbit / s.
Solche Lösungen sind gefragt, wenn die Kapazität eines Kanals nicht ausreicht. Zum Beispiel Transport-, Echtzeit-Videoüberwachungs- und Video-Streaming-Systeme, Live-Fernseh- und Radiosendungen, Objekte außerhalb der Stadt, bei denen Telekommunikationsbetreiber nur Vertreter der Big Four haben, und die Geschwindigkeit auf einem Modem / Kanal nicht ausreichen.
Für jeden dieser Bereiche stellen wir eine eigene Gerätelinie her. Der Softwareteil ist jedoch nahezu identisch, und ein qualitativ hochwertiges Überwachungssystem ist eines der Hauptmodule, ohne dessen korrekte Implementierung das Produkt nicht möglich wäre.
Seit mehreren Jahren ist es uns gelungen, ein mehrstufiges schnelles, plattformübergreifendes und leichtes Überwachungssystem zu schaffen. Was wir mit einer seriösen Community teilen möchten.
Erklärung des Problems
Das Überwachungssystem bietet Metriken für zwei grundlegend unterschiedliche Klassen: Echtzeitmetriken und alle anderen. Das Überwachungssystem hatte folgende Anforderungen:
- Hochfrequenzsynchrone Erfassung von Echtzeitmetriken und deren unverzügliche Übertragung an das Kommunikationssteuerungssystem.
Die hohe Frequenz und Synchronisation verschiedener Metriken ist nicht nur wichtig, sondern auch für die Analyse der Entropie von Datenübertragungskanälen von entscheidender Bedeutung. Wenn in einem Datenkanal eine durchschnittliche Verzögerung von 30 Millisekunden auftritt, führt ein Fehler bei der Synchronisation zwischen den verbleibenden Metriken um nur eine Millisekunde zu einer Verschlechterung der Geschwindigkeit des resultierenden Kanals um etwa 5%. Wenn wir bei der Synchronisation für 1 Millisekunde in 4 Kanälen einen Fehler machen, kann die Geschwindigkeitsverschlechterung leicht auf 30% fallen. Darüber hinaus ändert sich die Entropie in den Kanälen sehr schnell. Wenn wir sie also weniger als einmal alle 0,5 Millisekunden messen, erhalten wir auf schnellen Kanälen mit einer kleinen Verzögerung eine Verschlechterung der Geschwindigkeit. 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, wird der Fehler von 1 Millisekunde kaum spürbar sein. Für die Metriken von Lebenserhaltungssystemen reichen die Abruf- und Synchronisationsfrequenzen von 2 Sekunden aus. Das Überwachungssystem selbst sollte jedoch in der Lage sein, mit ultrahohen Abruffrequenzen und ultrapräziser metrischer Synchronisation zu arbeiten. - Minimaler Ressourcenverbrauch und ein einziger Stapel.
Das endgültige Gerät kann ein leistungsstarker Bordkomplex sein, der die Situation auf der Straße analysieren oder die Biometrie von Personen aufzeichnen kann, oder ein handflächengroßer Computer mit einer Platine, der von einem Soldaten der Spezialeinheit unter Körperschutz getragen wird, um Echtzeitvideos unter schlechten Kommunikationsbedingungen zu übertragen. Trotz dieser Vielfalt an Architekturen und Rechenleistung möchten wir den gleichen Software-Stack haben. - Regenschirmarchitektur
Metriken sollten auf dem Endgerät gesammelt und aggregiert werden, über ein lokales Speichersystem verfügen und in Echtzeit und nachträglich visualisiert werden. Wenn Kommunikation verfügbar ist, übertragen Sie Daten an das zentrale Überwachungssystem. Wenn keine Verbindung besteht, sollte sich die sendende Warteschlange ansammeln und keinen RAM verbrauchen. - Eine API zur Integration in das Überwachungssystem eines Kunden, da niemand viele Überwachungssysteme benötigt. Der Kunde muss Daten von Geräten und Netzwerken in einer einzigen Überwachung erfassen.
Was ist passiert?
Um das bereits beeindruckende Longrid zu laden, werde ich nicht Beispiele und Messungen aller Überwachungssysteme geben. Dies wird einen weiteren Artikel ziehen. Ich möchte nur sagen, dass wir kein Überwachungssystem finden konnten, das zwei Metriken gleichzeitig mit einem Fehler von weniger als 1 Millisekunde erfassen kann und das sowohl auf einer ARM-Architektur mit 64 MB RAM als auch auf einer x86_64-Architektur mit 32 GB RAM gleichermaßen effizient funktioniert. Deshalb haben wir uns entschlossen, unsere eigenen zu schreiben, was genau das kann. Folgendes haben wir:
Summieren des Durchsatzes von drei Kanälen für verschiedene Netzwerktopologien
Visualisierung einiger Schlüsselmetriken
Architektur
Als Hauptprogrammiersprache sowohl auf dem Gerät als auch im Rechenzentrum verwenden wir Golang. Er hat sein Leben durch die Implementierung von Multitasking und die Möglichkeit, eine statisch verknüpfte ausführbare Binärdatei für jeden Dienst zu erhalten, erheblich vereinfacht. Infolgedessen sparen wir erheblich Ressourcen, Methoden und Datenverkehr für die Bereitstellung von Diensten auf Endgeräten, Entwicklungszeit und Code-Debugging.
Das System ist nach dem klassischen modularen Prinzip implementiert und enthält mehrere Subsysteme:
- Registrierung von Metriken.
Jede Metrik wird von einem eigenen Stream bedient und über Kanäle synchronisiert. Es ist uns gelungen, eine Synchronisationsgenauigkeit von bis zu 10 Nanosekunden zu erreichen. - Metrischer Speicher
Wir haben uns dafür entschieden, unser Repository für Zeitreihen zu schreiben oder eines der verfügbaren zu verwenden. Die Datenbank wird für retrospektive Daten benötigt, die anschließend visualisiert werden müssen. Das heißt, sie enthält keine Daten zu Verzögerungen im Kanal alle 0,5 Millisekunden oder Fehleranzeigen im Transportnetz, aber alle 500 Millisekunden gibt es eine Geschwindigkeit für jede Schnittstelle. Neben den hohen Anforderungen an plattformübergreifenden und geringen Ressourcenverbrauch ist es für uns äußerst wichtig, verarbeiten zu können. Daten an dem Ort, an dem sie gespeichert sind. Dies spart enorm Rechenressourcen. Seit 2016 verwenden wir Tarantool DBMS in diesem Projekt und bis jetzt sehen wir keinen Ersatz dafür am Horizont. Flexibel, bei optimalem Ressourcenverbrauch, mehr als angemessener technischer Support. Tarantool hat auch ein GIS-Modul. Es ist sicherlich nicht so leistungsfähig wie PostGIS, aber es reicht für unsere Aufgaben aus, einige Metriken zu speichern, die an einen Ort gebunden sind (relevant für den Transport). - Metrik-Visualisierung
Hier ist alles relativ einfach. Wir nehmen die Daten aus dem Speicher und zeigen sie entweder in Echtzeit oder nachträglich an. - Datensynchronisation mit einem zentralen Überwachungssystem.
Das zentrale Überwachungssystem empfängt Daten von allen Geräten, speichert sie mit einer bestimmten Retrospektive und sendet sie über die API an das Überwachungssystem des Kunden. Im Gegensatz zu klassischen Überwachungssystemen, bei denen der "Kopf" geht und Daten sammelt, haben wir das entgegengesetzte Schema. Geräte selbst senden Daten, wenn eine Verbindung besteht. Dies ist ein sehr wichtiger Punkt, da Sie damit Daten vom Gerät für die Zeiträume empfangen können, in denen sie nicht verfügbar waren, und keine Kanäle und Ressourcen laden können, während das Gerät nicht verfügbar ist. Als zentrales Überwachungssystem verwenden wir den Influx-Überwachungsserver. Im Gegensatz zu Analoga können retrospektive Daten importiert werden (dh mit einem Zeitstempel, der sich vom Zeitpunkt des Empfangs der Metrik unterscheidet). Die gesammelten Metriken werden durch eine modifizierte Grafana-Datei visualisiert. Dieser Standardstapel wurde auch ausgewählt, weil er über vorgefertigte Integrations-APIs für nahezu jedes Kundenüberwachungssystem verfügt. - Datensynchronisation mit einem zentralen Geräteverwaltungssystem.
Das Geräteverwaltungssystem implementiert Zero Touch Provisioning (Aktualisieren von Firmware, Konfiguration usw.) und empfängt im Gegensatz zum Überwachungssystem nur Geräteprobleme. Dies sind die Auslöser der integrierten Hardware-Watchdog-Dienste und aller Metriken von Lebenserhaltungssystemen: CPU- und SSD-Temperatur, CPU-Auslastung, freier Speicherplatz und SMART-Zustand auf Datenträgern. Der Subsystemspeicher basiert ebenfalls auf Tarantool. Dies gibt uns eine erhebliche Geschwindigkeit bei der Aggregation von Zeitreihen über Tausende von Geräten und löst auch das Problem der Datensynchronisation mit diesen Geräten vollständig. Tarantool verfügt über ein ausgezeichnetes Warteschlangensystem und eine garantierte Lieferung. Wir haben dieses wichtige Feature sofort einsatzbereit, großartig!
Netzwerkmanagementsystem
Was weiter
Das bisher schwächste Glied in unserem Land ist das zentrale Überwachungssystem. Es ist zu 99,9% auf dem Standardstapel implementiert und hat eine Reihe von Nachteilen:
- InfluxDB verliert Daten, wenn die Stromversorgung ausgeschaltet wird. In der Regel nimmt der Kunde umgehend alles, was von den Geräten kommt, und es befinden sich keine Daten in der Datenbank, die älter als 5 Minuten sind. In Zukunft kann dies jedoch schmerzhaft sein.
- Grafana hat eine Reihe von Problemen mit der Datenaggregation und Synchronisation ihrer Anzeige. Das häufigste Problem ist, wenn die Datenbank eine Zeitreihe mit einem Intervall von 2 Sekunden ab 00:00:00 enthält und Grafana Aggregationsdaten ab +1 Sekunde anzeigt. Als Ergebnis sieht der Benutzer eine Tanzkarte.
- Überschüssiger Code für die API-Integration in Überwachungssysteme von Drittanbietern. Kann viel kompakter gemacht werden und natürlich in Go umschreiben)
Ich nehme an, Sie alle haben perfekt gesehen, wie Grafana aussieht, und ohne mich kennen Sie ihre Probleme, deshalb werde ich den Beitrag nicht mit Bildern überladen.
Fazit
Ich habe bewusst keine technischen Details beschrieben, sondern nur das unterstützende Design dieses Systems. Erstens ist ein weiterer Artikel erforderlich, um das System technisch vollständig zu beschreiben. Zweitens wird nicht jeder interessiert sein. Schreiben Sie in die Kommentare, welche technischen Details Sie wissen möchten.
Wenn jemand Fragen außerhalb dieses Artikels hat, kann ich an a.rodin @ qedr.com schreiben