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Калі памер рэзка ўзляцеў да 50 ГБ, мы выявілі, што нейкі ідыёт усталяваў перыяд выяўлення на 1 секунду. Памятайце, што сам журнал маніторынгу — гэта аб'ект, які трэба кантраляваць!

💡 Этапы праверкі і адладкі

1. Праверка сінтаксісу канфігурацыі:

   monit -t
   

2. Канфігурацыя перагрузкі:

   monit reload

Заключны тэст

1. Тэст на самагубства: прамыkill -9Завяршыце працэс PHP-FPM і паглядзіце запісы аб адраджэнні ў журнале маніторынгу. Гэта як глядзець фільм пра зомбі!
2. Ін'екцыя атруты: наўмысна змяніце старонку ўваходу, каб яна вяртала код стану 503, і ​​прасачыце, ці можа сістэма маніторынгу дакладна атакаваць. Я называю гэты метад «лічбавай вакцынай» — загадзя ўводжу невялікую колькасць віруса ў сістэму, каб выціснуць імунную рэакцыю сістэмы маніторынгу. Калі сігналізацыя будзе дзіка міргаць, а службы аднаўляцца, вы ўбачыце, як гарыць самая сэксуальная воля да выжывання ў свеце кода!