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

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

Замке на које сам наишао док сам користио Монит за праћење Апачи2

Прошлог петка, сервер ми је дао Монит упозорење усред ноћи.

Збуњено сам бацио поглед на панел, а у колони статуса apache2, била је црвена натпис „Timeout“.

Размишљао сам мало о томе. Управо сам током дана додао Монит праћење на сервер и копирао сам и налепио конфигурацију из онлајн туторијала. Не би требало да буде никаквих проблема, зар не?

Следећег јутра, време је поново истекло. После трећег пута, Монитор је једноставно одустао, а на контролној табли је приказано „Није надгледано“.

Ја...

Признајем, нисам то схватио озбиљно у почетку. Праћење 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. Монит затим покушава да провери порт 80, што такође не успева, па се поново покреће. Овај циклус се понавља док Монит не одлучи да је немогуће поправити и истекне време.

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

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

Након промене порта са 80 на 8081, Монит би теоретски требало да буде у стању да га детектује, зар не?

Међутим, у стварности, и даље повремено пријављује „Извршење није успело “.

Након дугог мучења, коначно сам открио да је разлог једноставан: ПИД датотека је била оштећена.

Размислите о томе, Монит је френетично рестартовао Apache2, сваки пут га је насилно убијао и поново покретао, враћајући се неколико пута напред-назад. Током овог процеса, датотека /var/run/apache2/apache2.pid је могла да постане 0 бајтова.

Другим речима, датотека је још увек ту, али је празна.

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

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

Ово је застој. Monit не успева да детектује инстанцу Apache 2, поново покреће Apache 2, оштећује 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. То је корен проблема.

Други корак је поправка оштећене ПИД датотеке. Ово је једноставније.

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

Прво, паузирајте Монитово праћење како бисте спречили његово ометање док поправљате ствари. Затим, поново покрените Апачи2 да бисте му омогућили да препише чист ПИД. На крају, користите `cat` да бисте проверили садржај датотеке; требало би да садржи низ бројева, а не празан низ.

Када се овај корак заврши, проблем је у основи решен.

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

Онлајн туторијали о конфигурисању 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, процес ће се поново покренути након два узастопна циклуса како би се спречили ЦЦ напади, али није превише агресивно.

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

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

ХестиаЦП Мониторинг МониторингРезиме решавања проблема са конфигурацијом и дељење искуства

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

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

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

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

Дакле, ако користите и HestiaCP и играте се са Monit-ом да бисте пратили Apache2, само запамтите две ствари: Промените порт на 8081 и користите команду `systemctl` да бисте га зауставили, а не `killall -9`. Ако урадите ове две ствари, требало би да будете у могућности да избегнете даље проблеме.

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

Хвала вам што сте прочитали мој чланак. Видимо се следећи пут.