Частые сбои 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 сзади.

Если попросить Monit проверить работоспособность Apache2 на порту 80, это всё равно что пойти в Макдоналдс за KFC. Сервер смотрит на вас пустым взглядом, а вы в ответ смотрите друг на друга. В конце концов, Monit определяет, что сервер не работает, и начинает в панике перезапускать его.

После перезапуска порт по-прежнему равен 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, перезапускает 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. В этом корень проблемы.

Второй шаг — восстановление поврежденного 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 Мониторинг: Рекомендации по настройке

Измените файл /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.

Для остановки PID-файла используйте команду `systemctl stop` вместо `killall -9`, чтобы избежать его повреждения.

Добавлено ограничение на количество дочерних процессов: если число дочерних процессов превышает 120, процесс перезапустится после двух последовательных циклов, чтобы предотвратить атаки CC, но это не слишком агрессивное ограничение.

Логика обнаружения сбоев была изменена и теперь использует подход «в течение 2 циклов», то есть перезапуск запускается только после двух последовательных сбоев, что снижает количество ложных срабатываний. Предыдущая конфигурация, которая перезапускалась после одного обнаружения, была, честно говоря, несколько излишне чувствительной.

Пороговое значение времени ожидания в конечном итоге снижено до 5 перезапусков в течение 10 циклов, что обеспечивает достаточную отказоустойчивость.

ГестияCP Мониторинг мониторингаКраткий обзор устранения неполадок при настройке и обмен опытом.

После внесения изменений в конфигурацию я отслеживал состояние apache2, и на панели наконец-то появился зеленый индикатор "OK".

Как описать мои чувства в тот момент? Это было похоже на то, как если бы вы два дня боролись с ошибкой, а потом выяснилось, что причина кроется всего в одной неправильной строке конфигурации. Это было одновременно и неприятно, и смешно.

Monit сам по себе полезен, а мониторинг демонов — это то, что должен делать каждый сервер. Но проблема в том, что многие онлайн-уроки основаны на предположении, что "Apache2 использует исключительно порт 80", в то время как HestiaCP использует обратный прокси, а это означает, что это предположение неверно.

Если вы будете следовать инструкциям, проблема не в вас; проблема в том, что данное руководство применимо к совершенно иной ситуации, чем ваша.

Итак, если вы также используете HestiaCP и экспериментируете с Monit для мониторинга Apache2, запомните две вещи: измените порт на 8081 и используйте команду `systemctl` для остановки, а не `killall -9`. Если вы сделаете эти два действия, вы сможете избежать дальнейших проблем.

Раз уж вы дочитали до этого места, если вам это показалось полезным, пожалуйста, поставьте лайк и поделитесь этим постом. Если вы хотите получать обновления первыми, вы также можете подписаться на меня!

Спасибо за прочтение моей статьи. До встречи в следующий раз.