When designing client libraries to send data to our API, one of our top priorities is to make sure that none of our code affects the performance of your core application. That is tricky when you have a single-threaded, "shared-nothing" language like PHP. [...] Ideally, we like to keep the setup process minimal and address a wide variety of use cases. As long as it runs with PHP (and possibly a common script or two), you should be ready to dive right in. We ended up experimenting with three main approaches to make requests in PHP. Here's what we learned.

Their three suggestions don't involve external dependencies (like a queue server) and can operate pretty quickly:

• Opening a socket and closing it before waiting for a response
• Write to a log file (a pseudo-queue)
• Fork a curl process (through something like exec)

They each have small code examples included with them and explanations as to their plusses and minuses. For their needs, the "forked curl" solution worked out the best, but check out the other options too - you might have different needs.

So this past week I have been doing a lot of logging, parsing, and graphing. I was sitting there wondering what I could do to make the Apache access logs easier to work with. Then it hit me, a brilliant stroke of win: why not format it in JSON? Then in my log parser I could just json_decode it! As far as I know there are no tricks to make Apache do this for you, so really all we have to do is define a custom log format that happens to look like JSON.

He includes the "LogFormat" line you'll need to add to your Apache configuration to make it log the JSON and a bit of PHP to help you pull in the file's contents and parse each line.

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.

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.

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.

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 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.

]]> Tue, 04 Jan 2011 08:58:45 -0600 http://www.phpdeveloper.org/news/15462 http://www.phpdeveloper.org/news/15462 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.

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.

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.