.NET Core Logger using Serilog – Part 3

Introduction

Welcome back. In the previous part of this series, we centralized exception handling logic using ASP .NET Core Middleware and our Web Helper for logging concern. We saw the error messages are being persisted to the corresponding file. In this post we will see how to persist other type of logs as well (i.e. Performance, Diagnostic, Usage etc)

Diagnostic Logs

These are similar to console.log() in JavaScript. These will be used mostly by developers, when they want to log particular messages from the code. Due to this nature, we introduced a Boolean Flag via Environmental variable in part 1 of this series. So developers can add this kind of logging in the code and whether to persist it or not can be configured by that Boolean flag.

Controller Code

We will start from the top and see how we can introduce this kind of logging in our code. I have the following method in the WeatherForecastController:

It is very similar to ErrorLogging. We are using WebHelper.LogWebDiagnostic method and you can see that along with product and layer information, we can pass some additional info as well in form of message or a dictionary.

LogWebDiagnostic Method Code

This method is similar to what we discussed in the previous post. I will not go into much details as it is self explanatory, however, if you still have question, feel free to ask in comments:

Diagnostic Log File

Here is the snap shot of info in the diagnostic log file. You can open it in some JSON Viewer, to get more formatting. You can see that its less verbose than errorlog and our custom log messages are being saved as well along with other useful information.

Usage Logs

This type of log capture usage information based on incoming web request.

We will leverage, ASP.NET Core ActionFilterAttribute to encapsulate this logic and it will also make easy for us to put our logging code on the Actions, for which we want to capture these informations.

Controller Code

Here is how our code will look like:

ActionFilterAttribute Code

Notice, that this attribute code is internally using WebHelper.LogWebUsage method and following the code for that method for your reference. It is very similar to methods we have seen earlier:

Usage Log File

Here is the usage log file.

Performance Logs

Very similar to other type of logs, but they also capture how much time a particular method execution is taking. For this type of log, we will use IActionFilter from ASP.NET Core. Lets see how this is implemented:

We, have another internal component called PerfTracker and here is the code for that class for shall be easy to understand:

We are starting a stopwatch in the constructor and then stopping it in the stop method and recording elapsed milliseconds along with other information.

Capturing Performance Logs

Getting this kind of log in our solution is very simple:

by adding the above mentioned code to AddMvc it will start capturing this kind of log information. Following are the content from the log file and you can see in this log we are also capturing information about the execution time:

Reuse of the Logging Code

The source-code for this solution is available on this git repo. You can test it, change it etc. Now If you want to use this code in your app, it should not be difficult as well.

All the code related to logging infrastructure is in a folder. A very simple approach is as follows:

• Install nuget packages, add enviornmental variable or configurations for logfiles path.
• Copy the CoreLogger folder to your source code.
• Setup Exception Handling or use the corresponding error logging code in your own exceptional handling code.
• Decorate Action Methods for Usage logging.
• Configure MVC MiddleWare for Performance Logging
• Add logging statement yourself in the code for Diagnostic logging.
• Extend as needed.

Summary

At this stage we have logging functionality, which can write to Text Files. But writing to other destinations e.g. elastic-search shall be now very easy, as we have all the necessary infrastructure code in place and in the next and final part of this series, we will talk about that and other things. Till next time, Happy Coding.