Error logging/handling on application basis?

We have a web server that we're about to launch a number of applications on. On the server-level we have managed to work out the error handling with the help of Hyperic to notify the person who is in charge in the event of a database/memcached server is going down.

However, we are still in the need of handling those eventual error and log events that happen on application level开发者_如何学编程 to improve the applications for our customers, before the customers notices.

So, what's then a good solution to do this?

Utilizing PHP:s own error log would quickly become cloggered if we would run a big number of applications at the same time. It's probably isn't the best option if you like structure.

One idea is to build a off-site lightweight error-handling application that has a REST/JSON API that receives encrypted and serialized arrays of error messages and stores them into a database. Maybe it could, depending on the severity of the error also be directly inputted into our bug tracker.

Could be a few well spent hours, but it seems like a quite fragile solution and I am sure that there's better more-reliable alternatives out there already.

Thanks,

Why would using PHP's own error_log quickly become 'cloggered'? If all goes well you won't see many errors, correct?

Building a separate application, especially one using an API, just for error reporting adds a lot of possible points of failure for error logging if you ask me. You could perhaps build an application that checks the existing error logs on various servers / for different applications to be able to display them in a sort of error dashboard, so you can see when things are REALLY going wrong.

But I'm interested to see what others might suggest as well, I haven't thought about it thát much yet for myself.

We actually tail -f the server's php error log for various outputs, but also catch a lot of exceptions we throw ourselves. By throwing a custom exception, you could have it (based on priority of course) write to your database, a log stream, your bug tracker and/or mail those-responsible-for-that-module. Of course you should log why the exception was raised (for example, var_export()/serialize() the func_get_args() of the method you threw an exception in. Make the exception message huge, since it will save you.

In addition to this, we use Zend_Log where exceptions are a bit overkill (for example if the argument given to the method should be deprecated, we might log a bit of debug_backtrace() to see where that call came from. This could be extended to programs making graphs of expensive calls etc, but that's a sidenote :)

My best tip: know where your application could fail and where it can not, it's so much easier to search for that error. Make sure errors that are raised based on external services are interpreted as such.

... and to be honest, I think this kind of thinking (Error-API/-Service on app. level) is a bit weird: how could you prevent an error if you knew exactly how to handle it? Wouldn't you avoid/automatize it?

You could use set_exception_handler and set_error_handler to gather more specific info and report it in a way that will alleviate the 'cloggering'. You could do different files for each client or application, introduce your own codes that allow for easy processing by an error parsing script, etc.

I'd be careful about introducing extra code or infrastructure to the error-handling process. It needs to be super solid so you can trust the info you get. Reporting errors directly to the database? What about database connection errors? (and on and on)

What you're searching for are PHPs error handling functions: http://de.php.net/manual/en/ref.errorfunc.php

Especially interesting would be set_error_handler() that allows you to completely override PHPs internal error handler.

With that you can make your own logs per application / send emails to admins / save error info to a db / tell users that an admin has been notified or whatever.

By either returning true or false you can also control wether PHPs internal error handler should run after your function or not.