End2End Grundlagen

Warum ist es sinnvoll, echte End2End-Tests mit einer engen Abtastrate zu machen und welche Fallstricke muss man bei der Auswertung der Daten beachten.

Dauertest vs. Einzeltest

Nahezu alle Produkte, die Verfügbarkeitsprüfungen machen, prüfen in fest vorgegebenen Intervallen. Ein interner Scheduler startet den Check z.B. im Abstand von 1 Minute oder 5 Minuten. Viel kürzere Intervalle, z.B. eine Messung pro Sekunde, verbieten sich bei diesem Ansatz aus zwei Gründen:

  • Daten-Overflow
    Wenn jede Sekunde ein Messwert geliefert und dieser dann in der Monitoring-Lösung auch gespeichert wird, bläht dies die Datenbank auf
  • CPU-Last
    Die meisten Tests sind eigenständige Module, Skripte oder Programme. Ein so enges Testintervall würde sehr viele Programmaufrufe bedeutet. Der Scheduler und das Betriebssystem sind entsprechend gefordert immer wieder den Prozess-Space zu instanzieren und aufzuräumen.

Ziel muss also sein, dass der Test eigenständig arbeitet. Entweder dass er z.B. jede Minute gestartet wird, eine Minute lang im Sekundentakt misst und die Ergebnisse schon selbst zusammenführt. Das aufrufende System bekommt also vorverarbeitete Ergebnisse.

Aber selbst der Aufruf alle Minute ist für einige Tests nicht hilfreich, da Sie z.B. eine "Warmlaufphase" brauchen. Wer z.B. die Funktion von EWS testen will, muss am Anfang sowohl "Autodiscover" durchlaufen als auch ggfls. eine ADFS-Anmeldung durchführen. Das dauert natürlich deutlich länger als der einfache EWS-Check. Ein Anwender meldet sich ja auch nicht jede Minute neu an.

Wer aber einen Test dann z.B. eine Stunde lang laufen lässt, wird irgendwie auch die Zwischenergebnisse an die Überwachungssoftware zurückgeben sollen. Zudem dürfte die ein oder andere Überwachungssoftware auch nicht gerade glücklich darüber sein, wenn ein von ihr gestarteter Prozess so lange läuft. Zwischenergebnisse wird sie zudem nicht erwarten.

Es gibt also verschiedene Gründe, warum ein angepasstes Monitoring in Verbindung mit einer Überwachungslösung sinnvoll ist. Das Monitoring muss sich dann aber schon selbst Gedanken über die Zusammenfassung der Messwerte machen.

Maximalwerte und Average

Es ist immer einfach aus mehreren Werten einfach den Mittelwert zu ermitteln und zu berichten. Leider sagt ein Mittelwert über 60 Messwerte in einer Minuten nicht viel mehr aus als ein Messwert einer Einzelmessung pro Minute. Ein einzelner sehr hoher Wert hebt den Mittelwert kaum an und selbst 10% Pakete, die 10mal solange unterwegs sind die die anderen Pakete, heben den Mittelwert um gerade ml 10% an. Benutzer werden sich aber schon beschweren, wenn jede 10te Abfrage lange dauert. Insbesondere bei Anfragen, die den Client blockieren wie eine Frei/Belegt-Anfrage in Outlook oder Zugriffe auf Stellvertreter, die nicht im Cached-Mode abgedeckt sind. Insofern ist es ratsam, neben dem Mittelwert auch den Min und Max-Wert zu melden.

Damit ist aber immer noch keine Aussage möglich, wie die Verteilung der Zugriffe ist. Nur ein einzelner Regentag macht ja noch keinen schlechten Sommer. Insofern kann es sinnvoll sein, die Antwortzeiten zu gewichten und zu klassifizieren, z.B. die Werte anzugeben, bei denen z.B. 50% oder 85% drunter liegen.

Denkbar wäre auch, wenn schon in der Prüfung die Grenzwerte "gut (Grün)", "problematisch (Gelb)" und "kritisch" (rot) bewertet würden. Dann reicht allein eine numerische Angabe der Antwortzeiten, die in die Bereiche fallen.

Maximalwerte und Fail

Ein zweites Kriterium ist die Frage, wann eine Anfrage als "Fail" bewertet werden soll. Sicher gibt es Abrufe, die zu einem klaren Fehler führen. Insbesondere wenn die Verbindung nicht möglich ist oder die Gegenseite nicht erreichbar ist. Das ist dann schon ein klassischer TCP-Timeout. Aber was bringt mir ein Messwert von 5000ms bis eine Anfrage beantwortet ist, wenn die meisten Werte sich im Bereich um 50-200ms tummeln. Er sorgt einfach nur für einen leicht erhöhten Durchschnittswert und einen großen Peak in den Maximalwerten, so dass jede Grafik verzerrt wird.

Wenn ich also Werte von 0-200ms als "normal" ansehe und 200-500ms dann als "problematisch, dann ist alles >500ms natürlich kritisch. Wenn ich aber noch Maximalwerte erfasse und zudem fehlerhafte Requests erfasse, dann könnte ein deutlich zu langer Request durchaus auch einfach als "Fail" zählen. Bei Zugriffen auf Daten in der Cloud könnte man schon bei 1-2 Sekunden davon ausgehen, dass da etwas deutlich zu langsam ist.  Das gilt zumindest für einfache synthetische Tests. Es ist natürlich klar, dass eine Volltextsuche in einem großen Datenbestand durchaus länger dauern darf. Wer so einen Test umsetzt, muss dann natürlich anders gewichten.

Ein Nebeneffekt einen erfolgreichen aber zu "zu langsamen" Request als Fail zu werten zeigt folgendes Beispiel in der Auswertung. Hier ein Bericht über eine End2End-HTTP-Bericht ohne Vorverarbeitung

Hier scheint es in den Daten eine Duration von 4.000.000 ms zu geben oder 4000Sek. Keine Ahnung woher PowerBI diesen Wert nimmt. Erst mit einer Filterung auf Werte unter z.B. 5000ms kommt man etwas in die Richtung einer sinnvollen Anzeige

Wobei hier alle Messwerte > 2000ms einfach unterschlagen werden. Es könnte durchaus sinnvoll, sein, in dem Beispiel Request >2000ms genauso zu behandeln wie "Fails" und z.B. mit "-1" einzutragen. Dann gäbe es links neben der "0" einen Strick für failed Requests.

Reaktionszeit und Datenmenge

Bei der Reaktionszeit sollten Sie auch die Datenmenge im Blick haben. Es gibt einen Unterschied zwischen einem keinen ICMP-Ping oder einem kleinen UDP-Paket mit der entsprechenden Antwort, welches problemlos im Bereich von 10-100ms zurückkommen kann und einem HTTPS-Request Schon das HTTP-Protokoll braucht einen gewissen Handshake und wenn Sie die Verbindung neu aufbauen und ein CRL-Check dazu kommt, geht noch mehr Zeit verloren. Wenn Sie dann nicht nur ein paar Byte als Antwort bekommen sondern eine große Dateimenge, die in mehreren Paketen übertragen werden muss, dann dauert es entsprechend länger bis ihr Aufruf wieder zurück kommt:

Leider veröffentlichen die meisten Anbieter nur ein paar Richtwerte bezüglich der erforderlichen Netzwerkperformance und vergessen dabei auch zu beschreiben, welchen Wert Sie eigentlich messen. Bei einem Ping (ICMP) ist es relativ einfach die Zeit zu messen. Bei einem TCP-Test könnte man sich auf den Abschluss des 3-Wege-Handshakes einlassen. Aber bei allen anderen höherwertigen Protokollen gibt es keine verlässliche Aussagen. Zudem unterscheidet sich der Overhead auch noch einmal von der verwendeten Anmeldung (Passthough, ADFS u.a.) und anderen Randbedingungen.

Für die meisten Tests reicht es aber anonym auf gewisse Dienste zuzugreifen und selbst mit TLS-Handshake z.B.: die CRL-Prüfung zu ignorieren. Dennoch macht natürlich auch die Datenmenge einen Unterschied bei der Dauer eines Request.

Caching

Nur erwähnen möchte ich, dass es durchaus Schnittstellen und Komponenten gibt, die Zugriffe "Cachen". Wer also z.B. per MAPI mit Outlook anspricht um die Reaktionszeit beim Lesen einer Mail zu messen, wird meist nur die lokale Performance von Outlook messen, da die Daten vermutlich aus dem lokalen Cache kommen. Auch HTTP-Zugriffe auf Server können durch einen Proxy-Server gecached werden. Das kann sogar passieren, obwohl sie explizit ein "No Caching" als Direktive vorgeben.

Einen sicheren HTTP-Test erreichen Sie nur, wenn der Server bei seiner Antwort schon mitgibt, dass die Daten nicht gecached werden dürfen oder Sie HTTPS nutzen und der Proxy kein SSL aufbricht. In der Regel lassen sich solche Caches umgehen, wenn Sie eine authentifizierte Verbindung nutzen und immer neue Daten abrufen. Sie sollten aber auf jeden Fall einen Request mehrfach wiederholen und sehen, ob die Zugriffszeiten stark abweichen. Das gilt auch für größere Datenmengen. Wenn ein Download z.B. beim zweiten Mal viel schneller ist, dann dürfte ein Cache dazwischen die Daten ausliefern.

Die richtigen Ziele und Anzahl an Tests nutzen

End2End-Tests haben einen Ausgangspunkt und einen Zielpunkt. Das erscheint einfach aber zwischen den beiden Kommunikationspartnern liegen oft viele Stationen. Dazu zählen LAN und WAN-Stecken, Router und Switches und natürlich Firewall und Proxy-Server. Das folgende Bild habe ich meinem Office 365 Netzwerk Assessment entnommen und zeigt gut, wie vielschichtig eine Umgebung sein kann.

Wenn ich hier z.B. einen End2End-Test zwischen einem Client im grünen Netz und Office 365 als Gegenstelle nutze, dann ist der Weg eigentlich klar. Die Ergebnisse alleine aber helfen mir nur dahingehend weiter, ob die Verbindung zur Zeit der Messung ausreichend gut war Aber gehen Sie besser nicht davon aus, dass dies immer der Fall ist.

Ein seriöser Aufbau versucht mit mehreren End2End-Tests bei Problemen auch die Ursache einzukreisen. Ein Office 365 Test sollte hier z.B. auch mit einem End2End-Tests gegen eine Gegenstelle beim Provider als auch im Internet erfolgen. Vergessen sie auch nicht innerhalb ihres internen Netzwerks die relevanten Pfade zu messen. Oft sind mehrere Probleme zu verschiedenen Zeiten involviert.

Mittelwerte und Summen

Wenn Sie die Daten von längeren Zeiträumen auswerten, dann können sich nicht mehr jeden einzelnen Wert anzeigen. So viele Pixel haben Sie auf dem Bildschirm nicht und "sehen" kann man dann auch nichts mehr. Also müssen Sie Daten gruppieren und zusammenfassen. Die meisten Produkte machen dies dann über Mittelwerte. Das funktioniert mit "Durchschnittszeiten" noch sehr gut. Wenn ich aber keinen Prozentsatz oder Zeiten sondern absolute Mengen habe, dann möchte ich schon eine Addition der Werte, wenn die Zeitscala zusammengefasst wird.

Fünf Mails pro Minute sind eben nicht auch weiterhin 5 Mails/Stunde, wenn eine Anzeige nur noch Stunden liefert. dann sollten es eben 300 Mails/Stunde sein.

Besonderheiten bei der Auswertung

Ich nutze bei meinen End2End-Tests zu allererst die Möglichkeit die Daten in CSV-Dateien wegzuschreiben. Das können schon einmal einige Megabytes werden. Aber weiterhin sende ich die Daten auch per PRTG - HTTP Push-Sensor an eine ggfls. vorhandene PRTG-Instanz. Diese liefert dann quasi Echtzeit schon einige nette Übersichtsdaten. Wenn ich aber mehrere Sensoren so betrachte, dann ist das in PRTG etwas mühsam und nicht immer baue ich mit dann eine Sensor Factory zusammen, die von verschiedenen Sensoren die Werte übereinander legt. Also kommt wieder Power Bi zum Einsatz, um mehrere CSV-Dateien mit ihren Datensätzen zu analysieren. Wenn man in allen CSV-Dateien den Timestamp identisch formatiert und diese dann verknüpft, dann klappt das ganz gut. Dabei sind mir natürlich auch einige Dinge aufgefallen, die maßgeblich zur Entstehung dieser Seite beigetragen haben

Runden von Werten für Verteilung

Ich schreibt in die CSV-Dateien natürlich die Antwortzeiten. Da es sich um Bruchteile einer Sekunde handelt, nutzt ich Millisekunden als Einheit. Allerdings habe ich anfangs die Werte ganz genau aufgezeichnet was nicht wirklich sinnvoll erscheint. So wollte ich gerne in PowerBi eine Verteilung der Zugriffszeiten darstellen. Oft ist es aber gar nicht erforderlich, für jeden Request die "Nanosekunde" genau zu haben. Zumal fraglich ist, wie genau so eine Messung sein kann. Hier ein Beispiel einer End2End-HTTP-Messung. Anscheinend gibt es "bevorzugte" Ergebnisse für eine Dauer. Die Messung hier erfolgte über viele Stunden und daher ist es nicht di zu erwartende klassische Normalverteilung.

 

Noch nicht erklären konnte ich mir aber die Spitzen bei 31,47, 62, 78, 94, 109,125, 141, 156ms. Vielleicht hat "Measure-Command" bestimmte Vorlieben nach CPU-Tricks eine Zeit zu liefern?. Folgendes Bild zeit ein unschönes Standardverhalten von PowerBi:

In der Datenbank sind sehr viele Messwerte mit unterschiedlicher Duration. Auf der X-Achse habe ich zwar die Duration gelegt, aber PowerBi fasst die Werte nicht zusammen sondern zeigt nur eine Teilmenge davon an. Man muss in PowerBi also erst eine Transformation auf den Daten machen, damit man die Duration z.B. rundet.

Eine Rundung auf "-1" Dezimale macht aus den vielen kleinen Werte wenige gerundete Blöcke a 10ms. In der Grafik macht sich das dann auch besser.

Für die Ergebnisse ist es nicht wichtig, die Zeigen auf wenige Millisekunden oder Nanosekunden zu wissen. Eine Verteilung mit 10ms Genauigkeit ist oft vollkommen ausreichend und sogar besser zu sehen. Insofern muss die Frage erlaubt sein, ob eine zu genaue Auflösung überhaupt sinnvoll ist.

Interessant wird hier natürlich noch eine Auswertung über die Zeit. Sie sehen ja, dass das hier keine "Normalverteilung" ist. Es ist ja auch die Summer aller Requests über den Tag hinweg. Es ist daher durchaus denkbar, dass die 50ms einfach nur die Requests in der "Nacht" sind und die von 90-100ms eben am normalen Tag anliegen. Das bekommen Sie dann doch wieder besser angezeigt, wenn die X-Achse die Zeit wiedergibt.

Hier ist besser zu sehen, dass speziell in der Nacht die meisten Requests schnell sind aber um 21:00-22:00, 03:30-04:00 und dann natürlich ab 09:00 die Antwortzeit höher ist. Wer also zu früh Daten zusammenfasst, verliert notwendige Details zum hinein-zoomen

Weitere Links