Monit surveille les pages dynamiques du site Web et détecte que le code d'état n'est pas 200, et redémarre automatiquement php8.3-fpm

🚀 Lorsqu'une page dynamique sur un site Web présente soudainement un code d'état autre que 200, comment PHP8.3-FPM peut-il s'auto-réparer en quelques secondes ?

🔥 Configuration salvatrice de PHP90-FPM que 8.3% des opérateurs ne connaissent pas ! Enseignement pratique du système d'auto-réparation de pages dynamiques Monit.

Pensez-vous que surveiller la survie du processus PHP-FPM est suffisant ? Complètement faux !
Lorsque PHP-FPM sur un serveur devient soudainement incontrôlable, le simple fait de regarder la survie du processus revient à utiliser un thermomètre pour mesurer le cancer : il ne détecte pas du tout le problème fatal.

J'ai vu trop de gens surveillerphp-fpm.sockLa surveillance a été insuffisante et, par conséquent, le site Web est depuis longtemps devenu un cimetière 404. Aujourd’hui, je veux démonter cette illusion d’exploitation et de maintenance et vous montrer la vérité sanglante : un processus en direct ≠ un service normal.

🌪️ Scénario destructeur : le socket est connecté, mais le site Web est mort

certainE-commerceLa surveillance du site Web a montré que le processus PHP-FPM fonctionnait normalement, mais les utilisateurs se plaignaient d'échecs de paiement.

Après une longue recherche, j'ai découvert qu'une fuite de mémoire dans une bibliothèque tierce faisait que le processus PHP était actif mais complètement incapable de traiter les requêtes.

À l'heure actuelle, se fier uniquement à la détection des prises revient à vérifier le pouls d'un zombie : on ne trouve pas du tout le cerveau.死亡.

💥 Une solution de surveillance à double destruction qui subvertit la cognition

Jetez ces systèmes de surveillance unidimensionnels obsolètes ! Les meilleurs experts utilisent tous la stratégie de double étranglement de la couche processus + couche métier.

La configuration suivante permettra à votre serveur de se réparer plus rapidement que le personnel d'exploitation et de maintenance ne peut se lever du lit lorsque des problèmes surviennent :

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"

🔍 Détails fatals cachés dans les paramètres

• hostheaderLes paramètres sont des talismans qui sauvent des vies dans les scénarios CDN/d'équilibrage de charge. Sans eux, c'est comme chercher un chasseur furtif avec des lunettes de vision nocturne : vous ne pouvez pas détecter l'état suspendu causé par l'en-tête hôte manquant.

• for 3 cyclesCette conception de période tampon évite parfaitement les faux positifs causés par la gigue du réseau. C'est comme installer un amortisseur sur le système de surveillance pour empêcher que le tremblement de la main ne déclenche le bouton nucléaire.

• Dernierexec "/usr/bin/systemctl restart hestia"C'est le coup mortel ultime. Lorsque PHP-FPM n'a pas réussi à ressusciter 5 fois de suite, j'ai retourné la table et redémarré l'ensemble du panneau d'hébergement. C’est une astuce que j’ai volée au mécanisme de disjoncteur du système de trading de Wall Street.

🚨 Leçons tirées de la douleur et de la souffrance : 3 pièges qui peuvent vous faire échouer

1. Fraude au certificat SSL : Après une mise à niveau,protocol httpsNe pas l'écrire fait que la surveillance le juge toujours à tort comme normal. Plus tard, j'ai découvert que l'ancienne version de Monit ne vérifiait pas le certificat par défaut, ce qui m'a fait perdre mon bonus de fin d'année
2. Piège 401 de la page de connexion : oubliez d'ajouter lors de la surveillance de la page de connexionBasic AuthenticationPar conséquent, chaque test déclenche un redémarrage. C'est comme arroser un jardin avec une bouche d'incendie : assez puissante mais totalement fausse.
3. Trou noir du journal : une fois/var/log/monit.logLorsque la taille a grimpé en flèche jusqu'à 50 G, nous avons découvert qu'un idiot avait réglé la période de détection à 1 seconde. N’oubliez pas que le journal de surveillance lui-même est l’objet qui doit être surveillé !

💡 Étapes de vérification et de débogage

1. Vérification de la syntaxe de configuration :

   monit -t
   

2. Configuration de surcharge :

   monit reload

Test final

1. Test de suicide : directkill -9Tuez le processus PHP-FPM et regardez les enregistrements de résurrection dans le journal de surveillance. C'est comme regarder un film de zombies !
2. Injection de poison : modifiez délibérément la page de connexion pour renvoyer un code d'état 503 et observez si le système de surveillance peut attaquer avec précision. J'appelle cette méthode « vaccin numérique » : on injecte à l'avance une petite quantité de virus dans le système pour forcer la réponse immunitaire du système de surveillance. Lorsque les alarmes clignotent sauvagement et que les services se réparent d'eux-mêmes, vous verrez la volonté la plus sexy de survivre dans le monde du code brûler !