Ein weiteres Überwachungssystem

16 Modems, 4 Mobilfunkanbieter = Übertragungsgeschwindigkeit 933,45 Mbit/s

Einführung

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

Über das Projekt

Wir haben ein ziemlich spezielles Produkt. Wir bieten eine umfassende Lösung zur Zusammenfassung von Bandbreite und Redundanz in Datenübertragungskanälen an. Das bedeutet, dass es mehrere Kanäle gibt, beispielsweise Anbieter1 (40 Mbit/s) + Anbieter2 (30 Mbit/s) + Noch etwas (5 Mbit/s), und am Ende entsteht ein stabiler und schneller Kanal mit einer Geschwindigkeit von etwa: (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. Beispielsweise im Transportwesen, bei Videoüberwachungssystemen und Streaming in Echtzeit, bei der Übertragung von Live-TV- und Radiosendungen sowie in ländlichen Gebieten, wo nur die Vertreter der großen vier Anbieter vorhanden sind und die Geschwindigkeit eines Modems/Kanals unzureichend ist.
Für jeden dieser Bereiche haben wir eine eigene Produktlinie entwickelt, jedoch ist der Softwareteil fast identisch und ein qualitativ hochwertiges Überwachungssystem ist eines der Hauptmodule, ohne dessen richtige Implementierung das Produkt unmöglich wäre.

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

Aufgabenstellung

Das Überwachungssystem ermöglicht die Erfassung von Metriken zweier grundsätzlich verschiedener Klassen: Echtzeitmetriken und alle anderen. An das Überwachungssystem wurden lediglich folgende Anforderungen gestellt:

1. Hochfrequente synchrone Erfassung von Echtzeitmetriken und deren Übertragung an das Kommunikationsverwaltungssystem ohne Verzögerungen.
   Eine hohe Frequenz und Synchronisation unterschiedlicher Metriken sind nicht nur wichtig, sie sind lebensnotwendig für die Analyse der Entropie von Datenübertragungskanälen. Wenn die durchschnittliche Verzögerung in einem Datenübertragungskanal 30 Millisekunden beträgt, wird ein Synchronisationsfehler zwischen den anderen Metriken von nur einer Millisekunde zu einer Geschwindigkeitsverschlechterung des resultierenden Kanals von etwa 5 % führen. Wenn wir in der Synchronisation um 1 Millisekunde in 4 Kanälen fehlerhaft sind, kann die Geschwindigkeitsverschlechterung leicht auf 30 % sinken. Darüber hinaus verändert sich die Entropie in den Kanälen sehr schnell, daher erhalten wir bei einer Messung seltener als einmal alle 0,5 Millisekunden in schnellen Kanälen mit geringen Verzögerungen eine hohe Geschwindigkeitsverschlechterung. Natürlich ist eine solche Genauigkeit nicht für alle Metriken und Bedingungen erforderlich. Wenn die Verzögerung im Kanal 500 Millisekunden beträgt und wir auch damit arbeiten, wird ein Fehler von 1 Millisekunde kaum bemerkbar sein. Auch für die Metriken der Systeme zur Lebenssicherung reicht eine Abfrage- und Synchronisationsfrequenz von 2 Sekunden aus, jedoch muss das Monitoringsystem selbst in der Lage sein, mit extrem hohen Abfragefrequenzen und extrem genauer Synchronisation der Metriken zu arbeiten.
2. Minimaler Ressourcenverbrauch und ein einheitlicher Stack.
   Das Endgerät kann sowohl ein leistungsstarkes Bord-Komplexsystem sein, das die Situation auf der Straße analysieren oder biometrische Daten von Personen erfassen kann, als auch ein Einplatinencomputer in Handgröße, den ein Spezialeinsatzkämpfer unter einer kugelsicheren Weste trägt, um Videos in Echtzeit unter schlechten Verbindungsbedingungen zu übertragen. Trotz dieser Vielzahl von Architekturen und Rechenleistungen würden wir gerne einen einheitlichen Software-Stack haben.
3. Übergreifende Architektur
   Metriken müssen am Endgerät gesammelt und aggregiert, eine lokale Speicherung und eine Visualisierung in Echtzeit sowie retrospektiv haben. Im Falle einer Verbindung sollten die Daten an das zentrale Monitoring-System übertragen werden. Wenn keine Verbindung besteht, sollte die Warteschlange für den Versand aufgebaut werden und keinen Arbeitsspeicher verbrauchen.
4. API zur Integration in das Monitoring-System des Kunden, denn niemand braucht viele Monitoring-Systeme. Der Kunde sollte Daten von beliebigen Geräten und Netzwerken in einem einheitlichen Monitoring sammeln.

Was ist herausgekommen?

Um den bereits umfangreichen Longread nicht weiter zu belasten, werde ich keine Beispiele und Messungen aller Überwachungssysteme anführen. Das würde einen weiteren Artikel in Anspruch nehmen. Ich sage einfach, dass es uns nicht gelungen ist, ein Überwachungssystem zu finden, 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 gleich effektiv funktioniert. Daher haben wir uns entschieden, unser eigenes zu schreiben, das das alles kann. Das ist das Ergebnis:

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

Visualisierung einiger wichtiger Metriken

Architektur

Als Hauptprogrammiersprache verwenden wir sowohl auf dem Gerät als auch im Rechenzentrum Golang. Dies hat das Leben durch die Implementierung von Multithreading erheblich erleichtert und ermöglicht es, für jeden Dienst eine statisch verlinkte ausführbare Binärdatei zu erhalten. Dadurch sparen wir erheblich in Bezug auf Ressourcen, Methoden und den Traffic beim Deployment des Dienstes auf die Endgeräte sowie bei der Entwicklungs- und Debuggerzeit.

Das System ist nach dem klassischen modularen Prinzip aufgebaut und enthält mehrere Teilsysteme:

1. Registrierung von Metriken.
   Jede Metrik wird von einem eigenen Thread verarbeitet und über Kanäle synchronisiert. Es ist uns gelungen, eine Synchronisationsgenauigkeit von bis zu 10 Nanosekunden zu erreichen.
2. Speicherung von Metriken
   Wir haben zwischen der Entscheidung, unser eigenes Speichersystem für Zeitreihen zu schreiben, oder etwas Vorhandenes zu verwenden, gewählt. Die Datenbank ist für retrospektive Daten erforderlich, die anschließender Visualisierung unterliegen. Das heißt, sie enthält keine Daten über Verzögerungen im Kanal alle 0,5 Millisekunden oder Fehlermeldungen im Transportnetz, sondern die Geschwindigkeit an jedem Schnittstelle alle 500 Millisekunden. Neben den hohen Anforderungen an die Plattformunabhängigkeit und den geringen Ressourcenverbrauch ist es für uns von entscheidender Bedeutung, die Daten dort zu verarbeiten, wo sie gespeichert sind. Das spart enorm Rechenressourcen. Seit 2016 nutzen wir die Datenbank Tarantool in diesem Projekt und sehen zurzeit keinen Ersatz dafür in Sicht. Flexibel, mit optimalem Ressourcenverbrauch und mehr als angemessener technischen Unterstützung. Auch ein GIS-Modul ist in Tarantool implementiert. Es ist zwar nicht so leistungsstark wie PostGIS, reicht aber für unsere Bedürfnisse zur Speicherung einiger, standortbezogener Metriken aus (aktuell im Transportbereich).
3. Visualisierung von Metriken
   Hier ist alles relativ einfach. Wir nehmen die Daten aus dem Speicher und zeigen sie entweder in Echtzeit oder retrospektiv an.
4. Synchronisierung der Daten mit dem zentralen Überwachungssystem.
   Das zentrale Überwachungssystem empfängt die Daten von allen Geräten, speichert sie mit der festgelegten Retrospektive und gibt sie über eine API an das Überwachungssystem des Kunden weiter. Im Gegensatz zu klassischen Überwachungssystemen, bei denen die 'Kopf' Einheit umhergeht und Daten sammelt – haben wir ein umgekehrtes Schema. Die Geräte senden die Daten selbst, wenn eine Verbindung besteht. Dies ist ein sehr wichtiger Punkt, da es ermöglicht, die Daten von einem Gerät in den Zeiträumen zu erhalten, in denen es nicht verfügbar war, und die Kanäle und Ressourcen nicht zu belasten, während das Gerät nicht verfügbar ist. Als zentrales Überwachungssystem verwenden wir den Influx Monitoring Server. Im Gegensatz zu Alternativen kann es retrospektive Daten importieren (d.h. mit einem Zeitstempel, der von dem Zeitpunkt der Datenerfassung abweicht). Die gesammelten Metriken werden mit dem nachbearbeiteten Grafana visualisiert. Dieser Standard-Stack wurde auch ausgewählt, weil er fertige API-Integrationen für praktisch jedes Überwachungssystem des Kunden bietet.
5. Synchronisierung der Daten mit dem zentralen Gerätemanagementsystem.
   Das Gerätemanagement-System implementiert Zero Touch Provisioning (Firmware-Updates, Konfigurationen usw.) und erhält im Gegensatz zum Überwachungssystem nur Geräteprobleme. Dies sind Trigger für die Funktionalität der integrierten Hardware-Überwachungsdienste sowie alle Metriken der Lebenshaltungssysteme: CPU-Temperatur und SSD, CPU-Auslastung, freier Speicherplatz und S.M.A.R.T.-Gesundheit der Festplatten. Der Speicher der Subsysteme basiert ebenfalls auf Tarantool. Dies ermöglicht uns eine signifikante Geschwindigkeit bei der Aggregation von Zeitreihen über tausende Geräte und löst vollständig das Problem der Datensynchronisation mit diesen Geräten. Tarantool verfügt über ein ausgezeichnetes Queue- und garantierte Liefer-System. Diese wichtige Funktion haben wir direkt „out of the box“ erhalten, hervorragend!

Netzwerkmanagement-System

Was kommt als nächstes

Derzeit ist unser schwächstes Glied das zentrale Überwachungssystem. Es basiert zu 99,9% auf einem Standard-Stack und hat eine Reihe von Nachteilen:

1. InfluxDB verliert Daten bei Stromausfällen. In der Regel holt der Auftraggeber alles, was von den Geräten kommt, schnell ab und in der Datenbank sind keine Daten älter als 5 Minuten vorhanden, dies könnte jedoch in Zukunft problematisch werden.
2. Grafana hat eine Reihe von Problemen bei der Datenaggregation und der Synchronität ihrer Anzeige. Das häufigste Problem besteht darin, dass in der Datenbank eine Zeitreihe mit einem Intervall von 2 Sekunden vorliegt, beginnend sagen wir um 00:00:00, während Grafana beginnt, Daten ab +1 Sekunde anzuzeigen. Infolgedessen sieht der Benutzer ein „springendes“ Diagramm.
3. Übermäßiger Code für die API-Integration mit externen Überwachungssystemen. Es könnte viel kompakter gestaltet werden, und natürlich könnte es auf Go umgeschrieben werden!)

Ich nehme an, ihr habt alle gesehen, wie Grafana aussieht, und kennt deren Probleme, daher werde ich den Beitrag nicht mit Bildern überladen.

Fazit

Ich habe bewusst auf technische Details verzichtet und nur das zugrundeliegende Design dieses Systems beschrieben. Erstens, um das System technisch vollständig zu beschreiben, wäre ein weiterer Artikel erforderlich. Zweitens, es wird wahrscheinlich nicht für alle von Interesse sein. Schreibt in die Kommentare, welche technischen Details ihr wissen möchtet.

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

Quelle: habr.com