poznámka Editora: php-fpm používá termín „master“ popisovat jeho primární proces. Datadog tento termín nepoužívá. V rámci tohoto blogu, budeme odkazovat na to jako „primární,“ s výjimkou zájmu jasnosti v případech, kdy musíme odkazovat na konkrétní název procesu.

tento příspěvek je součástí série o odstraňování chyb NGINX 502 Bad Gateway. Pokud nepoužíváte PHP-FPM, podívejte se na náš další článek o řešení problémů NGINX 502s s Gunicorn jako backend.

PHP-FastCGI Process Manager (PHP-FPM) je démon pro zpracování požadavků webového serveru pro PHP aplikace. Ve výrobě je PHP-FPM často nasazován za webovým serverem NGINX. NGINX proxy web požaduje a předává je pracovníkům PHP-FPM, které provádějí aplikaci PHP.

NGINX vrátí 502 Bad Gateway chybu, pokud nemůže úspěšně proxy požadavek na PHP-FPM, nebo-li PHP-FPM nereaguje. V tomto příspěvku prozkoumáme některé běžné příčiny chyb 502 v zásobníku NGINX/PHP-FPM a poskytneme pokyny, kde najdete informace, které vám mohou pomoci tyto chyby vyřešit.

Některé možné příčiny 502s

V této části popíšeme, jak tyto podmínky mohou způsobit NGINX vrátit 502 error:

• PHP-FPM není spuštěna
• NGINX nemůže komunikovat s PHP-FPM
• PHP-FPM je načasování

Pokud NGINX je schopen komunikovat s PHP-FPM pro některý z těchto důvodů, to bude reagovat s chyba 502, berouce na vědomí to v jeho přístupu log (/var/log/nginx/přístup.log), jak je znázorněno v tomto příkladu:

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

NGINX je přístup k log nevysvětluje příčinu 502 error, ale můžete konzultovat své chyby log (/var/log/nginx/error.log) se dozvědět více. Zde je například odpovídající položka v protokolu chyb NGINX, která ukazuje, že příčinou chyby 502 je to, že soket neexistuje, možná proto, že PHP-FPM není spuštěn. (V další části se podíváme na to, jak tento problém zjistit a opravit.)

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 není spuštěna

Poznámka: Tento oddíl obsahuje název procesu, který používá termín „master.“S výjimkou případů, kdy se odkazuje na konkrétní procesy, tento článek místo toho používá termín „primární“.

Pokud PHP-FPM není spuštěn, vrátí NGINX chybu 502 pro jakýkoli požadavek určený k dosažení aplikace PHP. Pokud vidíte 502s, nejprve zkontrolujte, zda je spuštěn PHP-FPM. Například na Linux hostitele, můžete použít ps příkaz jako je tento pohled pro běh PHP-FPM procesy:

sudo ps aux | grep 'php'

PHP-FPM organizuje své pracovní procesy ve skupinách tzv. bazény. Ukázkový výstup níže ukazuje, že primární proces PHP-FPM je spuštěn, stejně jako dva pracovní procesy ve výchozím fondu (pojmenované 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

výstup ps příkaz nemá žádné PHP-FPM primární nebo bazén procesy, budete potřebovat, aby si PHP-FPM běží na vyřešení 502 chyby.

v produkčním prostředí byste měli zvážit použití systemd ke spuštění PHP-FPM jako služby. Díky tomu může být vaše aplikace PHP spolehlivější a škálovatelnější, protože démon PHP-FPM automaticky začne obsluhovat vaši aplikaci PHP při spuštění serveru nebo při spuštění nové instance. PHP-FPM je součástí zdrojového kódu PHP, takže můžete přidat PHP-FPM jako systemd službu při konfiguraci PHP.

Jakmile je váš PHP-FPM projekt je nakonfigurován jako služba, můžete použít následující příkaz k zajištění, že automaticky spustí, když server spustí:

sudo systemctl enable php7.2-fpm.service

můžete použít list-unit-files příkaz zobrazí informace o vaše služby:

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

Na PHP 7.2 serveru, který má PHP-FPM nainstalován (i když to není spuštěna), výstup tohoto příkazu bude:

php7.2-fpm.service enabled

Chcete-li zobrazit informace o PHP-FPM služby, použijte tento příkaz:

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

Tento příkaz by měl vrátit výstup active. Pokud tomu tak není, můžete službu spustit pomocí:

sudo service php7.2-fpm start

NGINX nemá přístup do zásuvky

Když PHP-FPM začíná, to vytvoří jeden nebo více TCP nebo Unix socketů, jak komunikovat s NGINX webový server. Pracovní procesy PHP-FPM používají tyto sokety k poslechu požadavků od NGINX.

Chcete-li zjistit, zda chyba 502 byla způsobena nesprávnou konfigurací soketu, potvrďte, že PHP-FPM a NGINX jsou nakonfigurovány pro použití stejného soketu. PHP-FPM používá samostatný konfigurační soubor pro každý fond pracovních procesů; tyto soubory jsou umístěny na /etc/php / 7.2 / fpm / pool.d/. Socket každého fondu je definován v direktivě listen v konfiguračním souboru fondu. Například listen směrnice níže konfiguruje bazén s názvem mypool použít Unix socket nachází na /run/php/mypool.sock:

listen = /run/php/mypool.sock

Pokud NGINX nemůže získat přístup k zásuvce pro konkrétní bazén, můžete určit, který pracovník bazén se podílí na problém tím, že kontrolu, která zásuvka je jmenován v NGINX error log entry. Pokud se například PHP-FPM nepodařilo spustit mypool Worker pool, NGINX vrátí 502 a jeho záznam protokolu chyb by zahrnoval:

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

Zkontrolujte, zda vaše nginx.soubor conf, který zajistí, že příslušný blok location určí stejný soket. Níže uvedený příklad obsahuje include směrnice, která načte nějaké obecné konfigurační údaje pro PHP-FPM, a fastcgi_pass směrnice, která určuje stejné Unix socket jménem v mypool.soubor conf, výše.

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

Unix zásuvky jsou předmětem Unix oprávnění systému souborů. Konfigurační soubor fondu PHP-FPM určuje režim a vlastnictví soketu, jak je ukázáno zde:

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

ujistěte Se, že tato oprávnění umožňují uživateli a skupině běží NGINX, aby přístup k zásuvce. Pokud oprávnění na zásuvky jsou nesprávné, NGINX se přihlásit 502 chyba v jeho přístupu protokol a zprávu, jako je uvedeno níže, v jeho protokolu chyb:

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"

Všimněte si, že výchozí hodnoty listen.ownerlisten.group odpovídal výchozí vlastník a skupina běží NGINX, a listen.mode výchozí 0660. Při použití těchto výchozích hodnot by měl mít NGINX přístup k soketu.

Pokud PHP-FPM naslouchá na TCP socket, bazén conifguration listen směrnice bude mít hodnotu v podobě address:port, jak je uvedeno níže:

listen = 127.0.0.1:9000

stejně jako s Unix socket, můžete zabránit 502 chyby tím, že potvrzuje, že umístění této zásuvce odpovídá jedné uvedeno v NGINX konfigurace.

PHP-FPM je timing out

Pokud vaše aplikace trvá příliš dlouho na odpověď, uživatelé zažijí chybu časového limitu. Pokud PHP-FPM je časový limit—který je nastaven v bazénu konfigurace request_terminate_timeout směrnice (výchozí hodnota je 20 sekund)—je méně než NGINX je časový limit (které výchozí hodnota je 60 sekund), NGINX bude reagovat s chyba 502. Níže uvedený protokol chyb NGINX ukazuje, že jeho upstream proces-což je PHP-FPM-uzavřel připojení před odesláním platné odpovědi. Jinými slovy, toto je protokol chyb, který vidíme, když PHP-FPM vyprší:

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"

V tomto případě, PHP-FPM log (které ve výchozím nastavení se nachází v souboru /var/log/php7.2-fpm.log) zobrazuje korelovanou zprávu, která poskytuje další informace:

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

můžete zvýšit PHP-FPM je nastavení časového limitu pomocí úpravy bazénu je konfigurační soubor, ale to by mohlo způsobit další problém: NGINX může časový limit dříve, než obdrží odpověď od PHP-FPM. Výchozí časový limit NGINX je 60 sekund; pokud jste zvýšili časový limit PHP-FPM nad 60 sekund, NGINX vrátí chybu časového limitu brány 504, pokud vaše aplikace PHP neodpověděla včas. Tomu můžete zabránit také zvýšením časového limitu NGINX. V příkladu níže jsme zvýšili hodnotu časového limitu 90 sekund tím, že přidá fastcgi_read_timeout prvek http blok /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;}

znovu Načíst konfigurace NGINX chcete tuto změnu použít:

nginx -s reload

Next, zjistit, proč PHP-FPM vypršel, můžete shromažďovat protokoly a application performance monitoring (APM) údaje, které mohou odhalit příčiny latence v rámci i mimo vaší aplikaci.

Sbírejte a analyzujte své protokoly

Chcete-li odstranit chyby aplikace, můžete své protokoly shromažďovat a odesílat do služby správy protokolů. Kromě protokolů NGINX, které jsme zkoumali výše, může PHP zaznamenávat chyby a další události, které by pro vás mohly být cenné. Další informace naleznete v našem průvodci logováním PHP.

když přinesete protokoly PHP a NGINX do služby správy protokolů v kombinaci s protokoly z příslušných technologií, jako jsou servery a databáze pro ukládání do mezipaměti, můžete analyzovat protokoly z celého webového zásobníku na jedné platformě.

Sbírat APM dat z webového zásobníku

APM může pomoci identifikovat překážky a řešit problémy, jako 502 chyby, které mají vliv na výkon vaší aplikace. Snímek obrazovky níže ukazuje data APM NGINX vizualizovaná v Datadogu. Tento pohled shrnuje objem požadavků, chybovost a latenci služby založené na NGINX a pomáhá vám vyšetřovat problémy s výkonem, jako jsou chyby 502.

200 OK

čím rychleji můžete diagnostikovat a vyřešit chyby 502 vaší aplikace, tím lépe. Datadog umožňuje analyzovat metriky, stopy, protokoly a údaje o výkonu sítě z celé vaší infrastruktury. Pokud jste již Datadog zákazník, můžete začít sledovat NGINX, PHP-FPM, a více než400 dalších technologií. Pokud ještě nemáte účet Datadog, zaregistrujte se na 14denní bezplatnou zkušební verzi a začněte během několika minut.