Apache 2 под наблюдением. Мониторинг загрузки системы веб-сервером

Apache 2 под наблюдением



Вступление


Уже написано немало постов на просторах интернета, о мониторинге веб-сервера Apache. При вводе такой фразы, как «мониторинг нагрузки apache» в строке поиска Google, результаты поиска указывают на полезнейший модуль mod_status. А также о еще большей полезности этого модуля в сочетании с perl-расширениями. А если еще и немного пропатчить эти perl-расширения — то вообще супер система получается. Но настроив такую систему — системный администратор на этом, как правило, не останавливается, ему уже необходимо история нагрузки по серверу в целом, потом по каждому хосту, а далее и с точностью до скрипта. И чтоб потом сравнить можно было, а как раньше было, а как теперь нагрузка распределяется.
И вот здесь на помощь может прийти модуль для веб-сервера Apache — mod_performance.


И так, приступим к рассмотрению


Что этот модуль собой представляет. Это обычный модуль Apache 2.x для Linux. Из документации к нему:
  • модуль предназначен для сбора и накопления статистики по использованию ресурсов(CPU и memory, время выполнения скрипта) веб-сервером Apache 2.2;
  • модуль позволяет провести анализ собранных данных.

Что все это значит? А то, что он позволяет отслеживать за тем, сколько ресурсов потребляет поступивший веб-серверу запрос. Каждый раз сохраняя следующую информацию:
  1. виртуальный хост, которому поступил запрос;
  2. файл, который запрашивается;
  3. URI запроса;
  4. CPU нагрузка в %;
  5. использование памяти в %;
  6. время обработки запроса.

А накопившуюся статистику — позволяет анализировать. В качестве базы данных для сохранения и анализа используется SQLite.
В качестве анализатора использования ресурсов, используется не scoreboard, как в mod_status и расширениях perl, а glibtop.
Модуль позволяет отслеживать как абсолютно все запросы, так и конкретные, отфильтрованные по правилу с помощью регулярных выражений. Точнее будет сказано, что модуль ВСЕГДА обрабатывает только те запросы, которые соответствуют фильтру, содержащему регулярное выражение.

Как просмотреть накопленные данные


Модуль предоставляет два интерфейса для просмотра и анализа данных: 1) глобальный; 2) так называемый per-host.
Каждый интерфейс прикреплен к хендлеру:

user-status — per-host
performance-status — глобальный


Доступ к интерфейсам настраивается как и в модуле mod_status, т.е.:

<Location /perf-status>
    Order allow,deny
    SetHandler performance-status
    Allow from 1.1.1.1
</Location>


Глобальный интерфейс позволяет просматривать и анализировать накопленные данные по всем виртуальным хостам, per-host интерфейс же отображает и анализирует только информацию по хосту, к которому интерфейс прикреплен, например, если вызвать хост test.test.test/user-status, то вся выводимая статистика будет касаться только этого хоста. Статистика по другим хостам отображаться не будет.

Глобальный интерфейс управления модулем выглядит, как приведено на рисунке ниже:
Главная форма mod_performance

В главной форме, на рисунке можно увидеть поля:
Mode — режим отображения данных.
Period — дней, период отображения или анализа данных, начиная от начала текущего дня.
Period begin — начало периода, заданного в формате YYYY-MM-DD hh:mm:ss.
Period end — конец периода, заданного в формате YYYY-MM-DD hh:mm:ss.
Если заданы Period begin, Period end — в таком случае отображаются данные ограниченные этими параметрами, а поле Period — игнорируется. В противном случае анализируемый участок задается параметром Period.
Hostname(SQL) — фильтр, выводить данные только по указанному хосту. Синтаксис вызова подобно конструкции like в SQL. Т.е. если задать «%test», то будут выбраны все хосты заканчивающиеся на «test».
Script name(SQL) — подобно предыдущему параметру, только анализируется имя вызываемого скрипта.
URI(SQL) — подобно предыдущему параметру, только анализируется URI запроса.
Graph Mode(Y/N) — отображать графикой или текстом.

Примерный вывод данных выглядит так:
Текстовый вывод накопленной информации

Хост приведенный в примере на картинке — абсолютно тестовый, если он совпадает с реальным — приношу извинения.
А графический режим отображения приведен на рисунке ниже:
Графический вывод

Режимы анализа


Show output without analytics – вывести собранную информацию без анализа, отфильтрованную по хосту, скрипту и URI(графический и текстовый режим).
Maximal %CPU – вывести только записи с максимальным значением %CPU(с учетом фильтрации).
Maximal memory % — вывести только записи с максимальным значением %memory(с учетом фильтрации).
Maximal execution request time – вывести самыйдолго выполняющийся скрипт.
Host requests statistics– вывести статистику обращений к хостам с сортировкой по убыванию (в % от общего числа с учетом фильтров).
Execution history screen(use Period begin) – позволяет вычислять список выполняющихся запросов на указанное время
Number of requests per domain — вывести статистику обращений к хостам с сортировкой по убыванию(не в процентах а количество).
Average usage per host — вывести среднюю загрузку сервера каждым хостом(сумма % CPU, сумма % MEMORY, сумма выполнения скриптов, средний % CPU за период, средний % использования памяти, среднее время выполнения скриптов).
Не буду вдаваться в подробности и некоторые режимы оставлю без внимания.

Как установить модуль


Здесь я привожу пример установки для rpm-систем. Все действия необходимо проводить под пользователем root.
1) установим необходимые пакеты для сборки:

yum install httpd-devel apr-devel libgtop2-devel sqlite-devel gd-devel


2) создадим временную паку для исходных кодов:

mkdir ~/my_tmp
cd ~/my_tmp


3) скачиваем исходные коды модуля и распаковываем архив и переходим в распакованную папку:

wget http://lexvit.dn.ua/utils/getfile.php?file_name=mod_performance_tar201104233487.gz -O mod_performance.tar.gz
tar zxvf mod_performance.tar.gz
cd mod_performance/


4) собираем модуль:

make


5) на warning не обращаем внимания. Главное, чтоб не было error. Если все собралось нормально, то:

make install

или
cp .libs/mod_performance.so <путь куда копировать>


Конфигурируем Apache


Конфигурация будет осуществляться для стандартной установки Apache, т.е модули располагаются в каталоге /etc/httpd/modules, существует каталог /etc/httpd/conf.d/ и он подключен в /ect/httpd/conf/httpd.conf.
1) создать файл конфигурации модуля:

touch /etc/httpd/conf.d/mod_performance.conf


2) вставить в него:

LoadModule performance_module modules/mod_performance.so

<IfModule mod_performance.c>
PerformanceHistory 5
PerformanceEnabled On
PerformanceMaxThreads 80
PerformanceScript \.php
PerformanceStackSize 1
PerformanceUseCanonical On

<Location /admin-status>
Order allow,deny
SetHandler performance-status
Allow from 1.1.1.1
</Location>
</IfModule>


3) сохранить файл и перезапустить Apache:

service httpd restart


Файл конфигурации выступает лишь как пример. Все параметры должны быть подобраны под конкретный сервер.
Вышеприведенная конфигурация модуля позволяет отслеживать запросы к php скриптам.
Описание всех параметров конфигурации можно прочитать в документации модуля.

Внимание, на текущий момент модуль не может отслеживать запросы для конфигурации сервера Apache+mod_fcgid, Apache+mod_cgid или конфигурации, где запрос обрабатывает отдельный демон.

На этом обзор модуля завершен.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 21
  • +3
    SQLite? Закапывайте. Это ж лок на локе и локом погоняет.
    • –1
      Но сорцы погляжу, интересно.
      • +3
        Ну, не стоит сразу закапывать, ибо sqlite не так уж и плоха, она проста в обращении, не требует дополнительных телодвижений от пользователя. + ко всему есть планы прикрутить к модулю сохранение в postgres и mysql. но это пока планы.
        • 0
          Было бы неплохо, если бы можно было самому написать нужный драйвер. Например для Mongo или ещё чего. Но вообще начинание неплохое.
          А ещё лучше чтобы была возможность в Log Format нужные значения, и тем самым разделить проект на две части: логгер и анализатор.
          Например:
          LogFormat "%v:%p %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D %T %{perf_cpu} %{perf_memory}" performance
          И для нужных хостов
          CustomLog /tmp/perf.log performance

          Так и свой анализатор можно сделать, и позволить администратору написать свой.
          • 0
            И ещё добавить в статистику cpu seconds, то есть процессорное время, а не процент.
            • 0
              А здесь — большое спасибо за совет, внесу это в ближайшее время
            • +1
              Да. Здесь вы правы насчет возможности логирования еще и в лог(опциональный выбор). Насчет анализатора, впринципе, я и хочу написать, что-то наподобие phpmyadmin, который будет разбирать накопленную информацию. Но определенный функционал по анализу, все же хочу в модуле оставить, чтоб после минимальной установки у пользователя уже была возможность анализировать, а потом по его желанию, если он хочет — то ставит дополнительные скрипты анализа.
          • –4
            Apache? Закапывайте! :)
            • 0
              o'rly? кто еще нормально сервает AJP?
          • 0
            А чего минусуем Nc_Soft, он отчасти прав. Популярен Apache — да, есть для более быстрые и менее прожорливые веб-сервера — да. Иимхо: собирать статистику, имхо, лучше не модулями веб-сервера, а на более низком уровне. Автору спасибо за инфу, удачи с развитием, не бросай.
            • 0
              а подскажите пожалуйста, как собирать статистику по отдельным скриптам на более низком уровне?
          • +4
            Небольшое замечание по оформлению поста, на правах зануды

            Хост приведенный в примере на картинке — абсолютно тестовый

            это очевидно, ведь это хост example.com
            Согласно RFC2606 если вы хотите указать просто пример какого-нибудь абстрактного хоста, то вам нужно использовать домен example.com

            test.test.test/user-status,

            А вот это уже ошибко, потому что согласно тому же RFC2606 использовать доменные имена из зоны .test рекомендуется для тестирования вещей, связанных с dns

            Для статей и документаций рекомендуется использовать доменные имена из зоны .example или example.com

            • 0
              ошибко ошибка конечно же :)
              • +1
                Спасибо за рекомендации, учту на будущее
              • +3
                А вы не пробовали тестировать с помощью Apache benchmark насколько сильно включение вашего модуля сказывается на производительности сайта?

                Т.е. насколько падает число запросов в секунду которые апач может пережевать при включении статистики?
                • 0
                  Ну как бы на производительность отдельного сайта он особо не влияет, т.к. все что делает модуль по запросу — это только через сокет демону посылает необходимые сведения, на этом все, запрос далее выполняется как обычно. А вот на сервер вцелом по IO может нагрузка увеличиться из-за того, что демон после прекращения запроса будет записывать данные в базу. На текущий момент модуль может обрабатывать одновременно ограниченное чило запросов, при достижении предела он прекращает прием новых а просто занимается завершением обработки уже принятых, но при каждом запросе сверх лимита, он сообщает в лог сервера, о том, что текущего лимита по одновременной обработке не хватает и просит увеличить число. На те запросы, которые не могут быть обработаны демоном это никак не влияет, они выполняются как и обычно, но просто не отслеживаются.
                  • 0
                    Понятно, спасибо за ответ.
                    Интересно было бы посмотреть на бенчмарки когда доведете до состояния конфетки :)
                  • 0
                    ab использовал пока что только в тестах на стрессоустойчивость. А вот временные характеристики пока не снимал — каюсь. Но обещаю все это проделать, как доведу его до состояния «конфетки» :)
                  • 0
                    К сожалению со временем производительность будет падать. Так как SQLite имеет очень плохую тенденцию разрастаться и, впоследствии, все запросы селект, апдейта и инсерта начинают крайне медленно отрабатывать.
                    При относительно высокой нагрузке такие базы придется менять раз в день(Это, кстати, повод подумать на эту тему).

                    По поводу нагрузки на сервер и времени запроса интересно модуль держит постоянное соежинение с демоном или переподключается к нему каждый раз? Через порт или юникссокет?

                    • 0
                      Абсолютно верное замечание, но на такой случай в модуле имеется подрезание истории. Т.е. мне на практике более 30 дней истории не требовалось. Поэтому демон каждые три часа проводит сканирование базы и удаляет старые записи. А по поводу интенсивной нагрузки и базы SQLite, я выложил 0.2 версию модуля, где имеется возможность сохранять по выбору: 1) в текстовый лог(с заданным форматом); 2) SQLite базу и 3) MySQL база данных. Т.е для неинтенсивных серверов можно использовать SQLite, а для более нагруженных MySQL или лог. Плюс еще в новой версии модуля организована поддержка Apache+mod_ruid2(это был первый шажок в поддержке безопасного запуска скриптов сайта). Насчет соединений: при каждом запросе происходит подключение к демону через unix-сокет, по окончанию обработки запроса соединение разрывается.
                      По поводу доработанного модуля я готовлю новую статью, где постараюсь прикрепить исследование нагрузки на сервер при подключении модуля, но быстро ее подготовить не получается :(. Если кто захочет модуль протестировать и обнаружит баги пишите — на сайте модуля организована поддержка :)

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.