Hierarchical Tracing

Hierarchical tracing was made most famous by log4net, and means that trace destinations and levels can be configured according to coarse or fine grained application areas as neeeded.

If you retrieve a logger for a type named MyApp.Commands.MyCommand (with Tracer.Get<MyCommand>()), you end up with four potential configuration areas in Tracer:

• *: this wildcard area allows to set up a catch-all configuration for every component using Tracer on the given AppDomain.
• MyApp: this typically would be the root namespace of all your app/company components, and makes for a good place to split your own components logging from third-party ones.
• MyApp.Commands: this source would allow you to bump or redirect the logging for all commands in the app, without getting noise from other app areas.
• MyApp.Commands.MyCommand: if you need to diagnose a particular class, you can increase its logging level directly without increasing it for any other source.

The SystemDiagnostics tracer implementation adds support for this very useful feature on top of the .NET built-in TraceSource. This allows you for example to set up a general destination for logs at the application root source (i.e. MyApp), and allow run-time dynamic increasing of the level for particular areas as needed (i.e. something isn't working quite right, and you can provide an in-app setting to increase the tracing level to Verbose of, say, the MyApp.Commands.MyCommand source). This will cause the verbose messages for that particular command, to end up in the MyApp trace destination (i.e. the XML Activity Tracing-enabled listener)