PHP Logging Is Your Friend

March 22, 2010

There are many ways of debugging PHP and it’s mainly a matter of preference; however I’m amazed at how little attention is given to error logging in favor of error displaying. Not only is the latter method more inefficient, it also leads to sloppy sites that reveal a great deal about their coding and organization to the Internet.

We’ll do a quick walk-through to get started with error logging.

Prepare php.ini

There are a few options that need to be set in php.ini to make proper logging possible. If you don’t have access to php.ini you can attempt to set the options at runtime (your mileage may vary.) An alternative to using php.ini is setting directives in an .htaccess file, but I won’t be discussing it in this post.

error_reporting  =  E_ALL
display_errors = Off
log_errors = On
error_log = /file/writeable/by/web/server/

Let’s look at this options a bit closer to understand what they do. error_reporting can take a number or different settings that grant an entire discussion all their own. I like using E_ALL which can be a little chatty at times, but can help to write better code. With PHP 5 E_STRICT has also been included, and has to be declared explicitly (not included in E_ALL.) This setting doesn’t provide additional logging, but gives recommendations to write even cleaner code.

display_errors is usually turned on during development, and turned off when going into production. If you are using logging, you’ll soon realize that it’s not necessary to turn this on at all.

log_errors is almost self explanatory, but could cause a newcomer to wonder why log files aren’t being written. This is the first place you should look if you aren’t getting logging information.

error_log has to be set to the path of a file writable by the web server; this is the second place you should look if your logs aren’t working. File ownership and permissions aren’t as daunting as they seem and you’ll be doing yourself a huge favor by learning how to apply them properly. If log_errors isn’t turned on, then this setting will have no effect whatsoever.

Set Up Your Box

This is where the rubber meets the road. Once you have all your settings in place and you’ve verified that errors are written to the log, it’s time to start using it. Open a terminal (command line as some folks call it) and give it the following command:

tail -f /log/file

The tail command retrieves the last 10 lines of a given file, the -f switch tells it to do it in real time. That is to say, that the display will be updated each time there’s a new entry in the log as opposed to having to run the command each time you want to see what’s going on. Leave this terminal running at all times and make it the first thing you glance at when something isn’t working right.

Talk To The Log, It Listens

So far you are able to view errors generated by PHP which is incedibly useful, but how about sending your own messages to the log? Enter error_log. This function allows you (in its simplest form) to send a custom message to the log. Let’s see an example, enter the following bit of code in a file and access it with your browser.

<?php
if ( 1 > 0 )
{
    error_log('it would be weird to NOT get this message');
}
?>

Now the log in the terminal (that’s ALWAYS open) will display something like

[22-Mar-2010 06:54:05] it would be weird to NOT get this message

This function also provides several other options such as being able to send the message via e-mail, or to a TCP port. So you can imagine the possibilities for customizing responses to different situations are endless. Here’s a list of useful resources that will help you in your logging quests.

This post only covers the very basics of logging PHP, but it’s intended as a starting point. I’m very interested in learning how you use logging or what debugging techniques you’ve developed. Don’t be shy and leave a comment.

Tags: , , , , , ,

Speak up

CommentLuv Enabled