503 Service Unavailable: overbelasting, onderhoud en Retry-After

Levend, en het werk weigerend

Om überhaupt een 503 terug te geven, moet er iets draaien: het accepteerde de TCP-verbinding, parseerde het verzoek en genereerde een antwoord. Dat ene feit sluit al een hele klasse problemen uit. De host is up, het netwerkpad werkt, TLS termineerde, en de webserver of proxy functioneert. Wat ontbreekt, is capaciteit of bereidheid.

RFC 9110 voegt een voorbehoud toe: een server is niet verplicht om 503 te gebruiken bij overbelasting. Sommige weigeren gewoon de verbinding in plaats daarvan. Een 503 is dus de beleefde vorm van overbelasting. Krijgt u een geweigerde verbinding of een time-out in plaats van een 503, dan kijkt u naar een andere en meestal ergere storing.

Twee buren zijn makkelijk te verwarren. Een 504 Gateway Timeout betekent dat de backend werd geaccepteerd en vervolgens nooit op tijd antwoordde; het verzoek werd wel geprobeerd. Een 503 betekent dat het verzoek werd afgewezen voordat er echt werk begon. De hele familie wordt vergeleken in het 5xx-overzicht.

Retry-After, en waarom u het altijd zou moeten sturen

RFC 9110 staat toe dat een 503 een Retry-After-header draagt, in een van twee vormen: een aantal seconden om te wachten, of een absolute HTTP-datum.

HTTP/1.1 503 Service Unavailable
Retry-After: 300
Content-Type: text/html

Het kost niets. Nette clients en libraries wachten het opgegeven interval af in plaats van een al worstelende server te blijven bestoken. Crawlers van zoekmachines behandelen de URL als tijdelijk onbeschikbaar en komen later terug in plaats van de storing als verwijderde content te behandelen. Uw eigen monitoring en statustooling krijgt een expliciet verwacht hersteltijdstip om te tonen.

Een 503 is standaard niet cachebaar, dus tussenliggende partijen blijven hem niet serveren nadat de dienst herstelt.

Wat een 503 veroorzaakt

• Overbelasting. Alle workerthreads, processen of verbindingsslots zijn bezet, dus nieuwe verzoeken worden geweigerd in plaats van eindeloos in de wachtrij gezet. Begint doorgaans onregelmatig op piekmomenten en wordt constant naarmate de belasting groeit.
• Onderhoudsmodus. Een opzettelijke schakelaar, vanuit een frameworkvlag, een onderhoudsbestand of een proxyregel. Dit is een 503 die precies doet wat hij zou moeten doen.
• Een afhankelijkheid is down. Een goed geschreven applicatie die zijn database, cache of wachtrij niet kan bereiken, zou 503 moeten teruggeven in plaats van een stacktrace, want de toestand is tijdelijk en niet de schuld van het verzoek.
• Geen gezonde backends. Een load balancer waarvan elk lid zijn health check niet doorstaat, heeft niets om naartoe te routeren, en velen geven in die toestand 503 terug.
• Deployments en herstarts. Het venster tussen het aftappen van het oude proces en het gereed komen van het nieuwe.
• Bewust afschudden. Circuit breakers en toelatingscontrole geven met opzet 503 terug om de onderdelen van het systeem die nog werken, te beschermen.
• Uitputting van resources op hostniveau. Geen geheugen meer, geen file descriptors meer, of een volle schijf, wat verhindert dat nieuw werk start.

Het patroon van 503 tijdens een deployment

Dit is de meest voorkomende 503 die geen echt incident is, en heeft een herkenbare vorm: een korte uitbarsting van 503's, seconden tot een paar minuten lang, die precies bij een release begint en vanzelf eindigt. Leg de tijdstempels naast uw deploymentgeschiedenis voordat u iets anders onderzoekt.

Goed afgehandeld zou een onderhouds-503 het volgende moeten doen:

1. De echte statuscode teruggeven. Een onderhoudspagina geserveerd met 200 vertelt crawlers dat uw content nu een onderhoudsmelding is, wat het slechtst mogelijke resultaat is voor een geplande onderbreking.
2. Retry-After opnemen met een realistische schatting van het venster.
3. Statisch en goedkoop blijven. De onderhoudspagina zou niet afhankelijk moeten zijn van de database of applicatie die u zojuist offline heeft gehaald.
4. Uw eigen adressen doorlaten zodat het team de nieuwe release kan verifiëren voordat het weer opengaat.
5. In monitoring worden ingepland als onderhoudsvenster, zodat een geplande onderbreking niemand oproept die wachtdienst heeft.

De oplossing voor ongeplande deployment-503's is een health-gated rolling update: start het nieuwe proces, wacht tot het een gereedheidscontrole doorstaat, tap dan het oude af en stop het. Goed gedaan is er geen venster waarin niets kan bedienen.

Hoe u een ongeplande 503 oplost

1. Bevestig de code en lees de headers, inclusief of er een Retry-After werd gestuurd en welk onderdeel het antwoord ondertekende:

   curl -sS -o /dev/null -D - https://example.com/

2. Sluit onderhoudsmodus als eerste uit. Controleer op een onderhoudsvlag of -bestand dat na een release is blijven staan. Dat gebeurt vaker dan iemand toegeeft.
3. Controleer de gezondheid van de backend. Kijk op een load balancer hoeveel leden hun checks doorstaan. Nul gezonde leden is een direct antwoord.
4. Kijk naar verzadiging. Gebruik van worker- en verbindingspools, geheugen, databaseverbindingen en wachtrijdiepte. Een 503 onder belasting met alles op zijn plafond is capaciteit, geen bug.
5. Controleer afhankelijkheden. Is de database, cache of een kritieke API down, herstel dan dat in plaats van de weblaag.
6. Verlicht de belasting, zoek dan de oorzaak. Opschalen of limieten verhogen herstelt de dienst, maar een 503 die verscheen zonder verkeerstoename verbergt meestal een trage query of een lek dat terugkomt.

503's op piekuren en geplande onderhoudsvensters

Overbelastings-503's zijn meestal onregelmatig lang voordat ze constant worden, en verschijnen op piekuren en verdwijnen vanzelf weer. Die vroege fase is makkelijk te missen vanuit een browser en overduidelijk in een doorlopende registratie. Een geplande HTTP-controle die de verwachte statuscode toetst, verandert die verspreide mislukkingen in een zichtbare trend met tijdstippen erbij, zodat u kunt ingrijpen voordat de onregelmatige fase een storing wordt. Onderhoudsvensters in dezelfde tool inplannen voorkomt dat geplande 503's meldingen genereren.