<var id="jl7jb"><span id="jl7jb"></span></var>
<cite id="jl7jb"><noframes id="jl7jb">
<del id="jl7jb"><noframes id="jl7jb"><del id="jl7jb"></del>
<ins id="jl7jb"></ins>
<ins id="jl7jb"></ins><ins id="jl7jb"></ins>

Ultimate Guide to Logging

Your open-source resource for understanding, analyzing, and troubleshooting system logs

.NET Searching Logs

We’ve looked at the different libraries you can use to log .NET events. The way you search logs completely depends on how you log events from your code. You can store logs in plain text, XML format, or directly to the Event Viewer. You can search Event Viewer and XML logs using PowerShell. PowerShell has native libraries that search both formats for you without creating any kind of elaborate code.

In this section, we’ll cover the different methods you might use to search logs in .NET applications. We’ll use PowerShell because it contains many internal functions that make searching easy. It’s also available on any Windows machine, and you can use it to connect to remote machines such as your server.

Before we go any further, you should first know the numerous advantages of searching compared to just looking at raw logs from the server. Finding the right issue can be like finding a needle in a haystack. You can have thousands of logs to look through, and searching ?can help you find the issue in just a few minutes rather than days.

Searching from Event Viewer

The Windows Event Viewer is a native utility available on any version of the operating system. It’s mainly used by administrators to review application and system errors. We covered ways to log errors to the Event Viewer. We’re now going to show you how to search events using PowerShell.

When you review your logs, you could have several different criteria that you want to use to find specific events. You might want to search using a date and time. You might want to search recent events for a specific application.

First, let’s start with a simple command to get used to the way PowerShell works with the Event Viewer.

Type: Get-Eventlog –List and press Return.


As you can see, it gives you a list of logs on your system. It also shows you what happens when the log gets full.

Your application events are written to the Application log. Notice it’s where we have many of the errors. The System event log is also large. It logs computer system errors.

Let’s say we want to see the most recent error events for applications that logged a critical error. We want to search the last 200 events.

Type: Get-Eventlog -Logname Application -Newest 200 | ?Where-Object {$_.entryType -Match "Error"} and press Return.

In the search above, we found that Skype had a critical error on April 19. We can extend the search to more events. In the code above, we just search the last 200 errors, but we can search the last 2,000 or 20,000 events. The –Newest switch is what determines the number of events you search. The Where-Object parameter is where you specify the entry type. We want to know errors, but you can also search for information or warnings.

In most root cause analysis, you only know that an error occurred at a specific date. You usually work off of a user report or a group of reports based on a business analyst or project manager report. In this case, all you have is a date and you don’t know if any warnings or errors were thrown. You somewhat “fly blind” on the error that’s being produced from the application. You have the dates, though, and these can be used to search and parse the Event Viewer log to find events.

Type: Get-Eventlog -Logname Application -After (Get-Date -Date '4/1/2016') -Before (Get-Date -Date '4/22/2016’) and press Return.

The above code searches the application log for any events between 4/1/2016 and 4/22/2016. We have several events that meet this criteria.

In the image above, we see all events between those two dates for all applications. You probably just want to see errors for your own application. Let’s narrow down the search to just events for one application. We’ll use the same date and time parameters, but we’ll narrow it down to just the MSSQLSERVER application.

Type: Get-Eventlog -Logname Application –Source MSSQLSERVER -After (Get-Date -Date '4/1/2016') -Before (Get-Date -Date '4/22/2016’) and press Return.

Now, we can just see one application’s errors within a specific date criteria.

Using these PowerShell commands, you can search your application logs to find specific errors that match user reports.

Searching XML

Some libraries store logs in XML format. For instance, ELMAH is a plugin library that .NET developers can use to store errors in either XML format or in an SQL database. An XML file is the default.

PowerShell has native functions that let you search and review XML. It’s not as extensive as Event Viewer logs. For this reason, it’s best to store your logs in the Event Viewer or you need to buy third-party applications to more extensively search your XML logs. We’ll show you how to work with XML files using PowerShell.

We created a simple XML file that contains two errors.

Just like standard development, the way to work with XML files in PowerShell is to first assign the file to a variable. We’ll assign our XML log to a variable named $errors.

Type: [xml]$errors = Get-Content C:\errors.txt and press Return.

Of course, replace the path of our “errors.txt” file with your own.

Notice that PowerShell doesn’t give you much output. It just assigns the XML to the variable and waits for your next command.

Now we can work with the XML data.

We can verify that the assignment worked by just typing the variable name.

From the output, we know that the XML was assigned. Let’s take a look at the errors. We know that each error is contained in an error node. Let’s print out a list of our errors.

Type: $errors.errors.error and press Return.


As you can see, PowerShell parses the XML and lists each error in its own column. We only have two errors, but this command gives you an easy way to quickly print out an XML log into a readable format for your review.

This provides a great way to see all errors, but usually we want to see a subset of the logs. Suppose we want to view a list of errors related to the login module. We know that our application logs any errors using the “login” text, so we can search the XML file for this information.

Type: $errors.errors.error | Where-Object {$_.failure -like 'login*'} and press Return.

And the output.

The output shows us all errors that contain the “login” text. You can use the Where-Object parameter to search for exact matches or use the “like” option to find a partial match.

We can also use our dates. Suppose you want to find all errors that were logged on 4/20/2016.

With XML you have some functionality but it’s limited. Luckily, XML is not a common way for .NET developers to log issues. For the most part, you’ll find that logs are stored in Event Viewer, plain text, or in SQL Server.

Parsing Solutions

You might think that using PowerShell commands and parsing your logs every week is tedious, and it is. Logging solutions such as Loggly can parse your logs for you and even provide you with analytics without a single line of code or parsing from you. It’s even a more powerful solution than creating reports and parsing yourself.

Take a look at an example.

This is an example (cropped) image of Event Viewer logs taken from a Windows server and imported into Loggly. Each item in the log is shown here. Even though it’s not parsed into a report, it’s parsed enough where you can quickly review events and identify major errors.

Now let’s take a look at a report.

The above small report gives you a list of events by time and day. This report is displayed using Loggly, and no parsing or programming was needed.

Using the above data, you can even get pie, line, or bar charts.

The above screenshot was taken from the previous image’s data. It’s a line graph that shows a trend in errors by time. Again, no programming or parsing was needed.

This is the advantage of log management solutions. They can do all of the parsing for you so that you can manage servers instead of managing logs and reports.

One final note on logging—error logs can grow to tremendous sizes. They can take several gigabytes of data if you don’t carefully manage them. They should be backed up, but you should have a retention policy that determines how long you need to keep them. Most libraries break up logs into dates or a specific size before they start a new file. Ensure that the logging technique that you use gives you the capability of tracking events for at least three months. Some bugs aren’t caught for several weeks after release.