How to Enable and Monitor PHP-FPM Status in Nginx?
PHP-FPM (FastCGI Process Manager) is a popular implementation of PHP as a FastCGI process manager. It offers significant performance improvements over the traditional PHP implementation and is widely used in high-traffic websites. Nginx is a popular web server and reverse proxy that can be used to serve PHP applications via PHP-FPM. In this article, we will discuss how to enable and monitor PHP-FPM status in Nginx.
Enabling PHP-FPM Status Page
PHP-FPM comes with a built-in status page that provides real-time information about the current state of PHP-FPM processes. Enabling the PHP-FPM status page in Nginx is a simple process.
First, open the PHP-FPM configuration file using your favorite text editor. The location of this file may vary depending on your system configuration. For example, on Ubuntu, the file is located at /etc/php/7.4/fpm/pool.d/www.conf.
Next, uncomment the following lines −
pm.status_path = /status ping.path = /ping
These lines enable the status and ping pages. Save the changes and restart PHP-FPM service −
sudo service php7.4-fpm restart
Next, edit the Nginx configuration file for your PHP application. Add the following location block to the server block −
This location block allows access to the status and ping pages only from localhost. You can change the IP address to allow access from a different IP address.
Save the changes and reload the Nginx configuration −
sudo service nginx reload
You can now access the PHP-FPM status page by visiting http://your-domain.com/status and the ping page by visiting http://your-domain.com/ping. If everything is configured correctly, you should see a page with real-time information about the PHP-FPM processes.
Monitoring PHP-FPM Status
Monitoring the PHP-FPM status page is an essential part of maintaining a healthy PHP application. It allows you to detect and diagnose issues with PHP-FPM processes.
One way to monitor the PHP-FPM status page is to use a tool like curl. For example, to get the status information, you can run the following command −
curl http://your-domain.com/status
This command will output the status information in your terminal.
Another way to monitor the PHP-FPM status page is to use a monitoring tool like Nagios, Zabbix, or Prometheus. These tools allow you to set up alerts and notifications based on the status of PHP-FPM processes.
In addition to using tools like curl and Nagios to monitor the PHP-FPM status page, there are also several web-based monitoring tools available. One popular tool is the PHP-FPM Status Page Script, which is a web-based script that provides a detailed overview of the PHP-FPM processes. This script can be easily installed on your server and configured to provide real-time monitoring of PHP-FPM processes.
Another option is to use the built-in monitoring features of PHP-FPM. PHP-FPM comes with several built-in monitoring tools, including the pm.status_path and ping.path directives that we enabled earlier. These tools provide detailed information about the status of PHP-FPM processes, including the number of active processes, the number of idle processes, and the total number of requests processed.
You can also use the pm.status_listen directive to enable a TCP/IP socket for PHP-FPM status monitoring. This allows you to use tools like telnet to connect to the socket and view the status information in real-time.
It’s important to note that while monitoring the PHP-FPM status page is essential for maintaining a healthy PHP application, it’s also important to monitor other metrics like CPU and memory usage. These metrics can help you identify performance bottlenecks and optimize your PHP-FPM configuration for better performance.
Another way to monitor PHP-FPM status is to use third-party monitoring services like New Relic or Datadog. These services can provide detailed insights into the performance of your PHP application, including metrics related to PHP-FPM processes.
New Relic, for example, provides real-time performance monitoring and diagnostics for PHP applications. It can be configured to monitor PHP-FPM processes and provide insights into CPU and memory usage, as well as other important metrics. It can also send alerts and notifications when performance thresholds are exceeded, helping you proactively identify and resolve performance issues.
Datadog is another popular monitoring service that can be used to monitor PHP-FPM processes. It provides real-time visibility into the performance of your PHP application, including detailed metrics related to PHP-FPM processes. It can also be configured to send alerts and notifications when performance thresholds are exceeded.
In addition to monitoring PHP-FPM status, it’s also important to optimize PHP-FPM configuration for better performance. One important configuration parameter is the pm.max_children directive, which determines the maximum number of PHP-FPM child processes that can be spawned to handle incoming requests. Setting this value too high can lead to resource exhaustion, while setting it too low can result in poor performance due to long queue times.
Another important configuration parameter is the pm.max_requests directive, which determines the maximum number of requests that each PHP-FPM child process can handle before being recycled. Setting this value too high can lead to memory leaks and instability, while setting it too low can result in unnecessary process recycling and overhead.
It’s also important to consider the resources available on your server when configuring PHP-FPM. For example, if you have limited memory available, you may need to lower the value of pm.max_children to prevent resource exhaustion. Similarly, if you have limited CPU resources, you may need to adjust the pm.process_idle_timeout directive to prevent idle processes from consuming valuable CPU cycles.
Finally, it’s important to note that enabling PHP-FPM status can also have security implications. The status page can provide valuable information to attackers, including the number of active processes and the total number of requests processed. It’s important to ensure that the status page is only accessible from trusted IP addresses and that access is properly secured using authentication and authorization.
Another important aspect of monitoring and optimizing PHP-FPM is to analyze PHP error logs. PHP error logs can provide valuable insights into potential issues and errors that may be impacting the performance and stability of your PHP application. By analyzing these logs, you can identify and diagnose issues related to PHP-FPM processes, such as memory leaks, segmentation faults, and other errors.
You can configure PHP error logging by setting the error_log directive in your PHP configuration file. By default, PHP logs errors to the system error log, but you can configure it to log errors to a specific file or location for easier analysis and monitoring.
In addition to error logs, it’s also important to monitor other system and application logs for potential issues that may be impacting PHP-FPM processes. For example, you may need to monitor Nginx access logs and error logs to identify potential issues related to requests and responses.
Another way to optimize PHP-FPM performance is to use opcode caching. Opcode caching can significantly improve PHP performance by caching compiled PHP code and reducing the overhead of compiling code on each request. Popular opcode caching solutions include APCu, OpCache, and XCache.
Conclusion
Enabling and monitoring the PHP-FPM status page in Nginx is a simple and effective way to maintain a healthy PHP application. By following the steps outlined in this article, you can easily enable the PHP-FPM status page and monitor it using your preferred tools.
Php fpm status html
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:
Order Allow,Deny Allow from 127.0.0.1 ProxyPass "unix:/var/run/php-fpm.sock|fcgi://localhost/fpm-status"
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:
Additional information can also be returned using the full query parameter.
- 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» .
| 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 . |
| 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.