operations

Two Munin Graphs for Monitoring Our Code

Posted by Mike Brittain on December 17, 2009
PHP, WWW / Comments Off on Two Munin Graphs for Monitoring Our Code

We’re using a few custom Munin graphs at CafeMom to monitor our application code running on production servers.  I posted two samples of these to the WebOps Visualization group at Flickr.  The first graph measures the “uptime” of our code, a measure of how many minutes it’s been since our last deployment to prod (with a max of 1 day).  The second graph provides a picture of what’s going on in our PHP error logs, highlighting spikes in notices, warnings, and fatals, as well as DB-related errors that we throw of our own.

When used together, these graphs give us quick feedback on what sort of errors are occurring on our site and whether they are likely to be related to a recent code promotion, or are the effect of some other condition (bad hardware, third-party APIs failing, SEM gone awry, etc.).

I figured someone might find these useful, so I’m posting the code for both Munin plugins.

Code Uptime

When we deploy code to our servers, we add a timestamp file that is used to manage versioning of deployments to make things like rolling back super easy.  It’s also handy for measuring how long it’s been since the last deployment.  All this plugin does is reads how long ago that file was modified.

We run multiple applications on the same clusters of servers. I wrote our code deployment process in a manner that allows for independent deployment of each application. For example, one team working on our Facebook apps can safely deploy code without interfering with the deployment schedule another team is using for new features that will be released on the CafeMom web site.

Each of these applications is deployed to a separate directory under a root, let’s say “/var/www.”  This explains why the plugin is reading a list of files (directories) under APPS_ROOT.  Each app has it’s own reported uptime on the Munin graph.

#!/bin/sh
#
# Munin plugin to monitor the relative uptime of each app
# running on the server.
#

APPS_ROOT="/var/www/"

# Cap the uptime at one day so as to maintain readable scale
MAX_MIN=1440

# Configure list of apps
if [ "$1" = "config" ]; then
 echo 'graph_title Application uptimes'
 echo "graph_args --base 1000 --lower-limit 0 --upper-limit $MAX_MIN"
 echo 'graph_scale no'
 echo 'graph_category Applications'
 echo 'graph_info Monitors when each app was last deployed to the server.'
 echo 'graph_vlabel Minutes since last code push (max 1 day)'

 for file in `ls $APPS_ROOT`; do
 echo "$file.label $file"
 done
 exit 0
fi

# Fetch release times
now_sec=`date +%s`

for file in `ls $APPS_ROOT`; do
 release_sec=`date +%s  -r $APPS_ROOT/$file/prod/release_timestamp`
 diff_sec=$(( $now_sec - $release_sec ))
 diff_min=$(( $diff_sec/60 ))
 ((diff_min>MAX_MIN?diff_min=MAX_MIN:diff_min))
 echo "$file.value $diff_min"
done

Error Logs

The second plugin uses grep to search for occurrences of specific error-related strings in our log files. In our case, the graph period was set to “minute” because that gives the best scale for us (thankfully, it’s not in errors per second!).

If you’re wondering about using grep five times against large error files every time Munin runs (every five minutes), I want to point out that we rotate our logs frequently which ensures that these calls are manageable. If you run this against very large error logs you may find gaps in your Munin graphs if the poller times out waiting for the plugin to return data points.

Even if you don’t care about PHP logs, you may find this to be a simple example of using Munin to examine any sort of log files that your application is creating.

#!/bin/bash

#
# Collect stats for the contents of PHP error logs. Measures notice,
# warning, fatal, and parse level errors, as well as custom errors
# thrown from our DB connection class.
#

logs="/var/log/httpd/*.error.log"

# CONFIG

if [ "$#" -eq "1" ] && [ "$1" = "config" ]; then
	echo "graph_title Error Logs"
	echo "graph_category applications"
	echo "graph_info Data is pooled from all PHP error logs."
	echo "graph_vlabel entries per minute"
	echo "graph_period minute"
	echo "notice.label PHP Notice"
	echo "notice.type DERIVE"
	echo "notice.min 0"
	echo "notice.draw AREA"
	echo "warning.label PHP Warning"
	echo "warning.type DERIVE"
	echo "warning.min 0"
	echo "warning.draw STACK"
	echo "fatal.label PHP Fatal"
	echo "fatal.type DERIVE"
	echo "fatal.min 0"
	echo "fatal.draw STACK"
	echo "parse.label PHP Parse"
	echo "parse.type DERIVE"
	echo "parse.min 0"
	echo "parse.draw STACK"
	echo "db.label DB Error"
	echo "db.type DERIVE"
	echo "db.min 0"
	echo "db.draw STACK"
	exit
fi

# DATA

# The perl code at the end of each line takes a list of integers (counts) from grep (one per line)
# and outputs the sum.

echo "notice.value `grep --count \"PHP Notice\" $logs | cut -d':' -f2 | perl -lne ' $x += $_; END { print $x; } ' `"
echo "warning.value `grep --count \"PHP Warning\" $logs | cut -d':' -f2 | perl -lne ' $x += $_; END { print $x; } ' `"
echo "fatal.value `grep --count \"PHP Fatal error\" $logs | cut -d':' -f2 | perl -lne ' $x += $_; END { print $x; } ' `"
echo "parse.value `grep --count \"PHP Parse error\" $logs | cut -d':' -f2 | perl -lne ' $x += $_; END { print $x; } ' `"
echo "db.value `grep --count \"DB Error\" $logs | cut -d':' -f2 | perl -lne ' $x += $_; END { print $x; } ' `"

I’m open to comments and suggestions on how we use these, or how they were written.  Spout off below.

Tags: , , , , , , ,

Case Against Using Symlinks For Code Promotion

Posted by Mike Brittain on May 12, 2009
WWW / 4 Comments

I’ve read and argued a lot about the case for using symlinks in managing code promotion. I’ve talked about this a lot with my pal, John Goulah, and he also noted this approach in a post he wrote about deploying code.

My general approach goes something like this:

  1. Point your document root at a static location, such as /var/www/html/prod.
  2. Promote new code (from stage, dev, what have you) to a versioned directory on your prod server, such as /var/www/html/release_12345.
  3. Use a symlink, “prod” in this case, to point at a specific release (e.g. prod -> release_12345).

The goal here is that you have a handful of versions on your prod servers that make it very quick to revert to a previous version.  You can revert your code, right?  (I’ll admit that only after a number of years I’ve finally gotten reverts working quickly and consistently.)  Our build process is not too involved, but it takes about two minutes to get code out to all of our servers and then flip over the symlinks to make the new code live.  The flip only takes one or two seconds, so all of the web servers we are deploying to remain consistent.

We have used a similar technique for nearly the last year in our build process at CafeMom.  I stress the word used, because we just got rid of the symlinks.

It turns out that we ran into an issue with the way that Apache handles symlinks while under load.  At the point when we would flip our symlinks to a new release version, files (especially PHP) from the previous release were still being executed or served by Apache.  It seems that Apache caches the real path to a file after determining where the symlink is pointing, and doesn’t necessarily re-check the symlink.  I don’t know how long this occurs, or whether it is specific to individual Apache children, but I do know that it has been a regular pain in the ass (PHP fatals, blank white pages, yuck).

To be clear about details, we also run APC on our servers to speed things up in our PHP processing.  When we promote a new version of code we also flush the PHP cache, thinking that this would help clear out cached versions of files.  The only thing that would absolutely clear up this issue was to cycle Apache, which we would prefer not to do on every deployment.

What now?  Rather than repointing a symlink, we move entire directories.  Something like this:

  1. Sync code out to a new versioned directory on our prod servers, say release_12346.
  2. Switch release directories doing something like this: “mv prod release_12345; mv release_12346 prod”.  (We use a state file to keep track of where “prod” originally lived, in case you’re wondering where release_12345 came from.)

Renaming these directories takes about the same time as swapping the old symlink we were using.  The Apache virtual host configurations (document roots) don’t need to be updated, either.  Looking at our APC dashboard and the affect on our site, it seems like this approach is working much more smoothly.

If you’ve got questions, alternative suggestions, or if you know what the root issue is with Apache caching our symlinks, sound off in the comments below!

Tags: , , , , , ,