503 Service Unavailable: přetížení, údržba a Retry-After

Žije, a odmítá práci

Aby vůbec mohl vrátit 503, něco musí běžet: přijalo spojení TCP, zparsovalo požadavek a vygenerovalo odpověď. Tato jediná skutečnost vylučuje celou třídu problémů. Hostitel je nahoře, síťová cesta funguje, TLS se dokončilo a webový server nebo proxy funguje. Co chybí, je kapacita nebo ochota.

RFC 9110 přidává výhradu: server není povinen při přetížení použít 503. Některé prostě spojení rovnou odmítnou. 503 je tedy zdvořilá forma přetížení. Pokud dostanete odmítnuté spojení nebo vypršení časového limitu místo 503, díváte se na jiné a obvykle horší selhání.

Dva sousedy je snadné zaměnit. 504 Gateway Timeout znamená, že backend byl přijat a pak nikdy včas neodpověděl; požadavek byl vyzkoušen. 503 znamená, že požadavek byl odmítnut ještě před tím, než začala skutečná práce. Celá rodina je porovnaná v přehledu 5xx.

Retry-After, a proč byste ho měli vždy posílat

RFC 9110 povoluje, aby 503 neslo hlavičku Retry-After, v jedné ze dvou podob: počet sekund k čekání, nebo absolutní datum HTTP.

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

Nic to nestojí. Slušně se chovající klienti a knihovny ubírají po uvedený interval místo bušení do už zápasícího serveru. Crawlery vyhledávačů berou URL jako dočasně nedostupnou a vrátí se později místo toho, aby výpadek brali jako odstranění obsahu. Váš vlastní monitoring a stavové nástroje dostanou explicitní očekávaný čas zotavení k zobrazení.

503 není ve výchozím stavu cachovatelné, takže ho prostředníci nebudou dál servírovat poté, co se služba zotaví.

Co 503 způsobuje

• Přetížení. Všechna pracovní vlákna, procesy nebo sloty spojení jsou obsazené, takže nové požadavky jsou odmítnuty místo neomezeného čekání ve frontě. Obvykle začíná přerušovaně ve špičce a se zvyšující se zátěží se stává trvalým.
• Režim údržby. Záměrný přepínač, z příznaku frameworku, souboru údržby, nebo pravidla proxy. Toto je 503 dělající přesně to, co má.
• Závislost je nedostupná. Dobře napsaná aplikace, která se nedostane k databázi, cache nebo frontě, by měla vrátit 503 místo výpisu zásobníku, protože stav je dočasný a není chybou požadavku.
• Žádné zdravé backendy. Load balancer, u kterého každý člen selhává v health checku, nemá kam směrovat, a mnoho jich v tomto stavu vrací 503.
• Nasazení a restarty. Okno mezi vyprázdněním starého procesu a připraveností nového.
• Záměrné odlehčování. Jističe (circuit breakers) a řízení příjmu vrací 503 záměrně, aby ochránily části systému, které pořád fungují.
• Vyčerpání zdrojů na úrovni hostitele. Došlá paměť, došlé popisovače souborů, nebo plný disk, což zabrání spuštění nové práce.

Vzorec 503 během nasazení

Toto je nejběžnější 503, které není skutečný incident, a má rozpoznatelný tvar: krátký nápor 503, od pár vteřin do pár minut, začínající přesně při vydání a sám od sebe končící. Než začnete vyšetřovat cokoli dalšího, porovnejte časová razítka s historií nasazení.

Dobře zvládnuté 503 kvůli údržbě by mělo:

1. Vracet skutečný stavový kód. Stránka údržby servírovaná s 200 řekne crawlerům, že váš obsah je teď oznámení o údržbě, což je nejhorší možný výsledek pro plánované okno.
2. Obsahovat Retry-After s realistickým odhadem okna.
3. Zůstat statické a levné. Stránka údržby by neměla záviset na databázi nebo aplikaci, kterou jste právě odpojili.
4. Propustit vlastní adresy, aby tým mohl ověřit nové vydání před opětovným otevřením.
5. Být naplánované v monitoringu jako okno údržby, aby plánovaný výpadek nevolal pohotovostní službu.

Oprava pro neplánované 503 při nasazení je aktualizace řízená zdravím: spusťte nový proces, počkejte, až projde kontrolou připravenosti, pak vyprázdněte a zastavte starý. Uděláno správně, neexistuje okno, ve kterém nic neobsluhuje.

Jak opravit neplánované 503

1. Potvrďte kód a přečtěte si hlavičky, včetně toho, zda byl odeslán Retry-After a která komponenta odpověď podepsala:

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

2. Nejdřív vylučte režim údržby. Zkontrolujte, zda po vydání nezůstal příznak nebo soubor údržby. Stává se to častěji, než by kdo přiznal.
3. Zkontrolujte zdraví backendu. Na load balanceru se podívejte, kolik členů prochází kontrolami. Nula zdravých členů je okamžitá odpověď.
4. Podívejte se na nasycení. Využití pracovních vláken a poolu spojení, paměť, databázová spojení a hloubku fronty. 503 pod zátěží se vším na stropu je kapacita, ne chyba.
5. Zkontrolujte závislosti. Pokud je nedostupná databáze, cache nebo kritické API, opravte to místo webové vrstvy.
6. Nejdřív ulevte zátěži, pak najděte příčinu. Škálování nebo zvýšení limitů obnoví službu, ale 503, které se objevilo bez nárůstu provozu, obvykle skrývá pomalý dotaz nebo únik, který se vrátí.

503 ve špičce a naplánovaná okna údržby

Přetížená 503 bývají zpočátku dlouho přerušovaná, než se stanou trvalými, objevují se ve špičce a sama odezní. Tuto ranou fázi je snadné z prohlížeče přehlédnout a v nepřetržitém záznamu je zjevná. Naplánovaná HTTP kontrola, která ověřuje očekávaný stavový kód, promění tato roztroušená selhání ve viditelný trend s připojenými časy, takže můžete jednat dřív, než se přerušovaná fáze stane výpadkem. Naplánování oken údržby ve stejném nástroji zabrání tomu, aby plánovaná 503 generovala upozornění.