Ein weiteres Überwachungssystem

16 Modems, 4 Mobilfunkanbieter = Ausgangsgeschwindigkeit 933,45 Mbit/s

Einführung

Hallo! Dies ist ein Artikel darüber, wie wir ein neues Überwachungssystem für uns selbst entwickelt haben. Es unterscheidet sich von bestehenden Systemen durch die Möglichkeit, hochfrequente synchronisierte Metriken zu erfassen, und hat einen sehr geringen Ressourcenverbrauch. Die Abfragefrequenz kann bis zu 0,1 Millisekunden betragen, mit einer Synchronisationsgenauigkeit von 10 Nanosekunden zwischen den Metriken. Alle Binärdateien nehmen 6 Megabyte ein.

Über das Projekt

Wir haben ein ziemlich spezielles Produkt. Wir bieten eine umfassende Lösung zur Summierung der Bandbreite und Fehlertoleranz von Datenübertragungskanälen an. Das ist, wenn es mehrere Kanäle gibt, zum Beispiel Anbieter1 (40 Mbit/s) + Anbieter2 (30 Mbit/s) + etwas anderes (5 Mbit/s), ergibt sich ein stabiler und schneller Kanal, dessen Geschwindigkeit ungefähr so sein wird: (40+30+5)x0,92=75×0,92=69 Mbit/s.

Solche Lösungen sind gefragt, wo die Kapazität eines einzelnen Kanals nicht ausreicht. Beispielsweise im Transportwesen, bei Videoüberwachungssystemen und Echtzeit-Video-Streaming, Live-Übertragungen von Fernsehemissionen, sowie an ländlichen Standorten, wo nur Anbieter der großen Vier vertreten sind und die Geschwindigkeit eines Modems/Kanals nicht ausreicht.
Für jede dieser Richtungen bieten wir eine eigene Reihe von Geräten an, jedoch ist der Softwareteil nahezu identisch und ein qualitatives Überwachungssystem — eines der Hauptmodule, ohne dessen richtige Umsetzung das Produkt nicht möglich wäre.

In den letzten Jahren ist es uns gelungen, ein mehrschichtiges, schnelles, plattformübergreifendes und leichtgewichtiges Überwachungssystem zu entwickeln. Das möchten wir mit der geschätzten Gemeinschaft teilen.

Problemstellung

Das Überwachungssystem ermöglicht das Erfassen von Metriken aus zwei grundlegend unterschiedlichen Klassen: Echtzeitmetriken und alle anderen. Die Anforderungen an das Überwachungssystem waren die folgenden:

1. Hochfrequente, synchrone Erfassung von Echtzeitmetriken und deren Übertragung an das Kommunikationsmanagementsystem ohne Verzögerungen.
   Eine hohe Frequenz und die Synchronisation verschiedener Metriken sind nicht nur wichtig, sie sind 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 von nur einer Millisekunde zwischen den anderen Metriken zu einer Geschwindigkeitsverschlechterung des resultierenden Kanals um etwa 5 %. Wenn wir eine Synchronisationsfehler von 1 Millisekunde in vier Kanälen haben, kann die Geschwindigkeitseinbuße leicht auf bis zu 30 % fallen. Zudem ändert sich die Entropie in den Kanälen sehr schnell, sodass wir, wenn wir sie weniger oft als einmal alle 0,5 Millisekunden messen, bei schnellen Kanälen mit geringer Verzögerung eine erhebliche Geschwindigkeitseinbuße feststellen werden. Natürlich ist eine solche Präzision nicht für alle Metriken und nicht unter allen Bedingungen erforderlich. Wenn die Verzögerung im Kanal 500 Millisekunden beträgt und wir auch mit solchen arbeiten, wird ein Fehler von 1 Millisekunde kaum bemerkbar sein. Auch für Metriken von Versorgungssystemen reicht uns eine Abfragerate und Synchronisation von 2 Sekunden aus, jedoch sollte das Überwachungssystem in der Lage sein, mit extrem hohen Abfrageraten und äußerst präziser Synchronisation der Metriken zu arbeiten.
2. Minimale Ressourcenanforderungen und ein einheitlicher Software-Stack.
   Das Endgerät kann sowohl ein leistungsstarkes Bordkomplexsystem sein, das die Verkehrssituation analysiert oder biometrische Daten von Personen erfasst, als auch ein Hand-PC, den ein Spezialkräftekämpfer unter der kugelsicheren Weste trägt, um in Verbindung mit schlechter Netzwerkabdeckung Echtzeitvideos zu übertragen. Trotz dieser vielfältigen Architekturen und Rechenleistungen möchten wir dennoch einen einheitlichen Software-Stack verwenden.
3. Übergreifende Architektur
   Die Metriken sollten direkt auf dem Endgerät gesammelt und aggregiert werden, mit einem lokalen Speichersystem und Echtzeit- sowie retrospektiver Visualisierung. Bei einer bestehenden Verbindung sollten die Daten an das zentrale Überwachungssystem gesendet werden. Wenn keine Verbindung besteht, sollte die Sendewarteschlange angesammelt werden, ohne den Arbeitsspeicher zu beanspruchen.
4. API für die Integration in das Überwachungssystem des Kunden, denn niemand benötigt viele Überwachungssysteme. Der Kunde sollte Daten von beliebigen Geräten und Netzwerken in einer einheitlichen Überwachung sammeln.

Was entstanden ist

Um den bereits umfangreichen Bericht nicht weiter zu belasten, werde ich keine Beispiele und Messungen aller Überwachungssysteme anführen. Das würde eine eigene Artikelreihe erfordern. Ich sage einfach, dass wir kein Überwachungssystem finden konnten, das in der Lage ist, zwei Metriken gleichzeitig mit einer Abweichung von weniger als 1 Millisekunde zu erfassen und das sowohl auf ARM-Architektur mit 64 MB RAM als auch auf x86_64-Architektur mit 32 GB RAM gleichermaßen effizient arbeitet. Daher beschlossen wir, unser eigenes zu entwickeln, das all diese Funktionen bietet. Hier ist das Ergebnis:

Summierung der Bandbreite von drei Kanälen für unterschiedliche Netzwerk-Topologien

Visualisierung einiger wichtiger Metriken

Architektur von

Als Hauptprogrammiersprache verwenden wir sowohl auf den Geräten als auch im Rechenzentrum Golang. Es hat unser Leben erheblich erleichtert, da es Multithreading ermöglicht und die Erstellung einer statisch verlinkten ausführbaren Binärdatei für jeden Dienst erlaubt. Dadurch sparen wir erheblich an Ressourcen, Methoden und dem Datenaufwand für die Bereitstellung von Diensten auf Endgeräten sowie an Entwicklungs- und Debuggingzeiten.

Das System basiert auf dem klassischen modularen Prinzip und umfasst mehrere Teilsysteme:

1. Registrierung von Metriken.
   Jede Metrik wird von einem eigenen Thread bearbeitet und über Kanäle synchronisiert. Es ist uns gelungen, eine Synchronisationsgenauigkeit von bis zu 10 Nanosekunden zu erreichen.
2. Speicherung von Metriken
   Wir standen vor der Wahl, ob wir unser eigenes Speicher für Zeitreihen schreiben oder etwas Vorhandenes verwenden. Die Datenbank ist für retrospektive Daten notwendig, die später visualisiert werden sollen. Das bedeutet, dass sie keine Daten über Latenzen im Kanal alle 0,5 Millisekunden oder Fehleranzeigen im Transportnetz enthält, sondern die Geschwindigkeit an jedem Interface alle 500 Millisekunden. Neben den hohen Anforderungen an die Plattformunabhängigkeit und den geringen Ressourcenverbrauch ist es für uns extrem wichtig, die Daten dort zu verarbeiten, wo sie gespeichert sind. Das spart enormen Rechenaufwand. Seit 2016 nutzen wir die Datenbank Tarantool in diesem Projekt und bisher sehen wir keine Alternative dazu. Sie ist flexibel, mit optimalem Ressourcenverbrauch und bietet mehr als angemessenen technischen Support. Zudem bietet Tarantool ein GIS-Modul. Es ist zwar nicht so leistungsstark wie PostGIS, reicht aber für unsere Anforderungen zur Speicherung bestimmter, standortbezogener Metriken (insbesondere im Verkehr) aus.
3. Visualisierung von Metriken
   Hier ist alles relativ einfach. Wir holen die Daten aus dem Speicher und zeigen sie entweder in Echtzeit oder retrospektiv an.
4. Datenabgleich mit dem zentralen Überwachungssystem.
   Das zentrale Überwachungssystem empfängt Daten von allen Geräten, speichert sie mit einer festgelegten Rückschau und gibt sie über die API an das Überwachungssystem des Kunden weiter. Im Gegensatz zu klassischen Überwachungssystemen, bei denen die "Zentrale" die Daten abruft, praktizieren wir ein umgekehrtes Modell. Die Geräte senden die Daten selbst, wenn eine Verbindung besteht. Dies ist ein sehr wichtiger Aspekt, da es ermöglicht, Daten von Geräten zu erhalten, selbst wenn diese zeitweise nicht verfügbar waren, ohne die Kanäle und Ressourcen zu belasten, während das Gerät nicht erreichbar ist. Als zentrales Überwachungssystem nutzen wir den Influx-Monitoring-Server. Im Gegensatz zu ähnlichen Lösungen kann er retrospektive Daten importieren (d.h. mit einem Zeitstempel, der von dem Zeitpunkt der Metrikempfang abweicht). Die gesammelten Metriken werden von dem optimierten Grafana visualisiert. Dieses Standard-Stack wurde auch gewählt, weil es nahezu für jede Überwachungslösung des Kunden fertige API-Integrationen bietet.
5. Datenabgleich mit dem zentralen Gerätemanagementsystem.
   Das Gerätemanagementsystem implementiert Zero Touch Provisioning (Firmware-Updates, Konfigurationen usw.) und im Gegensatz zu einem Überwachungssystem erhält es ausschließlich Probleme von Geräten. Dies sind die Trigger für die Funktion der eingebetteten Hardware-Wachdienste und alle Metriken der Betriebssysteme: Temperatur von CPU und SSD, CPU-Auslastung, freier Speicherplatz und S.M.A.R.T-Gesundheit der Laufwerke. Der Speicher der Subsysteme basiert ebenfalls auf Tarantool. Dies ermöglicht uns eine signifikante Geschwindigkeit bei der Aggregation von Zeitreihen über Tausende von Geräten und löst das Problem der Datensynchronisation mit diesen Geräten vollständig. Tarantool verfügt über ein hervorragendes Queuing-System und garantierte Zustellung. Diese wichtige Funktion haben wir standardmäßig integriert, wunderbar!

Netzwerkmanagementsystem

Was kommt als Nächstes

Momentan ist das schwächste Glied unser zentrales Überwachungssystem. Es basiert zu 99,9 % auf einem Standard-Stack und hat eine Reihe von Mängeln:

1. InfluxDB verliert Daten bei Stromausfällen. In der Regel holt der Kunde alles, was von den Geräten kommt, schnell ab, und in der Datenbank befinden sich keine Daten, die älter als 5 Minuten sind. In Zukunft könnte das jedoch ein Problem darstellen.
2. Grafana hat einige Probleme mit der Datenaggregation und der Synchronität der Anzeige. Das häufigste Problem tritt auf, wenn in der Datenbank eine Zeitreihe mit einem Intervall von 2 Sekunden gespeichert wird, beginnend, sagen wir, um 00:00:00, und Grafana beginnt, die Daten mit einer Aggregation ab +1 Sekunde anzuzeigen. Infolgedessen sieht der Benutzer ein springendes Diagramm.
3. Es gibt eine übermäßige Menge an Code für die API-Integration mit externen Monitoring-Systemen. Das kann viel kompakter gestaltet werden, und man könnte es sicherlich auf Go umschreiben.)

Ich nehme an, dass Sie alle bereits gesehen haben, wie Grafana aussieht, und die Probleme kennen, daher möchte ich den Beitrag nicht mit Bildern überladen.

Fazit

Ich habe absichtlich keine technischen Details beschrieben, sondern lediglich das grundlegende Design dieses Systems dargestellt. Erstens würde es eine weitere Artikel erfordern, um das System technisch vollständig zu beschreiben. Zweitens wird das nicht jeden interessieren. Schreiben Sie in die Kommentare, welche technischen Details Sie gerne erfahren würden.

Wenn jemand Fragen hat, die über diesen Artikel hinausgehen, können Sie mir unter a.rodin @ qedr.com schreiben.

Quelle: habr.com