NGINX 502 Bad Gateway: PHP-FPM
nota del Editor: php-fpm utiliza el término «maestro» para describir su proceso de primarias. Datadog no utiliza este término. Dentro de esta publicación de blog, nos referiremos a esto como «primario», excepto en aras de la claridad en casos en los que debemos hacer referencia a un nombre de proceso específico.
Esta publicación es parte de una serie sobre la solución de problemas de errores de puerta de enlace incorrecta de NGINX 502. Si no está utilizando PHP-FPM, consulte nuestro otro artículo sobre solución de problemas de NGINX 502s con Gunicorn como backend.
PHP-FastCGI Process Manager (PHP-FPM) es un demonio para el manejo de solicitudes de servidor web para aplicaciones PHP. En producción, PHP-FPM a menudo se implementa detrás de un servidor web NGINX. NGINX proxies solicitudes web y las pasa a los procesos de trabajo PHP-FPM que ejecutan la aplicación PHP.
NGINX devolverá un error de puerta de enlace defectuosa 502 si no puede proxy correctamente una solicitud a PHP-FPM, o si PHP-FPM no responde. En esta publicación, examinaremos algunas causas comunes de errores 502 en la pila NGINX/PHP-FPM, y proporcionaremos orientación sobre dónde puede encontrar información que pueda ayudarlo a resolver estos errores.
Explore las métricas, los registros y los rastros detrás de los errores de puerta de enlace defectuosos de NGINX 502 con Datadog.
Algunas posibles causas de 502s
En esta sección, describiremos cómo las siguientes condiciones pueden hacer que NGINX devuelva un error 502:
- PHP-FPM no se ejecuta
- NGINX no puede comunicarse con PHP-FPM
- PHP-FPM está fuera de tiempo
Si NGINX no puede comunicarse con PHP-FPM por cualquiera de estas razones, responderá con un error 502, anotándolo en su registro de acceso (/var/log/nginx/access.log) como se muestra en este ejemplo:
acceso.registro
127.0.0.1 - - "GET / HTTP/1.1" 502 182 "-" "curl/7.58.0"NGINX del registro de acceso no explicar la causa de un error 502, pero usted puede consultar su error log (/var/log/nginx/error.log) para obtener más información. Por ejemplo, aquí hay una entrada correspondiente en el registro de errores de NGINX que muestra que la causa del error 502 es que el socket no existe, posiblemente porque PHP-FPM no se está ejecutando. (En la siguiente sección, veremos cómo detectar y corregir este problema.)
error.registro
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 no se está ejecutando
Nota: Esta sección incluye un nombre de proceso que se utiliza el término «maestro.»Excepto cuando se refiere a procesos específicos, este artículo utiliza el término «primario» en su lugar.
Si PHP-FPM no se está ejecutando, NGINX devolverá un error 502 para cualquier solicitud destinada a llegar a la aplicación PHP. Si está viendo 502s, compruebe primero que PHP-FPM se está ejecutando. Por ejemplo, en Linux, puede utilizar un ps comando como este para buscar ejecutando PHP-FPM procesos:
sudo ps aux | grep 'php'PHP-FPM y organiza sus procesos de trabajo en grupos llamados piscinas. La salida de ejemplo a continuación muestra que el proceso primario PHP-FPM se está ejecutando, al igual que dos procesos de trabajo en el grupo predeterminado (llamado 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 wwwSi la salida de la etiqueta ps comando no muestra ninguna PHP-FPM primaria o a la piscina procesos, usted necesita para obtener PHP-FPM ejecución para resolver el 502 errores.
En un entorno de producción, debería considerar usar systemd para ejecutar PHP-FPM como servicio. Esto puede hacer que su aplicación PHP sea más confiable y escalable, ya que el demonio PHP-FPM comenzará a servir automáticamente su aplicación PHP cuando se inicie su servidor o cuando se inicie una nueva instancia. PHP-FPM está incluido en el código fuente de PHP, por lo que puede agregar PHP-FPM como un servicio systemd cuando configure PHP.
una Vez que su PHP-FPM proyecto se configura como un servicio, puede utilizar el comando siguiente para asegurarse de que se inicia automáticamente cuando el servidor se inicia:
sudo systemctl enable php7.2-fpm.servicea Continuación, puede utilizar la etiqueta list-unit-files comando para ver la información acerca de su servicio:
sudo systemctl list-unit-files | grep -E 'php*fpm'En PHP 7.2 servidor que tiene PHP-FPM instalado (incluso si no se está ejecutando), la salida de este comando será:
php7.2-fpm.service enabledPara ver la información acerca de PHP-FPM servicio, utilice este comando:
sudo systemctl is-active php7.2-fpm.serviceEste comando debe devolver una salida de active. Si no lo hace, puede iniciar el servicio con:
sudo service php7.2-fpm startNGINX no puede acceder al socket
Cuando PHP-FPM se inicia, crea uno o más de TCP o Unix sockets para comunicarse con el NGINX servidor web. Los procesos de trabajo de PHP-FPM usan estos sockets para escuchar solicitudes de NGINX.
Para determinar si un error 502 fue causado por una mala configuración de socket, confirme que PHP-FPM y NGINX están configurados para usar el mismo socket. PHP-FPM utiliza un archivo de configuración separado para cada grupo de procesos de trabajo; estos archivos se encuentran en /etc/php/7.2/fpm/pool.d. El socket de cada grupo se define en una directiva listen en el archivo de configuración del grupo. Por ejemplo, la directiva listen a continuación configura un grupo llamado mypool para usar un socket Unix ubicado en /run/php/mypool.calcetín:
mypool.conf
listen = /run/php/mypool.sock Si NGINX no puede acceder al socket de un grupo en particular, puede determinar qué grupo de trabajo está involucrado en el problema comprobando qué socket se nombra en la entrada de registro de errores de NGINX. Por ejemplo, si PHP-FPM no pudo iniciar el grupo de trabajadores mypool, NGINX devolvería un 502 y su entrada de registro de errores incluiría: error
.registro
connect() to unix:/run/php/mypool.sock failed (2: No such file or directory)Revise su nginx.archivo de configuración para garantizar que el bloque location especifica el mismo socket. El siguiente ejemplo contiene una directiva include que carga información general de configuración para PHP-FPM, y una directiva fastcgi_pass que especifica el mismo socket Unix nombrado en mypool.archivo de configuración, arriba.
nginx.conf
location / { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/mypool.sock;}Unix sockets están sujetos a Unix permisos de sistema de archivo. El archivo de configuración del pool PHP-FPM especifica el modo y la propiedad del socket, como se muestra aquí:
www.conf
listen.owner = www-datalisten.group = www-datalisten.mode = 0660asegúrese de que estos permisos permiten al usuario y de grupo en ejecución NGINX para acceder al socket. Si los permisos en el socket son incorrectos, NGINX registrará un error 502 en su registro de acceso y un mensaje como el que se muestra a continuación en su registro de errores: error
.registro
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"tenga en cuenta que los valores por defecto de listen.owner y listen.group coincide con el valor predeterminado de usuario y de grupo en ejecución NGINX, y listen.mode valor por defecto 0660. Usando estos valores predeterminados, NGINX debería poder acceder al socket.
Si PHP-FPM está escuchando en un socket TCP, la directiva conifguration listen tendrá un valor en forma de address:port, como se muestra a continuación:
www.conf
listen = 127.0.0.1:9000al igual que con un socket de Unix, puede evitar 502 errores mediante la confirmación de que la ubicación de este socket coincide con la especificada en la configuración de NGINX.
PHP-FPM se está agotando el tiempo de espera
Si su aplicación tarda demasiado en responder, sus usuarios experimentarán un error de tiempo de espera. Si el tiempo de espera de PHP-FPM, que se establece en la directiva request_terminate_timeout de la configuración del grupo (y por defecto es de 20 segundos), es menor que el tiempo de espera de NGINX (que por defecto es de 60 segundos), NGINX responderá con un error 502. El registro de errores de NGINX que se muestra a continuación indica que su proceso ascendente, que es PHP-FPM, cerró la conexión antes de enviar una respuesta válida. En otras palabras, este es el registro de errores que vemos cuando se agota el tiempo de espera de PHP-FPM: error
.registro
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"En este caso, el PHP-FPM registro (que por defecto se encuentra en /var/log/php7.2-fpm.log) muestra un mensaje correlacionado que proporciona más información:
php7.2-fpm.log
WARNING: child 2120, script '/var/www/html/index.php' (request: "GET /index.php") execution timed out (25.755070 sec), terminating Puede generar la configuración de tiempo de espera de PHP-FPM editando el archivo de configuración del grupo, pero esto podría causar otro problema: NGINX puede esperar antes de recibir una respuesta de PHP-FPM. El tiempo de espera de NGINX predeterminado es de 60 segundos; si ha aumentado el tiempo de espera de PHP-FPM por encima de los 60 segundos, NGINX devolverá un error de tiempo de espera de puerta de enlace 504 si su aplicación PHP no ha respondido a tiempo. Puede evitar esto aumentando también el tiempo de espera de NGINX. En el ejemplo siguiente, hemos aumentado el valor de tiempo de espera a 90 segundos agregando el elemento fastcgi_read_timeout al bloque http de /etc/nginx/nginx.conf:
nginx.conf
http { ... fastcgi_buffers 8 16k; fastcgi_buffer_size 32k; fastcgi_connect_timeout 90; fastcgi_send_timeout 90; fastcgi_read_timeout 90;}volver a Cargar la configuración de NGINX para aplicar este cambio:
nginx -s reloadA continuación, para determinar por qué se agotó el tiempo de espera de PHP-FPM, puede recopilar registros y datos de monitoreo de rendimiento de aplicaciones (APM) que pueden revelar causas de latencia dentro y fuera de su aplicación.
Recopile y analice sus registros
Para solucionar errores de aplicación, puede recopilar sus registros y enviarlos a un servicio de administración de registros. Además de los registros de NGINX que examinamos anteriormente, PHP puede registrar errores y otros eventos que podrían ser valiosos para usted. Consulte nuestra guía de registro PHP para obtener más información.
Cuando lleva sus registros PHP y NGINX a un servicio de administración de registros, combinados con registros de tecnologías relevantes como servidores de almacenamiento en caché y bases de datos, puede analizar los registros de toda su pila web en una sola plataforma.
Recopile datos de APM de su pila web
APM puede ayudarlo a identificar cuellos de botella y resolver problemas, como errores 502, que afectan el rendimiento de su aplicación. La siguiente captura de pantalla muestra los datos APM de NGINX visualizados en Datadog. Esta vista resume el volumen de solicitudes, las tasas de error y la latencia de un servicio basado en NGINX y le ayuda a investigar problemas de rendimiento como los errores 502.
200 OK
Cuanto más rápido pueda diagnosticar y resolver los errores 502 de su aplicación, mejor. Datadog le permite analizar métricas, rastros, registros y datos de rendimiento de red de toda su infraestructura. Si ya es cliente de Datadog, puede comenzar a monitorear NGINX, PHP-FPM y más de 400 tecnologías más. Si aún no tienes una cuenta de registro de datos, regístrate para una prueba gratuita de 14 días y comienza en minutos.
Leave a Reply