Monit monitorea las páginas dinámicas del sitio web y detecta que el código de estado no es 200 y reinicia automáticamente php8.3-fpm

🚀 Cuando una página dinámica de un sitio web de repente tiene un código de estado distinto de 200, ¿cómo puede PHP8.3-FPM autocurarse en segundos?​​

¡La configuración salvavidas de PHP90-FPM que el 8.3% de los operadores no conocen! Enseñanza práctica del sistema de autocuración de páginas dinámicas de Monit.

¿Crees que es suficiente monitorear la supervivencia del proceso PHP-FPM? ¡Totalmente equivocado!
Cuando PHP-FPM en un servidor de repente deja de funcionar, simplemente observar la supervivencia del proceso es como usar un termómetro para medir el cáncer: no detecta en absoluto el problema fatal.

He visto demasiada gente haciendo guardia.php-fpm.sockEl seguimiento fue complaciente y, como resultado, el sitio web se ha convertido desde hace mucho tiempo en un cementerio de errores 404. Hoy quiero destrozar esa ilusión de operación y mantenimiento y mostrarles la cruda verdad: un proceso vivo ≠ un servicio normal.

🌪️ Escenario destructivo: el socket está conectado, pero el sitio web está inactivo

ciertoComercio electrónicoEl monitoreo del sitio web mostró que el proceso PHP-FPM estaba funcionando normalmente, pero los usuarios se quejaban de fallas en los pagos.

Después de una larga búsqueda, descubrí que una pérdida de memoria en una biblioteca de terceros hacía que el proceso PHP estuviera activo pero fuera completamente incapaz de procesar solicitudes.

En este momento, confiar únicamente en la detección del socket es como comprobar el pulso de un zombi: no se puede encontrar el cerebro en absoluto.死亡.

💥 Una solución de monitoreo de doble eliminación que subvierte la cognición

¡Deshazte de esos anticuados sistemas de monitorización unidimensional! Los mejores expertos utilizan la estrategia de doble estrangulamiento de la capa de proceso + capa de negocio.

La siguiente configuración permitirá que su servidor se recupere a sí mismo más rápido de lo que el personal de operación y mantenimiento puede levantarse de la cama cuando ocurren problemas:

check process php8.3-fpm with pidfile /run/php/php8.3-fpm.pid
    start program = "/usr/sbin/service php8.3-fpm start"
    stop program  = "/usr/sbin/service php8.3-fpm stop"
    if failed unixsocket /run/php/php8.3-fpm.sock then restart
    if failed 
        host www.chenweiliang.com 
        port 443
        protocol https
        request "/wp-login.php"
        status = 200
        hostheader www.chenweiliang.com
        for 3 cycles
    then restart
    if 5 restarts within 5 cycles then exec "/usr/bin/systemctl restart hestia"

🔍 Detalles fatales ocultos en los parámetros

• hostheaderLos parámetros son talismanes que salvan vidas en escenarios de equilibrio de carga/CDN. Sin ellos, es como buscar un caza furtivo con gafas de visión nocturna: no se puede detectar el estado de suspensión causado por el encabezado de Host faltante.

• for 3 cyclesEste diseño de período de búfer evita perfectamente los falsos positivos provocados por la vibración de la red. Es como instalar un amortiguador en el sistema de vigilancia para impedir que el movimiento de la mano active el botón nuclear.

• Últimoexec "/usr/bin/systemctl restart hestia"Es el movimiento asesino definitivo. Cuando PHP-FPM no pudo resucitar 5 veces seguidas, giré la tabla y reinicié todo el panel de alojamiento. Este es un truco que robé del mecanismo de disyuntor del sistema de comercio de Wall Street.

Lecciones aprendidas del dolor y el sufrimiento: 3 trampas que pueden hacerte fracasar

1. Fraude de certificado SSL: después de una actualización,protocol httpsNo escribirlo provoca que el monitor siempre lo juzgue erróneamente como normal. Luego me enteré que la versión antigua de Monit no verificaba el certificado por defecto, lo que me hizo perder mi bono de fin de año.
2. Trampa 401 en la página de inicio de sesión: olvídese de agregarla al monitorear la página de inicio de sesiónBasic AuthenticationComo resultado, cada prueba desencadena un reinicio. Es como regar un jardín con una boca de incendios: es bastante fuerte, pero totalmente erróneo.
3. Agujero negro de registro: una vez/var/log/monit.logCuando el tamaño se disparó a 50G, descubrimos que algún idiota había establecido el período de detección en 1 segundo. Recuerde que el registro de monitoreo en sí es el objeto que necesita ser monitoreado.

💡 Pasos de verificación y depuración

1. Comprobación de la sintaxis de configuración:

   monit -t
   

2. Configuración de sobrecarga:

   monit reload

Prueba final

1. Prueba de suicidio: directakill -9Elimine el proceso PHP-FPM y observe los registros de resurrección en el registro de monitoreo. ¡Parece como ver una película de zombies!
2. Inyección de veneno: modificar deliberadamente la página de inicio de sesión para que devuelva un código de estado 503 y observar si el sistema de monitoreo puede atacar con precisión. Yo llamo a este método “vacuna digital”: inyectar una pequeña cantidad de virus en el sistema con antelación para forzar la respuesta inmune del sistema de monitoreo. Cuando las alarmas parpadeen descontroladamente y los servicios se recuperen a sí mismos, ¡verás la voluntad más sexy de sobrevivir en el mundo del código ardiendo!