MOPP : Day 3 : Errors and Log Management
This is another short and sweet tip. Errors have their place in every application. Most of the time developers use a simple conditional statement, and if there is an error, the application ‘dies’ with the error message.
This is improper error management. In order to analyze the performance, security, and usability of our applications, we need to know everything about each request and response as possible. This is especially true for errors.
First, if you are using vhosts, you should have special error/access logs for each site stored in that sites main directory (outside wwwroot). If you are unsure how to do this, check your web server’s documentation. For example, on my development server I have each websites main folder in the user ‘www’ home directory.
For example, a site I manage, called lousvoice.com, is located at ‘/home/www/lousvoice’. Inside that folder are 3 directories, live/staging/dev (if you read yesterdays tip you will have an idea what they mean). Inside those directories are more directories for application configurations, libraries, and a ‘logs’ directory. There is also a ‘public’ director which is mapped to the wwwroot of that version of the site. This keeps all of our important data behind wwwroot.
This is a sample vhost file (called lousvoice.conf) that contains the special directives for creating individual access/error logs in those directory. Using this, you can already imagine how much easier it is to parse and manage individual sites you are working on.
Now lets get to software error management. Bottom line, you should have an easily usable and extensible error and log classes. Note that i said error AND log classes. They have two completely different objectives.
The error class should contain static error codes/messages. This will keep all of your error output easily grep/searchable and be informative. It should allow extension, and with each extended class, should add more definitions to the error codes. For instance, our global error class might contain error codes for pages that are not found etc, while our database error class might add more definitions pertaining specifically to our database (such as connectivity issues, database not found etc). Then in any area of your application, you can call the closest error class (closest class extending our ‘master’ error class) and send it the error code plus any information pertaining specifically to what happened (more info the better).
The error class should parse the error passed to it and depending on how serious, be silent or take action in redirecting or informing the user what has happened. UNDER NO CIRCUMSTANCE SHOULD YOU EVER DISPLAY RAW ERROR DATA TO THE USER. This is not only a huuuge security risk, it is very unprofessional, usually uninformative to the user and will cause confusion. Fail Safely, and with good information explaining what happened. Either way, the formatted error message (eg. ‘Fatal 700 : Could Not Connect To Database : host/user/pw’) should be sent to our ‘logging’ class to be logged.
Our logging class will setup information such as where the logs should be saved (disk, database, etc) and how to save it (such as maximum log size, archiving etc). It should then have a method for logging the pre-formatted error string sent to it. It is a great idea to make your logging class extensible, in case you want to store specific logs in different places. For instance, I may have my database log manager set the log file name to ‘db.error.log’ which is distinguishable from our global error log that apache uses (‘httpd.error.log’ as seen above) and our applications normal log file (perhaps ‘app.error.log’). These naming conventions will make it very easy, using some command line kung-foo , to examine your applications performance etc.
There is not much more to say on the subject. I will post some classes later, including some special ideas using late static binding in php 5.3 to get your mind going. Log and error management is a must in any production environment. Without it, you are blind as to how your application is performing and can be extremely difficult to determine such things like security breaches and data integrity.
Stay tuned for day 4, and error/log class code examples.
