How can I organize EventSources for the Semantic Logging Application Block?
The Semantic Logging Application Block (SLAB) is very appealing to me, and I wish to use it in a large, composite application I am writing. To use it, one writes a class derived from 'EventSource', and includes one method in the class for each event they want to log as a typed event, vs. a simple string.
An application such as mine could have hundreds of such events. I could have an 'EventSource' based class with just one event, "SomethingHappened", and log everything through that, at the one extreme end of the effort and accuracy spectrum, and I could have one event for every operation I perform.
It strikes me as a good idea to have EventSource derivatives for different functional areas. The app has little to know business logic itself; that is all provided by MEF plugin modules, so I could have event sources for bootsrapping, security, config changes etc. and any plugin module can define an event source for whatever events it wants to log.
Is this a good strategy, or are many EventSource derived loggers an undesirable app feature?
From your question
... I wish to use it in a large, composite application I am writing...
I can deduce that large is meant in the context of a single developer. In that case you can derive from EventSource and add all events you possibly could want into that class. It does not make much sense to create an extra EventSource derived class for every part of your composite application since it would pollute the eventsource registration database where already 2K of providers are registered. Besides that it would make it hard to enable logging for your application if you need to remember 20 guids you need to enable to follow your application logic through several layers.
A compromise would be to define in your EventSource class some generic event like
public void WriteViolation(string Subsystem, string Message, string Context)
where you have in your components a logger class for each component
public static class NetworkLogger
{
public static void Violation(string message)
{
GenericSource.Instance.Violation("Network", message, NetworkContext.Current);
}
}
public static class DatabaseLogger
{
public static void Violation(string message)
{
GenericSource.Instance.Violation("Database", message, DBContext.Current);
}
}
That way you can keep the loggers component specific and you can add eg automatically contextual information to the generic event when necesssary. Another approach is to use in your application tracing where your trace method enter/leave, info, warning, error and your EventSource derived class knows only these events. When you add for every trace entry the type name + method name you can filter by namespaces and group by classes in WPA to see what you were doing. An example is shown in Semantic Tracing For .NET 4.0. For a large application you can check out on your machine the file
C:WindowsMicrosoft.NETFrameworkv4.0.30319CLR-ETW.man
You can open it with ecmangen.exe from Windows SDK to get a nice GUI to see how the events are structured. .NET has only two Event Providers defined. The many events are grouped via keywords to enable specific aspects of .NET eg GC, Loader, Exceptions, .... This is important since you can pass while you enable a provider specific keywords to it to enable only some events of a large provider.
You can also check out Microsoft.Windows.ApplicationServer.Applications.45.man to find out how the Workflow guys think about ETW events. That should help to find your own way. It is not so much about how exactly you structure your events since the real test is finding production bugs at customer sites. The probability is high that you need to take several iterations until you have found the right balance to log/trace relevant information that helps you to diagnose failures in the field.
This is a bit of handwaving as its too long for a comment. But how about templating and then a factory service?
This then doesn't change and you bind everything up on application start and after loading plugins.
interface IReportable
{
void Report(object param);
}
interface IKernel
{
T Get<T>();
}
class EventSource2 : EventSource
{
private IKernel _factory;
public EventSource2(IKernel factory)
{
_factory = factory;
}
public void Report<TReportable>(object param = null) where TReportable : IReportable
{
var reportable = _factory.Get<TReportable>();
reportable.Report(param);
//... Do what you want to do with EventSource
}
}
Group Events logically into a different smaller provider (EventSource classes) and not into 1 large file.
This has the advantage that you can enable the Events only for providers that you care in special cases.
链接地址: http://www.djcxy.com/p/90864.html上一篇: 在c ++上使用System :: Diagnostics :: Tracing :: EventSource时，警告C4538