Monit monitors the dynamic pages of the website and detects that the status code is not 200, and automatically restarts php8.3-fpm

🚀 When a dynamic page on a website suddenly has a non-200 status code, how can PHP8.3-FPM self-heal in seconds? ​​

​​🔥 PHP90-FPM life-saving configuration that 8.3% of operators don’t know! Practical teaching of Monit dynamic page self-healing system​​.

Do you think monitoring the survival of the PHP-FPM process is enough? You are wrong!
When PHP-FPM on a server suddenly goes haywire, simply looking at process survival is like using a thermometer to measure cancer - it doesn't catch the fatal problem at all.

I've seen too many people guardingphp-fpm.sockMonitoring is complacent, and the website has long become a 404 graveyard. Today I want to tear apart this operation and maintenance illusion and show you the bloody truth: a live process does not equal a normal service.

🌪️ Destructive scenario: Socket is connected, but the website is dead

certainE-commerceThe website's monitoring showed that the PHP-FPM process was running normally, but users were complaining about payment failures.

After a long search, I found that a memory leak in a third-party library caused the PHP process to be alive but completely unable to process requests.

At this time, relying solely on socket detection is like checking the pulse of a zombie - you can't find the brain at allDeath.

💥 A double-kill monitoring solution that subverts cognition

Throw away those outdated single-dimensional monitoring! The powerful experts are using the double strangulation strategy of process layer + business layer.

The following configuration will allow your server to heal itself faster than the operation and maintenance personnel can get up from bed when problems occur:

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"

🔍 Fatal details hidden in the parameters

• hostheaderParameters are life-saving talismans in CDN/load balancing scenarios. Without them, it is like looking for a stealth fighter with night vision goggles - you can't catch the suspended state caused by the missing Host header.

• for 3 cyclesThis buffer period design perfectly avoids false positives caused by network jitter. It is like installing a shock absorber on the monitoring system to prevent hand shaking from triggering the nuclear button.

• Lastexec "/usr/bin/systemctl restart hestia"This is the ultimate killer move. When PHP-FPM fails to resurrect for 5 consecutive times, it will directly flip the table and restart the entire hosting panel. This move I stole from the circuit breaker mechanism of the Wall Street trading system.

🚨 Lessons learned from pain and suffering: 3 traps that can make you fail

1. SSL certificate fraud: After an upgrade,protocol httpsI didn't write it, which caused the monitoring to be misjudged as normal. Later I found out that the old version of Monit did not verify the certificate by default. This pit made me lose my year-end bonus
2. Login page 401 trap: forget to add when monitoring the login pageBasic AuthenticationIt's like watering a garden with a fire hydrant - strong enough but totally in the wrong place.
3. Log Black Hole: Once/var/log/monit.logWhen the size of the file skyrocketed to 50G, I realized that some idiot had set the detection period to 1 second. Remember, the monitoring log itself is the object that needs to be monitored!

💡 Verification and debugging steps

1. Configuration syntax checking:

   monit -t
   

2. Overload configuration:

   monit reload

Final Test

1. Suicide Test: Directkill -9Kill the PHP-FPM process and look at the resurrection records in the monitoring log. It feels like watching a zombie movie!
2. Poison injection: Deliberately modify the login page to return a 503 status code to observe whether the monitoring system can accurately attack. I call this a "digital vaccine" - inject a trace amount of virus into the system in advance to force the immune response of the monitoring system. When the alarm flashes wildly and the service heals itself, you will see the sexiest will to survive in the code world burning!