Monit monitorizează paginile dinamice ale site-ului web și detectează că codul de stare nu este 200 și repornește automat php8.3-fpm.

🚀 Când o pagină dinamică de pe un site web are brusc un cod de stare diferit de 200, cum se poate repara automat PHP8.3-FPM în câteva secunde?

Configurație PHP90-FPM care salvează vieți, pe care 8.3% dintre operatori nu o cunosc! Predare practică a sistemului Monit de auto-reparare a paginilor dinamice.

Credeți că monitorizarea supraviețuirii procesului PHP-FPM este suficientă? Total greșit!
Când PHP-FPM pe un server o ia razna brusc, simpla analiză a supraviețuirii procesului este ca și cum ai folosi un termometru pentru a măsura cancerul - nu surprinde deloc problema fatală.

Am văzut prea mulți oameni păzindphp-fpm.sockMonitorizarea a fost nepăsătoare și, prin urmare, site-ul web a devenit de mult timp un cimitir 404. Astăzi vreau să dărâme această iluzie a operării și întreținerii și să vă arăt adevărul: un proces live ≠ un service normal.

🌪️ Scenariu distructiv: Socketul este conectat, dar site-ul web este mort

anumitfurnizor de energie electricăMonitorizarea site-ului web a arătat că procesul PHP-FPM funcționa normal, dar utilizatorii se plângeau de eșecuri de plată.

După o lungă căutare, am descoperit că o scurgere de memorie într-o bibliotecă terță a făcut ca procesul PHP să fie activ, dar complet incapabil să proceseze cererile.

În acest moment, a te baza exclusiv pe detectarea prizei cerebrale este ca și cum ai verifica pulsul unui zombi - nu poți găsi creierul deloc.moarte.

💥 O soluție de monitorizare cu dublă eliminare care subminează funcția cognitivă

Aruncați la o parte acele monitorizări unidimensionale învechite! Cei mai buni experți folosesc strategia dublei strangulare, a nivelului de proces + nivelului de business.

Următoarea configurație va permite serverului să se vindece mai repede decât se poate ridica personalul de operare și întreținere din pat atunci când apar probleme:

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"

🔍 Detalii fatale ascunse în parametri

• hostheaderParametrii sunt talismane care salvează vieți în scenariile CDN/echilibrarea încărcării. Fără ele, e ca și cum ai căuta un avion de vânătoare stealth cu ochelari de vedere nocturnă - nu poți observa starea de suspendare cauzată de lipsa antetului Host.

• for 3 cyclesAcest design al perioadei tampon evită perfect rezultatele fals pozitive cauzate de fluctuațiile rețelei. E ca și cum ai instala un amortizor pe sistemul de supraveghere pentru a preveni activarea butonului nuclear de către tremurul mâinii.

• Ultimulexec "/usr/bin/systemctl restart hestia"Este mișcarea ucigașă supremă. Când PHP-FPM nu a reușit să se reia de 5 ori la rând, am inversat tabelul și am repornit întregul panou de găzduire. Acesta este un truc pe care l-am furat din mecanismul de întrerupere a circuitului al sistemului de tranzacționare de pe Wall Street.

🚨 Lecții învățate din durere și suferință: 3 capcane care te pot face să eșuezi

1. Fraudă cu certificat SSL: După o actualizare,protocol httpsNescrierea acestuia face ca monitorizarea să îl considere întotdeauna greșit ca fiind normal. Mai târziu am aflat că vechea versiune de Monit nu verifica certificatul în mod implicit, ceea ce m-a făcut să pierd bonusul de sfârșit de an.
2. Capcana 401 a paginii de conectare: a uitat să o adaugi când monitorizezi pagina de conectareBasic AuthenticationPrin urmare, fiecare test declanșează o repornire. E ca și cum ai uda o grădină cu un hidrant - suficient de puternic, dar complet greșit.
3. Gaură neagră din jurnal: Odată/var/log/monit.logCând dimensiunea a crescut vertiginos la 50G, am descoperit că un idiot setase perioada de detecție la 1 secundă. Rețineți că jurnalul de monitorizare în sine este obiectul care trebuie monitorizat!

💡 Pași de verificare și depanare

1. Verificarea sintaxei de configurare:

   monit -t
   

2. Configurație suprasarcină:

   monit reload

Test final

1. Test de suicid: Directkill -9Opriți procesul PHP-FPM și verificați înregistrările de resurecție din jurnalul de monitorizare. E ca și cum ai viziona un film cu zombi!
2. Injecție otrăvitoare: Modificați în mod deliberat pagina de conectare pentru a returna un cod de stare 503 și observați dacă sistemul de monitorizare poate ataca cu precizie. Numesc această metodă „vaccin digital” - injectarea unei cantități mici de virus în sistem în prealabil pentru a forța răspunsul imun al sistemului de monitorizare. Când alarmele clipesc sălbatic și serviciile se vindecă singure, vei vedea cea mai sexy voință de a supraviețui din lumea codurilor arzând!