Страницы 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-statusphp-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. При переносе на новую машину без простоя пригодится пошаговая инструкция: перенос сайта без простоя.
Полезные настройки пула для метрик и стабильности
Проверьте параметры:
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 для наблюдения за метриками производительности. Настройте их однажды, сделайте доступ безопасным, подключите к мониторингу и держите под рукой интерпретацию ключевых показателей. Это минимальные усилия, которые часто экономят часы поиска проблем под нагрузкой.
