There are many resources we should analyze to ensure optimal ColdFusion operation or to help diagnose problems. Fortunately, there's an awesome free tool that comes to our aid to turn voluminous data into useful information.

In this article, I'd like to introduce you to the free Log Parser tool from Microsoft. Yes, it's free. And while you may not run ColdFusion on Windows, that's okay. You can use it on a Windows machine to monitor resources on a Linux machine. The tool applies just as well to those running BlueDragon or any CFML, PHP, .NET, or other environment.

I'll show you the many ways you can use the tool to solve common challenges in ways that no other monitoring feature in CF or even the dedicated monitoring tools like SeeFusion or FusionReactor can do. In one example, I'll show you how it can provide application-specific error log information that many struggle to obtain.

Basics of the Tool
Despite its name the tool is about more than just log files. What kind of resources can Log Parser monitor? It started out focused on Web server log files, and indeed it can do that (in IIS, W3C, and NCSA formats), but it can also analyze all manner of tabular text files (CSV and TSV), as well as XML files, the Windows Registry, the file system, the IIS metabase, the Windows event logs, the Windows Active Directory, and NetMon files.

And while it can produce simple textual results, it can also generate output to a file in plain text, CSV, TSV, or XML formats, as well as produce charts, and store results in a database

But the best, most compelling, and truly unique aspect of the tool is how you go about analyzing the input files. There's no interface for the tool. So how do you describe what data to retrieve? Would you believe you use SQL? That makes it an especially compelling tool for CFML developers, since we're used to using SQL already.

I'd like to focus here on particular forms of information that would be useful for CF developers and administrators to analyze using the tool, so I won't focus on its installation or basic use. I'll direct you to other resources at the end of this article that will get you started.

I'd just like to clarify that Log Parser is meant to be used at the command line (logparser.exe). I'll assume that you have it installed and configured so you can issue commands such as its help option:

Logparser -h

Of course, you can also use such a tool from the CFEXECUTE tag, but again that's beyond the focus of this article. I'll point you to a resource later that will cover such additional details.

Analyzing CF Log Files
It may seem odd at first to contemplate using SQL to analyze log files and the other non-database resources mentioned above, but it really is effective. While most of the existing resources that introduce the tool focus on analyzing Web server logs, I'd like to start by showing an analysis of ColdFusion logs.

Now, how could a tool that analyzes log files regard the columns in that file as columns to be used in SQL? Well, many log files do have a first line called a "header" line that provides a list of names that identify each column in the log file.

Even if the log file doesn't offer a header file, the Log Parser tool has a clever mechanism to analyze the first 10 lines of the file to try to determine what kind of data is in each column and create generic column names.

For this article, let's consider the application.log file that tracks errors in your CFML code and is stored in the "logs" directory where CFMX is installed. On my machine, that's c:\cfusionmx\logs. To query all the columns in all the records of that file, I could issue:

logparser "select * from C:\CFusionMX\logs\application.log" -i:csv

Note the familiar "select *" SQL statement that says "select all columns" and the "from" clause that names the actual log file to be processed, all of which is embedded in double quotes. The additional "-i:csv" argument tells the logparser engine that the file is a CSV (comma-separated value) format file. A subset of the result as it might appear is:

Filename RowNumber Severity ThreadID Date Time Application Message
--------------------------------- --------- ----------- -------- -------- -------- ----------- -------------
C:\CFusionMX\logs\application.log 2 Information jrpp-0 06/21/06 19:53:15 <NULL>
C:\CFusionMX\logs\application.log initialized
C:\CFusionMX\logs\application.log 3 Error jrpp-0 06/21/06 19:53:15 <NULL>
Error Executing Database Query.Data source not found.
The specific sequence of files included or processed is: C:\Inetpub\wwwroot\test.cfm

Yes, it's a jumble for now (all dumping onto your screen at the command line), but later we'll see how to limit what columns to show as well as how to write the output to a file for more effective observation.

Understanding Column Headers
The first line above shows all the column headers that were found in that header file. You can also have the tool list the columns that it's found or detected using the option -queryinfo, such as this:

logparser "select * from C:\CFusionMX\logs\application.log" -i:csv -queryinfo

In the data shown will be the list of columns found. In this example, it would be:

Query fields:

Note that the "S" and "I" indicators mean the columns hold strings or integers, respectively. Other types are "T" (timestamp) and "R" (real). We can use any of these column names in the SELECT statement to limit what columns we display. More important, we can use them to limit what "records" we display.

Limiting the Records Found
Going back to the earlier example that just did a "select *" the result was basically the same as if we'd just dumped the file to the screen. Where the tool gets powerful is in using additional SQL clauses to refine the search. For instance, since we see that one of the columns is "severity," which has values such as "Error" or "Information," we could limit the list to just those with errors using:

logparser "select * from C:\CFusionMX\logs\application.log where severity='Error'" -i:csv

Note the addition of where severity='Error.' As with most SQL engines, the string value must be surrounded with single (not double) quotes. On the other hand, notice that the first character of the value is capitalized because, unlike most SQL engines, the comparison here is case-sensitive.

Of still more interest may be to limit the errors to a given application. Since that's another field, you can use this:

logparser "select * from C:\CFusionMX\logs\application.log
where severity='Error' and application='test'" -i:csv

This would list only those errors for the application "test."

Grouping Records
Now, perhaps a different interest would be to see a breakdown of errors by application. Again, this is easy in SQL and therefore easy in Log Parser:

logparser "select application, count(*) as NumErrors
from C:\CFusionMX\logs\application.log
where severity='Error' group by application" -i:csv