With the recent passage of PSR-3, a standard for a common interface for logging libraries, it seems appropriate to discuss the implementation with my favorite logging library. log4php is an open source Apache project that is a very versatile logging framework. Through log4php's configuration files, logging has a variety of output locations, so it's possible to send specific log levels to different output locations.

He includes the Composer requirements for the interface and shares the code for a wrapper class that implements the Logger interface and defines methods for each of the logging levels (alert, notice, debug, etc). Also in the post is an example XML configuration for log4php and how to load it into your class instance.

The main goal is to allow libraries to receive a PsrLogLoggerInterface object and write logs to it in a simple and universal way. Frameworks and CMSs that have custom needs MAY extend the interface for their own purpose, but SHOULD remain compatible with this document. This ensures that the third-party libraries an application uses can write to the centralized application logs.

The implementation of this structure into your application makes it easier should you decide to swap out logging tools or want to create your own that can be used across several different frameworks. This is the third PSR to be accepted by the group, following PSR-1 and PSR-2 more related to coding standards.

PSR-3 is a proposed standard (voting has finished, it should appear as an accepted standard when the PSR folks recover from too much Christmas turkey) describing a common logging interface for PHP frameworks. It's based on a small subsection of RFC 5424, which describes the Syslog standard, which is a very sensible choice. Sysadmins think in terms of Syslog levels, and they utterly hate dealing with loggers that don't map cleanly onto Syslog.

He briefly introduces the PSR and the format of the logger with some of the main methods it should implement and what they do. He talk gets into some of his critiques about the proposal, namely the method naming, the exception handling parameter and the proposed LogLevel constants.

A new approach to implementing a query logger and potentially more complex features such as monitoring or read/write-splitting is the MySQLnd Userland Handler Extension (mysqlnd_uh, pecl website). The extension lets you register a PHP class as a proxy for every MySQLnd connection. Every call to a function to MySQLnd (usually indirect through mysqli, mysql, pdo_mysql) is passed to the PHP class, which then calls the original MySQLnd function.

They give a simple example to start - a logging function and how to configure it - followed by a more real-world scenario of logging inside of a project plugin.

This article shows you how to use Zend_Log, the logging component of the Zend Framework. It allows you to record messages from your application however you please. In this article I will show you how to record messages to a log file. Additionally, if you use the Firebug and FirePHP plug-ins for Firefox, Zend_Log can be extremely useful for application development and debugging. I will also show you how to achieve this.

They walk you through the creation of a simple logger and putting it to use by recording just the events you want (via error levels). There's also an extra section on integrating it with the Firebug/FirePHP extensions for Firefox and push your messages directly to the browser.

Whilst touring the web I found an interesting project for turning Apache Web Server log files into RSS feeds. This approach can be adjusted to monitor the maintenance needs of a web application deployed on an assumed productive system. Therefor a XML capable Zend_Log instance will be set up and the resulting log file will be transformed into a RSS feed via a custom Action Helper wrapping a XSLT transfomation.

He sets up the XML logger first, using the Zend_Log, Zend_Log_Writer_Stream and Zend_Log_Formatter_Xml to create the XML output from the logging. Then, with the help of the custom helper - Recordshelf_Controller_Action_Helper_Xslt - he reformats the XML output into an RSS feed ready for public consumption. (There's even a screenshot of what it might look like in a feed reader).

One big issue of the PHP error handling is that there's no built-in way to catch fatal errors with an user-defined error handler. So I thought a little bit about it and maybe you have better approaches or solutions...

With the goal of emailing the developers when such an error is thrown, he comes up with three different "storage methods" - using syslog, sapi, or a common logfile - and two different methods for watching them - file watching and syslogger. He works through these two options, trying to figure out which out be the simplest to implement.

He comes to the conclusion, though, that he might just be better off with one of the packages already out there to do something similar. Of the four he found, Swatch seemed to fit the best. He includes configuration and setup info to illustrate.

Now, paying attention to the topics that will be covered in this tutorial, what you'll learn here will consist essentially of applying the chain of responsibility schema to expand the capacity of the error logging system that was developed previously.

They take a look back at what they produced in the previous tutorial (the simple error logger) and show how to expand on it by adding functionality to log errors to a file. The finish it off by showing how to implement it all in a simple script.

At the end of this article you should be equipped with more robust knowledge of how to create a responsibility chain between PHP objects that perform truly useful tasks, like logging errors to specific components of a Web application.

They work from the code built up in the previous installations and show how to add the foundations of the error logger to the class before moving on to the more advanced bits. They then show how to use it to log some basic errors and, using only a bit more skill, logging some email-related errors.