Чести падови на Apache2 со HestiaCP? Водич за автоматско следење и решавање проблеми со Monit (со целосна конфигурација)

Чести падови на Apache2 или неуспеси при автоматско рестартирање на Monit во HestiaCP средини? Оваа статија дава практичен водич за избегнување на вообичаени стапици при следење на Apache2 со Monit, длабински анализирајќи ги вообичаените проблеми како што се неусогласеноста на PID патеката и блокирањето на дозволите, и нудејќи конфигурациски датотеки за автоматизација на Monit на ниво на производство. Совладајте ги техниките за одржување на серверот со висока достапност сега и постигнете автоматско закрепнување од неуспеси од второ ниво!

Стапиците со кои се соочив додека го користев Monit за следење на Apache2

Минатиот петок, серверот ми даде Monit известување среде ноќ.

Зашеметен погледнав кон панелот, и во колоната за статус на apache2 имаше црвен Исклучен рок на траење.

Размислував малку. Само што го додадов мониторингот на Monit на серверот во текот на денот, а конфигурацијата ја копирав и ја залепив од онлајн туторијал. Не би требало да има никакви проблеми, нели?

Следното утро, повторно истече времето. По третиот пат, мониторот едноставно се откажа, а панелот прикажа „Не е мониторирано“.

Јас...

Признавам, на почетокот не го сфатив сериозно. Мониторинг на Apache2? Можете да најдете многу конфигурации на шаблони на интернет, само копирајте и залепете. Но, тој процес на лепење навистина ме разбесни.

Основната причина за конфликтот помеѓу стандардната архитектура на HestiaCP и портите на Monit

Прво да ви ја покажам конфигурацијата што ми предизвика толку многу проблеми, за да можете да видите дали е потполно иста како верзијата што ја видовте.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/usr/sbin/service apache2 start"
    stop program  = "/usr/sbin/service apache2 stop"
    if failed host 127.0.0.1 port 80 protocol http then restart
    if 5 restarts within 5 cycles then timeout

Се чини дека е во ред, нели? Го проверува портот 80 и ако се сруши, се рестартира. Ако сè уште се сруши по 5 рестартирања, времето истекува.

Проблемот е што вашиот Apache2 дури и не работи на порт 80.

Ова е една од недостатоците на HestiaCP и основната причина зошто многу луѓе запаѓаат во неа. Стандардната архитектура на HestiaCP е обратен прокси на Nginx + Apache2, при што Nginx ги зафаќа портите 80 и 443 напред, а Apache2 работи на локалната порта 8081 назад.

Ако го замолите Монит да провери дали Apache2 е активен на порт 80, тоа е како да одите во McDonald's за да го најдете KFC. Серверот ве гледа празно, а вие двајцата се гледате еден со друг. На крајот, Монит утврдува дека не сте вклучени и почнува френетично да го рестартира.

По рестартирањето, портата е сè уште 8081. Потоа Monit се обидува да ја испита портата 80, што исто така не успева, па се рестартира повторно. Овој циклус се повторува сè додека Monit не одлучи дека не може да се поправи и не истече времето.

Кога првпат наидов на ова, бев навистина запрепастен. Девет од десет туторијали што ги најдов на интернет го користеа портот 80. Ако ги следевте, проблемот не беше во вас, туку во самиот извор на информациите.

Оштетена Apache2 PID датотека предизвика Monit погрешно да го идентификува процесот како непостоечки.

Откако ќе го смени портот од 80 на 8081, Monit теоретски би требало да може да го детектира, нели?

Сепак, во реалноста, сè уште повремено известува „Извршувањето не успеа “.

Откако долго време се мачев, конечно открив дека причината е едноставна: PID-датотеката е оштетена.

Замислете, Monit френетично го рестартираше Apache2, секој пат присилно исклучувајќи го и рестартирајќи го, враќајќи се напред-назад неколку пати. За време на овој процес, датотеката /var/run/apache2/apache2.pid може да стане 0 бајти.

Со други зборови, датотеката е сè уште таму, но е празна.

Кога Monit ја чита оваа датотека, не наоѓа ништо. Не го препознава вашиот Apache2, дури и ако вашиот Apache2 работи совршено добро во позадина; Monit не мисли дека процесот постои.

Кога го видов ова, останав без зборови на момент.

Ова е ќор-сокак. Monit не успева да ја детектира инстанцата на Apache 2, го рестартира Apache2, ја оштетува PID датотеката за време на процесот на рестартирање, не успева со следното детектирање и повторно се рестартира. Овој циклус продолжува сè додека не истече времето.

Чекори за решавање проблеми и поправка за Apache2 мониторинг во HestiaCP околина

Да бидам искрен, процесот на истрага не е комплициран, но треба да знаете во која насока да истражувате.

Првиот чекор е да одредите на кој порт слуша вашиот Apache2. Едноставно внесете команда во терминалот.

netstat -tulpn | grep apache2

Алтернативно, можете да ја користите командата `ss`; ефектот е ист.

ss -tulpn | grep apache2

Ќе видите излез сличен на овој.

tcp  0  0 127.0.0.1:8081       0.0.0.0:*  LISTEN  2942372/apache2

Потврдено е дека е 8081, а не 80. Тоа е коренот на проблемот.

Вториот чекор е да се поправи оштетената PID датотека. Ова е поедноставно.

monit unmonitor apache2
systemctl restart apache2
cat /var/run/apache2/apache2.pid

Прво, паузирајте го мониторингот на Monit за да спречите да се меша додека поправате работи. Потоа, рестартирајте го Apache2 за да му дозволите да преработи чист PID. Конечно, користете `cat` за да ја проверите содржината на датотеката; треба да содржи низа од броеви, а не празен низ.

Откако ќе се заврши овој чекор, проблемот е во основа решен.

Компаративна анализа на традиционалните адаптивни и агресивни заштитни конфигурации на Monit

Онлајн упатствата за конфигурирање на Apache2 со Monit генерално се делат на две категории.

Еден тип е „традиционалниот тип на адаптација“, кој ја користи командата `service` за управување со услуги и проверка на локални порти без додавање премногу комплицирани ограничувања. Оваа конфигурација може да се користи на HestiaCP со едноставно менување на портата и е релативно стабилна.

Друг пристап е методот „агресивна заштита“, кој користи systemctl за управување со услуги, додава ограничувања на детските процеси и користи построга логика за детекција. Изгледа одлично, но има фатална маана: командата за стоп што се користи е `killall -9`.

Што значи `killall -9`? Тоа значи насилно исклучување на уредот без оглед на тоа што прави. Оваа операција со груба сила лесно може да остави зад себе оштетени PID датотеки, што е проблемот што го споменав.

Моето лично искуство е дека ограничувањето на бројот на детски процеси во агресивна конфигурација е навистина корисно. Кога вашиот Apache2 е преоптоварен од напад на CC, ограничувањето на бројот на детски процеси може да спречи серверот да остане без меморија. Сепак, пристапот `killall -9` е навистина неупотреблив.

Па на крајот направив компромис и ги комбинирав предностите на обете конфигурации.

Конфигурација на најдобри практики за HestiaCP Apache2 Monit

Изменете ја датотеката /etc/monit/conf.d/apache2 со следната содржина.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/bin/systemctl start apache2"
    stop program  = "/bin/systemctl stop apache2"
    if children > 120 for 2 cycles then restart
    if failed host 127.0.0.1 port 8081 protocol http for 2 cycles then restart
    if 5 restarts within 10 cycles then timeout

Дозволете ми накратко да ја објаснам логиката зад овие неколку линии на конфигурација.

Напишете го портот 8081 за прецизно да се совпаѓа со обратната прокси архитектура на HestiaCP; престанете глупаво да го пишувате портот 80.

Користете ја командата `systemctl stop` наместо `killall -9` за да ја запрете PID датотеката, за да не ја оштетите.

Додадено е ограничување на детските процеси: ако бројот на деца надмине 120, процесот ќе се рестартира по два последователни циклуси за да се спречат напади со CC, но не е премногу агресивен.

Логиката за откривање на дефекти е изменета за да користи пристап „за 2 циклуси“, што значи дека рестартирањето се активира само по два последователни дефекти, со што се намалуваат лажните позитиви. Претходната конфигурација, која се рестартираше по само едно откривање, искрено, беше малку премногу чувствителна.

Конечниот праг на тајмаут се намалува на 5 рестартувања во рок од 10 циклуси, оставајќи доволна толеранција на грешки.

HestiaCP Следете го мониторинготРезиме за решавање проблеми со конфигурацијата и споделување искуства

Откако ги направив промените во конфигурацијата, го следев apache2 и панелот конечно покажа зелен индикатор „ОК“.

Како да ги опишам моите чувства во тој момент? Беше како да поминам два дена борејќи се со баг, само за да откријам дека причината е една единствена линија во конфигурацијата што е погрешна. Беше и фрустрирачко и смешно.

Monit е добра работа сама по себе, а следењето на демоните е нешто што секој сервер треба да го прави. Но, проблемот е што многу онлајн туторијали се базираат на претпоставката дека „Apache2 исклучиво го користи портот 80“, додека HestiaCP користи обратен прокси, што значи дека оваа претпоставка не важи.

Ако ги следите упатствата, проблемот не е во вас; проблемот е што упатството е применливо во различно сценарио од вашето.

Значи, ако користите и HestiaCP и се замарате со Monit за да го следите Apache2, само запомнете две работи: Променете го портот на 8081 и користете ја командата `systemctl` за да го запрете, а не `killall -9`. Ако ги направите овие две работи, би требало да можете да избегнете понатамошни проблеми.

Бидејќи прочитавте до тука, ако ви беше од помош, лајкнете го и споделете го. Ако сакате први да добивате новости, можете да ме следите и мене!

Ви благодарам што ја прочитавте мојата статија. Се гледаме следниот пат.