mod_performance 0.4 – мониторинг запросов сервера Apache 2.0/2.2/2.4

Скачать исходные коды модуля на github здесь

Функционал

Это обычный модуль Apache 2.x для Linux:

  • модуль предназначен для сбора и накопления статистики по использованию ресурсов(CPU и memory, время выполнения скрипта и пр.) веб-сервером Apache 2.4/2.2/2.0;
  • модуль позволяет производить анализ собранных данных.

Он позволяет отслеживать за тем, сколько ресурсов потребляет поступивший веб-серверу запрос. Каждый раз сохраняя следующую информацию:

  • виртуальный хост, которому поступил запрос;
  • файл, который запрашивается;
  • URI запроса;
  • CPU нагрузка в %;
  • использование памяти в %;
  • время обработки запроса.

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

Сборка и установка модуля

Детально о сборке и установке модуля можно прочесть по этой ссылке.

Принцип работы:

При запуске веб-сервера Apache — запускается демон модуля mod_performance. Успешный запуск демона отмечается в логе сервера строками ниже:

[timestamp] mod_performance: module enabled :)
[timestamp] mod_performance: server started :)

Запустившийся демон открывает unix-сокет и ожидает соединений.

При обработке запроса сервером, происходит проверка запроса на условие: необходимо ли для запроса сохранять статистику или нет. Если проверка прошла успешно, процесс сервера, принявший соединение отправляет демону информацию из procfs и PID(TID) процесса/потока, который будет обрабатывать запрос. По окончании работы отслеживаемого процесса, демон записывает данные в базу данных статистики. На текущий момент, модуль может работать в режиме сервера:

Параметры:

С полным списком параметров можно ознакомиться здесь.

Приведу пример сборки и конфигурирование модуля для CentOS:

  1. отключить selinux
  2. yum install httpd-devel apr-devel gd-devel sqlite3
  3. mkdir ~/tmp
  4. cd ~/tmp
  5. wget https://github.com/bayrepo/mod_performance/archive/master.zip --no-check-certificate -O mod_performance.zip
  6. unzip mod_performance.zip
  7. cd mod_performance-master/
  8. make
  9. cp .libs/mod_performance.so /etc/httpd/modules/
  10. cp mod_performance.conf /etc/httpd/conf.d/
  11. раскомментировать LoadModule performance_module modules/mod_performance.so
  12. mkdir -p /opt/performance/
  13. chown apache:apache /opt/performance/
  14. chmod 755 /opt/performance/
  15. раскомментировать в mod_performance.conf строки #PerformanceDB и #PerformanceSocket
  16. service httpd restart
  17. cp libmodperformance.so.0.4 /usr/lib64/
  18. ln -s libmodperformance.so.0.4 /usr/lib64/libmodperformance.so
  19. ldconfig

Типовая конфигурация для DSO: CentOS

mod_performance.conf
LoadModule performance_module modules/mod_performance.so
 
<IfModule mod_performance.c>
 PerformanceEnabled On
 PerformanceUseCanonical On
 PerformanceScript .php
 PerformanceLogType SQLite
 PerformanceDB /opt/performance/perfdb
 PerformanceSocket /opt/performance/perfsock
 #Minimal script execution time, wich accounts by script as load
 PerformanceMinExecTime 50 SOFT
 <Location /performance-status>
  SetHandler performance-status
  Allow from 1.1.1.1
 </Location>
 
</IfModule>

Объясню, что задано в конфигурационном файле.

PerformanceEnabled — этим параметром активируется демон. Если его не включить, то модуль пудет работать в пассивном режиме. Т.е просто загружаться но не обрабатывать запросы.

PerformanceScript — здесть самое сердце модуля. Этот параметр задает — за чем следить. За какими скриптами. Я установил, что необходима слежка именно за PHP-скриптами.Параметр принимает регулярное выражение.

PerformanceUseCanonical -параметр позволяет игнорировать redirect-handler, генерируемый модулем mod_rewrite. Например, если не включить этот параметр, то можно в итоге получит не путь к скрипту, а нечто нижеследующее:

redirect: /index.php

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

Далее, подобно mod_status, я прикрепляю админский хендлер модуля ко всем хостам по запросу /admin-status. И разрешаю доступ к этой странице только с адреса 1.1.1.1.

PerformanceLogType – этим параметром задается , что данные о запросах будут накапливаться в базе данных sqlite.

PerformanceDB и PerformanceSocket задают путь к базе дынных и сокету.

Типовая конфигурация для php как cgi,suphp,php-fpm,cgid,fastcgi. Предварительно устанавливается расширение mod_performance + любой тип php(php-fpm, cgi, suphp, cgid, fcgid, fastcgi)

mod_performance.conf
LoadModule performance_module modules/mod_performance.so
 
<IfModule mod_performance.c>
 PerformanceEnabled On
 PerformanceUseCanonical On
 PerformanceLogType SQLite
 PerformanceDB /opt/performance/perfdb
 PerformanceSocket /opt/performance/perfsock
 #Minimal script execution time, wich accounts by script as load
 PerformanceMinExecTime 50 SOFT
 PerformanceSocketPermType 777 NOPID
 <Location /performance-status>
  SetHandler performance-status
  Allow from 1.1.1.1
 </Location>
 
</IfModule>

Веб-интерфейс модуля

Доступен при PerformanceLogType = SQLite, MySQL, Postgres.

Расскажу немного о его особенностях (рис 1).

Рис 1.

1. Hide/Show – кнопка «Скрыть/Показать фильтр» – предназначена для сворачивания и разворачивания окна фильтров.
2. Report – выпадающий список доступных отчетов (отчеты анализа накопленных данных)
3. Sort Field – номер выводимого поля, по которому будет производится сортировка (не действует на пользовательские отчеты)
4. Sort Type – тип сортировки выбранного поля – по-возрастанию или по-убыванию (не действует на пользовательские отчеты)
5. Period(days) – интервал в днях от текущего дня за который будут проанализированы данные
6. Period begin (Period End) – точная дата и время начала и конца анализируемого периода (если указаны эти значения, то поле Period(days) игнорируется)
7-8-9. – Дополнительные параметры фильтра анализируемых данных. Возможно как строгое совпадение, так и не строгое – например значение заканчивающееся на test – %test.
10. Ссылка на скачивание самой последней версии
11. Ссылка на документацию по модулю
12. Значок сортировки данных на странице (v – по-убыванию, ^-по-возрастанию)
13. Строка заголовков столбцов
14. Фиксированная строка номера столбца. Не сдвигается даже при прокрутке страницы.

Интерфейс модуля использует JavaScript.

Встроенные отчеты модуля

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

Выводимые поля в отчетах:

  • ID — идентификатор записи;
  • DATE ADD — когда прошел запрос;
  • HOSTNAME — имя виртуального хоста;
  • URI — uri запроса;
  • SCRIPT — выполнявшийся скрипт;
  • CPU(%) — использование CPU в %;
  • MEM(%) — использование памяти в %;
  • TIME EXEC(sec) — время выполнения запроса;
  • CPU TM(sec) — процессорное время в секундах;
  • MEM USE(Mb) — использование памяти в мегабайтах;
  • IO READ(Kb) — прочитано Кбайт процессом;
  • IO WRITE(Kb) — записано Кбайт процессом.

Отчеты доступны в режиме: SQLite, MySQL, Postgres

Если текстовой информации не достаточно, есть возможность посмотреть на диаграмму:

Пользовательские отчеты

Добавлена возможность создавать свои отчеты (отчет – это метод анализа собираемых модулем данных). Модуль по-прежнему несет определенный набор отчетов, так называемый «из коробки». Но в исходных кодах модуля присутствует файл custom.tpl, который расширяет число доступных отчетов модуля. А также позволяет создавать свои собственные запросы к базе данных и отображение полученных результатов. Как это сделать я опишу далее.

Пример настройки пользовательских отчетов (для CentOS/Redhat/Fedora) поставляемых с исходным кодом модуля:

Пользовательские отчеты

Алгоритм сбора статистики

Показатель CPU usage вычисляется по следующей схеме. Модуль при поступлении запроса снимает показания jiffies процесса (системы в целом и текущего процесса) и в конце запроса еще раз производится замер и эти данные посылаются демону. На их основании принимается решение об использовании процессора. Т.е. если наблюдая с помощью top вы увидели загрузку: 0%, 10%, 100%, 20%, то не ожидайте, что модуль сохранит 100%, т.к. сохранится именно то количество временни, которое за время существования запроса было выделено именно на этот процесс. «На глазок» для вышеприведенного примера это число будет равно — 32%.

А вот показатель памяти собирается по другому принципу. Во время обработки запроса, демон каждые 10 миллисекунд производит замер использования памяти процессом обрабатывающим запрос и в конце сохраняет самое максимальное значение.

Показатель IO (read & write) отслеживается подобно CPU — производится замер прочитанных и записанных данных процесса в начале запроса и в конце запроса. Разница этих величин переводится в килобайты и сохраняется в базе. Т.е. фактически этот показатель отслеживает число записанных/прочитанных байт в течении существования запроса. Сразу скажу, что в качестве анализируемого источника используется показатель: /proc/[pid]/io — read_bytes, write_bytes, cancelled_write_bytes.

Куда сохранять статистику запросов?

Вот он важный вопрос — куда сохранить собираемую статистику. Для упрощения этой головоломки в новой версии модуля встроена поддержка таких БД как: SQLite, MySQL, PostgreSQL, а так же экзотика — сохранение в файл логов. Теперь не нужно подстраиваться под модуль — он подстроится под вас. Для успешной работы модуля(не в режиме «Сохранение в лог») необходимо наличие на машине хотя бы одной из следующих библиотек:

  • libsqlite3.so;
  • libmysqlclient_r.so;
  • libpq.so.

При сборке пакета наличие mysql-devel, sqlite-devel, postgresql-devel не требуется. Эти библиотеки подгрузятся динамически во время работы модуля. Точнее подгрузится нужная для выбранного режима библиотека.

Пример 1. Работа с SQLite. Самый простой вариант, база данных создается автоматически, таблица создается автоматически, нет необходимости в пользователях и прочее. Только одно очень важное замечание для тех кто уже использовал модуль версии 0.1: в старой базе и новой различаются структуры таблиц, поэтому для успешной работы старую базу лучше удалить. Т.к. cам модуль не пересоздает существующую таблицу.

Для работы с SQLite необходимо:

PerformanceDB /statistics/apache/perfdb
PerformanceLogType SQLite

Пример 2. Работа с MySQL. Более сложный вариант. Создайте базу данных, например, perf и пользователя perf с правами на эту базу:

mysql> create database perf;
mysql> CREATE USER 'perf'@'localhost' IDENTIFIED BY 'perf';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'perf'@'localhost' WITH GRANT OPTION;

таблицу модуль создаст сам. И теперь в настройках модуля:

PerformanceLogType MySQL
PerformanceDbUserName perf
PerformanceDBPassword perf
PerformanceDBName perf

И опять же очень важное замечание для тех кто уже использовал модуль версии 0.2 более ранних версий чем 0.2-8: в старой базе и новой различаются структуры таблиц, поэтому для успешной работы старую базу лучше удалить. Т.к. cам модуль не пересоздает существующую таблицу.

Пример 3. Работа с PostgreSQL. Более сложный вариант. Так же необходимо создать базу и пользователя для доступа:

postgres=# CREATE USER perf WITH PASSWORD 'perf';
postgres=# CREATE DATABASE perf;
postgres=# GRANT ALL PRIVILEGES ON DATABASE perf to perf;

в файле /var/lib/pgsql/data/pg_hba.conf

/var/lib/pgsql/data/pg_hba.conf
local all all trust
host all all 0.0.0.0/0 trust
host all all : : : 1/128 trust

и наконец настройки модуля:

PerformanceLogType Postgres
PerformanceDbUserName perf
PerformanceDBPassword perf
PerformanceDBName perf

Пример 4. Работа с текстовым логом. В данном режиме не требуется никаких дополнительных библиотек. Достаточно приписать файл, куда будет консолидироваться статистика.

PerformanceLogType Log
PerformanceLog /statistics/apache/perf.log

По умолчанию данные в этот файл попадают в таком формате:

[%DATE%] from %HOST% (%URI%) script %SCRIPT%: cpu %CPU% (%CPUS%), memory %MEM% (%MEMMB%), execution time %EXCTIME%, IO: R — %BYTES_R% W — %BYTES_W%

что разворачивается в:

[2011-06-05 19:28:28] from example.com (/index.php) script /var/www/example.com/index.php: cpu 0.093897 (0.010000), memory 0.558202 (5.597656), execution time 10.298639, IO: R — 104.000000 W — 248.000000
[2011-06-05 19:28:39] from example.com (/index2.php) script /var/www/example.com/index2.php: cpu 0.000000 (0.000000), memory 0.558202 (5.597656), execution time 10.159158, IO: R — 0.000000 W — 0.000000

А сейчас более подробно. Для этого режима можно задать формат выводимой в лог строки. Для этого существуют предопределенные макроимена:

  • %DATE% — преобразуется в дату начала запроса;
  • %CPU% — использование CPU в процентах;
  • %MEM% — использование памяти в процентах;
  • %URI% — URI запроса
  • %HOST% — имя виртуального хоста, к которому адресовался запрос;
  • %SCRIPT% — имя скрипта;
  • %EXCTIME% — длительность выполнения скрипта в секундах;
  • %CPUS% — сколько секунд система потратило именно на этот процесс в секундах;
  • %MEMMB% — использование памяти в мегабайтах;
  • %BYTES_W% — килобайт записано;
  • %BYTES_R% — килобайт прочитано;
  • — вывести знак процента. К примеру: Hello from %HOST% I use %CPU% cpu today %DATE%

развернется в Hello from example.com I use 0.23 % cpu today 2011-06-05 19:28:28

Такой лог может быть глобальным, а также и для каждого виртуального хоста свой. Также как и каждый хост может иметь свой уникальный формат вывода в лог.

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

Сохранение данных в одном централизированном хранилище

Настройка модуля для работы с централизированным хранилищем:

Сохранение данных в одном централизованном хранилище

Для тех у кого был установлен модуль версии 0.3

В версии 0.4 поменялся формат таблицы данных. Для корректного функционирования 0.4 версии старую таблицу необходимо модифицировать:

SQLITE: ALTER TABLE performance ADD hostnm CHAR(32);
MySQL: ALTER TABLE performance ADD hostnm CHAR(32);
PostreSQL: ALTER TABLE performance ADD hostnm CHAR(32);
1) , 2)
устаревший метод