End2End Throttling
Mittlerweile sollten die meisten Leser wissen, dass ich mit Rimscout (https://www.rimscout.com) ein Produkt zum Assessment von Netzwerken und Clients am Start habe. Ein kleiner Agent den Clients prüft die Erreichbarkeit von Diensten und meldet dies an ein Backend zur automatischen und manuellen Auswertung. Wer sie aber an einem Standort viele Clients haben, dann sollte die Last durch solche Tests nicht die Umgebung überfordern oder sogar die Ergebnisse verfälschen. Darum geht es auf dieser Seite.
Weitere Informationen zu Rimscout finden Sie hier https://www.rimscout.com
Startpunkt
Ich predige schon lange Zeit, dass ich mit dem klassischen Monitoring mit einer Abfrage aus dem RZ pro Minute nur die generelle Erreichbarkeit eines Service überwacht und auch die Netzwerkauswertung per SNMP nur einen groben Überblick der Netzwerkperformance erlaubt. Um wirklich ein Netzwerk und einen Service zu überwachen, muss der Client, d.h. der Computer des Anwenders die Prüfungen ausführen. Nun wird niemand einen vollwertigen Monitoring-Agent o.ä. auf einem Client installieren. Letztlich muss aber eine Software auf dem Client aus meiner Sicht drei Dinge machen:
- Inventory
Erfassen der relevanten Umgebungsparameter wie Versionen, Subnetz, Standort etc. - Erreichbarkeit
Der Client sollte zudem die Erreichbarkeit der genutzten Dienste regelmäßig und bei einem Netzwerk-Change überwachen, um lokale Probleme schnell zu erkennen - Performance
Und zuletzt geht es darum, die komplette Verbindung vom Client zum Service so zu überwachen, dass auch kurze Aussetzer etc. erkannt werden
Der letzte Punkt bedarf aber einer genaueren Betrachtung:
Wenn ich z.B. einen Client habe, der für ein Assessment eine kontinuierliche engmaschige Verbindungsüberwachung betreibt, ist das erst einmal unkritisch zu sehe.
Überlast
Wenn ich aber nun mehrere Clients an einem Standort habe, dann addieren sich natürlich die Datenmengen und Verbindungen. Hier muss man schon genau drauf schauen, dass die Prüfungen nicht selbst zu einer Überlastung und Verfälschung der Ergebnissen führen.
In der Summe könne da schon viele Verbindungen und Megabit zusammenkommen. Wenn ein Client eine RTP-Audio-Simulation mit 100kbit nutzt, dann sind 50 Clients an einem Standort schon 5 Megabit Dauerlast. Hier muss ich also drosseln, ohne aber die Aussagekraft der Daten zu riskieren.
Weniger testen
Eine Lösung besteht natürlich darin, die Testintensität einfach zu reduzieren. Warum sollte ich 50 Pakete pro Sekunde senden und empfangen, wen genug andere Nachbarn auch den gleichen Test ausführen. Ich kann am Ende die Ergebnisse aller Client am gleichen Standort zusammenfassen und damit den gemeinsamen Weg dieses Standorts zum Cloud-Service genauso gut auf Unterbrechungen oder Latenzzeitprobleme analysieren:
Das Problem dabei ist aber, dass der einzelne Client immer weniger detailliert seine eigene Performance ermittelt. Das Problem kann ja auch auf dem Client selbst vorliegen, z.B. eine lokale Firewall-Software oder das Netzwerkkabel, die defekte Dose oder eine schlechte WLAN-Abdeckung. Ich hatte auch schon Umgebungen, in denen ein einzelne Pakete quasi kein Problem aufgezeigt haben aber erst viele Pakete einen sporadischen Fehler erkennen ließen.
Bursts
Daher kann es auch eine Option sein, den eigentlich Test in der gewohnten Intensität aber mit Pausen laufen zu lassen. Der eigentliche Test sendet dann z.B. viele Pakete aber eben nicht kontinuierlich sondern mit Unterbrechungen.
Mit mehreren Clients gibt es dann aber dennoch genug Messwerte, um eine durchgehende Abdeckung zu erreichen und dennoch auch auf dem Client aussagekräftige Daten zu erhalten. Nur mit wenig Clients könnte es blinde Flecken geben. Hier ist dann abzuwägen, wie stark die Reduzierung der Abfragen in Abhängigkeit der Clientanzahl sinnvoll ist.
Client pausieren
Eine dritte, aber aus meiner Sicht weniger sinnvolle, Option ist das komplette Aussetzen von Clients, wenn es genug andere schon aktive Clients gibt.
Der Vorteil ist natürlich die lückenlose Überwachung durch die aktiven Clients bezüglich der eigenen Verbindungsqualität bis zum Service. Auf der anderen Seite haben Sie so natürlich keinerlei Daten der inaktiven Clients. Wenn diese Anwender über Probleme klagen, müssen sie erst dafür sorgen, dass dieser Client wieder testet.
24h-Client
Wenn Sie die Anbindung von einem Standort mit mehreren Clients unabhängig von den Clients überwachen wollen, sollte ihre Lösung einen Betrieb eines 24h-Node unterstützen, welcher aus dem Throttling ausgenommen wird. Dieser Client kann dann kontinuierlich und ungedrosselt überwachen und damit eine "Baseline" für einen Standort erstellen.
Bei dem Setup können Sie dann auch sehr elegant die Clients der Anwender mit der Baseline vergleichen und haben sogar eine Überwachung in den betriebsarmen Zeiten. Für eine Überwachung ist es natürlich wichtig, auch in der Nacht, am Wochenende oder zu Feiertagen nicht ohne Daten zu sein. Wobei bei einer guten Software in dem Fall der einzige aktive Client auch keine Drosselung erfahren sollte. Dennoch ist eine vergleichbare lückenlose Baseline immer ratsam.
End2End-Skripte
Aktuell hat keines meiner End2End-Skripte eine solche Logik eingebaut. Die Powershell-Skripte nutze ich nur auf ausgewählten Systemen zur Analyse von alleinstehenden Problemen und nicht als verteilte Installation auf vielen Clients. Die End2End-Skripte habe auch keine zentrale Datenhaltung oder Konsolidierung. Ausgewählte Skripte können natürlich die Ergebnisse an PRTG oder andere Tools senden aber dies ist keine Plattform mit zentraler Konfiguration, abgesicherter verschlüsselter und authentifizierter Kommunikation zwischen dem Code auf dem Client und einer Managementplattform im Backend.
Weitere Informationen zu Rimscout finden Sie hier https://www.rimscout.com
