Introduction to the Semantic Logging Application Block (SLAB)

In my previous post, I discussed diagnostics logging and why it’s important, and how structured logging can help you troubleshoot problems and do some data mining. Now I want to talk about SLAB and what features it has, and provide some resources for you to use to follow up with. In my next post, I’ll offer up an example and talk about the things you have to consider when designing your structured logging.

Technologies for semantic logging

Here are the technologies involved:

Event Tracing for Windows (ETW)

  • Is native to Windows.
  • Has great performance and OK diagnostic tooling
  • It has historically been difficult to publish events.

EventSource class

  • New in .NET 4.5
  • Helps make it easier to create structured logging
  • It’s extensible, but only supports ETW out of the box

Semantic Logging Application Block (SLAB)

  • This is a wrapper around ETW; it allows you to use ETW without having any specific knowledge of ETW.
  • It rovides several destinations (sinks) for events published with EventSource.
  • It has additional tooling support for writing events.

Basically, SLAB enables you to use the EventSource class to write log messages from your application. You set up a listener, and SLAB receives notifications whenever the application writes a message using an EventSource class. SLAB then writes the message to whatever sink you have set up.

SLAB can act as a stepping stone. When you use EventSource, there is no commitment to how you consume events. You can later decide to replace it with your own tooling or use something else.

SLAB Features – Sinks

SLAB has the following sinks/destinations built-in:

  • Microsoft Azure Staroge Table
  • SQL Database
  • Flat File
  • Rolling flat file
  • Console
  • Elastisearch

And the following formatters for text-based sinks:

  • JSON
  • XML
  • plain text

SLAB Out-of-process service

SLAB can be used in-process – you start up the listener when your application starts up and let it run until the application ends. It also has an out-of-process service that you can host as a Windows Service (it needs to run in an account with elevated permissions). This service will get events out of the originating process using ETW and persist the events to the selected sink.

All sinks are supported, and the service is configuration-driven with support for reconfiguration. Also, the monitored application does not reference SLAB. It writes to EventSource, which is caught by the out-of-process service.

Benefits:

  • Increased fault tolerance in case of application crash.
  • You can monitor multiple processes from a single service.
  • This moves the logging overhead from the application to a separate process. The overhead is still there, it’s just not part of your applicaton.

Drawbacks:

  • There are more moving pieces.
  • The internal buffers may overflow without notification.
  • You have to make sure the process starts before the logging starts, and doesn’t end until after the logging ends.

SLAB Features – Event Source Analyzer

This helps you author and validate the Event Source derived class, and flags hard-to-detect errors relating to plumbing. You can run this inside a unit test to validate your classes.

SLAB Features – Observable-based

The event listener is IObservable.

The event sinks are IObservers.

This means you can use Reactive Extensions (Rx) to filter, pre-process, or transform the event stream before it’s persisted.

For example, you could use Rx to check the errors coming in, and if you get the same error 5 times in a row, it could send you an e-mail and not publish the same error for a few minutes. An example where this would be helpful is if your application is calling SQL Server and SQLServer is down, and as a result you’re about to have hundreds (or thousands) of error messages that are all the same come through the system. It would be useful to receive a notification that you might be having a serious problem. I had this problem once at the startup I worked at. We had a problem with SQL Azure, and I got over a thousand e-mails within a few minutes before we managed to shut down the service. Yikes! :-O

Resources

Here are some resources I found really helpful when learning about this topic.

Developer’s Guide

Enterprise Library 6

Enterprise Library 6 code + downloads + documentation

The last one has the Enterprise Library 6 Reference Docs, Quick Starts (this includes the reactive extension examples), and the Developer’s Guide and samples. They have a really good example of adding semantic logging to a Windows Forms app that calculates pi.

Summary

This post talked about the features of SLAB and ETW. In my next post, I will show you a class with a bunch of trace logging in it, and talk about how to “SLAB-ify” it.

Tags: , , ,

2 Responses to “Introduction to the Semantic Logging Application Block (SLAB)”

  1. Diagnostics logging and structured logging | RobinDotNet's Blog Says:

    […] / ClickOnce « Azure Blob Storage, Click Once deployment, and recursive file uploads Introduction to the Semantic Logging Application Block (SLAB) […]

  2. SLAB design considerations | RobinDotNet's Blog Says:

    […] Azure Like It / ClickOnce « Introduction to the Semantic Logging Application Block (SLAB) […]

Leave a comment