Ready to know about downtime before your customers?
Status List delivers uptime monitoring and professional hosted status pages for sites of all shapes and sizes.
Trusted by 1000+ companies
Contents
PHP-FPM Status Page Setup Guide
The PHP-FPM process manager influences the performance of your web application. It’s critical that you setup and monitor your PHP-FPM status page. If PHP-FPM isn’t working at it’s best, your site will lag and customers will leave.
So how do we setup the PHP-FPM status page? It’s pretty straight forward actually. We’re going to update our www pool, web server and we’re off to the races. Ready?
1. Update PHP-FPM Config
Locate the configuration file for your www pool. Usually it’s located at /etc/php-fpm.d/www.conf.
Enable the pm.status_path parameter by setting it to /php-fpm/status.
pm.status_path=/php-fpm/status
Valid PHP-FPM Config
Before we restart the service, let’s check that our edits were formatted correctly. The command below should give an “ok” output. If there are any errors, please fix them before proceeding.
php-fpm -t
2. Update Web Server
NGINX
Locate the configuration file for your website. It’s usually at /etc/nginx/nginx.conf. Add the following location block to your default server section.
location /php-fpm/status {
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
fastcgi_index /php-fpm/status;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
include fastcgi_params;
}
Validate your changes with the following command
nginx -t
Proceed to heading #3 below before restarting.
Apache
Locate the configuration file for your website. It’s usually in the /etc/httpd/ directory. Add the following location block.
<LocationMatch "/php-fpm/status">
ProxyPass "unix:/var/run/php-fpm.sock|fcgi://127.0.0.1/php-fpm/status"
</LocationMatch>
Validate your changes with the following command
httpd -t
Proceed to heading #3 below before restarting.
3. Securing the Status Page
The PHP-FPM status page contains some sensitive information like script names and PIDs. We only want internal users and metrics collectors to have access. It’s a serious vulnerability to have this unrestricted. Please restrict your status page IPs!
Please follow the appropriate guide below for your web server.
NGINX
location /php-fpm/status {
allow 127.0.0.1; # restrict to localhost
allow 10.0.0.0/8; # restrict to internal ips
deny all; # don't allow anyone else
# ... your standard fastcgi params
}
Validate your changes and restart the service with the following commands.
nginx -t
nginx -s reload
Apache
<LocationMatch "/php-fpm/status">
Order Allow,Deny
Allow from 127.0.0.1 10.0.0.0/8
# ... your standard fastcgi params
</LocationMatch>
Validate your changes and restart the service with the following commands.
httpd -t
service httpd restart
4. View Status Output
Open http://127.0.0.1/php-fpm/status?full to view PHP-FPM’s complete status page. You can also get a condensed page at http://127.0.0.1/php-fpm/status, or in json format at http://127.0.0.1/php-fpm/status?json.
The status page shows manager level statistics and per-process stats. Depending on what you’re trying to debug, different sections may be helpful.
Here’s what my status page looks like:
pool: www
process manager: dynamic
start time: 17/Apr/2023:16:31:51 +0000
start since: 203
accepted conn: 16
listen queue: 0
max listen queue: 0
listen queue len: 0
idle processes: 5
active processes: 1
total processes: 6
max active processes: 2
max children reached: 0
slow requests: 0
************************
pid: 12493
state: Idle
start time: 17/Apr/2023:16:31:51 +0000
start since: 203
requests: 3
request duration: 148003
request method: POST
request URI: /wp-cron.php?doing_wp_cron=0000000.0000000000000000
content length: 0
user: -
script: /opt/marketing/wordpress/wp-cron.php
last request cpu: 67.57
last request memory: 6291456
************************
pid: 12494
state: Idle
start time: 17/Apr/2023:16:31:51 +0000
start since: 203
requests: 3
request duration: 219
request method: GET
request URI: /status2?all
content length: 0
user: -
script: /opt/marketing/wordpress/status2
last request cpu: 0.00
last request memory: 2097152
(repeating for each PID)
Status Page Output Definitions
Here is an explanation of the metrics shown on the status page. Most are self explanatory, but here’s the nitty gritty details.
Pool Details
- pool: The name of the pool (usually www)
- process manager: The type of process manager used for this pool (see your php-fpm/www.conf)
- start time: The timestamp when the pool was started
- start since: The number of seconds that the pool has been active
- accepted conn: The number of connections the pool has accepted
- listen queue: The number of requests that are currently waiting for a free process
- max listen queue: The max number of requests in the listen queue since the pool was started
- listen queue len: The max number of requests that will be queued before requests will be rejected
- idle processes: The number of processes that are alive, but not processing anything
- active processes: The number of processes that are currently processing a request
- total processes: The total number of processes in the pool
- max active processes: The max number of processes that the pool will spin up to service the request load
- max children reached: A boolean (0 or 1) that shows 1 if the max active processes has been reached
- slow requests: A counter of requests that took >= request_slowlog_timeout (see php-fpm/www.conf)
Process Details
- pid: The system pid for that process. This can be useful for tracing or killing a specific process.
- state: Wether the process is idle or running
- start time: The timestamp when the process was started
- start since: The number of seconds that the process has been active
- requests: The total number of requests served
- request duration: The time (in seconds) that has been spent processing the last request. If you have a large value here, you may want to check your server load or optimize your code.
- request method: The HTTP method of the last request processed
- request uri: The URI of the last request processed (The URI passed to php-fpm. This may not match the user requested URI because of your nginx or apache configuration)
- content length: The body length of the last request processed
- user: The PHP_AUTH_USER of the last request processed
- script: The absolute path of the script executed by the last request. This is very useful when tracking down what script is actually running.
- last request cpu: The % of cpu required to process the last request. This only has a value if the process state is idle. Large values here may point to slow/bloated website code.
- last request memory: The max amount of memory that the last request used. Large values here may point to too many objects or unnecessary data loading.
Monitoring Integrations
Ready to know about downtime before your customers?
Status List delivers uptime monitoring and professional hosted status pages for sites of all shapes and sizes.
Trusted by 1000+ companies
Integrations allow you to track metrics from the PHP-FPM status page and create warning alerts. If you have a status page that you don’t look at, it’s not that useful. But, piping the data into a 3rd party can make it very useful for you and your team.
Here are some guides on how to integrate your PHP-FPM status page into specific providers.
ElasticSearch Integration
Send your php-fpm status details to your ElasticSearch instance. Update your collector’s config and your data will start appearing in your Elastic queries.
- module: openmetrics
metricsets: ['collector']
period: 10s
hosts: ["127.0.0.1:80"]
metrics_path: /php-fpm/status
You can get more details in the Elastic Openmetrics Documentation.
DataDog Integration
You can send your php-fpm status details to your DataDog dashboard. Update your agent’s config and your data will start flowing.
Edit the openmetrics.d/conf.yaml in you DataDog configuration directory.
instances:
- openmetrics_endpoint: http://127.0.0.1/php-fpm/status
namespace: php-fpm
metrics:
- .+:
type: gauge
Restart the agent
service datadog-agent start
Your data should start appearing in your dashboard within a few minutes.
Read more in the Datadog Openmentrics Documentation
Common Status Properties to Watch
Your PHP-FPM status page has some valuable insights on the performance of your application. Here are a few key insights we’ve used to improve our performance.
- Check your slow requests counter. If you start seeing >= 5 requests per day, you may need to check your app code. You can dig into your http log (e.g. /var/log/nginx/access.log) to narrow down exactly which request is causing the problem.
- Check your max listen queue counter. You want to see seeing numbers lower than the number of processes in your pool. Anything over that and you’re going to start seeing very overall slow response time and a laggy site.
- Check specific process last request memory. It’s normal for requests to use a chunk of memory. But a request that uses more than a few MB probably needs some attention. Often large requests can be moved to background jobs or refactored in the application.
If you watch these properties, you’ll be able to narrow down most performance issues. Your site will be snappier and your customers will be happier.
See Also
We hope you enjoy your new PHP-FPM status page. If you would like to do some more reading, you may want to check out
the fpm_get_status() php function.