In this new post to his site Rob Allen shows you how to implement a simple logging method for catching exceptions in your Zend Framework 2 application.

I recently had a problem with a ZF2 based website where users were reporting seeing the error page displayed, but I couldn't reproduce in testing. To find this problem I decided to log every exception to a file so I could then go back and work out what was happening. In a standard ZF2 application, the easiest way to do this is to add a listener to the 'dispatch.error' event and log using ZendLog.

He uses an event listener to attach a service that contains a "logException" method. This method uses the ZendLog component to write out the error message to a local log file including a backtrace of where the issue occurred.

On PHPMaster.com Patrick Mulvey has written up a new tutorial looking at using the PSR-3 logging structure to make a basic logger for your application.

Logging is one of the most ubiquitous tasks encountered in PHP. We use logs to track error messages, record important events, and debug problems with our code. In any PHP project, the code is likely to be full of calls to a logging library which handles these actions for us. [...] To promote compatibility between logging libraries, the PHP-FIG group recently released PRS-3, a common interface for logger objects. In this article, I'll discuss how the logger interface defined by PSR-3 allows us to write reusable code that isn't dependent on any particular logging implementation.

He includes a quick introduction to the PSR-3 format, how to get the files you'll need to use it (via Composer). He includes some sample code showing how to make the basic email class with a logger injected for use. Since the Monolog logging project follows the PSR-3 format, it's an easy drop-in option. He also talks about using PSR-3 to avoid having logger dependencies with the "LoggerInterface". There's also a bit at the end of the tutorial showing you how to use the Adapter design pattern to "proxy" the logging calls to the class via a PSR-3 interface.

The PHP-FIG (Framework Interoperability Group) has recently accepted the PSR-3 definition for a standardized Logger interface structure that can be used for interoperability between frameworks (and other tools).

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.

In a new post to his site Jeremy Cook introduces you to Graylog2, a logging server that can aggregate messages from multiple sources/feeds into one consolidated location.

Graylog stores them in a database and allows you to perform custom searches on them. You can also see in real time how many log messages are being received and processed. The real killer feature in Graylog is streams. A stream in Graylog is a predefined custom search. The server will display to you log messages that only match the stream criteria selected, graphing the results for you.

He mentions other features of the Graylog2 system including customized alerts, messaging via UDP/AMQP and how it uses MongoDb and ElasticSearch. He also introduces Monolog, a PHP tool that lets you log in multiple formats directly to the Graylog2 server. He includes an example of how it works with a sample "LoggingHelper" added as custom exception and error handlers.

Scott Mattocks has started off his series about the LUCID development methodology (one he recently proposed) with the first article covering "L" for Logging.

Communication is the only way you can tell if an application is feeling well or is about to fall apart. If your application can't talk to you, you have no way of helping it to feel better. The L in LUCID is for logging. Logs are how applications speak. They capture information that allows us to pick up on those little signs and act early enough to make sure the application doesn't come down with the flu. If you don't have good logging throughout your system, the best you can do is react to your application falling over. A silent application is an application destined to cause midnight surprises for you and your operations team.

He talks about the difference between "just logging" and "correct logging" as well as a recommendation for the different levels: trace, debug, info, warn and error.

Letting you know that something went wrong is really only half of a log messages job. The other responsibilities of a log message are to allow you to accurately reproduce the conditions under which the event occurred, and to allow you to fix any data inconsistencies.

In response to this suggestion from Alessandro Nadalin about using the "Strategy" design pattern to replace a switchChris Hartjes has this new post sharing his opinion of "the right way" do it it.

Once I realized what he was doing, I realized that the Strategy pattern was applicable in this case…but his chosen example was dumb and one that I wouldn't have used to demonstrate things. As expected, he told me to supply a sample of a better way. I did, telling him that the sample would be better if he didn't mash the logging level together with the message.

Included in the post is sample code, first showing the initial version of the logging class, complete with accompanying tests. Following that, he shows how to refactor it into something using the Strategy pattern, replacing the logging type switch statement with protected methods for each logging message type (critical, notice, etc).

On PHPMaster.com today there's a new tutorial from Lorna Mitchell introducing you to using Analog for error logging in a MongoDb connection. Because of the way the tool (Analog) is designed, it could be used anywhere - she just uses the MongoDB connection as an example because it integrates easily and efficiently.

MongoDB is an excellent fit for logging (and of course other things as well) for many reasons. For one, it is very VERY fast for writing data. It can perform writes asynchronously; your application wont hang because your logging routines are blocked. This allows you to centralize your logs which makes it easier to querying against them to find issues. Also, its query interface is easy to work with and is very flexible. You can query against any of the field names or perform aggregate functions either with map/reduce or MongoDB 2.2's upcoming aggregation framework.

This article will show how you can use existing code to add a logging library to your code and log errors to MongoDB. You'll also see how to query MongoDB from the command line and how to filter those queries to find the information you are interested in.

Analog makes it simple to log information in an easy to use, self-contained, extensible kind of way, offering writers for multiple output formats including: files, the FirePHP plugin output, email, POSTing to another machine and sending to a syslog daemon. She also mentions the different logging levels the tool makes available and how to filter down your logging results based on them (searched by "equal to", "greater than" and grouped by level).

Ryan Gantt has a new tutorial posted to his blog today looking at one of the features in the upcoming PHP 5.4.x releases - traits. Specifically he looks at the horizontal reusabillity they allow for in your applications.

The ability for a class to inherit from multiple parents is maligned by many, but can be a good thing in some situations. For those working in PHP, multiple inheritance has never been an option; classes are limited to one parent, though they can implement many other datatypes through the use of interfaces. Interfaces can lead to code duplication in improperly-factored inheritance hierarchies. Even in well-architected hierarchies, multiple classes that implement similar methods can contain a lot of overlap.

He starts with a definition of what traits are and where their real usefulness is (as well as what should be the difference between a class and a trait). He gives an example of a typical hierarchy where two classes extend a parent but then they both need the same functionality. Code duplication's not a possibility and inheritance make run into exposure issues. Traits come to the rescue by dropping in just the feature you need when you need it. His example code shows adding some logging to a simple class via a "Logging" trait and a "Singleton trait" example.

Dave Marshall is already looking ahead to the next major release of PHP, version 5.4, and one of the features it will include - traits. In this new post to his blog, he introduces a "logging trait" he's come up with to make logging simpler in your (Zend Framework) application.

One of the 'traits' I find myself constantly adding to library files is optional logging of it's behaviour. The library class has it's own log method, that checks to see if the instance has had a logger injected and if so, logs the message. I see this as a perfect candidate for becoming a reusable trait, as I tend to have the same code copy/pasted throughout my library classes. The problem is, according to the rfc, traits aren't supposed to have state/properties, which makes it difficult to have a DI setter method in a trait.

He includes the code for his trait example (noting that it may or may not end up working correctly in the 5.4 final release) that sets a logger on a sample class and logs a few values out to the console. It's a simple example, but it shows you one of the most useful things about traits - the "drop in resuability" nature they allow in your libraries and classes.

Henry Hayes has written up a handy post to his blog looking at using FirePHP and Zend_Log_Writer_Firebug to log messages directly to your Firefox's Firebug console.

Due to sloppy programming in the past many PHP error logs can become very clogged up and, unless you use some fancy grep technique, unusable. [...] A project has been around for some time now called FirePHP. This enables us to log messages of various levels of severity to the Firebug console! - Awesome. Just imagine if you are developing an ajax app, you could have all your debug messaging in one place.

He walks you through the steps needed to get the logging up and running - setting up FireBug (if you don't have it already) and FirePHP, editing your Zend Framework bootstrap file to add an _initLogging() method and using it for logging, both in the backend script and on the frontend in the console. He also includes a quick update to the logging method that only logs to the Firebug console if the environment is not production.