Look for Server “Ouches” – By Collecting Server Logs

At some point, most parents have asked their child to “show me where it hurts”. Perhaps a parent asks this question because their child has just yelled “ouch” or maybe the child seems to not be himself (i.e. lethargic). And the reason parents do this is because they want to help their child get better and catch any problem as early as possible.

In a similar way, we need to know when our servers are yelling “ouch” or don’t seem to be themselves. We can do this by examining the event logs, which basically is like the server talking to us, and by baselining the performance of our server.

Now, the easiest way to do both of these things is if we have some sort of monitoring software. Typically, monitoring software will examine server logs and baseline servers, and will alert us to any issues. This is the ideal situation …

However, what if we don’t have any monitoring software or we don’t have the monitoring software on all our servers. Well, then we may have to build our own process. And in this post, I am going to examine how to look for “ouches” in our server’s event logs.

How to read a server’s event logs?

First, I am going to acknowledge that you could go to each server and examine the event logs, but that seems like a horrible idea to me. Although, I have heard of some DBA’s doing that, the problem is that this method is not scalable. If you have one or two servers, ok, it could work. But, if you have hundreds of servers, it will never work.

So, that is where automation comes in and using PowerShell is my tool of choice. I am going to demonstrate some ways to read a server’s event logs.

Method 1: Use Get-EventLog (https://technet.microsoft.com/en-us/library/hh849834.aspx)

Get-EventLog -ComputerName $server -LogName “Application” -EntryType Error,Warning -After $logdate

Method 2: Use Get-WinEvent (https://technet.microsoft.com/en-us/library/hh849682.aspx)

Get-WinEvent -FilterHashtable @{LogName=’Application’; Level=1,2,3; StartTime=$logdate} -ComputerName $server

 As you can see, it is pretty simple to read a server’s event logs. Now, all you have to do is read the data into a table and report on it daily. This will also help you to keep a history of the “ouches”, in case you need it. But, there are some things to keep in mind:

  • For the best performance, filter the amount of records returned by the command by using the parameters EntryType when using Get-EventLog and/or Level when using Get-WinEvent. This will perform much better than piping the command to an output, which will read all the records, and then using a where clause for filtering. In my deployment, since I am looking for “ouches”, I only care about messages that are: critical, error, and warnings.
  • Get-EventLog is the older command and can’t read some of the newer event logs from Windows Vista and later. So, it is recommended to use Get-WinEvent for newer operating systems.
  • Get-WinEvent also lists event logs and event log providers. You can get events from selected logs or from logs generated by selected event providers. And, you can combine events from multiple sources in a single command. Get-WinEvent allows you to filter events by using XPath queries, structured XML queries, and simplified hash-table queries.


So, although there are multiple ways to look for “ouches” on a server, I always recommend a monitoring software solution or an automated process that can easily be built with PowerShell.

This entry was posted in DBA and tagged . Bookmark the permalink.

One Response to Look for Server “Ouches” – By Collecting Server Logs

  1. Pingback: Look for Server “Ouches” – By Collecting SQL Server Logs (Part 2) | SQL Bad Boy – Michael Lowery

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s