Как проверить работу php fpm

This page provides information on the setup and contents of the FPM status page. See also fpm_get_status() .

Configuration

The FPM status page can be enabled by setting the pm.status_path configuration parameter in the FPM pool configuration.

For security the FPM status page should be restricted to internal requests or known client IPs only as the page reveals request URLs and information about available resources.

Depending on the web server configuration it might be needed to configure the web server to allow requests directly to this path, bypassing any PHP scripts. An example of a configuration for Apache with FPM listening on UDS and pm.status_path set to /fpm-status would look like:

After reloading or restarting both FPM and the web server the status page will be accessible from the browser (as long as the request comes from an allowed IP address if the IP restriction was configured).

Query Parameters

The format of the status page output can be altered by specifying one of the following query parameters:

html
json
openmetrics
xml

Additional information can also be returned using the full query parameter.

Example status page URLs:

https://localhost/fpm-status — Brief output in the default text format
https://localhost/fpm-status?full — Full output in the default text format
https://localhost/fpm-status?json — Brief output in JSON format
https://localhost/fpm-status?html&full — Full output in HTML format

Displayed Information

Date/Time values use the unix timestamp format in JSON and XML output, otherwise they use the format resulting in the following example date "03/Jun/2021:07:21:46 +0100" .

Basic information — Always displayed on the status page

Parameter	Description
pool	The name of the FPM process pool.
proccess manager	The process manager type — static, dynamic or ondemand.
start time	The date/time that the process pool was last started.
start since	The time in seconds since the process pool was last started.
accepted conn	The total number of accepted connections.
listen queue	The number of requests (backlog) currently waiting for a free process.
max listen queue	The maximum number of requests seen in the listen queue at any one time.
listen queue len	The maximum allowed size of the listen queue.
idle processes	The number of processes that are currently idle (waiting for requests).
active processes	The number of processes that are currently processing requests.
total processes	The current total number of processes.
max active processes	The maximum number of concurrently active processes.
max children reached	Has the maximum number of processes ever been reached? If so the displayed value is 1 otherwise the value is 0 .
slow requests	The total number of requests that have hit the configured request_slowlog_timeout .

Per-process information — only displayed in full output mode

Parameter	Description
pid	The system PID of the process.
state	The state of the process — Idle, Running, .
start time	The date/time at which the process started.
start since	The number of seconds since the process started.
requests	The total number of requests served.
request duration	The total time in seconds spent serving requests.
request method	The HTTP method of the last served request.
request uri	The URI of the last served request (after webserver processing, it may always be /index.php if you use a front controller pattern redirect).
content length	The length of the request body, in bytes, of the last request.
user	The HTTP user ( PHP_AUTH_USER ) of the last request.
script	The full path of the script executed by the last request. This will be '-' if not applicable (eg. status page requests).
last request cpu	The %cpu of the last request. This will be 0 if the process is not Idle because the calculation is done when the request processing is complete.
last request memory	The maximum amount of memory consumed by the last request. This will be 0 if the process is not Idle because the calculation is done when the request processing is complete.

Note:

All values are specific to the pool and are reset when FPM is restarted.

Note:

OpenMetrics format output uses different parameter types to better suit the OpenMetrics format. The parameters and descriptions of their values are included in the OpenMetrics format output.

Быстро проверить работу FastCGI

В RHEL/CentOS он ставится легко и просто следующей командой:

В Ubuntu название инструмента и синтаксис для установки немного другой:

Проверяем PHP-FPM / HHVM

Проверить работоспособность php-fpm или hhvm очень просто:

При необходимости (если вдруг настройки для пинга изменены через файл конфигурации) можно задавать параметры через переменные окружения:

На выходе получим такой ответ:

Таким образом можно так же проверять страницу статуса или какой-то произвольный URL, хотя для этих целей можно использовать так же wget, curl, telnet…

Getting The PHP-FPM Status From The Command Line

[3:41 PM] Me:

$ curl 127.0.0.1:9000/status
curl: (56) Failure when receiving data from the peer

Is this supposed to work?

I quickly learned that no, it is not supposed to work…

[3:41 PM] Coworker:

no it doesn’t use http

Here I’ll go into details on how you can get the PHP-FPM status from the command line.

The cgi-fcgi executable

In order to communicate with a FastCGI application (like PHP-FPM) you can use the cgi-fcgi executable. It does not come installed by default on most OSes.

Per the article “Directly connecting to PHP-FPM” from www.thatsgeeky.com you can yum install it as follows…

I personally tested the yum install out on a CentOS machine and it worked fine.

Once installed you’ll be able to use the cgi-fcgi binary to talk directly to PHP-FPM.

Ensuring That The Status Page Is Available

By default, PHP-FPM does not make the status page available. You’ll need to ensure that the following is included in your PHP-FPM configuration…

NOTE: You don’t need to use /status for the path and can use another path if you’d prefer.

Communicating With PHP-FPM

At this point you’ll be able to use cgi-fcgi to send requests directly to PHP-FPM. However it’s important to confirm whether or not PHP-FPM is listening on a port or a unix socket.

If listening on a port you’ll see something like this in your PHP-FPM configuration…

On a Unix socket you’ll see this…

If PHP-FPM is listening on a port you can send requests to it with cgi-fcgi as follows…

If it’s listening on a socket simply update the connection name to point to the Unix socket.

When connecting to a Unix socket, you need to ensure the user you’re running the command as has permissions to read the socket file. You may need to sudo …

In order to get the full status, you can pass a query string as follows…

You can also use QUERY_STRING to request an alternate format, such as JSON.

Name already in use

Work fast with our official CLI. Learn more about the CLI.

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

A PHP fpm Health Check script

With the ascension of containerized applications it becomes more and more useful to have a php-fpm healthcheck .

This POSIX compliant sh script gets php-fpm status page using cgi-fcgi tool, parses it’s outcome and allows you to choose a metric which you want to check one, a ping mode is also available which only makes sure php-fpm is answering.

Previously at work we had Docker containers containing both php-fpm and Nginx processes, while they were managed by another process being Supervisord or s6 overlay for instance. One good example is this image from Ric Harvey

It works really well, but I wanted to achieve a few other things like using the official images and its release cycle, logs belonging to their own processes, not mixed, I didn’t like to rely on Supervisord since I had bad experiences in the past with it, and other things related to the «Docker way», I’m not saying it’s perfect but I wanted some of those things.

Now comes the php-fpm healthcheck part, while having in place a healthcheck which requested an url in the application asking if it was alive, it was indirectly testing the whole chain, Nginx -> php-fpm -> application , and now I had the chance to test still the whole chain via nginx but also monitor how busy and stable is php-fpm , if you check its /status page it has quite some useful information, so why not monitor on it? For instance you could make a container unhealthy after a certain amount of requests, or if the queue is too long and even slow requests, and that’s what this script tries to achieve!

Good news is that you can still do it even using the mixed container approach, but I wanted to take a time to explain why I came to do it like this now! The advantage in my opinion is that having separate containers you have a better grasp on where the problem is laying and you can restart only what’s failing, not the whole, also avoiding Supervisord to restart it for you since you are already behind a container orchestration tool.

Enable php-fpm status page

On you php-fpm pool configuration add: pm.status_path = /status

For instance on the official php image you can alter the file /usr/local/etc/php-fpm.d/zz-docker.conf

The script is POSIX sh but also uses some tools from your operating system, being:

cgi-fcgi
sed
tail
grep

In case you’re using alpine you only need to make sure you have installed busybox and fcgi packages.

Как проверить работу php fpm