Grundlastmessung mit SNMP und HTTP

Beim Network Assessment gibt es neben der Planung, Dimensionierung und Simulation auch den Bedarf der Messung. Die Überwachung der "Cloud Performance" ist sogar eine Komponente, die idealerweise sehr früh ansetzen und während der Einführung und auch später im Regelbetrieb weiter geführt wird. Die Werkzeuge und Möglichkeiten sind dazu natürlich vielfältig. Um den "Sinn" und die Aussagekraft etwas zu verdeutlichen habe ich eine Messung hier für Sie aufgeschrieben.

Was wird gemessen?

Das Setup besteht aus einem LAN mit einer 20MBit Internet-Anbindung. Die Verbindung wird über eine Firewall und Proxy-Server hergestellt.

Ich nutze in dieser Umgebung das Programm PRTG zur Datenerfassung. PRTG liest per SNMP das WAN-Interface der Firewall (eth1) um alle Minute die aktuelle Auslastung Mbit/Sec zu ermitteln. Parallel läuft intern ein End2End-HTTP-Sensor, der alle Sekunde die Exchange Online OWA-Seite abfragt und deren Antwortzeit misst.

2 Stunden Auswertung

Dieses Bild zeigt einen 2h Ausschnitte einer Überwachung durch zwei Sensoren. Der obere Sensor zeigt die per SNMP gemessene Belastung der Leitung. Sie sehen, dass die Empfangsrichtung mit ca. 20MBit nahezu komplett gefüllt ist. Unten ist nun die Ausgabe von end2end-http z zu sehen. Obwohl die Leitung "dicht" ist, scheint die Antwortzeit der Exchange Online Dienste zumindest hinsichtlich des Netzwerks nicht zu leiden.

Die Auswertung per SNMP würde also erst einmal alle Alarmglocken schrillen lassen. Erst die Messung der Ende zu Ende-Performance gibt zumindest für Outlook Entwarnung. Das kann z.B. durch eine Bandbreitenrichtlinie gesteuert sein, die Verkehr zu Office 365 priorisiert. Das wäre dann mit NetFlow und anderen Optionen etwas genauer zu untersuchen.

2 Tage Übersicht

Ich habe dann das ganze noch mal über zwei Tage ermittelt. Dabei werden die Messungen, die beim 2h-Diagramm alle Minute erfolgen, natürlich zusammengefasst und gemittelt. Wenn also auf der 2h-Anzeige noch eine 100% Last anliegt, dann ist das beim 2-Tage-Diagramm schon schwerer, da die Last hier dann schon entsprechend lang kontinuierlich hoch sein muss. Auch der end2end-http-Test wird natürlich gemittelt und die Anzahl der langsamen Pakete wird per Default nicht aufaddiert, sondern gemittelt. Hier ist aber schon zu sehen, dass mit Zunahme der Belastung auf dem WAN-Link auch die "Avg Request Time" im unteren Bild ansteigt.

Man sieht aber auch, dass selbst bei minimaler Last im WAN die Antwortzeit auch manchmal ansteigt. Wenn aber das eigene Firmennetzwerk hier keine Belastung auf das WAN legt und die Antwortzeit ansteigt, dann muss das Problem "auf dem Weg" zu Exchange Online liegen. Wo das Problem hier dann genau zu suchen ist, kann aus den Bildern nicht ermittelt werden. Es kann ja ein Exchange Online Problem sein oder auf dem Weg durch den eigenen Provider ein Engpass bestehen oder ein Peering überlastet sein.

Um diese Probleme weiter einzukreisen sollte das Monitoring nicht nur Exchange Online, sondern auch SharePoint, Azure und Skype for Business Online umfassen und zudem nicht nur die Endpunkte bei Microsoft sondern vielleicht auch die Router auf dem Zwischenweg z.B. per PING auf ihre Antwortzeit geprüft werden.

Weitere Links