Fel som försvinner precis när du letar. Orsaker till intermittenta 502/503, varför de är svåra att fånga för hand och hur loggar och kontinuerlig mätning avslöjar mönstret.

De mest frustrerande felen är de som försvinner precis när du börjar leta. En besökare rapporterar en 502 Bad Gateway, du laddar om sidan och allt fungerar. En timme senare händer det igen, för någon annan. Intermittenta 502- och 503-fel är svåra just för att de är sporadiska, och de går sällan att återskapa på begäran. Här går vi igenom vad som orsakar dem och hur du fångar ett fel du inte kan framkalla.

Vad 502 och 503 faktiskt betyder

Båda koderna kommer oftast från en webbserver eller lastbalanserare som ligger framför din applikation. En 502 Bad Gateway betyder att den främre servern skickade en förfrågan vidare men fick ett ogiltigt eller inget svar tillbaka från uppströmstjänsten, till exempel PHP. En 503 Service Unavailable betyder att tjänsten tillfälligt inte kan hantera förfrågan, ofta på grund av överbelastning eller en pågående omstart. I båda fallen är det oftast lagret bakom webbservern som sviktar, inte webbservern själv.

Vanliga orsaker

PHP-FPM-mättnad. Om alla PHP-FPM-arbetare är upptagna hamnar nya förfrågningar i kö och tar till slut timeout, vilket ger 502 eller 503. Detta uppstår vid trafiktoppar eller när enskilda anrop är onormalt långsamma.
Uppströms timeout. Webbservern väntar bara ett visst antal sekunder på PHP. Ett långsamt databasanrop eller ett externt API som hänger sig kan få webbservern att ge upp och svara 502.
Minnesbrist. När processer slår i minnestaket dödas de av systemet, och pågående förfrågningar avbryts mitt i.
Omstarter och driftsättningar. Under en omstart av PHP-FPM eller webbservern finns ett kort fönster där förfrågningar kan avvisas, vilket ger tillfälliga 502/503.

Varför de är så svåra att fånga för hand

Ett intermittent fel dyker upp kanske några gånger i timmen, ofta bara under last, och är borta innan du hinner öppna en terminal. När du testar manuellt är chansen liten att du råkar träffa exakt den sekund det inträffar. Dessutom drabbar felet ofta bara en delmängd av besökarna, så din egen upplevelse säger dig att "allt fungerar". Utan kontinuerlig mätning ser du bara enstaka klagomål utan mönster.

Det finns också en psykologisk fälla. Eftersom felet försvinner när du tittar är det lätt att avfärda det som ett engångsfel eller att skylla på besökarens uppkoppling. Men ett fel som återkommer, om än sällan, är nästan alltid ett symptom på en underliggande resursbrist som växer med trafiken. Ju längre det får vara ifred, desto oftare slår det till.

Kontrollera server- och PHP-loggar

Loggarna är din bästa källa till sanning eftersom de fångar felet i stunden. Titta på:

Webbserverns felloggar (nginx eller Apache) efter rader om "upstream timed out", "connection refused" eller "no live upstreams" med exakta tidsstämplar.
PHP-FPM-loggen efter varningar om "server reached max_children", vilket är ett tydligt tecken på arbetarbrist.
PHP-felloggen och WordPress debug.log efter fatala fel och minnesfel vid samma tidpunkter.
Systemloggen (till exempel dmesg) efter OOM-killer som dödat processer på grund av minnesbrist.

Nyckeln är att korrelera tidsstämplarna. Om en 502 i webbserverloggen inträffar exakt när PHP-FPM rapporterar max_children, har du hittat mönstret.

Snabba första åtgärder

Medan du gräver i loggarna finns det några åtgärder som ofta lindrar symptomen och samtidigt ger ledtrådar:

Höj antalet PHP-FPM-arbetare försiktigt om servern har minne kvar, och se om felen minskar. Gör de det pekar det mot mättnad.
Öka timeout-värdet mot uppströmstjänsten en aning. Försvinner 502:orna var orsaken långsamma svar, inte krascher.
Titta på minnesanvändningen under en trafiktopp. Ett tydligt tak som nås strax innan felen är ett starkt tecken på minnesbrist.

Var försiktig så att du inte bara döljer problemet. Att höja timeouts kan gömma en långsam databasfråga som egentligen borde optimeras. Åtgärderna är till för att bekräfta orsaken, inte ersätta en riktig lösning.

Så gör du det osynliga synligt med Ravnsight

Det du saknar när du felsöker för hand är just kontinuitet och historik. Ravnsight kör kontroller minut för minut från flera geografiska platser, dygnet runt. När ett intermittent 502 eller 503 slår till fångar vi det medan det pågår, med en fullständig nedbrytning av svarstiden, så att du ser om det var DNS, anslutning, TLS eller väntan på servern som brast. Eftersom vi bekräftar en misslyckad kontroll från en andra plats innan vi larmar vet du att felet är verkligt. Framför allt ger historiken dig mönstret: du ser att felen klustrar vid trafiktoppar eller började direkt efter en driftsättning. Vi säger korrelerat, inte att vi definitivt vet orsaken, men det pekar dig rakt mot rätt logg och rätt fönster i tiden.