In a new post to his blog Brian Moon describes a need he had for detecting if the client or user calling a PHP script was using an interactive terminal (TTY) or not:

Let's say I am trying to find out why some file import did not happen. Running the job that is supposed to do it may yield an error. Maybe it was a file permission issue or something. There are other people watching the alerts. What they don't know is that I am running the code and looking at these errors in real time.

Since the errors were being sent to the log file, they were lost to the client/user on the other end left staring at their script wondering what went wrong. He ended up with a solution (a pretty simple one too) that uses posix_ttyname and posix_isatty. He includes the little snippet of code he puts in his prepend file that checks for errors then checks for a TTY. If both are there, it turns off logging the errors to the file and sends them direct instead.

Sameer Borate has posted an alternative to "tail" that you can use to find the last X number of lines in a log file you'd like to follow without having the overhead of parsing the entire file.

Frequently one needs to get the last few lines of some log files, whether php error logs or Apache logs. Most of these file sizes run into megabytes, which makes it difficult and time consuming to remotely open them using ftp. [...] The [example] is a simple but useful 'tail' implementation in PHP. I've encapsulated the tail function in a 'LogRead' class, which can be further enlarged by adding other useful log functions.

His code opens a file pointer to the requested log, grabs the file size and uses the fseek function to move the pointer to the line/location you've requested. Obviously, if the requested lines of data is large, it will still have some overhead, but this is a much better way for keeping track of the latest additions to a log. You can then use the "tail" method on the "LogRead" class to grab just the lines you want.

Josh Adell has a new post to the Everyman Software blog talking about a solution he and his team have developed for logging user sessions across requests with the help of the Zend_Log component and a custom logging formatter.

One way to handle this is to put a request-specific identifier in every log message. But I shouldn't have to remember to append or prepend the identifier to their log messages. I'd rather have it happen automatically, without me or my teammates having to think about it. Here's a method we've been using to try and untangle the mess and retain the usefulness of our logs. The code uses Zend's logging component, but can easily be adapted to other log systems.

Their example sets a custom log format message with placeholders for a timestamp, log ID number and the log message. A unique ID is then generated for the user's session and applied to the Zend_Log object. This data is then automatically applied to the log file's output without any extra hassle. The full sample code (pretty simple, really) is included.

On the Working Software blog there's a recent post looking at correcting a mistake that the developer made when choosing the logging method of his application - pushing the output of print_r into a file.

recently deployed a job on which the timeline was so tight that my ability to type quickly was what made the difference between delivering on time or not. Everything was rushed, the budget was tight, it was one of those real seat of the pants deals and there was far too little testing done. [...] The only problem is that, in the 5 minutes before the site was supposed to go live, I didn't really have much time to thoughtfully prepare a logging system to record all this stuff and, in my haste, I settled for [a file_put_contents of the print_r of $_GET and $_POST].

Obviously, this solution is useful for casual browsing of the information, but if you need any real data from it, it's a real chore. To help you with the task, they've put together a snippet of code that can work through your print_r output and return it in a much more handy line-by-line result. Full code is copy-and-paste ready in the post.

In this quick tip from NetTuts.com today they show you how to set up custom error logging for your PHP application with the help of the set_error_handler function.

In today's video quick tip, we'll review the process of setting custom error handlers with PHP. Along the way, we'll also learn how to log and email those potential errors to ourselves. That way, even when your web application has been deployed, you'll be the first to know when an error is encountered.

They make a custom handler, nettuts_error_handler, that takes in the error information and translates it into an error message that's emailed to an admin of the site. It also checks the error reporting level to see if it needs to display the error back to the user or not. This helpful hint is part of a screencast, but they've provided the code separately to make it easier to work with.

On the Design-Ireland.net site, there's a recent tutorial showing you how to log messages to Scribe from PHP. Scribe is Facebook's open sourced server for aggregating log data streamed in from multiple places.

n a previous tutorial, I showed you how to install Facebook Scribe on a Linux server. In this tutorial we will continue to look at Scribe, but this time from the client perspective. Note that this tutorial assumes that you already have your Scribe and Thrift environment set up as outlined in the previous tutorial. You can log messages to Scribe from many different languages. In this tutorial I will show you how to use Thrift to generate a PHP client, and then use that client from your own PHP project to log messages.

The tutorial walks you through setting up Thrift to work with your PHP installation and gives an example script to send your first messages over to the Scribe server. They also show how you can go into the Scribe instance's folders and look for the log information you just inserted.

Brian Moon has a new post to his blog that pulls together some of his thoughts on monitoring PHP applications and how to handle the error that might be thrown.

PHP errors are just part of the language. Some internal functions throw warnings or notices and seem unavoidable. A good case is parse_url. The point of parse_url is to take apart a URL and tell me the parts. Until recently, the only way to validate a URL was a regex. You can now use filter_var with the FILTER_VALIDATE_URL filter. But, in the past, I would use parse_url to validate the URL. It worked as the function returns false if the value is not a URL. But, if you give parse_url something that is not a URL, it throws a PHP Warning error message. The result is I would use the evil @ to suppress errors from parse_url. Long story short, you get errors on PHP systems. And you don't need to ignore them.

He talks about the two-step process he's upgraded to to help monitor and handle the errors that pop up - an error handler that logs human-readable and json versions of the errors and something like Circonus to do metric tracking. He also mentions some external services recommended on twitter - HopToad and Loggly.

On the ServerGrove blog today there's a quick new post showing a method you can use to log the queries to your MongoDB database in your Symfony2-based application.

Symfony 2 comes with native support to connect to MongoDB using the DoctrineMongoDBBundle. Getting started is quite simple and there is not much that needs to be configured, but the manual does not say how to enable query logging although it is already possible with Symfony PR3. Query logging allows you to debug queries sent to the DB server by writing them in a log file. It is very useful for cases when you issue a query and you are not getting the results you expected.

The key is to add a "logger_class" value into your Symfony configuration file pointing to the "DoctrineMongoDBLogger" tool. The queries will then show up in your normal log files. They include a sample line along with a brief explanation of the values inside.

Paul Gregg has written up an example of what he calls "tail -# file for PHP" (starting from the end of file and moving backwards a given number of lines).

Here I will demonstrate a fairly tuned method of seeking to the end of the file and stepping back to read sufficient lines to the end of the file. If insufficient lines are returned, it incrementally looks back further in the file until it either can look no further, or sufficient lines are returned.

His script meets two goals - reading enough lines in for the request and keeping those lines to a minimum. His code grabs the size of the file and opens the file as a resource to fseek to a certain point and read in the lines from the defined start to finish and push them into an array. You can see the source here and a sample execution here.

In a recent post to his blog Evert Pot warns against some of the issues that mutual dependencies in your applications.

Much like most people, I try work out my class dependencies through a top-down 'waterfall'-ish approach. By attempting this, I think allows me to keep the structure very clear and understandable. [...] I try to apply the same model to instantiated objects and packages (groups of classes). When an object encapsulates another object, I attempt to make sure the sub-object object is not aware of the parent. When I design packages, I attempt to make sure 2 packages don't require 'each other'.

He gives an example of where this could cause problems - a Database logger that has three types of logging included: file, syslog and database. Obviously the last of the three requires the Database class so they must always be used/included together.

As a bonus a database-error could occur while logging, resulting in an endless loop (or segmentation fault if you're using PHP). [...] However, these types of situations are sometimes simply unavoidable (that's why we have include_once). When they are needed, they should be implemented with care and consideration.