There are different reasons for logging information, different strategies for what and how to log, and of course different ways of implementing it. This article will look at why you would want to log, what you want to log and how to do it.
With every installation of PHP, there are several logs available. Your webserver will keep its own access log and error log, from which you can get quite some information that can be used for statistics on your users and possibly also debugging your website. Then php also has an error log, which is also very useful for debugging your code. All these logs are completely independent of your application: They'll be there whether your application is or isn't. They give very global information on your application, mainly when something goes wrong. If you want more detailed information on what your application is doing, then you won't find that information in these logs. Your application is a black box. Something comes in, something happens, and then there is output. What can you do?
The webserver and PHP logs are what I'd like to call server level logs. They are written by the server layer on every request, or at least when necessary, and give information on a server level. To get more information on your application and the behaviour of your application, you'll need to implement a system yourself for logging information. Because this happens inside your application, this is the application level log. The application log will contain all the information that you choose to save about what happens inside your application.
Unlike the server logs, the application logging will need to be implemented by you. This will mean more work for you, but also more power. Because now you will be able to determine what gets logged, and in which situation that information is being logged.
There are different reasons why you'd want to log information from your application:
I'm sure a lot of people reading this have been in the situation where they are working on something complicated, and you don't get the output you expect. Whatever you do, you can not get the expected output to pop up. You keep thinking to yourself “Wouldn't it be great if I could find out what was going on inside to see where it goes wrong?” Of course you can! Aside from the various debuggers, like the Zend Studio debugger or DBG, logging your information into a file or database will also help you in this. In the various stages of your application, you can log certain values that are essential or might be wrong at some point, you run the script, and then view the logs to find out where it goes wrong. This is also safer than adding echo or print statements while developing. Imagine what happens if you accidentally forget to remove one of these statements after debugging has finished...
Another situation you might recognize is where you get the report from a user that some part of your system is malfunctioning. However, when you do what they do, nothing seems wrong. The user has found a situation that you have not tested or could not test. When you are logging the essential information, the only question you need to ask your user is: “When exactly were you trying this?” Armed with the time (possibly converted from the user's local time to your server time) you start going through your logs. The logs can be a treasure in this process, wielding tons of information that would usually be very hard to find.
This reason is more for corporate environments I guess, but statistics can be good for all kinds of things. Logging certain information that you need for statistics is the best way of gathering the information. Most basic information (like user agent, browser plugins, referrers etc) can be gathered from the server logs. But if, for whatever reason, you need more information than the basic information, just log it into a file or database, and you can write all the statistical scripts you want gathering the data from your logs.
Of course, everyone wants to write scripts that are secure, that can not be cracked. Unfortunately, nobody is perfect and (almost) everybody will make a mistake here or there. The best thing is always prevention, but in the case that you are victim of a cracker, information you are logging may give you important clues on the methods the cracker used to get into your system. Aside from finding the vulnerability, logging might also give you an idea of what exactly the cracker did in your system, what damage might've been done, what information the cracker might have obtained, and if this cracker left any traces or backdoors for possible future attempts.
