php-fpm status и ping: включаем, мониторим и ищем узкие места

Страницы status и ping в php-fpm — это лёгкие и полезные точки для контроля здоровья пула и диагностики производительности. ping отвечает простым «жив/не жив», а status выдаёт метрики пула и процессов: от очереди соединений до числа медленных запросов. Ниже — пошагово: как включить, безопасно опубликовать за Nginx, что означают метрики, как их собирать и использовать для поиска узких мест.

Что такое php-fpm ping и status, и когда они нужны

ping — «живой» эндпоинт пула. Возвращает статический ответ (по умолчанию «pong») и годится для healthcheck в балансировщике и простых проверок мониторинга. Если php-fpm подвиснет, ping перестанет отвечать.

status — диагностический эндпоинт, который выдаёт агрегированные (и при желании детализацию по процессам) метрики: размер очереди, количество активных и свободных воркеров, сколько раз достигался лимит детей, сколько медленных запросов и т.д. Эти показатели позволяют понять, «во что упираемся» — CPU, лимиты пула, базу данных или медленные скрипты.

Идеальная связка: балансировщик/обратный прокси опрашивает ping для быстрого healthcheck, а система мониторинга периодически забирает метрики со status в JSON.

Включаем status и ping в пуле php-fpm

Открываем конфиг пула (пример для PHP 8.2, путь может отличаться):

sudo nano /etc/php/8.2/fpm/pool.d/www.conf

Добавляем/раскомментируем параметры:

pm.status_path = /fpm-status
ping.path = /fpm-ping
ping.response = pong

Перезапускаем или мягко перечитываем конфиг:

sudo systemctl reload php8.2-fpm

Аналогично для других версий (php7.4-fpm, php8.3-fpm) — меняйте путь сервиса.

Публикуем и защищаем через Nginx

Лучше публиковать /fpm-status и /fpm-ping только локально или под строгим ACL. Пример локаций с доступом лишь с 127.0.0.1 и сервера мониторинга:

location = /fpm-ping {
    allow 127.0.0.1;
    allow 10.0.0.10;
    deny all;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

location = /fpm-status {
    allow 127.0.0.1;
    allow 10.0.0.10;
    deny all;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

Если используется TCP-сокет, укажите fastcgi_pass 127.0.0.1:9000;. Важно: не оставляйте статус и пинг открытыми в интернет — это риск лишней информации для сторонних.

Публикуйте пути статуса/пинга вне общего PHP-маршрута, чтобы CMS/фреймворк не перехватывал запросы. Используйте точные локации =.

Проверяем доступность

Проверка «живости»:

curl -sS -D - http://127.0.0.1/fpm-ping

Ожидаем 200 OK и тело pong (если меняли ping.response — вернётся ваше значение).

Получаем метрики в текстовом виде:

curl -sS http://127.0.0.1/fpm-status

php-fpm умеет отдавать JSON и детализацию по процессам:

curl -sS "http://127.0.0.1/fpm-status?json"
curl -sS "http://127.0.0.1/fpm-status?json&full"

Что означают ключевые метрики php-fpm

Базовые поля:

• pool — имя пула.
• process manager — режим pm (static, dynamic, ondemand).
• start time, start since — когда запустился пул и сколько секунд работает.
• accepted conn — сколько входящих подключений обработано с запуска.
• listen queue — текущая очередь на сокете. Ненулевая — признак нехватки воркеров или зависаний.
• listen queue len — максимальный размер очереди (backlog сокета).
• idle processes, active processes, total processes — занятость пула.
• max active processes — пик одновременной активности.
• max children reached — сколько раз достигался лимит pm.max_children.
• slow requests — число запросов, превысивших request_slowlog_timeout.

В режиме full видны процессы с полями state (Idle, Running, Reading, Finishing), длительностью выполнения, скриптом и т.п. Это удобно для pinpoint-диагностики «кто сейчас тормозит».

Быстрый мониторинг через curl/jq

Пара команд, которые помогают понять динамику на лету:

# Текущая очередь
curl -sS "http://127.0.0.1/fpm-status?json" | jq '."listen queue"'

# Суммарно обработано соединений
curl -sS "http://127.0.0.1/fpm-status?json" | jq '."accepted conn"'

# Одновременная активность
curl -sS "http://127.0.0.1/fpm-status?json" | jq '."active processes"'

# Пики и лимиты
curl -sS "http://127.0.0.1/fpm-status?json" | jq '."max active processes", ."max children reached"'

Измерим «скорость» обработанных соединений за интервал:

c1=$(curl -sS "http://127.0.0.1/fpm-status?json" | jq -r '."accepted conn"')
sleep 10
c2=$(curl -sS "http://127.0.0.1/fpm-status?json" | jq -r '."accepted conn"')
echo $(( (c2 - c1) / 10 ))

Если при пиках listen queue вырастает, а active processes около pm.max_children и растёт max children reached — пул упирается в лимиты. Если же дети свободны, но slow requests увеличивается — ищем медленные скрипты/базу/внешние запросы.

Интерпретируем метрики: типовые узкие места

Очередь на сокете

Симптом: listen queue > 0 под нагрузкой, а active processes близок к pm.max_children. Значит, воркеров мало. Решения:

• Увеличить pm.max_children (учитывая RAM и лимиты pm.* при dynamic).
• Разбить сайты по пулам, чтобы «прожорливый» проект не выедал воркеров у остальных.
• Оптимизировать код/кэширование, уменьшить время обработки.

Длительные запросы

Симптом: растёт slow requests, активных процессов много, CPU невысок. Часто это внешние ожидания (БД, API, файловые операции). Действия:

• Включить slowlog и профилирование проблемных точек.
• Кэшировать повторные вычисления/запросы.
• Вынести тяжёлые операции в очереди/воркеры.

Пики RPS и исчерпание лимитов

Симптом: max children reached > 0, а на фронте 502/504. Подтяните pm.max_children, при dynamic — разумно расширьте pm.max_spare_servers, pm.max_requests, проверьте listen.backlog. Не забывайте, что каждый воркер — это память, плюс добавьте CPU-запас. Если проект стабильно упирается в лимиты на одном сервере — подумайте о выделенных ресурсах на VDS. При переносе на новую машину без простоя пригодится пошаговая инструкция: перенос сайта без простоя.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Полезные настройки пула для метрик и стабильности

Проверьте параметры:

• pm — dynamic даёт баланс между простоями и пиками, static — максимум предсказуемости, ondemand — экономия RAM при редких запросах.
• pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers — базовые лимиты.
• pm.max_requests — перезапуск воркеров после N запросов, помогает бороться с утечками.
• request_terminate_timeout — принудительный таймаут запроса.
• request_slowlog_timeout и slowlog — включение медленного лога для триажа.

Сбор метрик в системы мониторинга

Даже без промышленных экспортёров можно быстро собрать базу метрик из JSON-статуса в cron или через таймер:

#!/usr/bin/env bash
set -euo pipefail
URL="http://127.0.0.1/fpm-status?json"
TS=$(date +%s)
JSON=$(curl -sS "$URL")
q=$(echo "$JSON" | jq -r '."listen queue"')
ac=$(echo "$JSON" | jq -r '."accepted conn"')
ap=$(echo "$JSON" | jq -r '."active processes"')
ic=$(echo "$JSON" | jq -r '."idle processes"')
mc=$(echo "$JSON" | jq -r '."max children reached"')
sr=$(echo "$JSON" | jq -r '."slow requests"')
printf "phpfpm_listen_queue %s %s\n" "$q" "$TS"
printf "phpfpm_accepted_conn %s %s\n" "$ac" "$TS"
printf "phpfpm_active_processes %s %s\n" "$ap" "$TS"
printf "phpfpm_idle_processes %s %s\n" "$ic" "$TS"
printf "phpfpm_max_children_reached %s %s\n" "$mc" "$TS"
printf "phpfpm_slow_requests %s %s\n" "$sr" "$TS"

Так можно писать во временный файл и собирать далее агентом. Главное — снимать метрики часто (10–30 секунд) и строить алерты: очередь > 0 N секунд подряд, рост max children reached, аномальный всплеск slow requests.

Несколько пулов и раздельные статус/пинг

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

[site1]
user = site1
listen = /run/php/php8.2-fpm-site1.sock
pm = dynamic
pm.max_children = 20
pm.status_path = /site1-fpm-status
ping.path = /site1-fpm-ping

[site2]
user = site2
listen = /run/php/php8.2-fpm-site2.sock
pm = dynamic
pm.max_children = 10
pm.status_path = /site2-fpm-status
ping.path = /site2-fpm-ping

В Nginx — отдельные локации под каждый пул с нужным fastcgi_pass. Так вы быстро увидите, какой сайт стал «прожорливым».

Безопасность: не светите служебные эндпоинты

Базовые принципы безопасности:

• Давайте доступ к /fpm-status и /fpm-ping только с внутренней сети или 127.0.0.1.
• Используйте точные локации и deny для остальных.
• Не проксируйте эти пути через публичные CDN/кеши.
• Периодически просматривайте логи на предмет сканирования.

Типовые ошибки и их исправление

• 403/404 на статус/пинг. Проверьте точные локации = и что pm.status_path и ping.path совпадают с Nginx. Убедитесь, что fastcgi_pass указывает на верный сокет/порт пула.
• Публичный доступ к статусу. Добавьте allow/deny. Проверяйте с внешнего IP: статус должен быть недоступен.
• Очередь есть, но CPU свободен. Часто проблема в медленных внешних ресурсах (БД, API). Смотрите slowlog, профилируйте проблемные точки.
• Рост памяти. Увеличьте pm.max_requests, чтобы воркеры перезапускались и освобождали память, разберитесь с утечками в коде/расширениях.

В связке с Nginx: healthcheck и таймауты

Простой внешний healthcheck — HTTP-запрос к /fpm-ping через фронт. На уровне Nginx настроены таймауты fastcgi_connect_timeout, fastcgi_send_timeout, fastcgi_read_timeout. Если listen queue растёт, эти таймауты начнут «стрелять». Снижайте задержки в приложении и увеличивайте пропускную способность пула.

Стресс-тест и верификация ёмкости

Перед релизом удобен быстрый нагрузочный прогон и наблюдение за status:

watch -n 1 "curl -sS http://127.0.0.1/fpm-status?json | jq -r '[."active processes", ."idle processes", ."listen queue", ."max children reached"] | @tsv'"

На устойчивой конфигурации очередь должна оставаться нулевой или малой, а доля активных процессов — не всегда у потолка. Если достигли лимита детей и очередь растёт — повышайте лимиты или оптимизируйте приложение/кэш.

Мини-чеклист по php-fpm status/ping

• Включены pm.status_path и ping.path, заданы разумные пути.
• Эндпоинты защищены: allow/deny, только локальная сеть.
• Метрики снимаются регулярно, есть алерты по очереди и лимитам детей.
• При пиках анализируется slowlog.
• Пулы разделены по приложениям/сайтам для изоляции.

Итог

php-fpm предоставляет два простых и крайне полезных инструмента: ping для проверки «живости» и status для наблюдения за метриками производительности. Настройте их однажды, сделайте доступ безопасным, подключите к мониторингу и держите под рукой интерпретацию ключевых показателей. Это минимальные усилия, которые часто экономят часы поиска проблем под нагрузкой.