Sofortiges 503 oder 403? Erst oberhalb der Anwendung prüfen

Keine Latenz ist die erste Messung

Die Zeit bis zum ersten Byte sagt Ihnen, ob die Anwendung überhaupt gearbeitet hat. Ein Fehler, der etwa in der Round-Trip-Zeit des Netzwerks ankommt, wurde ohne sie entschieden. Ein Fehler, den die Anwendung erzeugt hat, trägt die Zeit in sich, die sie verbraucht hat, bevor sie aufgegeben hat.

curl -s -o /dev/null -w 'code=%{http_code} ttfb=%{time_starttransfer} total=%{time_total}\n' https://site.example/
curl -sI https://site.example/

Die Header nennen die Schicht in den meisten Fällen. Ein Server-Header oder ein Via-Header, der zum Edge oder zum Balancer gehört und nicht zum Webserver, ein X-Cache oder eine Request-ID des Edge, ein Body in reinem Text, wo die Anwendung ein Template rendern würde: jedes davon sagt, wer geantwortet hat. Damit in der Hand ist die Checkliste kurz.

Die Checkliste, von oben nach unten

Das CDN oder der Edge. Eine WAF-Regel, ein Rate Limit, eine Geo-Regel, eine Bot-Challenge oder ein Zertifikatsproblem zwischen Edge und Origin, das der Edge als eigenes 5xx meldet. Umgehen Sie ihn: Lösen Sie den Namen direkt auf den Origin auf und wiederholen Sie die Anfrage.

curl -s -o /dev/null -w 'code=%{http_code} ttfb=%{time_starttransfer}\n' \
     --resolve site.example:443:ORIGIN_IP https://site.example/

Der Origin antwortet 200, der Edge antwortet 5xx: Der Fehler gehört dem Edge, und ebenso die Regel, die ihn erzeugt hat.

Der Load Balancer. HAProxy antwortet von sich aus mit 503, wenn kein Backend up ist, mit eigenem Server-Header und einem einzeiligen Body. Das ist eine Frage des Health Checks, nicht der Anwendung: ein Prüfpfad, der sich im letzten Deploy geändert hat, ein Prüfport, der umgezogen ist, oder ein Backend, das aus einem Grund als down markiert ist, der auf der Stats-Seite steht. Fragen Sie ein Backend direkt vom Balancer-Host ab, um zu bestätigen, dass es ausliefert.

Die Plattformschicht. Ein Sperr- oder Wartungszustand im Control Panel, der Wartungsschalter eines Deploy-Werkzeugs, ein auf null skalierter Dienst. Jedes davon liefert eine feste Seite aus, ohne die Anwendung aufzurufen, und jedes ist ein Flag, das Sie lesen können, keine Theorie.

Webserver-Regeln. Eine einzige return-, rewrite- oder deny-Direktive antwortet sofort und sieht katastrophal aus. Geben Sie die wirksame Konfiguration aus, nicht die Datei, von der Sie glauben, dass sie geladen ist.

# nginx: the configuration actually in effect, with the rules that short-circuit a request
nginx -T 2>/dev/null | grep -nE '^\s*(return|rewrite|deny|allow)\b'

# IIS: the URL Rewrite rules for the site
appcmd list config /section:system.webServer/rewrite/rules

Lesen Sie bei Apache die wirksame .htaccess-Kette für den Pfad, nicht nur den vhost.

DNS. Bestätigen Sie, dass der Name auf den Host auflöst, den Sie gerade debuggen. Ein veralteter Eintrag, ein Split-Horizon-Unterschied oder eine Änderung, die sich noch verbreitet, bedeutet, dass die Maschine, die Sie beobachten, nicht die ist, die antwortet.

Rechte und SELinux. Der Webserver kann das Document Root nicht lesen oder sich nicht mit dem Upstream-Socket verbinden. Ein 403 oder ein 502 ohne eine einzige Zeile im Anwendungslog. Auf einem System im Enforcing-Modus nennt das Audit-Log die Verweigerung, und die Lösung ist ein Policy-Modul, kein Moduswechsel.

ausearch -m avc -ts recent | audit2why

Erst jetzt die Anwendung. Worker-Pools, Runtime, Abhängigkeiten, der Code. Jedes davon ist einzeln teuer zu untersuchen und kann nicht die Ursache einer Antwort sein, die die Anwendung nicht erzeugt hat.

Zwei Details, die die Suche verlängern

Ein 429 hat zwei mögliche Urheber. Ein Limiter am Edge beantwortet es mit den Headern des Edge und üblicherweise einem Retry-After. Ein Limiter der Anwendung beantwortet es aus der Anwendung heraus, mit den Headern der Anwendung und nachdem die Anwendung etwas gearbeitet hat. Die Zeit bis zum ersten Byte und die Header trennen die beiden, und die Lösung liegt jeweils an einer anderen Stelle.

Eine Fehlerseite kann ihre Ursache überleben. Edges und Reverse Proxies können ein 5xx kurz zwischenspeichern, sodass der Origin sich erholt und der Edge den gespeicherten Fehler weiter ausliefert, bis er abläuft. Ein Age-Header in der Fehlerantwort sagt, dass es eine Kopie aus dem Cache ist. Leeren Sie den Pfad am Edge oder warten Sie die TTL ab, bevor Sie schließen, dass die Korrektur nicht gewirkt hat.

Lassen Sie jede Schicht sich selbst beweisen

Jeder Schritt oben paart eine Schicht mit einem Weg an ihr vorbei: Die Auflösung direkt auf den Origin umgeht den Edge, die Anfrage an ein Backend vom Balancer-Host umgeht den Balancer, die Anfrage an den Anwendungsport auf localhost umgeht den Webserver. Der erste Hop, an dem die Antwort vom Fehler zu Inhalt wechselt, ist die Schicht, der der Fehler gehört. Die Methode ist mit Absicht mechanisch, und genau das macht sie zu jeder Tageszeit schnell.