Share via

Log Parser Studio - What's an EEL log anyway?

  • Article

You just downloaded and launched the latest version of Log Parser Studio and stumble upon two new log types that you have never seen before; EEL and EELX. What on earth could those be for? If you don't already know, LPS was born from within the Exchange Server Support organization as a tool to help engineers identify issues in sometimes gigabytes of log files quicker and easier. It was so useful that it was made available to the public in the TechNet Gallery soon after. With the built-in query library being somewhat Exchange centric and the fact that Exchange Server exposes a LOT of logs it became clear that these two additional log types would come in handy.

The name is from the concept of "Exchange Extensible Logging" where Exchange logs much more discrete data these days to make both automated health monitoring and active troubleshooting easier. These logs follow a basic W3C/CSV type format but there are some customizations in the formats of various logs. In order to use the built-in formats you'd be making changes to the CSV input format each time you moved from one log type to the other. In the interest of simplicity LPS doesn't store LP 2.2 input formats on a per query basis, it stores those settings globally. To keep things simple EEL and EELX are extensions of the existing CSV format with preset customizations to handle the two most used Exchange logging formats.

EEL

EEL will handle most 2010 style formats such as Exchange 2010 RPC Client Access logs. If you want to get an idea of just how comprehensive Exchange Server logging has become just look in the Logging folder in C:\Program Files\Microsoft\Exchange Server\E14 (or E15 if you have Exchange 2013). You'll also notice there are already multiple queries in the library that work with these formats.

EELX

EELX is more common in Exchange 2013 which has even more comprehensive logging but may occur in earlier versions as well. However, there are a number of 2013 logs that also use EEL. If you are looking to build queries for Exchange logs that aren't already in the library, either of these two formats will usually suffice.

To dig a little deeper, the main difference between the two is how the header and fields of the log file are laid out. Logs that work with EEL look something like the example below. Notice there are only 5 header lines prepended with hash marks with the last one being the field or column list:

 #Software: Microsoft Exchange Server
#Version: 15.00.0516.025
#Log-type: MigrationLog
#Date: 2013-03-06T15:05:08.032Z
#Fields: timestamp,thread-id,source,event-type,context,data

 However, logs that work with EELX are slightly different. Notice the very first line which is similar to the very last line and is a list of field names which doesn't exist in the above format:

 DateTime,RequestId,MajorVersion,MinorVersion,BuildVersion
#Software: Microsoft Exchange Server
#Version: 15.00.0620.000
#Log-type: HttpProxy Logs
#Date: 2013-04-17T18:00:44.044Z
#Fields: DateTime,RequestId,MajorVersion,MinorVersion,BuildVersion

You could handle both of the above formats by simply tweaking the CSV format yourself and it would work just fine but these additional formats are preset to work with these logs as-is with no extra tweaking required. EEL and EELX are also fully configurable as needed but its recommended to leave them at their defaults because those settings are what make them EEL/EELX compatible. If you ever do tweak these and forget the defaults just click Reset in the format properties window.

So, the TLDR summary is that both of the above are for querying Exchange Protocol logs which vary in format. They are preset for simplicity and with just these two log types you can query almost all existing exchange log files. If you are building your own query you can try EEL and if that doesn't work, try EELX. In most cases one of these will properly parse the header and create the proper field names. If you only use the built in queries, you don't need to do anything but enjoy the results.

Comments

  • Anonymous
    March 19, 2014
    Thanks for the clarification Kary!