Monit controleert de dynamische pagina's van de website en detecteert dat de statuscode niet 200 is, en start php8.3-fpm automatisch opnieuw op

🚀 Hoe kan PHP200-FPM zichzelf binnen enkele seconden herstellen als een dynamische pagina op een website plotseling een statuscode anders dan 8.3 heeft?

​​🔥 PHP90-FPM levensreddende configuratie die 8.3% van de operators niet kent! Praktische uitleg over het zelfherstellende systeem voor dynamische pagina's van Monit.

Denkt u dat het monitoren van de overleving van het PHP-FPM-proces voldoende is? Helemaal fout!
Wanneer PHP-FPM op een server plotseling op hol slaat, is het kijken naar de overlevingskansen van het proces vergelijkbaar met het meten van kanker met een thermometer: het detecteert het fatale probleem helemaal niet.

Ik heb te veel mensen gezien diephp-fpm.sockEr werd onvoldoende toezicht gehouden, waardoor de website al lang een 404-kerkhof is geworden. Vandaag wil ik deze illusie van bediening en onderhoud doorbreken en u de verdomde waarheid laten zien: een levend proces ≠ een normale service.

🌪️ Destructief scenario: Socket is verbonden, maar de website is dood

zekerelektriciteitsleverancierUit de monitoring van de website bleek dat het PHP-FPM-proces normaal verliep, maar gebruikers klaagden over mislukte betalingen.

Na lang zoeken kwam ik erachter dat een geheugenlek in een externe bibliotheek ervoor zorgde dat het PHP-proces weliswaar actief was, maar absoluut geen verzoeken kon verwerken.

Op dit moment is het enkel vertrouwen op socketdetectie als het controleren van de hartslag van een zombie: je kunt de hersenen helemaal niet vindenDood.

💥 Een oplossing voor dubbele monitoring die cognitie ondermijnt

Gooi die ouderwetse, eendimensionale monitoring weg! De beste experts gebruiken allemaal de dubbele wurgstrategie van proceslaag + bedrijfslaag.

Met de volgende configuratie kan uw server zichzelf sneller herstellen dan het bedienings- en onderhoudspersoneel uit bed kan komen als er problemen optreden:

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"

🔍 Fatale details verborgen in de parameters

• hostheaderParameters zijn levensreddende hulpmiddelen in CDN-/load balancing-scenario's. Zonder deze is het alsof je een stealth fighter met een nachtzichtbril zoekt: je kunt de onderbroken status die ontstaat door de ontbrekende Host-header niet vaststellen.

• for 3 cyclesDit bufferperiodeontwerp voorkomt foutpositieve resultaten die worden veroorzaakt door netwerktrilling. Het is alsof je een schokdemper in het bewakingssysteem plaatst, zodat de nucleaire knop niet geactiveerd wordt door het trillen van de handen.

• Laatstexec "/usr/bin/systemctl restart hestia"Het is de ultieme dodelijke zet. Toen PHP-FPM vijf keer achter elkaar niet meer opstartte, heb ik de tabel omgedraaid en het hele hostingpaneel opnieuw opgestart. Dit is een truc die ik heb gestolen van het circuit breaker-mechanisme van het handelssysteem op Wall Street.

🚨 Lessen geleerd uit pijn en lijden: 3 valkuilen die ervoor kunnen zorgen dat je faalt

1. SSL-certificaatfraude: Na een upgrade,protocol httpsAls je het niet opschrijft, zal de monitoring het altijd ten onrechte als normaal beschouwen. Later ontdekte ik dat de oude versie van Monit het certificaat niet standaard verifieerde, waardoor ik mijn eindejaarsbonus kwijtraakte
2. Inlogpagina 401-val: vergeten toe te voegen bij het monitoren van de inlogpaginaBasic AuthenticationHierdoor wordt bij elke test een herstart veroorzaakt. Het is alsof je een tuin besproeit met een brandkraan: sterk genoeg, maar totaal verkeerd.
3. Log Black Hole: Eens/var/log/monit.logToen de grootte omhoogschoot naar 50G, ontdekten we dat een idioot de detectieperiode had ingesteld op 1 seconde. Vergeet niet dat het bewakingslogboek zelf het object is dat bewaakt moet worden!

💡 Verificatie- en foutopsporingsstappen

1. Controle van configuratiesyntaxis:

   monit -t
   

2. Overbelastingsconfiguratie:

   monit reload

Eindtoets

1. Zelfmoordtest: Directkill -9Sluit het PHP-FPM-proces en bekijk de wederopstandingsrecords in het monitoringlogboek. Het voelt alsof je naar een zombiefilm kijkt!
2. Gifinjectie: wijzig de inlogpagina opzettelijk zodat er een 503-statuscode wordt geretourneerd en kijk of het bewakingssysteem nauwkeurig kan aanvallen. Ik noem deze methode 'digitaal vaccin': vooraf wordt een kleine hoeveelheid virus in het systeem geïnjecteerd om de immuunreactie van het bewakingssysteem uit te schakelen. Wanneer de alarmen wild afgaan en de diensten zichzelf herstellen, zul je de meest sexy wil om te overleven in de codewereld zien branden!