Ein Proxy ruft Ihre IP-Prüfseite ab und scheitert an der API, die Ihre Anwendung benötigt. Ihn „gesund“ oder „tot“ zu nennen, verliert die nützlichste Tatsache: Die beiden Anfragen waren verschieden.

Beginnen Sie mit einem transportweiten Datensatz für den Endpunkt. Erreichen Sie dessen Listener und schließen Sie die erforderliche Proxy-Aushandlung ab? Halten Sie zielbezogene Beobachtungen neben diesem Datensatz fest, anstatt ihn zu überschreiben.

BeobachtungZu untersuchender Umfang
Der Proxy-Listener lehnt Verbindungen abDer Endpunkt und die Route dorthin
Der Proxy verweigert einen ZielportDie erlaubte Operation für dieses Ziel
Eine Website liefert einen KontofehlerDie Zielanwendung und die Anmeldedaten
Große Antworten stocken, kleine werden fertigDie Übertragungslast und die Timeout-Richtlinie

Eine HTTP-Antwort kann belegen, dass ein Anforderungspfad etwas zurückgegeben hat, und dennoch für die Anwendung unbrauchbar sein. Halten Sie Transporterfolg, HTTP-Status und erwarteten Inhalt als getrennte Ergebnisse fest.

Wenn ein Ziel wiederholt scheitert, pausieren Sie diese Endpunkt-Ziel-Paarung oder untersuchen Sie sie. Den Proxy für jede unabhängige Aufgabe zu deaktivieren, kann nützliche Kapazität verschwenden. Umgekehrt sollte ein globaler Verbindungsfehler nicht hinter dem isolierten Datensatz einer einzelnen Website verborgen bleiben.

Ein praktischer Zustandsschlüssel kann die Proxy-Kennung, den Zieldienst und die Operationsart enthalten. Vermeiden Sie es, die gesamte anmeldedatenhaltige URL oder jeden eindeutigen Ressourcenpfad als ständig wachsenden Schlüssel zu verwenden. Gruppieren Sie nur dort, wo die Gruppierung eine sinnvolle Vorhersage über die nächste Anfrage trifft.

Der Zweck sind bessere Routing-Belege, nicht eine größere Sammlung grüner Abzeichen. Ein Zustandsergebnis sollte sagen, was versucht wurde, wann und was es tatsächlich belegt hat.

Ähnliche Artikel