End2End-HTTP

Die Performance und Erreichbarkeit eines WebServices sollte nicht nur durch passive Überwachung von CPU, RAM, Disk-IO und Netzwerkkarte erfolgen. Diese Daten liefern nicht immer zuverlässige Daten und sie sind Blind für Probleme auf dem Übertragungsweg. Der Anwender merkt diese aber sehr wohl und speziell mit Office 365 ist es um so wichtiger, die Erreichbarkeit und den Weg zu den Cloud-Diensten zu überwachen. Mit End2End-HTTP habe ich mir ein entsprechendes Werkzeug geschaffen.

Überlegungen

Für die Überwachung von Office 365-Verbindungen ist ein einfacher PING nicht gut genug. Die meisten Office 365-Dienste nutzen HTTPs und da bietet es sich an, diese Daten immer wieder regelmäßig abzufragen und die Antwortzeit und Reaktionszeit zu überwachen. Wie ich schon mehrfach auf Ende zu Ende Monitoring beschrieben habe, ist es wichtig hier nicht nur die Erreichbarkeit eines Dienstes zu überprüfen sondern auch die Performance aus Sicht des Clients zu überprüfen. beachten Sie dazu auch End2End ClientCheck, mit dem ich auf einem Client unterschiedliche Dienste überwachen kann. Mit End2End-HTTP hingegen möchte ich als Administrator die Verbindung von meinem LAN zu einem WebService sehr eng überwachen ohne einen Last-Test zu fahren.

Aus meiner Sicht ist die Funktion einer "Lastsimulation" von der Überwachung getrennt zu sehen, auch wenn beide das Gleiche nur mit andrem Volumen machen. Ich kann aber problemlos beide Bausteine derart kombinieren, dass meine kleine Dauerüberwachung natürlich eine Veränderung feststellen wird, wenn eine Lastsimulation die gleiche Leitung belegt. Ich muss dann gar nicht unbedingt die Performance der Last-Simulation genau erfassen. Bei der Lastsimulation interessiert natürlich schon, wie viel Bandbreite, wie viele Requests und mit welcher Latenzzeit die Aufgaben erledigt werden. Eine Lastsimulation ist aber keine Daueraufgabe sondern dienst der Verifikation vor einem Umbau und nach einem Umbau der Verbindungen oder Veränderungen am Lastprofil.

Hier ist die Dauerüberwachung als Grundlagenmessung sogar bedeutender, da sie über Tage und Wochen hinweg die Erreichbarkeit eines Dienstes und die Performance vom Client auf dem der Test läuft bis zum Ziel misst. Ich habe mir dabei überlegt, dass ich z.B. jede Sekunde einen HTTP-Request ausführe und die Dauer und Datenmenge dazu erfasse. Nun kann und will ich nicht für jede Sekunde einen Messwert an mein Monitoring übergeben. Für eine Fehlersuche und eine Detailauswertung schreibe ich natürlich eine lokale CSV-Datei. Für die Auswertung habe ich mir aber zwei andere Dinge überlegt.

Mit jedem Abruf erhalten ich die Anzahl der Bytes, einen Status und die Dauer, die der Abruf benötigt hat. Diese Werte bereite ich entsprechend auf, damit ich folgende Kennzahlen in einem gegebenen Messintervall ermitteln kann.

  • Gleitender Mittelwert der Antwortzeiten
    Ich ermittelt den Mittelwert der letzten Anfragen. Um Veränderungen über den Tag hinweg zu erkennen, wird der Mittelwert aus der Summe aller Anfragen im Messintervall geteilt durch die Anzahl der Anfragen ermittelt.
  • Längste Antwortzeit
    Von allen erfolgreichen Abfragen im Messintervall wird der Maximal wert gesammelt
  • Kürzeste Antwortzeit
    Auch die Zeit für die schnellste Anfrage im Messintervall wird festgehalten
  • Anzahl der guten/absolut langsamen/relativ langsamen/fehlerhaften Anfragen
    Neben den Zeiten in ms zählt die Auswertelogik den Status der Abfragen. Neben der Anzahl der fehlerhafte Anfragen wird bei den anderen drei Klassen die Dauer der Anfrage bewertet. Es gibt einmal eine absolute Obergrenze, über der eine Anfrage als "Absolut langsam" gezählt wird. Zudem führt das Skript intern einen Mittelwert der letzten 10 Abfragen mit und bewertet die Anfragen als "relativ langsam", die zu weit von dem Mittelwert entfernt sind. Dieser Abstand wird durch einen Faktor vorgegeben

So kann ich am Ende jeder Mess-Periode nicht nur einen Wert liefert, sondern mehrere Werte, die durch geeignete Programme entsprechend visualisiert werden können.

Melden und Auswerten

Das Skript kennt drei Möglichkeiten, die Daten zu übermitteln. Alle Datenziele sind optional nutzbar.

  • CSV-Datei
    Alle Messwerte werden im Sekundentakt in eine CSV-Datei geschrieben. Diese Daten können später mit Excel, PowerShell, Power Bi oder anderen Tools ausgewertet werden.
  • Pipeline
    Alternativ können Sie Ergebnisse auch über die Pipeline an ein Skript zur eigenen Weiterverarbeitung senden lassen.
  • SMTP-Mail
    Werden die Werte für den Mailserver und Empfänger als Parameter übergeben, dann sendet das Skript immer dann eine Meldung, wenn eine Abfrage nicht in Ordnung war. Das kann also ein fehlgeschlagener Abruf oder auch zu lange Antwortzeiten sein. Dieser Weg ist aber eher für ein Ad-Hoc-Monitoring, da es keine grafische Aufbereitung gibt und im Fehlerfall sehr viele Mails entstehen. Es ist aber dennoch hilfreich, wenn Sie End2End-HTTP z.B. mit längeren Abständen eine Webseite prüfen lassen. Solche Tests kann aber eine normale "Monitoring-Software" meist auch.
  • PRTG-Sensor
    Da das Skript ein "Langläufer" ist, macht es keinen Sinn es per PRTG alle 5 Minuten zu starten. Zudem ist auf dem Mess-Client nicht immer auch eine PRTG-Probe installiert. Daher nutzt das Skript die Funktion der PRTG - HTTP Push-Sensoren, um die ermittelten Werte an PRTG zu übergeben. PRTG dient dann nur als Datensammler und zur Darstellung

Das Skript ist im Prinzip zwar auf einen Dauerbetrieb ausgelegt. Einige dazu erforderliche Funktionen (Starten als Dienst, Meldungen im Eventlog etc.) sind aber nicht implementiert. Ich lasse es daher entweder "interaktiv" oder über den Taskplaner (PowerShell und Taskplaner) starten. PRTG ist ja so smart und kann einen Alarm auslösen, wenn die Ergebnisse ausbleiben.

Beispiele

Ich habe auf einem PC das PowerShell-Skript kontinuierlich laufen und es meldet alle 15 Sekunden seinen "Datensatz" an PRTG. So kumuliert das Skript im Schnitt die Ergebnisse von 14-15 Messungen in einem Datensatz zusammen.

  • Anzeige der Abrufanzahl:
    Es ist gut zu sehen, dass die allermeisten Anfragen "gut" sind. und ab und an eine Anfrage als "Absolut zu langsam" erfasst wird. Durch die Aufaddition der Anfragen im Sensor selbst ist es auch nicht mehr so wichtig, ob man nun die Werte alle Sekunde, alle 10 Sekunden oder wie hier alle 60 Sekunden an PRTG meldet. Die absoluten Zahlen pro Intervall ist für eine Auswertung ausreichend. Man muss nicht auf die Sekunde genau wissen, wann ein einzelner Request zu lange gedauert hat. Einzig kurze "Bursts" lassen sich so noch nicht ermitteln.
  • Anzeige der Laufzeiten
    Der gleiche Sensor hat ja auch die Daten zur Dauer der Abfrage. Da das Skript auch hier die Antwortzeiten der Einzelmessungen schon vorab auswertet, sieht man gut die Max und Min-Werte mit dem Average in der Mitte. Ich habe hier die Grafik gezoomt, damit die drei Linien besser zu sehen sind

Beide Grafiken sind für die Bewertung einer Verbindung nützlich, denn erst die Vorverarbeitung der vielen Einzelmessungen erlaubt eine sinnvolle Darstellung. Wenn PRTG oder ein anderes Werkzeug die Messung jeder Sekunde verarbeiten müsste, wäre die Datenmenge sehr groß und einzelne Ausreißer würden zu leicht übersehen. So kann ich über den Mittelwert eine allgemeine Abschätzung machen. Wenn der Maximalwert aber sehr hoch ist oder der Mittelwert ansteigt, dann blende ich mir einfach noch die entsprechende Linie für die "Anzahl langsame/fehlerhafte" Anfragen mit ein um besser einen einmaligen Ausrutscher von einer Störung zu unterscheiden.

Bei all den Tests darf man aber nicht übersehen, dass 7kB/Sek ca. 420kB/Min oder 25 MB/Stunde bedeutet. So kommen allein durch den Grundlasttest 18 GB/Monat zusammen. Das ist natürlich ein Klacks wenn man später die Anwender produktiv arbeiten lässt. Sie können ja heute schon mal mit PRTG, NetFlow, IISLogs etc. ermitteln, wie viel Bytes alleine ihre Clients mit dem Exchange Server austauschen. Das wird später über die Leitung mit Exchange Online anliegen.

Eine weiteres Beispiel zum Einsatz von End2End-HTTP finden Sie auf der Seite Network Assessment:Grundlastmessung

Parametrisierung

Alle relevanten Parameter zur Steuerung des Programs sind als PARAM-Block hinterlegt:

Als "Text-URL" nutze ich einfach das Favicon (7Kbyte) von OWA, welches anonym abgerufen werden kann. ich lasse alle Daten für eine Fehlersuche in eine CSV-Datei schreiben aber sende die Daten nicht zusätzlich an die Pipeline und Mails möchte ich auch keine haben. Der Mailserver ist daher leer. Alle Anfragen, die länger als 1000ms (slowabsms) dauern, sind definitiv zu langsam. Als Faktor für die Abweichung vom Mittelwert habe ich 5 (slowavgfactor) gesetzt. Wenn der Mittelwert z.B. 150ms beträgt, dann ist ein Abruf mit über 5*150m = 750ms ebenfalls "slow".

Nachdem eine Messung erfolgt ist, "schläft" das Skript 1000ms und nach spätestens 86400 Durchläufen, also einen Tag zzgl. der aktiven Laufzeit beendet es sich alleine. Alle 60 Sekunden wird eine Zusammenfassung der ca. 60 Messwerte per HTTPPush an die angegebene PRTG-URL gesendet. Den Sensor muss ich natürlich manuell vorab anlegen und in der URL die IP-Adresse, den Port und das Sensor-Token hinterlegen.

Das Skript unterstützt natürlich eine "Verbose"-Ausgabe zur Fehlersuche. Diese macht die Abfragen natürlich deutlich langsamer durch das "Scrollen" auf dem Bildschirm. Im normalen Betrieb gibt das Skript zu jeder Messing ein einzelnes Zeichen mit Write-Host aus:

Ein "." steht für eine erfolgreiche Messung. Das "P" bedeutet, dass ein Datensatz an PRTG gesendet wurde. Weiterhin gibt es "E" für Fehler, und "S" (Slow) für langsame Abfragen.

Das Skript wartet auf Tastatureingaben und ein "X" beendet das Skript nach dem nächsten abgeschlossenen Durchlauf und schließt alle Dateien. Jede andere Eingabe führt zu einer Anzeige, dass das Skript mit "x" beendet werden kann.

Code

Der Code ist ein einfaches PowerShell-Script, welches keine weiteren externen Abhängigkeiten hat. Es kann von jedem normalen Anwender ohne administrative Rechte aufgerufen werden. Allerdings ist es keine "Plug and Play"-Software, die man einfach aufruft und etwas später das Ergebnis begutachten kann. Der Einsatz muss auf ihre Umgebung abgestimmt werden. Auch die Einrichtung in PRTG, die Bewertung der Ergebnisse u.a. sind beratungsintensiv. Daher nutze ich das Skript aktuell noch im Rahmen von Projekten bei Kunden. Es ist auch noch sehr früh in der Entwicklung und muss erst noch ein paar Wochen im Feld sich beweisen. Zudem macht es so alleine nur bedingt Sinn. Man misst damit quasi eine "leere" Leitung. Sie benötigen also immer noch ein Modul zur Simulation von Last.

Bitte haben Sie Verständnis, dass dieses Skript aktuell noch nicht als freier Download vorliegt.

Ich bin natürlich an einem Erfahrungsaustausch interessiert. Ich muss aber auch die Zeit dazu finden, das Feedback zu verarbeiten und bei der Einrichtung zu unterstützen. Bitte haben Sie daher noch etwas Geduld.

Offen

Es fehlt noch eine Beschreibung, wie man den Job als "Geplanter Task" einstellt und natürlich sollte das Skript einen Blick auf die Größe der CSV-Datei legen und ggfls. alte Versionen löschen, da eine 24h Aufzeichnung gerne bis zu 7 Megabyte/Tag groß wird.

Weitere Links