Angenommen, ein Client sendet eine Anfrage ohne Proxy-Zugangsdaten, erhält eine Aufforderung und versucht es erfolgreich erneut. Ein Anfrage-Log kann zwei Einträge enthalten. Die Person, die die Anwendung nutzt, hat jedoch einen abgeschlossenen Vorgang erlebt.

Deshalb belegt ein Log, das gleichmäßig zwischen TCP_DENIED/407 und TCP_TUNNEL/200 aufgeteilt ist, nicht automatisch eine Fehlerquote von fünfzig Prozent. Stellen Sie zuerst fest, ob die Einträge Paare aus Aufforderung und Wiederholung bilden.

Zählen Sie das, was Ihnen wirklich wichtig ist

MessgrößeAnzahl
AuthentifizierungsaufforderungenProxy-Antworten, die eine Authentifizierung verlangen
Proxy-VersucheEinzelne Transaktionen, die der Vermittler aufzeichnet
Abgeschlossene AufgabenAnwendungsvorgänge, die ihr beabsichtigtes Ergebnis erreichen

Verknüpfen Sie Zeitstempel, Client-Kontext, Ziel und jede verfügbare Anfragekennung. Ein nicht authentifizierter Versuch hat möglicherweise keinen protokollierten Benutzernamen, während seine erfolgreiche Wiederholung einen hat. Gleichzeitige Aktivität bedeutet, dass benachbarte Zeilen allein schwache Belege dafür sind, dass zwei Einträge zusammengehören.

Halten Sie außerdem einen erfolgreichen Tunnel getrennt von einem erfolgreichen Website-Vorgang. Die Annahme von CONNECT stellt den Tunnel her; das Ziel kann während TLS dennoch fehlschlagen oder danach einen Anwendungsfehler zurückgeben.

Untersuchen Sie wiederholte abschließende Aufforderungen, Aufgaben ohne spätere Fertigstellung oder eine plötzliche Änderung der Austauschanzahl. Diese unterscheiden sich von einem stabilen Client, der zuerst eine Aufforderung erhält und genau das tut, was seine Konfiguration verlangt. Die Authentifizierung zu unterdrücken, nur um ein Dashboard grüner zu machen, würde den Dienst verändern, statt die Messung zu reparieren.

Ähnliche Artikel