My personal experience with the Windows Event logs has been frustrating, but there are tools that can turn “useless” into “useful.” The logs themselves ARE pretty useless if you the only time you look at them is when the server is down and you are desperately searching for answers. All too often, what you find then is that they are full of repetitive information–a secondary problem such as lack of disk space–and it is too late to find the event that triggered the cascade of failure.

Here are a few tips to get ahead of that…

Set limits. First of all, review the properties on each event log to make sure the logs are not allowed to grow indefinitely. You want to see something like this:

Although you can lose data this way, in a cascading event failure where you have the event logs set to “do not overwrite” you will fill up your disk with unhelpful messages anyway.

Consider a subscription to EventID.Net. This service provides windows administrators with a way to look up the often cryptic EventIDs and find a more helpful description online. As you peruse their site, you will notice a great deal of advertising and “reviews” of one of Heroix competitor’s products–but they have produced a great deal of helpful content for debugging the event logs.

Make sure you have a subscription to Microsoft TechNet or check out a site like this where someone has posted lists of the EventIDs for free.

Develop a plan to avoid the crisis review of logs I described above. Any plan is better than sitting there complaining about how worthless the logs are, but different plans yield different constraints/costs:

Plan A is to have a network or systems administrator periodically review the event logs and investigate “anything suspicious.” Good luck with that plan. I think you have to honest about how effective such an approach will be–despite best intentions, it will fail because it takes too much time away from other tasks and it mind-numbingly boring.

Plan B is to outsource these kinds of issues to a IT support company for network and application monitoring and hope they have a better plan. Again, good luck with that. The nature of many problems I have experienced is that they present in unique ways and require more substantial knowledge, not only of the network and applications environment, but also of the business environment and processes to really comprehend what types of patterns indicate a new, real problem. Outsourcing delegates too much unless they are ultimately responsible for the whole operational environment.

Plan C is for “cobble” as in “Cobble together open-source solutions” and own this as a part of your job. Probably most small to medium-sized companies will follow this approach, but it is still subject to the cost constraints of time to create, time to maintain, etc.

An alternative is to consider what Heroix Longitude can do to help.

• The event log records can be displayed in Longitude’s Windows Event Log Viewer.
• Collected event log records can be translated into Longitude events for display with other Longitude events in the Applications view of the Longitude Event Monitor.
• Translated events can be used to trigger Longitude correlated events.
• Event reports display the statistics related to the number of event log records of each type, and include drill down for more detail on the events.

The main point is that you can get the event logs imported into an integrated systems management application where the history and profile information you would be saving…in your brain per the manual approach…can be analyzed more easily. It should make the difference between hours of grunt work you don’t want to do and a more effective approach to proactively monitoring your systems for problems and performance issues.