Monit monitoruje dynamiczne strony witryny i wykrywa, że ​​kod statusu nie jest równy 200, a następnie automatycznie uruchamia ponownie php8.3-fpm

🚀 W jaki sposób PHP200-FPM może naprawić błąd w ciągu kilku sekund, gdy dynamiczna strona witryny nagle otrzyma kod stanu różny od 8.3?

🔥 PHP90-FPM – ratująca życie konfiguracja, której 8.3% operatorów nie zna! Praktyczna nauka obsługi dynamicznego systemu samonaprawiania stron Monit.

Czy uważasz, że monitorowanie przetrwania procesu PHP-FPM jest wystarczające? Całkowicie nieprawda!
Gdy PHP-FPM na serwerze nagle przestaje działać, samo sprawdzanie przeżywalności procesu jest jak mierzenie raka za pomocą termometru – w ogóle nie wykryje śmiertelnego problemu.

Widziałem zbyt wielu ludzi pilnującychphp-fpm.sockMonitoring był bezduszny, a w efekcie strona internetowa stała się cmentarzyskiem błędów 404. Dziś chcę obalić iluzję obsługi i konserwacji i pokazać wam krwawą prawdę: żywy proces ≠ normalna usługa.

🌪️ Scenariusz destrukcyjny: gniazdo jest połączone, ale strona internetowa jest nieaktywna

pewnyE-commerceMonitorowanie witryny wykazało, że proces PHP-FPM działał prawidłowo, ale użytkownicy skarżyli się na problemy z płatnościami.

Po długich poszukiwaniach odkryłem, że wyciek pamięci w bibliotece zewnętrznej powodował, że proces PHP działał, ale nie był w stanie przetwarzać żądań.

Obecnie poleganie wyłącznie na wykrywaniu gniazd jest jak sprawdzanie pulsu u zombie – w ogóle nie można znaleźć mózguŚmierć.

💥 Rozwiązanie do podwójnego monitorowania, które podważa poznanie

Wyrzućmy ten przestarzały, jednowymiarowy monitoring! Najlepsi eksperci stosują strategię podwójnego uduszenia, obejmującą warstwę procesową i warstwę biznesową.

Poniższa konfiguracja pozwoli serwerowi na samodzielną naprawę szybciej, niż personel ds. obsługi i konserwacji zdąży wstać z łóżka w przypadku wystąpienia problemów:

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"

🔍 Krytyczne szczegóły ukryte w parametrach

• hostheaderParametry są talizmanami ratującymi życie w scenariuszach CDN/równoważenia obciążenia. Bez nich sytuacja przypomina poszukiwanie myśliwca stealth z goglami noktowizyjnymi — nie da się uchwycić stanu zawieszenia spowodowanego brakiem nagłówka Host.

• for 3 cyclesTaka konstrukcja okresu buforowego doskonale zapobiega fałszywym wynikom pozytywnym wywoływanym przez drgania sieci. To tak, jakby zainstalować amortyzator w systemie monitoringu, który ma zapobiec temu, aby drżenie rąk spowodowało uruchomienie się przycisku nuklearnego.

• Ostatniexec "/usr/bin/systemctl restart hestia"To jest ostateczny, zabójczy ruch. Kiedy PHP-FPM nie udało się uruchomić ponownie pięć razy z rzędu, odwróciłem tabelę i ponownie uruchomiłem cały panel hostingowy. To sztuczka, którą ukradłem z mechanizmu wyłącznika automatycznego systemu transakcyjnego Wall Street.

🚨 Lekcje wyciągnięte z bólu i cierpienia: 3 pułapki, które mogą sprawić, że poniesiesz porażkę

1. Oszustwo związane z certyfikatem SSL: Po aktualizacjiprotocol httpsJeśli tego nie napiszesz, monitoring zawsze będzie błędnie oceniał to jako coś normalnego. Później dowiedziałem się, że stara wersja Monit nie weryfikowała domyślnie certyfikatu, przez co straciłem premię na koniec roku
2. Pułapka 401 na stronie logowania: zapomnij dodać podczas monitorowania strony logowaniaBasic AuthenticationW rezultacie każdy test powoduje ponowne uruchomienie. To jak podlewanie ogrodu hydrantem – wystarczająco mocnym, ale całkowicie błędnym
3. Czarna dziura w dzienniku: Kiedyś/var/log/monit.logGdy rozmiar gwałtownie wzrósł do 50G, odkryliśmy, że jakiś idiota ustawił okres wykrywania na 1 sekundę. Pamiętaj, że sam dziennik monitorowania jest obiektem, który należy monitorować!

💡 Kroki weryfikacji i debugowania

1. Sprawdzanie składni konfiguracji:

   monit -t
   

2. Konfiguracja przeciążenia:

   monit reload

Test końcowy

1. Test samobójczy: bezpośrednikill -9Zakończ proces PHP-FPM i sprawdź rekordy wskrzeszenia w dzienniku monitorowania. Czujesz się jakbyś oglądał film o zombie!
2. Wstrzyknięcie trucizny: celowo zmodyfikuj stronę logowania, aby zwracała kod stanu 503, i obserwuj, czy system monitorujący będzie w stanie przeprowadzić prawidłowy atak. Nazywam tę metodę „szczepionką cyfrową” – polega ona na wcześniejszym wstrzyknięciu do systemu niewielkiej ilości wirusa, aby wymusić reakcję immunologiczną systemu monitorującego. Gdy alarmy zaczną migać jak szalone, a usługi same się uzdrowią, zobaczysz, jak płonie najseksowniejsza wola przetrwania w świecie kodów!