Отслеживание Apache с помощью VirtualHost

У меня есть веб-сервер apache, на котором запущено множество VirtualHosts.

В последнее время он увязал и перестает отвечать, и мне интересно, как я могу определить, какие VirtualHosts вызывают большую часть проблемы. В прошлом у нас были случаи, когда ошибка в коде отдельного сайта приводила к отключению всего сервера. Моя цель - быстро диагностировать эти случаи.

Я слежу за сервером с помощью Мунин и обратите внимание, что количество процессов apache, использование памяти и загрузка обычно очень высоки в рассматриваемые периоды. Проблема в том, что эта статистика предназначена для всего веб-сервера, а не для отдельных VirtualHosts.

Я написал сценарий для анализа журналов на наличие трафик на VirtualHost, но, похоже, этого недостаточно. Мне наверное нужно определить сколько процессов apache каждый VirtualHost несет ответственность за, или как долго они держат каждый процесс открытым - или возможно сколько памяти за использование каждый несет ответственность.

Где я могу найти эту информацию? Я не против написать скрипт для отслеживания этих данных, но я не знаю, откуда именно их извлечь.

Я понимаю, что не всегда удобно, чтобы mod_status был доступен постоянно, но он и apachetop - лучший способ диагностировать эти проблемы. Однако есть много способов снять шкуру с кошки.

Этот трюк полезен в ряде случаев, и не только для Apache. Однако это зависит от ряда факторов, и вам нужно знать, что он делает, чтобы знать его ограничения.

for pid in `pgrep -u www-data`; do find /proc/${pid}/cwd -printf "%l\n" ; done

Давайте разберемся:

pgrep -u www-data дает вам список pid, работающих под пользовательскими www-данными. Это значение по умолчанию в Debian / Ubuntu, измените его в соответствии с вашей собственной системой (системы на основе RedHat обычно используют httpd, например, как пользователь). Для систем без pgrep вы можете использовать ps axuwww | пользователь grep | awk '{print $ 2}'
для; делать; ... done * loop означает, что мы перебираем каждую запись, выполняющую команду (ы) в части do цикла.
найти / proc / $ {pid} / cwd -printf "% l \ n" просто ищет / proc для каждого из этих PID и выводит текущий рабочий каталог для этого процесса. Apache будет chdir () на VirtualHost по умолчанию при обслуживании файлов с этого VirtualHost. / proc / PID / cwd - это символическая ссылка на каталог, в котором запущен процесс apache. printf "% l \ n" печатает конечную точку для этой ссылки. См. Find (1) для получения дополнительной информации.

У этого трюка есть два основных предостережения:

1) Если что-то, работающее в том же контексте, что и процесс Apache, выполняет chdir () за пределами каталога VirtualHost, вам будет сложно это выяснить.

например сценарий PHP, работающий под mod_php (CGI будет отличаться, поскольку вилка Apache представляет собой отдельный процесс, но я предполагаю, что CGI не проблема, иначе вы могли бы легче отслеживать их).

2) Если у вас есть экземпляры Apache, которые очень быстро обслуживают страницы (например, небольшая статическая HTML-страница). Обычно это не проблема, но возможно. Если вы получаете много ошибок типа «Нет такого файла или каталога», это в основном его проявление. Я ожидал бы некоторых, но не большинства, если они не подходят этому конкретному случаю. В основном это связано с тем, что процессы Apache, которые вы просканировали с помощью ps, уже завершились к тому моменту, когда вы проверили / proc. Очевидно, это означает, что они обслуживают страницы очень быстро.

Что касается процессов Apache, связанных с памятью, я использую ps_mem.py для расчета использования памяти на моих веб-серверах. Если у вас большие процессы Apache (с точки зрения размера резидентной памяти) и они быстро завершаются, это примерно эквивалентно тому, чтобы просить большого толстяка продолжать бегать на 100-метровые спринты. Если ваш веб-сервер не является общим, ошибки типа «Нет такого файла или каталога» обычно являются хорошими кандидатами для перемещения некоторого контента на меньший легкий веб-сервер (например, nginx / lighttpd) или для начала интенсивного кэширования контента (например, varnish / squid).

Я думаю, тебе нужен апачетоп, иначе mod_status (с участием ExtendedStatus On). У меня еще не было проблемы с производительностью в Apache, которая не освещалась mod_status, а apachetop выглядит как изящный инструмент (с некоторыми досадными ограничениями в структуре журнала).