Redaktørens notat: php-fpm bruker begrepet «master» for å beskrive sin primære prosess. Datadog bruker ikke dette begrepet. I dette blogginnlegget vil vi referere til dette som «primær», bortsett fra klarhetens skyld i tilfeller der vi må referere til et bestemt prosessnavn.

dette innlegget er en del av en serie om feilsøking AV NGINX 502 Bad Gateway-feil. Hvis du ikke bruker PHP-FPM, sjekk ut vår andre artikkel om feilsøking NGINX 502s Med Gunicorn som backend.PHP-FastCGI Process Manager (PHP-FPM) ER EN daemon for håndtering av webserverforespørsler FOR PHP-applikasjoner. I produksjon er PHP-FPM ofte distribuert bak EN NGINX webserver. NGINX proxyer web forespørsler og sender dem videre TIL PHP-FPM arbeidsprosesser som utfører PHP-programmet.

NGINX vil returnere en 502 Dårlig Gateway-feil hvis den ikke kan proxy en forespørsel TIL PHP-FPM, eller HVIS PHP-FPM ikke svarer. I dette innlegget vil vi undersøke noen vanlige årsaker til 502-feil i NGINX/PHP-FPM-stakken, og vi gir veiledning om hvor du kan finne informasjon som kan hjelpe deg med å løse disse feilene.

noen mulige årsaker til 502s

I denne delen beskriver Vi hvordan FØLGENDE forhold kan føre TIL AT NGINX returnerer en 502-feil:

• PHP-FPM kjører ikke
• NGINX kan ikke kommunisere MED PHP-FPM
• PHP-FPM er timing ut

HVIS NGINX ikke kan for å kommunisere med php-fpm av noen av disse grunnene, vil den svare med en 502-feil, Og Notere dette i tilgangsloggen (/var/log/nginx/access.logg) som vist i dette eksemplet:

127.0.0.1 - - "GET / HTTP/1.1" 502 182 "-" "curl/7.58.0"

NGINXS tilgangslogg forklarer ikke årsaken til en 502-feil, men du kan konsultere feilloggen (/var / log / nginx / error.logg) for å lære mer. For eksempel er her en tilsvarende oppføring i NGINX-feilloggen som viser at årsaken til 502-feilen er at kontakten ikke eksisterer, muligens fordi PHP-FPM ikke kjører. (I neste avsnitt ser vi på hvordan du oppdager og retter dette problemet.)

2020/01/31 18:30:55 13617#13617: *557 connect() to unix:/run/php/php7.2-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.2-fpm.sock:", host: "localhost"

PHP-FPM kjører ikke

Merk: DENNE delen inneholder et prosessnavn som bruker termen «master. Bortsett fra når det refereres til bestemte prosesser, bruker denne artikkelen begrepet «primær» i stedet.

HVIS PHP-FPM ikke kjører, VIL NGINX returnere en 502-feil for enhver forespørsel som er ment å nå PHP-programmet. Hvis du ser 502s, må du først kontrollere AT PHP-FPM kjører. For Eksempel, På En Linux-vert, kan du bruke en ps kommando som denne for å se etter kjører PHP-FPM prosesser:

sudo ps aux | grep 'php'

PHP-FPM organiserer sine arbeidsprosesser i grupper kalt bassenger. Eksempelutgangen nedenfor viser AT PHP-FPM-primærprosessen kjører, og det er to arbeidsprosesser i standardutvalget (kalt www):

root 29852 0.0 2.2 435484 22396 ? Ssl 16:27 0:00 php-fpm: master process (/etc/php/7.2/fpm/php-fpm.conf)www-data 29873 0.0 1.5 438112 15220 ? Sl 16:27 0:00 php-fpm: pool wwwwww-data 29874 0.0 1.6 438112 16976 ? Sl 16:27 0:00 php-fpm: pool www

Hvis utgangen avpskommandoen ikke viser NOEN PHP-fpm primære eller pool prosesser, må DU få PHP-FPM kjører for å løse 502 feil.

i et produksjonsmiljø bør du vurdere å bruke systemd til å kjøre PHP-FPM som en tjeneste. DETTE kan gjøre PHP-applikasjonen mer pålitelig og skalerbar, siden PHP-FPM-demonen automatisk begynner å betjene PHP-appen din når serveren starter eller når en ny forekomst starter. PHP-FPM er inkludert I PHP-kildekoden, slik at DU kan legge TIL PHP-FPM som en systemd-tjeneste når DU konfigurerer PHP.

NÅR PHP-fpm-prosjektet er konfigurert som en tjeneste, kan du bruke følgende kommando for å sikre at den starter automatisk når serveren starter:

sudo systemctl enable php7.2-fpm.service

Så kan du brukelist-unit-filesKommando FOR Å SE INFORMASJON om tjenesten din:

sudo systemctl list-unit-files | grep -E 'php*fpm'

på en php 7.2 server som HAR PHP-FPM installert (selv om den ikke kjører), vil utgangen av denne kommandoen være:

php7.2-fpm.service enabled

for å se informasjon om PHP-fpm-tjenesten, bruk denne kommandoen:

sudo systemctl is-active php7.2-fpm.service

denne kommandoen skal returnere en utgang avactive. Hvis det ikke gjør det, kan du starte tjenesten med:

sudo service php7.2-fpm start

NGINX får ikke tilgang til kontakten

NÅR PHP-FPM starter, oppretter DEN en ELLER flere Tcp-eller Unix-kontakter for å kommunisere med NGINX-webserveren. PHP-FPMS arbeidsprosesser bruker disse kontaktene til å lytte etter forespørsler fra NGINX.

for å finne ut om en 502-feil ble forårsaket av en feilkonfigurasjon i kontakten, må DU bekrefte AT PHP – FPM og NGINX er konfigurert til å bruke samme kontakt. PHP-FPM bruker en egen konfigurasjonsfil for hvert arbeidsprosessutvalg; disse filene er plassert på / etc / php / 7.2/fpm / pool.d/. Hver bassengs socket er definert i etlisten – direktiv i bassengs konfigurasjonsfil. For eksempel konfigurerer listen – direktivet nedenfor et basseng som heter mypool for å bruke En Unix-kontakt plassert på / run/php / mypool.sock:

listen = /run/php/mypool.sock

Hvis NGINX ikke kan få tilgang til kontakten for et bestemt utvalg, kan DU bestemme hvilket arbeidsbasseng som er involvert i problemet ved å sjekke hvilken kontakt som er navngitt i NGINX-feilloggoppføringen. FOR EKSEMPEL, hvis PHP-FPM ikke hadde startetmypoolarbeiderbasseng, VILLE NGINX returnere en 502 og feilloggoppføringen ville inkludere:

connect() to unix:/run/php/mypool.sock failed (2: No such file or directory)

Sjekk din nginx.conf-fil for å sikre at den relevantelocation – blokken angir samme kontakt. Eksemplet nedenfor inneholder et include-direktiv som laster inn noe generell konfigurasjonsinformasjon FOR PHP-FPM, og et fastcgi_pass – direktiv som angir Samme Unix-socket som heter i mypool.conf fil, ovenfor.

location / { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/mypool.sock;}

Unix-kontakter er underlagt Unix-filsystemtillatelser. PHP-FPM-bassengets konfigurasjonsfil angir modus og eierskap av kontakten, som vist her:

listen.owner = www-datalisten.group = www-datalisten.mode = 0660

Kontroller at disse tillatelsene tillater brukeren og gruppen som kjører NGINX å få tilgang til kontakten. HVIS tillatelsene på kontakten er feil, logger NGINX en 502-feil i tilgangsloggen, og en melding som den som vises nedenfor i feilloggen:

2020/02/20 17:12:03 3059#3059: *4 connect() to unix:/run/php/mypool.sock failed (13: Permission denied) while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/mypool.sock:", host: "localhost"

merk at standardverdiene forlisten.owneroglisten.groupsamsvarer med standard eier og gruppen kjører nginx, oglisten.modesom standard til 0660. VED hjelp av disse standardene skal NGINX kunne få tilgang til kontakten.

HVIS PHP-FPM lytter på EN tcp-kontakt, vil pool conifguration ‘ s listen direktivet ha en verdi i form av address:port, som vist nedenfor:

listen = 127.0.0.1:9000

På Samme Måte som Med En Unix-kontakt, kan du forhindre 502-feil ved å bekrefte at plasseringen av denne kontakten samsvarer med den som er angitt i NGINX-konfigurasjonen.

PHP-FPM er timing ut

hvis søknaden din tar for lang tid å svare, vil brukerne oppleve en timeout feil. HVIS PHP-FPMS timeout – som er satt i bassengkonfigurasjonens request_terminate_timeout – direktiv (og standard 20 sekunder) – er mindre ENN NGINXS timeout (som standard til 60 sekunder), SVARER NGINX med en 502-feil. NGINX-feilloggen vist nedenfor indikerer at oppstrømsprosessen-SOM ER PHP—FPM-lukket forbindelsen før du sendte et gyldig svar. Med andre ord, dette er feilloggen vi ser NÅR PHP-FPM ganger ut:

2020/02/20 17:17:12 3059#3059: *29 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/mypool.sock:", host: "localhost"

I dette tilfellet ER PHP-FPM-loggen (som som standard ligger på/var / log / php7.2-fpm.logg) viser en korrelert melding som gir ytterligere informasjon:

 WARNING: child 2120, script '/var/www/html/index.php' (request: "GET /index.php") execution timed out (25.755070 sec), terminating

DU kan heve PHP-FPM tidsavbruddsinnstilling ved å redigere bassengets konfigurasjonsfil, MEN DETTE kan føre til et annet problem: NGINX kan gå ut før DU mottar et svar FRA PHP-FPM. STANDARD NGINX timeout er 60 sekunder; HVIS DU har hevet PHP-FPM timeout over 60 sekunder, VIL NGINX returnere en 504 Gateway Timeout-feil hvis PHP-programmet ikke har svart i tide. Du kan forhindre dette ved å øke DIN NGINX timeout. I eksemplet nedenfor har vi økt tidsavbruddsverdien til 90 sekunder ved å legge tilfastcgi_read_timeout – elementet tilhttp blokk av /etc/nginx/nginx.conf:

http { ... fastcgi_buffers 8 16k; fastcgi_buffer_size 32k; fastcgi_connect_timeout 90; fastcgi_send_timeout 90; fastcgi_read_timeout 90;}

Last INN NGINX-konfigurasjonen for å bruke denne endringen:

nginx -s reload

neste, for å finne ut hvorfor PHP-FPM tidsavbrutt, kan du samle logger og application performance monitoring (APM) data som kan avsløre årsaker til ventetid i og utenfor programmet.

Samle og analysere loggene

for å feilsøke programfeil kan du samle loggene og sende dem til en loggbehandlingstjeneste. I TILLEGG TIL NGINX-loggene vi undersøkte ovenfor, KAN PHP logge feil og andre hendelser som kan være verdifulle for deg. Se VÅR PHP logging guide for mer informasjon.Når DU tar MED PHP-og NGINX-loggene dine i en loggadministrasjonstjeneste, kombinert med logger fra relevante teknologier som caching-servere og databaser, kan du analysere logger fra hele webstakken din i en enkelt plattform.

Samle APM-data fra webstakken

APM kan hjelpe deg med å identifisere flaskehalser og løse problemer, som 502-feil, som påvirker ytelsen til appen din. Skjermbildet nedenfor viser NGINXS APM-data visualisert I Datadog. Denne visningen oppsummerer forespørselsvolum, feilfrekvenser og ventetid for EN NGINX-basert tjeneste, og hjelper deg med å undersøke ytelsesproblemer som 502-feil.

200 OK

jo raskere du kan diagnostisere og løse programmets 502 feil, desto bedre. Datadog lar deg analysere beregninger, spor, logger og nettverksytelsesdata fra hele infrastrukturen. Hvis Du allerede Er En Datadog-kunde, kan du begynne å overvåke NGINX, PHP-FPM og mer than400 andre teknologier. Hvis Du ikke har En Datadog-konto ennå, registrer deg for en 14-dagers gratis prøveperiode og kom i gang på få minutter.