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.