Log rolling

Through testing and trials, you’ve finally got your ColdFusion application up and running, and it seems to be doing ok.  Then you start hearing from your client’s clients that they’re having trouble.  You could ask your client for their client’s phone number and try and get someone twice removed from the situation to help debug your application, which is not likely going to happen, or you can sit down and try to figure it out yourself.  Chances are, you already have the information somewhere.  That somewhere is within your ColdFusion installation folders (we shall call it %cfroot% since I don’t know the technical term).   There are two locations to check out: %cfroot%/logs and %cfroot%/runtime/logs.  For now, wading through /logs is much easier, so that is what I will discuss…..

/logs

Now unless you’ve gone and made a special error log (in which case this blog will be useless) any uncaught errors will be found in this folder (and it’s easier to search through than the /runtime/logs.  This folder will hold two important files: application.log, and exception.log.  Generally speaking, you will only need to look at server.log if the problem seems to be long running pages (if you’re logging them in the ColdFusion Administrator).  Otherwise that log is just to keep note of the startup and shutdown information.  Mail.log will contain messages related to why a cfmail did not go out, so for this discussion, you won’t need that either.

application.log

Application.log will show any and all random application errors.  Here’s where you find out how important setting your cfapplication name is if you have more than one site.  Your log entry on error will look something like this: 

“Error”,”jrpp-1412″,”04/20/08″,”12:17:56″,”DDADemo”,”Error Executing Database Query.General error: Incorrect string value: ”for column ‘someColumn’ at row 1 The specific sequence of files included or processed is: driveletter:\yourwebsite\somefile.cfm, line: 150 “

This line is broken down into several sections.  The important information to look at is the date and time, since sometimes you will have just made an adjustment, the application name (in this instance “DDADemo”) and then the text describing the error.  Sometimes the error isn’t exactly clear, then you have to go match it up with the exception.log but that is a blog for another day.  The important thing here is that you will generally get a match up of a line of ColdFusion program code that you can take a look at and figure out what went wrong.  Programming ColdFusion isn’t just about writing code, it’s making sure the code is solid, and debugging even after the project has been ‘completed’.

I try to check out the ColdFusion logs every Monday morning unless I am debugging a ColdFusion application, and I check often.  This morning is no different from my regular routine.  I then copy and paste the errors for each of the programmers on their projects and forward so that we can be proactive about issues that arise.