Чести сривове на Apache2 с HestiaCP? Ръководство за автоматизирано наблюдение и отстраняване на проблеми с Monit (с пълна конфигурация)

Чести сривове на Apache2 или грешки при автоматично рестартиране на Monit в HestiaCP среди? Тази статия предоставя практическо ръководство за избягване на често срещани клопки при наблюдение на Apache2 с Monit, като анализира задълбочено често срещани проблеми като несъответствие на пътя на PID и блокиране на разрешения, и предлага конфигурационни файлове за автоматизация на Monit от производствено ниво. Овладейте техниките за поддръжка на сървъри с висока наличност сега и постигнете автоматично възстановяване от второ ниво след повреди!

Капаните, с които се сблъсках, докато използвах Monit за наблюдение на Apache2

Миналия петък сървърът ми даде предупреждение за Monit посред нощ.

Хвърлих замаян поглед към панела и в колоната за състоянието на apache2 имаше червено „Timeout“.

Помислих си малко. Току-що добавих мониторинга на Monit към сървъра през деня и копирах и поставих конфигурацията от онлайн урок. Не би трябвало да има проблеми, нали?

На следващата сутрин времето за задействане отново изтече. След третия път Monitor просто се отказа и панелът показа „Не се наблюдава“.

Аз...

Признавам, в началото не го приех насериозно. Мониторинг на 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. Ако сте ги следвали, проблемът не е бил във вас, а в самия източник на информацията.

Повреден PID файл на Apache2 е накарал Monit погрешно да идентифицира процеса като несъществуващ.

След промяна на порта от 80 на 8081, Monit теоретично би трябвало да може да го открие, нали?

В действителност обаче, понякога все още се появява съобщение „Изпълнението е неуспешно “.

След дълго мъчение, най-накрая открих, че причината е проста: PID файлът е повреден.

Помислете за това, Монит трескаво рестартираше 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 и панелът най-накрая показа зелен индикатор "OK".

Как да опиша чувствата си по онова време? Все едно прекарах два дни в борба с грешка, само за да открия, че причината е един-единствен грешен ред от конфигурацията. Беше едновременно разочароващо и смешно.

Monit е нещо добро само по себе си, а наблюдението на демони е нещо, което всеки сървър трябва да прави. Проблемът обаче е, че много онлайн уроци се основават на предположението, че „Apache2 използва изключително порт 80“, докато HestiaCP използва обратен прокси, което означава, че това предположение не е вярно.

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

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

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

Благодаря ви, че прочетохте статията ми. Ще се видим следващия път.