Monit monitora le pagine dinamiche del sito web e rileva che il codice di stato non è 200 e riavvia automaticamente php8.3-fpm

🚀 Quando una pagina dinamica di un sito web presenta improvvisamente un codice di stato diverso da 200, come può PHP8.3-FPM autoripararsi in pochi secondi?

🔥 Configurazione salvavita PHP90-FPM che il 8.3% degli operatori non conosce! Insegnamento pratico del sistema di auto-riparazione delle pagine dinamiche Monit.

Pensi che monitorare la sopravvivenza del processo PHP-FPM sia sufficiente? Completamente sbagliato!
Quando PHP-FPM su un server improvvisamente impazzisce, limitarsi a osservare la sopravvivenza del processo è come usare un termometro per misurare il cancro: non rileva affatto il problema fatale.

Ho visto troppe persone fare la guardiaphp-fpm.sockIl monitoraggio è stato sbrigativo e, di conseguenza, il sito web è da tempo diventato un cimitero di errori 404. Oggi voglio fare a pezzi questa illusione di gestione e manutenzione e mostrarvi la cruda verità: un processo in tempo reale ≠ un servizio normale.

🌪️ Scenario distruttivo: il socket è connesso, ma il sito web non funziona

certofornitore di energia elettricaIl monitoraggio del sito web ha mostrato che il processo PHP-FPM funzionava normalmente, ma gli utenti lamentavano problemi di pagamento.

Dopo una lunga ricerca, ho scoperto che una perdita di memoria in una libreria di terze parti faceva sì che il processo PHP fosse attivo ma completamente incapace di elaborare le richieste.

Al momento, affidarsi esclusivamente al rilevamento della presa è come controllare il polso di uno zombi: non è possibile trovare il cervello.死亡.

💥 Una soluzione di monitoraggio a doppia uccisione che sovverte la cognizione

Buttate via quel vecchio monitoraggio unidimensionale! I migliori esperti utilizzano tutti la strategia del doppio strangolamento: livello di processo + livello aziendale.

La seguente configurazione consentirà al server di ripristinarsi autonomamente più velocemente di quanto il personale addetto alla gestione e alla manutenzione possa alzarsi dal letto quando si verificano problemi:

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"

🔍 Dettagli fatali nascosti nei parametri

· XNUMX€ hostheaderI parametri sono talismani salvavita negli scenari di bilanciamento del carico/CDN. Senza di essi, è come cercare un caccia stealth con visori notturni: non è possibile rilevare lo stato di sospensione causato dall'intestazione Host mancante.

· XNUMX€ for 3 cyclesQuesta progettazione del periodo di buffer evita perfettamente i falsi positivi causati dal jitter della rete. È come installare un ammortizzatore nel sistema di sorveglianza per impedire che una stretta di mano faccia scattare il pulsante nucleare.

• Scorsoexec "/usr/bin/systemctl restart hestia"È la mossa letale per eccellenza. Quando PHP-FPM non è riuscito a riavviarsi per 5 volte di seguito, ho capovolto la tabella e riavviato l'intero pannello di hosting. Questo è un trucco che ho rubato dal meccanismo di interruzione del sistema di trading di Wall Street.

🚨 Lezioni apprese dal dolore e dalla sofferenza: 3 trappole che possono farti fallire

1. Frode del certificato SSL: dopo un aggiornamento,protocol httpsSe non lo scrivi, il monitoraggio lo giudicherà sempre come normale. Successivamente ho scoperto che la vecchia versione di Monit non verificava il certificato di default, il che mi ha fatto perdere il bonus di fine anno
2. Trappola 401 nella pagina di accesso: dimentica di aggiungere quando monitori la pagina di accessoBasic AuthenticationDi conseguenza, ogni test attiva un riavvio. È come annaffiare un giardino con un idrante: abbastanza potente ma totalmente sbagliato
3. Log Black Hole: Una volta/var/log/monit.logQuando le dimensioni sono schizzate a 50G, abbiamo scoperto che qualche idiota aveva impostato il periodo di rilevamento a 1 secondo. Ricordati che è il registro di monitoraggio stesso l'oggetto che deve essere monitorato!

💡 Passaggi di verifica e debug

1. Controllo della sintassi della configurazione:

   monit -t
   

2. Configurazione di sovraccarico:

   monit reload

Test finale

1. Test del suicidio: direttokill -9Uccidere il processo PHP-FPM e controllare i record di resurrezione nel registro di monitoraggio. Sembra di guardare un film di zombi!
2. Iniezione di veleno: modificare deliberatamente la pagina di accesso per restituire un codice di stato 503 e osservare se il sistema di monitoraggio riesce ad attaccare con precisione. Chiamo questo metodo "vaccino digitale": iniettando preventivamente nel sistema una piccola quantità di virus per forzare la risposta immunitaria del sistema di monitoraggio. Quando gli allarmi lampeggeranno all'impazzata e i servizi si autoripristineranno, vedrai bruciare la più sexy volontà di sopravvivenza nel mondo del codice!