
Ein 503 Service Unavailable ist der eine Serverfehler, der meistens Absicht ist. Irgendetwas hat entschieden, dass diese Anfrage gerade jetzt nicht bedient wird, und hat das gesagt, statt es zu versuchen und zu scheitern.
Das macht ihn zum Sonderling in seiner Familie. Ein 500 ist Code, der während der Ausführung kaputtging. Ein 502 ist ein Proxy, der von dem Ding dahinter eine unbrauchbare Antwort bekommt. Ein 504 ist dieses Ding, das überhaupt nicht rechtzeitig antwortet. Alle drei sind Fehlschläge. Ein 503 ist eine Entscheidung.
Die vier Dinge, die diese Entscheidung treffen
Im Browser sehen sie identisch aus und bedeuten für den Betreiber der Website völlig Verschiedenes.
Wartungsmodus. Jemand hat die Website absichtlich hinter eine Halteseite gestellt, während eine Migration läuft oder ein Deploy landet. Hier funktioniert der 503 genau wie vorgesehen, und das ist der einzige Fall, in dem die richtige Reaktion ist, später wiederzukommen.
Die Anwendung nimmt keine Verbindungen an. Jeder Worker ist beschäftigt, der Verbindungspool ist voll, die Warteschlange davor ist am Limit. Der Server davor ist noch da und antwortet noch, also antwortet er mit dem einzig Ehrlichen, das er hat: nicht jetzt.
Ein Rate Limiter. Sie oder das Netzwerk, in dem Sie sind, haben mehr Anfragen gesendet, als ein Schwellenwert erlaubt. Manche Dienste nehmen dafür einen 429, was spezifischer und nützlicher ist; viele nehmen 503, und ein CDN vor einer Anwendung macht oft aus dem einen das andere.
Es läuft nichts. Ein Autoscaler, der einer Lastspitze hinterherhinkt, ein Deploy, bei dem die neue Version ihren Health Check nicht bestanden hat, ein Container, der gestorben und nicht ersetzt worden ist. Der Load Balancer hat gesunde Ziele, an die er Traffic schicken soll, findet keine und gibt einen 503 zurück, weil es nirgendwohin zu schicken gibt.
Nur das erste davon ist geplant. Die anderen drei sind das System, das sagt, es sei am Limit oder habe etwas verloren, in der höflichen Formulierung, die einem vorübergehenden Zustand vorbehalten ist.
Der Header, den fast niemand liest
Ein 503 ist der Statuscode, an dem eine Antwort hängt. Die Response kann Retry-After tragen, was
entweder sagt, wie viele Sekunden zu warten sind, oder das genaue Datum und die Uhrzeit, zu der
man wiederkommen soll:
HTTP/1.1 503 Service Unavailable
Retry-After: 120
Content-Type: text/html
Das ist die Website, die Ihnen sagt, es werden zwei Minuten. Gut konfigurierte Wartungsseiten setzen ihn, CDNs reichen ihn durch, und ihn zu senden kostet nichts.
Daraus folgen zwei Dinge, und sie weisen in entgegengesetzte Richtungen. Wenn Sie einen Client
schreiben, lesen Sie den Header, statt sich Ihr eigenes Backoff auszudenken: ein Dienst, der
Ihnen 120 Sekunden genannt hat und alle zwei einen Retry bekommt, wird gebeten, genau die
Anfragen zu bedienen, von denen er eben gesagt hat, dass er sie nicht bedienen kann. Und wenn Sie
die Website betreiben, setzen Sie ihn. Ein 503 mit Retry-After ist eine Suchmaschine, die die
Seite hält, statt sie als verschwunden zu behandeln, und ein Client, der richtig wartet, statt
einer, der die Last erhöht, die das Problem verursacht hat.
Wenn Sie Besucher sind
Ein 503 bedeutet meistens Warten, und ungewöhnlich für einen Fehler funktioniert das Warten oft. Laden Sie nach ein, zwei Minuten neu. Wenn es ein Deploy oder eine Lastspitze ist, klärt sich das von allein, und in Ihrem Browser gibt es so oder so nichts, was daran rührt.
Das eine, was zu prüfen lohnt, ist, ob es nur Sie betrifft. Ein 503, den alle bekommen, ist die Kapazität der Website oder ihr Wartungsfenster. Ein 503, den Sie bekommen und eine Kollegin in einem anderen Netz nicht, ist eher ein Rate Limiter, der etwas gegen Ihre Adresse hat, und ein Handy im Mobilfunknetz beantwortet diese Frage in etwa zehn Sekunden. Auf diesen Unterschied läuft Ihren Bug von deren Ausfall zu unterscheiden im Ganzen hinaus.
Wenn es Ihre Website ist
Die Antwort sagt Ihnen fast nichts, aber anders als bei einem 500 liegt die Ursache meist vor der Anwendung und nicht in ihr.
Fangen Sie damit an, welche Schicht ihn ausgegeben hat. Ein 503 von nginx, von einem Load Balancer oder von einem CDN sieht für den Browser gleich aus und kommt aus drei verschiedenen Orten mit drei verschiedenen Logs. Oft verrät es der Body, weil jeder von ihnen seine eigene Standardseite mitbringt, und die Response-Header benennen meist das, was sie erzeugt hat. Wenn Ihre Anwendung nie gelaufen ist, wird ihr Log schweigen, und dieses Schweigen ist ein Beleg und keine Sackgasse.
Dann die offensichtliche Frage, die leicht übersprungen wird, wenn eine Website unten ist: ist der Wartungsmodus noch an? Eine Halteseite, die zehn Minuten dauern sollte und das Deploy überlebt hat, das sie hochgezogen hat, ist ein häufig genug vorkommender 503, um zuerst nachzusehen, und braucht Sekunden zum Ausschließen.
Wenn es Kapazität ist, liegt die Lösung nicht auf der Fehlerseite. Schauen Sie sich Auslastung der Worker, Pool-Limits und Queue-Tiefe über das Zeitfenster an, statt die Anfragen anzuschauen, die den 503 bekommen haben, denn die den 503 bekommen haben, sind die, die nach dem Beginn des Problems eintrafen. Wenn es Health Checks sind, ist die Frage, ob der Check recht damit hat, dass die Anwendung ungesund ist, oder ob er aus einem eigenen Grund fehlschlägt, und beides braucht entgegengesetzte Reaktionen.
Warum ein 503 es wert ist, ordentlich gemeldet zu werden
Die meisten 503 klären sich. Genau das macht sie glitschig: bis jemand nachsieht, ist die Website wieder da und es gibt nichts anzuschauen. Übrig bleibt jemandes Erinnerung an eine Fehlerseite und eine Vermutung darüber, wann ungefähr.
Kapazitätsprobleme und schlechte Rollouts wiederholen sich nicht auf Zuruf. Sie passieren in dem Moment, in dem der Traffic eine Linie überschritten hat, und der Beleg dafür ist ein Fenster in einem Graphen, von dem niemand weiß, dass er hinschauen soll, wenn nicht jemand aufgeschrieben hat, wann es passiert ist.
Session Replay
Kostenlose Chrome-Erweiterung. Ein Klick auf der Seite, die sich falsch verhält, erfasst den Screenshot, die Konsole und das Netzwerkprotokoll und gibt Ihnen einen Link zum Einfügen in das Ticket.
Bei einem 503 ist der nützliche Teil der Zeitstempel und die Response-Header: welche Schicht
geantwortet hat, welches Retry-After sie behauptet hat, und die genaue Minute. Das reicht, um
das richtige Fenster in einem Dashboard zu finden, und dort liegt die Antwort tatsächlich.
In einem Absatz
Ein 503 Service Unavailable bedeutet, dass sich etwas entschieden hat, die Anfrage nicht zu
bedienen, statt es zu versuchen und zu scheitern, und das unterscheidet ihn von einem 500, einem
502 und einem 504. Vier Dinge treffen diese Wahl: Wartungsmodus, eine Anwendung ohne Kapazität,
ein Rate Limiter und ein Load Balancer ohne gesundes Ziel für den Traffic. Nur das erste ist
geplant. Wenn Sie zu Besuch sind, warten Sie eine Minute und prüfen Sie dann, ob es sonst noch
jemand sieht. Wenn es Ihre ist, klären Sie zuerst, welche Schicht geantwortet hat, vergewissern
Sie sich, dass der Wartungsmodus nicht einfach noch an ist, und setzen Sie Retry-After, damit
die wartenden Clients richtig warten, statt die Last zu erhöhen.