Как проверить работоспособность php fpm
Мониторинг PostgreSQL + php-fpm + nginx + диска с помощью Zabbix
Много информации в сети по Zabbix, много и шаблонов самописных, хочу представить на суд аудитории свои модификации.
Zabbix — очень удобный и гибкий инструмент мониторинга. Хочешь — сотню мониторь, хочешь — тысячу станций, а не хочешь — следи за одним сервером, снимай сливки во всех разрезах. Буду не против отдать на github, если кто коллекционирует схожие.
Так случилось, что решили мы выложить на хостинг базу данных с оберткой из php-fpm+nginx. В качестве БД — postgres. Мысли собирать данные о работе машины были еще до покупки хостинга — это нужно, это полезно! Волшебным пенделем к внедрению системы послужили тормоза жесткого диска на нашей VDS станции — в начале скриптом каждую минуту кладем время и замерянную скорость в файл, а потом в экселе строим графики, сравниваем как было/стало, снимаем количественную статистику. И это всего один параметр! А вдруг виноват не VDS, а наши приложения, которые на нем работают. Вобщем, мониторить надо много, мониторить надо удобно!
Не буду останавливаться на том, как установить сервер, много вариантов и документации по этому поводу полно. Я пользовался официальной:
https://www.zabbix.com/documentation/ru/2.2/manual/installation/install_from_packages
В качестве операционной системы — CentOS 6.5
Файлы, которые вам понадобятся — в архиве habr-zabbix-mons.zip
На станцию агента помимо самого zabbix-agent обязательно ставим zabbix-sender:
Вместо «123.45.67.89» — IP машины, где вы установили zabbix-server.
Вместо «Ваш_агент_addr» поставить имя/ip машины, как добавили агента на сервере, поле «Host name».
Мониторим скорость жесткого диска
Я пользуюсь программой hdparm. Вы можете использовать другую, если имеете предпочтения:
Выбираем раздел, который будем мониторить:
Добавляем в /etc/zabbix/zabbix_agentd.d/user.conf
Разрешаем запуск sudo без консоли (отключаем requiretty) и добавляем команду, которую мы запускаем от имени пользователя zabbix:
Увеличиваем время на запрос параметра в конфиге агента, т.к. hdparm затрачивает 3-10 и более секунд на замер, в зависимости от скачков по скорости, видимо.
Также и на сервере надо исправить время ожидания ответа агента
Готово! У нас есть параметр, и есть граф по нему. Если вы добавляли в шаблон, прикрепите шаблон к хосту. Любуемся!
В нашем случае то, что было до 31.07 — это плохо, хоть и средняя скорость была высокой, но очень часто она спускалась ниже 1МБ/с. Сейчас (после перевода нас на очередную другую ноду) она стабильная и редко опускается, пока был минимум 5-6МБ/с. Думаю, что на прежней ноде она падала совсем не из-за диска, а из-за занятости каких-то других более важных ресурсов, но главное, что мы видим провалы!
Хороший параметр, но не снимайте его слишком часто, ведь в эти 3-10 секунд замера диск будет очень занят, рекомендую раз в 10-60 минут, или вообще отключить, если статистика вам понравилась и не будете мучить хостера.
Мониторим логи nginx
Казалось бы, зачем мониторить логи? Подключил метрику, да аналитику, и наблюдай все там. Но эти ребята не покажут нам ботов, которые не запускают js на странице, также как и человеков, если у них отключен js. Предлагаемое решение покажет частоту обхода роботами ваших страниц, и поможет предупредить высокую нагрузку на ваш сервер от поисковых ботов. Ну и любую статистику, если поковыряете loghttp.sh
Добавляем в /etc/zabbix/zabbix_agentd.d/user.conf
Кладем loghttp.sh в /etc/zabbix/scripts, в той же папке выполняем
Проверьте путь к access.log
Google молодец — сканит с одной скоростью, Иногда приходит Mail, редко Bing, а Yahoo и не видать. Yandex с переменным успехом индексирует, но много — еще бы в выдаче показал, было бы замечательно 🙂
На графике Гугл и Яндекс на левой шкале, остальные — на правой. Значение на шкале — количество посещений от замера до замера, тоесть за 10 минут. Можно поставить 1 час, но тогда рискуем пропустить много посещений в момент ротации лога.
Мониторим nginx
Зачем мониторить nginx — пока не знаю, ни разу проблем с ним не было. Но пусть будет, для статистики. Пробовал использовать набор шаблонов ZTC, но очень уж не нравятся мне мигающие процессы питона в памяти, по 10МБ каждый. Хочу нативно, хочу bash! И главное — за один запрос собрать все параметры. Именно этого я хотел добиться, когда мониторил все службы — минимум нагрузки на сервер и максимум параметров.
Подобных скриптов можно найти много, но раз уж я подошел комплексно к мониторингу Веб-сервера, выкладываю свою версию.
Научим nginx отдавать статусную страницу, добавим конфигурацию для localhost
Не забудьте применить изменения:
Добавляем в /etc/zabbix/zabbix_agentd.d/user.conf
Кладем nginx.sh в /etc/zabbix/scripts, в той же папке выполняем
Если не ставили curl на предыдущем шаге, надо установить:
Проверьте, на всякий случай, что в nginx.sh в переменных SENDER и CURL верные пути.
Импортируем loghttp.xml в шаблоны zabbix, подключаем шаблон к хосту.
Ну и, наслаждаемся картинками!
Данный монитор умеет информировать о том, что nginx не работает, либо что он начал отвечать слишком медленно. По-умолчанию порог такой: если за последние 10 замеров скорость реакции nginx не опускалась ниже 10мс, создаем Warning. Монитор сообщит, если сервер вернет некорректный статус(nginx в памяти, а отвечает белибердой).
Мониторим php-fpm
Полезно осуществлять, если у вас используется динамический набор процессов (pm = dynamic в /etc/php-fpm.d/www.conf) по умолчанию или осознанно. Монитор умеет предупреждать о недоступности службы, или ее замедлении.
Я пытался сделать опрос службы без nginx, но у меня не получилось найти такую установленную программу, которая бы помогла во взаимодействии с php-fpm. Подскажите варианты, если кто знает.
Возможно, php-fpm не отдает статус, проверим
Если что-то поменяли, применяем:
Добавляем в /etc/zabbix/zabbix_agentd.d/user.conf
Кладем php-fpm.sh в /etc/zabbix/scripts, в той же папке выполняем
Пропишите в php-fpm.sh путь до FastCGI сервера (параметр listen в /etc/php-fpm.d/www.conf)
Сокеты также поддерживаются.
Если не установлен cgi-fcgi, надо установить:
Импортируем php-fpm.xml в шаблоны zabbix, подключаем шаблон к хосту.
Мониторим PostgreSQL
Это основное блюдо! Его повар готовил дольше всех 🙂
В качестве прототипа был выбран pg_monz — open_source, поддерживается, много параметров, работает с последней версией postgres. Недостаток глобальный — я собираю все параметры по службе, т.к. не знаю, какой из них и когда “выпрыгнет”.
Когда разобрался с pg_monz и включил сбор всех параметров — по базам и таблицам, всего около 700 штук, нагрузка на сервер увеличилась в 10 раз! (скорее-всего с pgbouncer будет не так заметно) Хотя параметры собирались раз в 300 секунд. Оно и понятно — для каждого параметра запускается psql и выполняет запрос, часто к одним и тем же таблицам, просто к разным полям. В общем — от pg_monz остались только названия полей и таблиц. Ну, пробуем!
Добавляем в /etc/zabbix/zabbix_agentd.d/user.conf
Кладем psql*.sh в /etc/zabbix/scripts, в той же папке выполняем
Проверьте, на всякий случай, что в nginx.sh и psql_db_stats.sh в переменной PSQLC верный путь до psql.
Импортируем psql.xml в шаблоны zabbix. Если не планируете собирать данные по базам и таблицам, то сразу отключите на вкладке “Discovery” шаблона “PSQL DB list” и “PSQL table list”. А если планируете, то для начала задайте макрос на вкладке “Macros” агента <$PGTBL_REGEXP>— имя таблицы, которую будете мониторить подробно. Хотя, скорее всего, в начале вы захотите посмотреть все таблицы 🙂
Подключаем шаблон к хосту, смотрим как собираются данные…
Все параметры шаблона (унаследованы от pg_monz) и значения их по умолчанию можно посмотреть на вкладке “Macros” шаблона. Попробую сделать описание этих параметров:
| Macro | По умолчанию | Описание |
|---|---|---|
| postgres | Имя базы данных для подключения | |
| 127.0.0.1 | Хост PostgreSQL (относительно Zabbix агента, если там же: 127.0.0.1) | |
| /var/lib/pgsql/9.3/data/pg_log | Каталог с логами PostgreSQL | |
| 5432 | Номер порта PostgreSQL | |
| postgres | Имя пользователя для подключения к PostgreSQL | |
| . (все базы) | Название базы для сбора подробных сведений* | |
| . (все таблицы) | Название таблицы для сбора подробных сведений* | |
| 10 | Если количество checkpoint’ов превысит данный порог, сработает триггер | |
| 2 | Если среднее количество сессий за последние 10 минут превысит установленный порог, сработает триггер | |
| 1073741824 | Если размер базы превысит оговоренный лимит в байтах, сработает триггер | |
| 1048576 | Если скорость записи во временные файлы за последние 10 минут превысит PGTEMPBYTES_THRESHOLD в байтах, сработает триггер | |
| 90 | Если за последние 10 минут среднее попадание в кэш будет ниже порога, сработает триггер на базу | |
| 0 | Как только количество мертвых блокировок превысит установленный предел, сработает триггер | |
| 1 | Если запрос выполняется дольше PGSLOWQUERY_SEC секунд, то считать его медленным | |
| 1 | Если среднее количество медленных запросов за последние 10 минут превысит порог, то сработает триггер |
* в качестве параметра используется регулярное выражение, например
org — все таблицы и схемы, в которых содержится подстрока org
\.(organization|resource|okved)$ — таблицы с именами organization, resource, okved в любой схеме
^msn\. — все таблицы в схеме msn
Если у вас не появляется параметр “PSQL error log”, то скорее всего не верно задан путь <$PGLOGDIR>— поищите на агенте файлик “postgresql-Sun.log” — где он лежит, эту папку и записывайте в макрос.
Мониторим php-opcache
Как принято в лучших домах — десерт!
В данной статье просматривается вся цепочка — от запроса пользователя до данных, кроме одного узла — самого php. Чтобы чуть чуть приоткрыть этот ящик, попробуем собрать статистику встроенного в php5 ускорителя opcache функцией opcache_get_status.
Добавляем в /etc/zabbix/zabbix_agentd.d/user.conf
Кладем php-opc.* в /etc/zabbix/scripts, в той же папке выполняем
Пропишите в php-opc.sh путь до FastCGI сервера (параметр listen в /etc/php-fpm.d/www.conf)
Сокеты также поддерживаются. Тут еще можно отключить discovery(с разгрузкой сети), SCRIPTS_ENABLE=0
Если не ставили fcgi для мониторинга php-fpm, надо установить:
Импортируем php-opc.xml в шаблоны zabbix, подключаем шаблон к хосту.
Пока создавал триггеры, уменьшил размеры памяти на кэш для своего opcache в 2 раза. Так-что полезно видеть и эту статистику. Если бы проект на этом сервере не пополнялся новыми модулями, то уменьшил бы в 4 раза легко.
Заключение
Пока не знаю, какие еще параметры можно промониторить. Это основные сервисы, которые работают на нашей VDS-машине. Как наберется — поделюсь, конечно. Было бы неплохо добавить шаблон-скррипт mysql, но задачи пока нет. Если очень надо — сделаю 🙂
Подход можно обсуждать — у меня же получились отдельные примочки для каждой службы, и это тоже неплохо — взял скрипт, дополнил конфиг, залил шаблон — готово.
Если собирать эти мониторы в один пакет, то, конечно, надо делать дополнительно discovery на каждую службу — может быть несколько nginx, php-fpm, postgres. Они могут слушать как порты, так и сокеты.
Версии
CentOS release 6.5 (Final)
ZabbixServer 2.2.4
ZabbixAgent 2.2.4
hdparm 9.43
nginx 1.6.1
php-fpm 5.3.3
PostgreSQL 9.3.4
php-opcache 5.5.15
Шаблоны и скрипты тут: http://www.uralati.ru/frontend/for_articles/2014-08-habr-zabbix-mons.zip
Для мониторинга php-fpm и pfp-opcache в архиве имеется версия скриптов для работы с curl(с теми же шаблонами). Описание настроек закомментировано в соответствующих скриптах php-*_curl.sh, см.upd2
Теперь для мониторинга php-fpm не нужно прописывать конфиг nginx
Теперь для мониторинга php-opcache не нужно прописывать конфиг nginx
Но требуется прописывание LISTEN до php-fpm в скриптах и установка cgi-fcgi:
Это переключение с curl на fcgi позволило сократить время выполнения запросов на мониторинг в 2 раза
Также добавлен копирайт и проверки на правильность путей до программ. Теперь при запуске скрипта из консоли он умеет ругаться, если не из консоли, то ошибка попадет в логи сервера, как не верный ответ.
Устаревшие шаблоны и скрипты тут: скачать
Настройка PHP-FPM
Интерпретатор языка программирования PHP может работать в нескольких режимах. Он может быть интегрирован в веб-сервер в виде специального модуля или использоваться как отдельный сервис php-fpm. Аббревиатура FPM расшифровывается как Fastcgi Process Manager. Это сервис, который запускает несколько процессов, которые могут выполнять PHP скрипты. Процессы могут получить скрипты, которые надо выполнить по TCP или Unix сокетам.
Обычно php-fpm используется вместе с веб-сервером Nginx. В этой статье мы рассмотрим как выполняется настройка PHP-FPM для максимально эффективной работы на вашем сервере.
Настройка PHP-FPM
Менеджер процессов PHP-FPM может запускать несколько процессов обработчиков. Обычно для каждого отдельного сайта принято использовать отдельный обработчик, это позволяет распределить нагрузку и отслеживать статистику по каждому сайту. Поэтому есть общий конфигурационный файл php-fpm и конфигурационный файл для каждого обработчика, который обычно называется конфигурационным файлом пула. Обработчик принято называть пулом потому что на самом деле обработкой занимается не один процесс, а целая группа процессов, у каждого из которых есть несколько потоков. Всё это обеспечивает быстрое выполнение скриптов.
1. Установка компонентов
Сервис php-fpm поставляется вместе с интерпретатором php. Установка php-fpm Ubuntu выполняется такой командой:
sudo apt install php-fpm
Кроме того нам понадобится веб-сервер Nginx, потому что php-fpm чаще всего используется вместе с этим веб-сервером:
sudo apt install nginx
2. Конфигурационные файлы
В этой инструкции мы будем рассматривать настройку PHP-FPM на примере Ubuntu. Основной конфигурационный файл находится в такому пути:
Обратите внимание, что это не php.ini файл, а файл настройки именно FPM процессов. Файл php.ini находится в этой же папке:
А вот файлы конфигурации пулов находятся в каталоге /etc/php/7.4/fpm/pool.d/. По умолчанию там находится файл пула по умолчанию www.conf:
Вы можете использовать его в своей конфигурации или копировать для создания новых пулов.
3. Создание пула
Скопируйте файл пула, например losst.conf в папке /etc/php/7.4/fpm/pool.d/ скопируйте в него содержимое файла www.conf. В конце статьи я приведу полностью рабочий конфигурационный файл, но лучше всё же использовать конфигурацию вашей версии PHP:
cp /etc/php/7.4/fpm/pool.d/www.conf /etc/php/7.4/fpm/pool.d/losst.conf
Теперь откройте этот файл в текстовом редакторе, например в vim:
sudo vi /etc/php/7.4/fpm/pool.d/losst.conf
Далее надо изменить группу и пользователя, от имени которых будут запускаться процессы пула. Это важно, поскольку у процесса должен быть доступ к файлам PHP, которые надо выполнить. Обычно в Ubuntu для таких целей используется пользователь и группа www-data. От имени этого же пользователя обычно запускается веб-сервер:
Обычно, если вы получаете ошибку permission denied при интерпретации php файлов в php-fpm, означает, что процесс php-fpm запущен от имени не того пользователя или включена строгая политика SELinux.
4. Настройка сокета
Если вы используйте файловый сокет, к нему должен быть доступ у веб-сервера, поэтому надо сделать владельцами файла того пользователя и группу, от имени которых запущен веб-сервер, в данном случае www-data и дать им все права на него:
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
Если сокет сетевой, то в этом нет необходимости. Для сетевого сокета можно дополнительно указать с каких адресов можно к нему подключаться. Например, только от 127.0.0.1:
5. Настройка процессов
С помощью параметра pm можно настроить сколько дочерних процессов будет запускаться для этого пула и когда. Есть три режима работы:
Режим static не выгоден, потому что вне зависимости от нагрузки потребляется много памяти и процессорного времени на поддержание работы процессов. Более интересны режимы ondemand и dynamic. Давайте будем использовать режим dynamic. Этот режим имеет три настройки:
Для режима static надо указать только pm.max_children. Для режима ondemand кроме pm.max_children надо указать pm.process_idle_timeout этот параметр означает через какой промежуток времени простоя процесс будет завершен.
Давайте разберемся с режимом dynamic. Запускать много дочерних процессов при старте не надо, в большинстве случаев 2-3 будет достаточно:
Минимальное количество процессов в режиме ожидания тоже большое не нужно, это запас, чтобы php-fpm смог быстро обработать новые запросы не тратя время на запуск новых процессов. Однако это значение должно быть не меньше pm.start_servers, иначе ничего не заработает:
Максимальное количество процессов определяет как быстро процессы будут завершаться при падении нагрузки, можно оставить 10 процессов:
Параметр pm.max_children настройте под себя, обычно достаточно 20-30 процессов, но всё зависит от нагрузки и количества оперативной памяти, если памяти мало лучше пожертвовать производительностью и установить меньшее значение:
Почти готово. Но есть ещё одна проблема. Если дочерние процессы работают слишком долго, в них накапливаются утечки памяти, и рано или поздно на сервере память закончится. Чтобы этого избежать можно настроить автоматическое завершение процесса после выполнения определённого количества запросов, например, 1000:
6. Настройка статистики
Для подбора оптимального значения pm.max_children вам может понадобиться посмотреть статистику в реальном времени сколько процессов запущено, сколько из них находится в ожидании, а также какая длина очереди ожидающих выполнения запросов. Для включения вывода статистики просто добавьте такую строчку:
7. Настройка php.ini
php_admin_flag[display_errors] = off
php_admin_value[error_log] = /var/log/fpm-php.losst.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 32M
Когда все настройки завершены, не забудьте сохранить изменения и перезапустить php-fpm:
sudo systemctl restart php7.4-fpm
8. Настройка веб-сервера
Для того чтобы всё протестировать придётся настроить ещё и веб-сервер. В конфигурационный файл виртуального хоста Nginx надо добавить такие строки:
Последняя директива fastcgi_pass указывает как надо передавать данные php-fpm, сюда можно передать путь к файлу сокету, на котором слушает сервис или IP адрес и порт. В данном случае используется ранее настроенный 127.0.0.1:9000. После завершения настройки перезапустите Nginx:
sudo systemctl restart nginx
Теперь вы можете открыть в браузере страницу статистики, как видите всё работает:
Можно ещё создать файл phpinfo.php с текстом в каталоге веб-сервера и посмотреть настройки php, например, memory_limit, заданный в файле конфигурации пула работает:
Настройка веб-сервера может очень сильно отличаться в зависимости от ваших требований. Здесь приведен только общий пример, чтобы проверить работоспособность и верность настройки.
Менеджер процессов FastCGI (FPM)
Содержание
FPM (FastCGI Process Manager, менеджер процессов FastCGI) является альтернативной реализацией PHP FastCGI с несколькими дополнительными возможностями обычно используемыми для высоконагруженных сайтов.
Эти возможности включают в себя:
продвинутое управление процессами с корректной (graceful) процедурой остановки и запуска;
возможность запуска воркеров с разными uid/gid/chroot/окружением, а также запуска на различных портах с использованием разных php.ini (замещение safe_mode);
логирование стандартных потоков вывода (stdout) и ошибок (stderr);
аварийный перезапуск в случае внезапного разрушения opcode-кеша;
поддержка ускоренной загрузки (accelerated upload);
Динамическое/статическое порождение дочерних процессов;
Базовая информация о статусе SAPI (аналогично Apache mod_status);
Конфигурационный файл, основанный на php.ini.
User Contributed Notes 8 notes
You will probably want to create an init script for your new php-fpm. Fortunately, PHP 5.3.3 provides one for you, which you should copy to your init directory and change permissions:
/sapi/fpm/init.d.php-fpm.in /etc/init.d/php-fpm
$ chmod 755 /etc/init.d/php-fpm
It requires a certain amount of setup. First of all, make sure your php-fpm.conf file is set up to create a PID file when php-fpm starts. E.g.:
—-
pid = /var/run/php-fpm.pid
—-
(also make sure your php-fpm user has permission to create this file).
Now open up your new init script (/etc/init.d/php-fpm) and set the variables at the top to their relevant values. E.g.:
—
prefix=
exec_prefix=
php_fpm_BIN=/sbin/php-fpm
php_fpm_CONF=/etc/php-fpm.conf
php_fpm_PID=/var/run/php-fpm.pid
—
Your init script is now ready. You should now be able to start, stop and reload php-fpm:
$ /etc/init.d/php-fpm start
$ /etc/init.d/php-fpm stop
$ /etc/init.d/php-fpm reload
The one remaining thing you may wish to do is to add your new php-fpm init script to system start-up. E.g. in CentOS:
$ /sbin/chkconfig php-fpm on
Disclaimer: Although I did just do this on my own server about 20 mins ago, everything I’ve written here is off the top of my head, so it may not be 100% correct. Also, allow for differences in system setup. Some understanding of what you are doing is assumed.
Настройка мониторинга nginx, php-fpm, apache в Zabbix
Обновление моей старой и популярной статьи на тему мониторинга. В этой заметке мы займемся настройкой мониторинга web сервера nginx, apache и php-fpm в zabbix сервере с помощью готовых шаблонов. Полученная информация может пригодиться при анализе нагрузки на сайт, его скорости, при оценке качества хостинга, для прогнозирования максимально возможной посещаемости.
Цели статьи
Введение
Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:
То же самое на Debian 10, если предпочитаете его:
Я буду в своем примере настраивать все на CentOS 7, но в данном случае дистрибутив не имеет принципиального значения, все так же настраивается и на других linux системах с учетом их особенностей в установке пакетов и путей для конфигов и программ.
Мы будем использовать в качестве источника информации штатные возможности nginx, apache и php-fpm, затем передавать данные в zabbix сервер и там анализировать. Я подразумеваю, что nginx или apache вы уже настроили и имеете некое представление о работе его компонентов, поэтому некоторые вещи я не разжевываю, а просто говорю, что делать.
Подготовка nginx к мониторингу
Я планирую мониторить следующие параметры nginx:
| accepts per second | Число принятых соединений в секунду |
| active connections | Текущие активные соединения |
| handled per second | Число обработанных соединений в секунду |
| latency | Время ответа сервера в миллисекундах |
| memory allocated | Занимаемая память |
| process count | Число запущенных процессов |
| reading state connection count | Текущее число соединений, в которых nginx в настоящий момент читает заголовок запроса |
| requests per second | Число запросов в секунду |
| waiting state connection count | Текущее число бездействующих соединений в ожидании запроса |
| writing state connection count | Текущее число соединений, в которых nginx в настоящий момент отвечает |
| memory allocated | Сколько памяти занимают все worker process |
Сервер nginx умеет отдавать часть необходимой нам информации о своем состоянии. Для этого его надо соответствующим образом подготовить. Открываем конфиг сервера и добавляем туда следующую конструкцию:
Я обычно добавляю в самый конец основного конфига nginx.conf. Сохраняем и перечитываем конфигурацию, перед этим проверив его конфиг на ошибки:
Проверяем, можем ли мы получить необходимую информацию для настройки мониторинга:
Теперь проверим, сможет ли zabbix получать эту страницу.
Если у вас так же, то все в порядке, можно двигаться дальше. Если что-то не получается, то проверяйте конфиги, смотрите логи. Это штатный функционал, он должен без проблем настраиваться и работать.
Сразу обращаю внимание на один важный момент, на котором я застрял на приличное время. Через curl я без проблем забирал страничку со статусом nginx, а вот через zabbix никак не получалось. Была ошибка:
Я всю голову сломал, 10 раз перепроверил конфиги, никак не мог понять, почему не работает. Оказалось, дело было вот в чем. Zabbix-agent обращался к серверу Nginx по протоколу ipv6. Это при том, что как агент, так и nginx работали по ipv4. Я принудительно отключаю у служб ipv6, если он не используется.
Обнаружил это случайно, когда от безысходности запустил Nginx на всех интерфейсах и снял ограничения allow/deny в конфиге. Тогда запрос прошел нормально. Я посмотрел access лог и увидел, что zabbix-agent обращается с адреса ::1. И все стало ясно. Я так и не понял, как заставить агента ходить по ipv4. В итоге запустил nginx на обоих протоколах и разрешил забирать страницу статуса с адреса ::1. После этого заработало.
Самое неприятное в этой ситуации было то, что в логах нигде не было никаких ошибок, отклоненных запросов или чего-то еще, что могло бы дать зацепку. Zabbix agent просто писал, что подключение отклонено и все. О том, что он обращается по ipv6, не было никакого намека.
Настройка в zabbix мониторинга nginx
В прошлой редакции этой статьи дальше шло описание скрипта, который будет парсить вывод nginx-status и передавать данные в zabbix. Сейчас все можно сделать гораздо проще и удобнее. На агенте не надо ничего настраивать. Все выполняется исключительно в шаблоне. То есть вам достаточно загрузить готовый шаблон для мониторинга nginx на zabbix сервер, прикрепить его к хосту и все будет работать.
Это удобный подход, который избавляет от необходимости настраивать агентов. Теперь все выполняется с сервера. Минус этого подхода только в том, что возрастает нагрузка на сервер мониторинга. Это плата за удобство и централизацию. Имейте это ввиду. Если у вас большая инсталляция мониторинга и есть средства автоматизации типа ansible, возможно вам имеет смысл по старинке парсить данные скриптом. Но в общем случае я рекомендую делать так, как я расскажу далее.
Суть мониторинга Nginx будет сводиться к тому, что мы через агента станем забирать страницу http://localhost/nginx-status на сервер. Там с помощью регулярных выражений и зависимых элементов данных будем формировать нужные метрики.
Выбираем файл и снова нажимаем Import :
В шаблоне 11 итемов, описание которых я привел ранее.
Подробнее остановимся на триггерах. Их 5 штук.
С триггерами больше всего вопросов. Предложенная мной схема может работать независимо от проекта, не требует начальной калибровки, но могут быть ложные срабатывания из-за разовых очень сильных всплесков, которые быстро проходят, но сильно меняют средние параметры на интервале.
Более надежно могут сработать триггеры, где явно указаны лимиты в конкретных значениях. Но такой подход требует ручной калибровки на каждом проекте в отдельности. Надо смотреть средние значения метрик и выставлять лимиты в зависимости от них. Если проект будет расти, то лимиты постоянно придется менять. Это тоже не очень удобно и не универсально.
Я в итоге остановился на анализе средних значений, не используя конкретных лимитов. Как поступать вам, решайте отдельно, в зависимости от ситуации. Если у вас один проект, которому вы уделяете много внимания, то ставьте лимиты руками на основе анализа средних параметров. Если работаете на потоке с множеством проектов, то можно использовать мой вариант, он более универсален и не требует ручной правки.
Единственное, коэффициенты можно поправить, если будут ложные срабатывания. Но я обычно этот момент решаю через отложенные уведомления. Если чувствительность триггера очень высокая и есть кратковременные ложные срабатывания, меня они не беспокоят из-за 5-ти минутной задержки уведомлений. Зато при разборе инцидентов, эти кратковременные срабатывания помогают оценить ситуацию в целом.
В шаблоне есть несколько графиков. Не буду о них рассказывать, так как последнее время практически не пользуюсь графиками. Вместо этого собираю дашборды. Это более удобно и информативно. Жаль, что дашборды нельзя к шаблонам прикреплять. Очень хлопотно каждый раз вручную их составлять и тратить время. В конце покажу пример дашборда, который я использую для мониторинга web сервера.
На этом настройка мониторинга nginx закончена, можно пользоваться.
Подготовка php-fpm к мониторингу
Переходим к мониторингу php-fpm. Он отдает побольше метрик, не буду описывать их все. Рассмотрю только самые основные. Мы будем наблюдать следующие параметры php-fpm:
| active processes count | Число активных процессов |
| connections per sec | Количество соединений в секунду |
| idle processes count | Количество idle процессов |
| slow requests | Количество медленных запросов |
| length of listen queue | Размер очереди ожидающих подключений |
| max children reached | Сколько раз был достигнут лимит по процессам |
| max length of listen queue | Максимальный размер очереди подключений |
Пару слов о том, зачем это нужно и как пользоваться полученными данными. Этот мониторинг актуален, если у вас динамическое создание процессов в php-fpm. К примеру, если у вас значение max children reached регулярно больше единицы, то вам рекомендуется увеличить лимит на максимальное количество процессов, если позволяют ресурсы сервера. То же самое относится и к параметру length of listen queue. Если он больше нуля, то создается очередь из запросов, которые не успевают обработать сервер. Необходимо увеличить количество процессов, которые смогут обработать ожидающие подключения.
Приступаем к настройке мониторинга php-fpm на web сервере. Установим fcgi:
Теперь подготовим pfp-fpm для сбора статистики. Для этого мы снова воспользуемся nginx. Редактируем его конфиг, добавляя в ту же секцию server, что и на прошлом этапе, следующую конструкцию:
Проверяем, что по указанному адресу мы получаем статистику php-fpm:
И ее же в формате json.
Если у вас примерно то же самое, то все в порядке, php-fpm отдает информацию о своем состоянии.
Мониторинг php-fpm в zabbix
Теперь настраиваем мониторинг php-fpm на сервере zabbix. Действуем по аналогии с мониторингом nginx. Забираем страницу состояния php-fpm на сервер мониторинга и там его парсим в зависимых элементах данных.
С php-fpm будет один нюанс. Нам все-таки придется менять параметры zabbix agent. Настраивать мониторинг php-fpm очень легко, потому что он из коробки умеет отдавать все свои метрики в формате json. Это очень удобно, так как его не надо парсить регулярками. Достаточно только указать JSONpath для получения необходимой метрики.
Нам нужно добавить один UserParameter следующего содержания.
Перезапускаем zabbix-agent и проверяем, что он корректно возвращает необходимые данные.
Если все в порядке, то проверяйте графики, создавайте необходимые дашборды. Я свой покажу в самом конце.
В шаблоне php-fpm настроен только один триггер, который следит за тем, чтобы хотя бы один процесс php-fpm был запущен. Раньше я использовал больше триггеров, но потом решил, что они не очень нужны. Состояние работы сайта лучше оценивать по финальным метрикам, таким как скорость загрузки страниц, доступность сайта и коды ответов. Об этом я подобно написал в статье про мониторинг сайта в zabbix. Если с этими метриками проблемы, нужно идти в мониторинг, смотреть графики и решать, что нужно изменить в конфигурации. Это мое личное мнение, с ним можно поспорить. Для этого есть комментарии, буду рад замечаниям и обсуждениям по существу.
Подготовка apache к мониторингу
Приступим к настройке мониторинга web сервера apache. В данном примере я буду использовать web сервер для сайта на bitrix, работающего в окружении bitrixenv. В целом, тут никаких принципиальных отличий нет от обычного apache, просто представлена готовая конфигурация с обширными настройками.
Bitrixenv автоматически все настроит, если вы через консольное меню включите Monitoring in pool. Запустится роль ansible, которая настроит в том числе apache, установит и запустит nagios и munin. Если они вам не нужны, то просто добавьте приведенный выше кусок конфига в /etc/httpd/bx/custom/z_bx_custom.conf.
После этого проверьте настройки apache и перезапустите его.
Если все настроили правильно, то состояние apache можно посмотреть в консоли.
И на всякий случай проверьте, что zabbix-agent может получать эту же информацию.
Должны увидеть то же самое, только со служебными заголовками в начале. Если у вас все в порядке, то можно двигаться дальше.
Настройка мониторинга apache
Обратите внимание на элемент, который забирает страницу со статусом. Его url я реализовал через макросы:
Вот как выглядят настройки макроса на типичном сайте с bitrixenv.
Так же обращаю внимание на итемы проверки количества рабочих процессов и занимаемой виртуальной памяти. Для проверки процессов указан пользователь bitrix, от которого работают все воркеры. В случае проверки памяти указан пользователь root, так как основной процесс запущен от него. А все воркеры используют разделяемую память. Ее суммарный объем, особенно когда воркеров много, огромен и представляет из себя нереальную цифру. Отслеживать ее нет никакого смысла.
Так как apache обычно работает в роле бэкенда, у него минимум триггеров, как и у php-fpm. Я сделал 2:
Добавил еще пару графиков. Сами на них посмотрите. Вот в общем-то и все. После настройки шаблона для мониторинга apache, прикрепите его к хосту, не забудьте указать макросы и ждите поступления данных.
На это про мониторинг apache в zabbix все. Дальше идет пример готового Dashboard.
Дашборд Zabbix для Web сервера
Как и обещал, в завершении статьи по настройке мониторинга web сервера, показываю пример своего дашборда в zabbix для мониторинга bitrix сайта. Картинка очень большая, по клику открывается полная версия, если открыть в новой вкладке.
Ниже идут метрики с мониторинга web сайта. Выбирается контрольный набор из нескольких страниц (обычно 3-5) и настраивается мониторинг времени ответа и скорости загрузки этих страниц. Для этих параметров настроены триггеры, так как они очень важны. По сути, это ключевые метрики. Если с ними проблемы, надо внимательно смотреть web сервер и разбираться, в чем проблема. Мониторинг web сайта нужно настраивать минимум с двух независимых серверов zabbix, иначе вы не сможете отличить проблемы доступа с сервера мониторинга к сайту от реальных проблем сайта. Только если оба сервера мониторинга сигнализируют о проблемах, можно сделать однозначный вывод о том, что с сайтом и web сервером что-то не так.
Дальше идут метрики из шаблонов, которые я рассмотрел в этой статье. Если у вас вместо apache используется php-fpm, то все примерно то же самое, только в самом низу метрики от php-fpm. Не буду приводить пример с ним, чтобы не загромождать статью. Думаю, приведенного дашборда и так достаточно.
В принципе, сюда можно было бы добавить информацию по I/O дисков, инфу с сетевого стека, данные Mysql. Не стал этого делать, так как это обзорный dashboard, который беглым просмотром позволяет оценить состояние сервера. Так же этот дашборд можно показать заказчику. Для более глубокого анализа проблем, нужно собирать отдельную панель.
Заключение
Подведем итог того, что мы сделали:
То есть выполнили весь комплекс действий для организации полноценного мониторинга web сервера в zabbix.
Время отклика страниц сайта и скорость их загрузки в целом тоже улучшились. Я однозначно понял, что надо переезжать и не ошибся.
Это пример из старой версии статьи, где показаны старые метрики и графики. Оставил его, так как он в целом информативен. Текущий мониторинг web сайта так же можно использовать для анализа производительности хостинга.