szerkesztő megjegyzése: A php-fpm a “mester” kifejezést használja az elsődleges folyamat leírására. Datadog nem használja ezt a kifejezést. Ezen a blogbejegyzésen belül ezt “elsődlegesnek” nevezzük, kivéve az egyértelműség kedvéért azokban az esetekben, amikor egy adott folyamat nevére kell hivatkoznunk.

Ez a bejegyzés egy sorozat része a NGINX 502 rossz átjáró hibaelhárításáról. Ha nem használja a PHP-FPM, nézd meg a másik cikket hibaelhárítás NGINX 502S a Gunicorn, mint egy backend.

PHP-FastCGI Process Manager (PHP-FPM) egy démon kezelésére webszerver kérelmek PHP alkalmazások. A gyártás során a PHP-FPM gyakran egy NGINX webszerver mögött kerül telepítésre. Az NGINX támogatja a webes kéréseket, majd továbbítja azokat a PHP-FPM worker folyamatoknak, amelyek végrehajtják a PHP alkalmazást.

NGINX visszatér egy 502 rossz átjáró hiba, ha nem tudja sikeresen proxy kérés PHP-FPM, vagy ha PHP-FPM nem válaszol. Ebben a bejegyzésben megvizsgáljuk az NGINX / PHP-fpm verem 502 hibájának néhány gyakori okát, és útmutatást adunk arról, hogy hol találhat olyan információkat, amelyek segítenek megoldani ezeket a hibákat.

az 502S

néhány lehetséges oka ebben a szakaszban leírjuk, hogy a következő feltételek hogyan okozhatják az NGINX 502-es hiba visszatérését:

• PHP-FPM nem fut
• NGINX nem tud kommunikálni a PHP-FPM
• PHP-FPM-vel.a php-fpm-vel való kommunikációhoz ezen okok bármelyikével 502 hibával válaszol, megjegyezve ezt a hozzáférési naplójában (/var/log/nginx/access).log) a példa szerint:

  hozzáférés.log

  Copy

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

  NGINX hozzáférési naplója nem magyarázza meg az 502-es hiba okát, de megnézheti a hibanaplóját (/var/log / nginx / error.log), hogy többet. Például itt van egy megfelelő bejegyzés az NGINX hibanaplóban, amely azt mutatja, hogy az 502 hiba oka az, hogy az aljzat nem létezik, valószínűleg azért, mert a PHP-FPM nem fut. (A következő részben megvizsgáljuk, hogyan lehet felismerni és kijavítani ezt a problémát.)

  hiba.log

  Copy

  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 nem fut

  Megjegyzés: Ez a szakasz tartalmaz egy folyamatnevet, amely a “mester” kifejezést használja.”Kivéve, ha konkrét folyamatokra utal, ez a cikk az “elsődleges” kifejezést használja.

  Ha a PHP-FPM nem fut, az NGINX 502 hibát fog visszaadni a PHP alkalmazás eléréséhez szükséges bármely kéréshez. Ha 502S-t lát, először ellenőrizze, hogy a PHP-FPM fut-e. Például egy Linux host, akkor egyps parancs, mint ez, hogy keresse meg a futó PHP-FPM folyamatok:

  sudo ps aux | grep 'php'

  PHP-FPM szervezi a munkavállaló folyamatok csoportokban úgynevezett medencék. Az alábbi minta kimenet azt mutatja, hogy a PHP-FPM elsődleges folyamat fut, csakúgy, mint az alapértelmezett készletben lévő két munkafolyamat (www):

  Copy

  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

  Ha a kimenet a ps parancs nem mutat semmilyen PHP-FPM elsődleges vagy pool folyamatok, akkor kell, hogy PHP-FPM fut, hogy megoldja a 502 hibák.

  termelési környezetben fontolóra kell vennie a systemd használatát a PHP-FPM szolgáltatásként történő futtatásához. Ez megbízhatóbbá és skálázhatóbbá teheti a PHP alkalmazást, mivel a PHP-FPM démon automatikusan elkezdi kiszolgálni a PHP alkalmazást, amikor a szerver elindul, vagy amikor egy új példány elindul. PHP-FPM szerepel a PHP forráskód, így hozzá PHP-FPM, mint a systemd szolgáltatás, Ha beállítja a PHP.

  Ha a PHP-FPM project úgy van beállítva, mint egy szolgáltatás, akkor használja a következő parancsot annak érdekében, hogy automatikusan elindul, amikor a kiszolgáló indításakor:

  Másolás

  sudo systemctl enable php7.2-fpm.service

  Akkor használhatjuk a list-unit-files parancsot, hogy lásd, információk a szolgáltatás:

  Másolás

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

  A PHP 7.2 szerver van a PHP-FPM telepített (még akkor is, ha nem fut), a kimenet ez a parancs lesz:

  Másolás

  php7.2-fpm.service enabled

  információkat a PHP-FPM szolgáltatás, használd ezt a parancsot:

  Másolás

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

  Ez a parancs, vissza kell adnia egy kimenetet a active. Ha nem, akkor elindíthatja a szolgáltatást:

  Copy

  sudo service php7.2-fpm start

  NGINX nem tud hozzáférni a socket

  a PHP-FPM indításakor létrehoz egy vagy több TCP vagy Unix aljzatot az NGINX webszerverrel való kommunikációhoz. A PHP-FPM munkavállalói folyamatai ezeket az aljzatokat használják a NGINX kéréseinek meghallgatására.

  annak megállapításához, hogy egy 502-es hibát egy socket hibás konfigurációja okozott-e, erősítse meg, hogy a PHP-FPM és NGINX ugyanazt a foglalatot használja. PHP-FPM használ egy külön konfigurációs fájl minden munkavállaló folyamat medence; ezek a fájlok találhatók / etc / php / 7.2 / fpm / pool.d/. Minden egyes medence aljzatát egy listen direktíva határozza meg a medence konfigurációs fájljában. Például az alábbilisten irányelv egymypool nevű állományt konfigurál a /run/php/mypool-on található Unix aljzat használatához.sock:

  mypool.conf

  Másolás

  listen = /run/php/mypool.sock

  Ha a NGINX nem tud hozzáférni a socket egy adott medence, meghatározható, hogy melyik munkás medence vesz részt a kérdés, ellenőrzésével, amely socket neve a NGINX error log bejegyzés. Ha például a PHP-FPM nem tudta elindítani a mypool worker pool-t, akkor az NGINX egy 502-es értéket ad vissza, és a hibanapló bejegyzés a következőket tartalmazza:

  hiba.log

  Copy

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

  ellenőrizze nginx.conf Fájl annak biztosítására ,hogy a megfelelőlocation blokk ugyanazt az aljzatot adja meg. Az alábbi példa egy include irányelvet tartalmaz, amely betölt néhány általános konfigurációs információt a PHP-FPM-hez, valamint egy fastcgi_pass irányelvet, amely ugyanazt a Unix-aljzatot határozza meg, amelyet a mypool-ban neveztek el.conf fájl, felett.

  nginx.conf

  Copy

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

  Unix sockets a Unix fájlrendszer engedélyeinek hatálya alá tartoznak. A PHP-FPM pool konfigurációs fájlja meghatározza az aljzat módját és tulajdonjogát, ahogy itt látható:

  www.conf

  Copy

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

  győződjön meg róla, hogy ezek az engedélyek lehetővé teszik a NGINX-et futtató felhasználó és csoport számára az aljzat elérését. Ha az aljzat engedélyei helytelenek, az NGINX naplóz egy 502-es hibát a hozzáférési naplójában, valamint egy olyan üzenetet, mint az alább látható a hibanaplóban:

  hiba.log

  Copy

  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"

  vegye figyelembe, hogy alisten.owneréslisten.groupmegfelel az alapértelmezett tulajdonosnak és csoport fut nginx, éslisten.mode alapértelmezés szerint 0660. Ezekkel az alapértelmezett értékekkel az NGINX-nek képesnek kell lennie az aljzat elérésére.

  Ha a PHP-FPM TCP-aljzaton hallgat, akkor a pool conifguration listen direktívája értéke address:port, az alábbiak szerint:

  www.conf

  Copy

  listen = 127.0.0.1:9000

  csakúgy, mint egy Unix foglalat esetében, megakadályozhatja az 502 hibát, ha megerősíti, hogy a foglalat helye megegyezik az NGINX konfigurációban megadottal.

  PHP-FPM időzítése ki

  Ha az alkalmazás túl sokáig tart, hogy válaszoljon, a felhasználók tapasztalnak timeout hiba. Ha a PHP—FPM időtúllépése-amely a pool konfiguráció request_terminate_timeout direktívájában van beállítva (alapértelmezés szerint 20 másodperc) – kisebb, mint az NGINX időtúllépése (amely alapértelmezés szerint 60 másodperc), az NGINX 502 hibával válaszol. Az alábbiakban látható NGINX hibanapló azt jelzi, hogy az upstream folyamata—amely PHP-FPM—lezárta a kapcsolatot, mielőtt érvényes választ küldött volna. Más szavakkal, ez a hibanapló, amelyet a PHP-FPM időkorlátozásakor látunk:

  hiba.log

  Copy

  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"

  ebben az esetben a PHP-FPM napló (amely alapértelmezés szerint a / var / log / php7.2-fpm.log) Korrelált üzenetet jelenít meg, amely további információkat nyújt:

  php7.2-fpm.log

  Copy

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

  a PHP-FPM timeout beállítását a pool konfigurációs fájljának szerkesztésével növelheti, de ez újabb problémát okozhat: az NGINX időt vehet igénybe, mielőtt PHP-FPM választ kapna. Az alapértelmezett NGINX időtúllépés 60 másodperc; ha a PHP-FPM időtúllépését 60 másodperc fölé emelte, az NGINX 504 átjáró időtúllépési hibát fog visszaadni, ha a PHP alkalmazás nem válaszolt időben. Ezt megakadályozhatja azáltal is, hogy növeli a NGINX időtúllépését. Az alábbi példában a fastcgi_read_timeout elemet hozzáadtuk a http /etc/nginx/nginx blokkhoz.conf:

  nginx.conf

  Copy

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

  töltse újra NGINX konfigurációját a módosítás alkalmazásához:

  Másolás

  nginx -s reload

  a Következő meghatározni, miért PHP-FPM időzített ki, lehet gyűjteni a naplók, illetve alkalmazás teljesítmény monitoring (APM) adatok is mutatják oka a látencia belül, mind azon kívül, a kérelmet.

  Gyűjtse össze és elemezze a naplókat

  az alkalmazáshibák elhárításához Gyűjtse össze a naplókat, majd küldje el azokat egy naplókezelő szolgáltatásnak. A fent megvizsgált NGINX naplók mellett a PHP naplózhat hibákat és egyéb eseményeket, amelyek értékesek lehetnek az Ön számára. További információkért tekintse meg a PHP naplózási útmutatóját.

  amikor a PHP és NGINX naplóit egy naplókezelő szolgáltatásba hozza, a releváns technológiák, például a gyorsítótárazószerverek és adatbázisok naplóival kombinálva, egyetlen platformon elemezheti a naplókat az egész webes veremből.

  

  gyűjtsük össze az APM adatokat a web stack

  APM segítségével azonosítani szűk keresztmetszetek és problémák megoldására, mint 502 hibák, amelyek befolyásolják a teljesítményét az alkalmazás. Az alábbi képernyőképen NGINX APM-adatai láthatók a Datadog – ban. Ez a nézet összefoglalja a kérés mennyiségét, a hibaarányt és a késleltetést egy NGINX-alapú szolgáltatáshoz, és segít megvizsgálni az olyan teljesítményproblémákat, mint az 502 hibák.

  

  200 OK

  minél gyorsabban tudja diagnosztizálni és megoldani az alkalmazás 502 hibáját, annál jobb. Datadog lehetővé teszi, hogy elemezze mutatók, nyomok, naplók, valamint a hálózati teljesítmény adatokat az egész infrastruktúra. Ha már Datadog-ügyfél vagy, elkezdheted a NGINX, PHP-FPM és több mint 400 egyéb technológia felügyeletét. Ha még nincs Datadog-fiókja, iratkozzon fel egy 14 napos ingyenes próbaverzióra, majd kezdje el percek alatt.