PHP-FPM: Health Monitoring Status Page

Recently on our hosted site, some of our end users were receiving 502-Bad Gateway Errors sporadically. In researching the problem, we recognized that one of several web servers (being load-balanced across multiple servers) was constantly throwing 502-Bad Gateway errors back to the client. We discovered the NGINX process was running successfully, however the PHP-FPM process was hosed up and any php requests to that server was returning 502s.

To prevent this from occurring again, we’re updating our health monitoring (the load balancer monitors each server for availability) to test a PHP page instead of static content. This ensures both NGINX and PHP-FPM are up and responding to the clients, thus preventing the clients seeing 502 Bad Gateway errors thrown from NGINX.

PHP-FPM comes with it’s own health monitoring page that can be enabled through the configuration settings. By uncommenting (or adding) the pm.status_path setting in the etc/php-fpm.d/www.conf configuration file, and restarting the PHP-FPM process you should be able to invoke the page from a browser (ex:

Screen Shot 2015-05-21 at 1.17.17 PM

You can lock down the page from the public by only allowing requests from certain IP Addresses as shown below:

    location ~ ^/status$ {
        access_log on;
        allow 172.16.x.x;
        deny all;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root${fastcgi_script_name};

In the NGINX configuration above, we’re allowing only IP addresses and 172.16.x.x (in our case an internal IP address) access to the /status page. The request is being forwarded to the PHP-FPM backend process and that process returns results similar to the following:

pool:                 www
process manager:      static
start time:           21/May/2015:11:05:10 -0400
start since:          10956
accepted conn:        455
listen queue:         0
max listen queue:     0
listen queue len:     0
idle processes:       49
active processes:     1
total processes:      50
max active processes: 3
max children reached: 0
slow requests:        0

Magento – 403 Forbidden on Post to app/etc/local.xml

Found several instances in the NGINX error log where an HTTP Post was being made to app/etc/local.xml.

Screen Shot 2015-05-20 at 5.06.46 PM

Turns out this is a feature!  Magento performs a sanity check by attempting a POST to this file regularly.  If the POST succeeds, the Administrator is notified on the backend.

This caught my eye when I noticed it in the log file, so I wanted to remind myself should I forget (which I often do).