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.

DNS Aging

Wenn Sie einen Dauertest mit End2End-HTTP starten, dann wird die erste Messung länger dauern, da der Name noch nicht per DNS aufgelöst wurde. Die DNS-Anfrage dauert etwas aber die folgende Anfragen messen wirklich die HTTP-Latenzzeit. Ein Eintrag im DNS-Cache wird dort aber nicht endlos gespeichert und gerade Cloud-Dienste haben einen sehr kurzen TTL.

PS C:\> Resolve-DnsName www.msftconnecttest.com

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
www.msftconnecttest.com        CNAME  54    Answer     ncsi-geo.trafficmanager.net
ncsi-geo.trafficmanager.net    CNAME  54    Answer     v4ncsi.msedge.net
v4ncsi.msedge.net              CNAME  54    Answer     ncsi.4-c-0003.c-msedge.net
ncsi.4-c-0003.c-msedge.net     CNAME  54    Answer     4-c-0003.c-msedge.net

Wenn ich nun eine Serie von Messungen über 5 Minuten mache, dann wird ca. jede 55 Sekunden ein Messwert langsamer sein. Wenn ich perfekt sein möchte, sollte ich den DNS-Cache überwachen und die Messung dann verwerfen oder ich sorge dafür, dass die eigene Routine einen DNS-Cache nutzt und bei der IP-Adresse bleibt. Der DNS-Cache verhindert natürlich auch, dass ich verschiedene Gegenstellen abfrage.

In dem Fall ist noch ein anderes Verhalten aufgetaucht. Natürlich kann ich auch ein end2end-dns programmieren, welches kontinuierlich die Antwortzeit eines DNS-Servers misst. Wenn ich dazu einen Wer abfrage, den der DNS-Server immer kennt oder mit einem Fehler liefert, dann kann ich gut messen. Frage ich aber z.B. einen öffentlichen Namen ab, um Performance und generelle Erreichbarkeit zu überwachen, dann wird die erste Abfrage oft langsamer sein, bis der DNS-Server die Information selbst abgefragt hat und dann im Cache vorhält. Der Warmup kann helfen aber was passiert, wenn die Antwort z.B. 60 Sekunden im Cache liegt und mein test nach 59,99 Sekunden die nächste Testrunde mit einem "Warmup" startet. Die dann erste Anfrage wird schnell beantwortet und die zweite "geplante" Messung bekommt dann eine längere Antwortzeit, da genau zwischen den Messungen die Information im Cache des DNS-Servers verworfen wird.

Einzeltest oder Burst

Ein Dauertest gegen ein zu prüfendes System könnte so aussehen, dass der Test alle 10 Sekunden läuft. Je nach Roundtrip ist der Status dann "OK", "Warning", "Critical" oder "Timeout". Ein einzelner Test, der nicht OK ist, kann also schon eskalieren.

Nach der im Beispiel fehlerhaften zweiten Messung dauert es aber das normale Intervall bis der dritte Test erfolgt und die Fehlersituation wieder auflöst. Ein einzelner Fehler wirkt sich deutlich aus, aber ein Regentropfen ist noch lange kein Sommerregen. Daher kann es sinnvoll sein, entweder direkt mehrere Tests zu machen und aus der Summe der Ergebnisse eine gewichtete Aussage zu erstellen oder einen fehlerhaften Test direkt zu wiederholen.

Zwei "gute" Ergebnisse könnten den einen schlechten Test überstimmen. Vielleicht war es ja nur ein einmaliger Aussetzer. Wenn Sie direkt en ersten Test verwerfen und immer erst test 2 und folgende nutzen, dann haben sie ein "Warmup" eingebaut und lösen indirekt gleich das DNS-Aging-Thema.

Messen ohne Sequenznummer

Eine Latenzzeitmessung mit PING bedeutet nicht nur, dass der Sender regelmäßig ein Paket sendet und die Antwort abwartet. Er erhöht auch eine laufende Nummer, so dass der Sender die Rückläufer wieder zuordnen kann. Die Paketlaufzeit kann ja schon manchmal etwas länger sein. Das habe ich bei meinem End2End-UDP3478-Skript gesehen, welches ein Paket sendet und auf die Antwort wartet. Geplant war, dass es jede 20ms ein Paket sendet, so dass es 50/Sek unterwegs sind. Allerdings kann ich die Rückantwort nicht zuordnen, da alle Pakete "gleich" sind. Daher muss das Skript ein Paket sendet und auf die Antwort oder einen Timeout warten, ehe es das nächste Paket absendet. Wenn der Timeout aber zu klein gewählt wird, kann folgendes passieren, wenn das Paket tatsächlich nach dem Timeout noch zurückkommt:

00:000  Messung 1 startet mit einem Paket1
00:050  Messung 1 bekommt die Antwort nach z.B. 50ms und ist OK
00:051  Messung 2 startet danach mit einem Paket2
00:550  Messung 2 läuft auf einen Timeout von 500ms
00:551  Messung 3 startet mit einem Paket3
00:510  Paket2 von Messung 2 kommt nach 510ms zurück aber wird als Antwort auf Messung3 angesehen
d.h. Messung 3 "glaubt", dass Paket2 eigentlich sein erwartetes Paket3 ist.

Hier wird der verspätete Rückläufer als Antwort auf die zweite Messung fehlinterpretiert. Die Messung2 wird zwar immer noch als Timeout gezählt aber Messung 3 hat nun eine gemessene Zeit von 10ms, was natürlich viel zu kurz ist. Wenn nun das Skript gleich die Messung 4 startet, dann sollten Sie daran denken, dass das Paket von Messung 3 mit der Rückantwort auch noch unterwegs ist und früher zurück kommt, was die Verfälschungen fortschreibt.

Letztlich kann dies dazu führen, dass Sie viele "sehr schnell" Ergebnisse bekommen, die die wahre Ursache sogar verdecken. Wer sehr intensiv misst, sollte also den Timeout so hoch wählen, dass Rückläufer möglichst nicht mehr zu erwarten sind oder der Abstand zwischen zwei Messungen ausreichend groß ist.

Throtting mit E-A statt A-A

Damit kommen wir auch zum Thema Throttling, denn auch eine Messung produziert eine bestimmte Last. Wenn Sie viel messen, kann die Messung selbst schon einen Einfluss auf die Ergebnisse haben. Wer eine Messung abwartet, ehe er die nächste Messung startet, profitiert indirekt von einer Drosselung bei Überlast. Durch die verzögerte Antwort startet auch der nächste Test erst später. Es werden über das Intervall damit weniger Messungen ausgeführt. Die Konfiguration wird auch mal als "Ende-Anfang"-System bezeichnet. Sie kennen das vielleicht auch von ihrer Projektmanagement-Software.

Der Nachteil ist natürlich, dass abhängig von der Latenzzeit die Anzahl der Tests schwankt. Wer nun immer im gleichen Takt messen möchte, wird einen "Anfang-Anfang"-Test implementieren, d.h. ein Scheduler startet immer wieder den Test und zwar unabhängig vom vorherigen Abschuss oder Ergebnis. Der Vorteil ist dabei, dass die Anzahl der Tests pro Zeiteinheit immer gleich ist und auch über die Zeitachse die Daten erhoben werden. Allerdings nimmt so ein Test dann keine Rücksicht auf die Leistung der Verbindung und Gegenstelle sondern hämmert immer weiter an die Tür.

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