Are you writing an application that has high performance requirements, are you wondering how Azure Diagnostics works, do you want to write your own logging framework….this might help you out.
Not so long ago, the Application Server Group ISV Partner Advisory Team posted an excellent article on how to instrument specifically BizTalk applications, by leveraging the ETW infrastructure.
This allowed for significant high performance tracing and was measured against other frameworks as you can see in the diagram below;
What’s really interesting is that there are 2 patterns which you can implement:
1. In Process, where the Host which performs the log data is written to the ETW Infrastructure and the Listener is subscribed to the ETW data
2. Out of Process, where the Listener can be a Service outside of your application (most suitable for OnPremise usage)
With the Semantic logging application block, the idea is that the logging infrastructure is predefined (e.g. Start / Stop events which are logged) and that the application only provides the data/parameter used to log. You need to create an EventSource which contains all the LogEvents you would like to log. This means that, as well as with unit testing….you need to think, before you build. An example is shown below;
The great thing, and the reason I like this framework is that you are able to create the sinks, and due to the Out-Of-Process model, can leverage sinks which in itself are not high performance. Out of the box there are a number of sinks: SQL database, Windows Azure table, flat files and some others.
1. Example SQL Server Sink
2. Example SQL Server Result
- Result and extension points
Writing using the EventSource will write to the ETW Infrastructure, which has almost no performance impact. The Out-Of-Process listener will pick up the messages in a windows service (can also be downloaded from the EntLib download link), the Sink writes the data to the destination of your choice.
In a post of Tomasso Groenendijk the option of using MongoDb is explained, with the idea of having a high performance tracing mechanism. With SLAB the same functionality is available.
Additionally, writing large amounts of data can be something you don’t want to do on you database used for your primary process, so creating a MongoDb Sink is still a viable option, however, for different purposes.
- Getting started with SLAB
You can use the SLAB quite easily by using NuGet and search for Semantic, which will display the Application Block and the available Sinks for Windows Azure Tables and SQL Server as wel.
The hands-on labs and documentation should get you going quickly. As the EntLib settings can be configured outside of your code (recommended), diving in the EntLib config might not be as much fun as you would expect. For this, there is an EntLib configuration tool available.
- Getting started with EntLib Config
The following link, contains a EntLib 6 configuration add-in which helps you create the Configuration settings for some of the Application blocks and the Windows Service for out-of-process logging.
1. Select the configuration console
2. Click on the Config file and open the editor
3. Select the block and visually configure the block
4. Example TransientFaulthandling Config
5. Usage TransientFaultHandling Config