Часті збої Apache2 з HestiaCP? Посібник з автоматизованого моніторингу та усунення несправностей Monit (з повною конфігурацією)

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

Підводні камені, з якими я зіткнувся під час використання Monit для моніторингу Apache2

Минулої п'ятниці сервер посеред ночі надіслав мені сповіщення Monit.

Я заціпеніло глянув на панель, і в колонці стану apache2 з’явився червоний напис «Тайм-аут».

Я трохи подумав. Я щойно додав моніторинг 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` для перевірки вмісту файлу; він має містити рядок чисел, а не порожній рядок.

Після завершення цього кроку проблема в основному вирішена.

Порівняльний аналіз традиційних адаптивних та агресивних захисних конфігурацій Моніта

Онлайн-посібники з налаштування 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`. Якщо ви зробите ці дві речі, ви зможете уникнути будь-яких подальших проблем.

Оскільки ви дочитали до цього місця, якщо це було корисно, будь ласка, поставте лайк та поділіться цим. Якщо ви хочете отримувати оновлення першими, ви також можете підписатися на мене!

Дякую, що прочитали мою статтю. До зустрічі наступного разу.