Monit следи динамичните страници на уебсайта и открива, че кодът на състоянието не е 200, и автоматично рестартира php8.3-fpm.

🚀 Когато динамична страница на уебсайт внезапно получи код на състояние, различен от 200, как PHP8.3-FPM може да се самовъзстанови за секунди?

​​🔥 PHP90-FPM животоспасяваща конфигурация, която 8.3% от операторите не знаят! Практическо обучение по системата за самовъзстановяване на динамични страници Monit.

Мислите ли, че наблюдението на оцеляването на PHP-FPM процеса е достатъчно? Абсолютно грешно!
Когато PHP-FPM на сървър внезапно се побърка, простото наблюдение на оцеляването на процеса е като използването на термометър за измерване на рак - той изобщо не улавя фаталния проблем.

Виждал съм твърде много хора да пазятphp-fpm.sockМониторингът беше самодоволен и в резултат на това уебсайтът отдавна се е превърнал в гробище за 404. Днес искам да разкъсам тази илюзия за експлоатация и поддръжка и да ви покажа кървавата истина: жив процес ≠ нормална услуга.

🌪️ Деструктивен сценарий: Сокетът е свързан, но уебсайтът е мъртъв

определенЕлектричество доставчикаМониторингът на уебсайта показа, че процесът PHP-FPM протича нормално, но потребителите се оплакват от неуспешни плащания.

След дълго търсене открих, че изтичане на памет в библиотека на трета страна е довело до това PHP процеса да е активен, но напълно да не може да обработва заявки.

В този момент, разчитането единствено на откриването на контакти е като проверка на пулса на зомби - изобщо не можете да намерите мозъка.смърт.

💥 Решение за мониторинг с двойно унищожаване, което подкопава когнитивните функции

Изхвърлете тези остарели едноизмерни наблюдения! Най-добрите експерти използват стратегията за двойно задушаване на процесния слой + бизнес слоя.

Следната конфигурация ще позволи на вашия сървър да се самовъзстанови по-бързо, отколкото персоналът по експлоатацията и поддръжката може да стане от леглото, когато възникнат проблеми:

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"

🔍 Фатални детайли, скрити в параметрите

• hostheaderПараметрите са животоспасяващи талисмани в сценарии за CDN/балансиране на натоварването. Без тях е все едно да търсите стелт изтребител с очила за нощно виждане - не можете да уловите състоянието на замръзване, причинено от липсващия Host хедър.

• for 3 cyclesТози дизайн на буферния период перфектно избягва фалшивите положителни резултати, причинени от мрежовото трептене. Все едно да инсталираш амортисьор на системата за наблюдение, за да предотвратиш треперенето на ръцете от задействане на ядрения бутон.

• Последенexec "/usr/bin/systemctl restart hestia"Това е най-смъртоносният ход. Когато PHP-FPM не успя да се възкреси 5 пъти подред, обърнах таблицата и рестартирах целия хостинг панел. Това е трик, който откраднах от механизма на прекъсвача на търговската система на Уолстрийт.

🚨 Уроци, извлечени от болката и страданието: 3 капана, които могат да ви доведат до провал

1. Измама със SSL сертификат: След надстройка,protocol httpsНезаписването му кара мониторингът винаги да го прецени погрешно като нормално. По-късно разбрах, че старата версия на Monit не е проверявала сертификата по подразбиране, което ме накара да загубя годишния си бонус.
2. Капан 401 на страницата за вход: забравете да добавите при наблюдение на страницата за входBasic AuthenticationВ резултат на това всеки тест задейства рестартиране. Все едно да поливаш градина с пожарен хидрант - достатъчно силен, но напълно погрешен.
3. Черна дупка в логаритъм: Веднъж/var/log/monit.logКогато размерът скочи до 50G, открихме, че някой идиот е настроил периода на засичане на 1 секунда. Не забравяйте, че самият лог за наблюдение е обектът, който трябва да бъде наблюдаван!

💡 Стъпки за проверка и отстраняване на грешки

1. Проверка на синтаксиса на конфигурацията:

   monit -t
   

2. Конфигурация за претоварване:

   monit reload

Финален тест

1. Тест за самоубийство: Директенkill -9Затворете процеса PHP-FPM и вижте записите за възкресението в лога за наблюдение. Все едно гледаш филм за зомбита!
2. Инжектиране на отрова: Умишлено променете страницата за вход, за да върне код за състояние 503 и наблюдавайте дали системата за наблюдение може точно да атакува. Наричам този метод „цифрова ваксина“ - предварително инжектиране на малко количество вирус в системата, за да се елиминира имунният отговор на мониторинговата система. Когато алармите мигат диво и услугите се самоизлекуват, ще видите как най-сексапилната воля за оцеляване в света на кода гори!