The new version of CoherentSolutions.Extensions.Hosting.ServiceFabric is released!
The version 1.3.0 is available on NuGet.
The release notes can be found on project version page.
This release brings advanced support for ETW configuration.
Let’s see the details!
The ETW is the preferred way of reporting events in Service Fabric. When creating a new project using Service Fabric project template. It creates a default implementation of
EventSource class like this:
ServiceEventSource is used like this:
There are multiple advantages of using the predefined event sources: better debugging experience in Visual Studio, ability to generate ETW manifest, etc.
Starting from the beginning CoherentSolutions.Extensions.Hosting.ServiceFabric supports auto-generation of self-descriptive event source and redirection of
ILogger<T> events to this event source (see understanding logging wiki page for more information). The infrastructure was automatically gathering additional information depending on the source of event and attaching it as event payload.
This implementation had one major disadvantage – there were no way to redirect events to predefined event source.
Now this and related things can be changed using new event source reconfiguration.
Reconfiguring Event Source
The reconfiguration of event source is done using new
SetupEventSource method we can use
UseImplementation method to override the factory function used to instantiate event source implementation:
Before we would be able to specify
ServiceEventSource as an implementation it should implement the
IServiceEventSource interface. This is required to support automated event redirection from
Here is the example of how the
IServiceEventSource can be implemented to redirect all event as
The main advantage is that implementation now has control over how events from
ILogger<T> pipeline are redirected.
While this feature improved the mechanism of event redirection it doesn’t help with the
ServiceEventSource.Current usage. Fortunately current release made an improvement there too.
Imagine that you have and event raised each time a
GetValue method is invoked:
You can try to use
ILogger<T> pipeline and write some metadata in order to identify this event in
ServiceEventSource class or you can use
ServiceEventSource.Current.GetValueMethodInvoked directly where it is required or you can write an abstraction and use it through dependency injection.
All of the above methods have their disadvantages: complex logic, uncontrolled usage of global object, need to write unnecessary code. As it is mentioned on the project page one of the main goals of CoherentSolutions.Extensions.Hosting.ServiceFabric is to remove unnecessary code. That is why it does implements the third option for you.
All you need to do is to:
Define a desired interface and inherit in from
Implement this interface by
Now when the
ServiceEventSource is registered as the event source implementation the infrastructure automatically detects the interfaces derived from
IServiceEventSourceInterface and registers implementation instance by these interfaces in all dependency injection containers.
This allows you to write events directly using
The new release of CoherentSolutions.Extensions.Hosting.ServiceFabric improves the ability to report ETW events by reconfiguring the default self-descriptive event source, by providing control of how events redirected from
ILogger<T> pipeline are reported and by providing an ability to easily abstract event source under well formed interfaces.
Thank you for reading!
CoherentSolutions.Extensions.Hosting.ServiceFabric is an open source project owned and maintained by Coherent Solutions Inc.