Watching nginx upstreams with collectd

Jeff Waugh — Wed, 22 Jul 2009 11:22:12 +0000

Already happy with nginx in front of Apache for a number of sites, I decided it was time to start testing nginx/fastcgi on my personal server (the serial crash test dummy of my web operations). The only problem: I have yet to find a sensible method of grabbing useful runtime information from the PHP fastcgi process itself, and if you can’t sensibly watch it, you can’t sensibly deploy it.

So for now, instead of watching the PHP fastcgi process directly, I’m tracking its performance and usage from nginx’s perspective. You can log all kinds of data about upstream performance with nginx:

log_format upstream '$remote_addr - - [$time_local] "$request" $status '
    'upstream $upstream_response_time request $request_time '
    '[for $host via $upstream_addr]';

Then we log to a central upstream.log file from every location block which includes a fastcgi_pass parameter. For example:

location ~ \.php$ {
    include  fastcgi_params;
    access_log  /var/log/nginx/upstream.log  upstream;
    fastcgi_pass  fcgi_php;
    fastcgi_param  SCRIPT_FILENAME  $wordpress_root$fastcgi_script_name;
}

Now we know how many requests the PHP fastcgi process is handling, and how quickly it’s doing so. collectd‘s tail plugin can watch this log file…


  
  Instance "nginx"
    
      Regex ".*"
      DSType "CounterInc"
      Type counter
      Instance "requests"
    
    
      Regex " upstream ([0-9.]*) "
      DSType GaugeAverage
      Type delay
      Instance "upstream"

… and turn it into something readable. First, the number of requests per second (which I only started watching at 14:30 this afternoon), then the delay for each request:

(Relatively boring statistics here, as it’s only monitoring the dynamic processing of my personal sites.)

Combining nginx’s flexible logging and collectd’s tail plugin makes it pretty easy to watch the usage and performance of whatever you’re running behind nginx, even if you can’t instrument the application itself.

… and thus far, I’m pretty happy with the performance, reliability and resource usage of nginx in front of PHP in fastcgi mode.

PHP5 vs. daylight saving in Ubuntu 8.04.1 LTS

Jeff Waugh — Wed, 08 Oct 2008 05:35:53 +0000

Much of Australia went into DST mode this week, with the only holdouts being the odd little backwaters of our country (generally referred to as “Queensland”) for whom daylight saving is a threat to curtains or farm animals… and anyone relying on PHP5′s bundled timezone database.

I filed a bug and test case regarding the problem (which will hopefully be be fixed with an official update, given that Hardy is an LTS release), but here’s a quick guide to work around the problem in the mean time. Thanks to Andrew “ajmitch” Mitchell for pointing me in the right direction!

Grab and unpack the timezonedb extension tarball from PECL.
apt-get install php5-dev
phpize
./configure --with-php-config=/usr/bin/php-config5
make
sudo cp modules/timezonedb.so /usr/lib/php5/20060613/
Note: The precise name of the final directory might be different. For instance, on hardy-i386 it will be 20060613+lfs.
sudo vi /etc/php/conf.d/timezonedb.iniYes, this is a new file. Content: extension=timezonedb.so
sudo /etc/init.d/apache2 force-reload

Now your PHP has the very latest timezone data up its sleeve, so you can rest easy knowing that your web visitors won’t think you’re a Queenslander.

Zing!

Update: The php5-timezonedb extension was added to Debian, but removed from intrepid… seems it was because intrepid’s php5 has a patch to use the system tzdata. It would be awesome to get that patch into hardy!

Update: Uh, what about make…?

Be the signal » PHP

Watching nginx upstreams with collectd

PHP5 vs. daylight saving in Ubuntu 8.04.1 LTS