First lets try and understand the difference between logging and tracing:
Logging: Used to capture verbose details of events like errors, warning etc. So whenever there is an exception you would go looking for an error log to help you address the issue. Some of the choices available for logging are Common.Logging, Log4Net etc
Tracing: Used to capture an audit trail of the code execution. In other words tracing will have more instrumentation data than logging since it follows the program flow and data. Some of the choices available for tracing are ETW (available from .Net 3.5 and Windows Vista or greater), Diagnostics.Trace etc.
Error logs supplemented by the trace files would provide a rich set of debug information when trouble shooting in a live environment.
Brief overview of tracing using System.Diagnostics
System.Diagnostics supports Debug and Trace namespaces. However only the latter is a part of the binaries released to production compiled in release mode, hence use the methods accordingly.
This method of tracing uses trace listeners which receive trace output from a source and then outputs it either to a console, disk, event log or some other configured destination. The default trace listener is System.Diagnostics.DefaultTraceListener which routes the tracing information to Win32 OutputDebugString and Debugger.Log. You HAVE to disable/ remove this listener when performance is a concern as these get used by default and will induce a lot of latency. (http://stackoverflow.com/questions/15119791/performance-impact-of-defaulttracelistener).
Apart from DefaultTraceListener we have
– TextWriterTraceListener which writes to disk
– EventLogTraceListener which writes to an eventlog (even on a remote machine).
It uses trace switches to enable/ disable tracing and also set the level of information to be captured. These switches can be either a boolean switch or a trace switch. Boolean switch is an on/off switch whilst trace switch has levels like Off, Error, Warning, Info, Verbose.
All the trace settings can be controlled via a configuration file. In summary you decorate the code with trace statements and control it from outside the application.
Brief overview of tracing using Event Tracing for Windows (ETW)
ETW is the tracing mechanism employed by system device drivers and hence is geared towards high performance. Essentially what it has internally is a set of buffers per-processor implemented in the kernel to which the events get written to. The contents of this buffer is then written to disk by an asynchronous writer making it faster and better. The added benefit is that the logging can be dynamically enabled and disabled from outside the application without needing an application re-boot, making it easy to use in a controlled environment.
Now a typical ETW architecture consists of
Event Provider: They are the source of events. A provider has to register with ETW via a provider ID and then use this ID to write events.
Controller: It dynamically starts/ stops tracing by associating a tracing session with one or more providers. ETW adds more information to the event and places it into the tracing session.
Event Consumers: One can associate a consumer to a tracing session for processing each event written to the session. Consumers work using event call backs i.e. they register with the ETW sessions and then once an event is received in the session, ETW notifies the registered consumer.
Advantages of this loosely coupled architecture:
– Provider and tracing sessions are kept in separate spaces which allows for a flexible management. Any number of providers can be associated with a session (operates in the kernel) controlled by the controller.
– Tracing becomes application immune i.e. even if the application crashes, any events raised will not be lost as the trace kernel memory is separate from the application buffer. This is particularly in debugging application issues.
– Controller can start/stop tracing dynamically without needing an application re-start which is particularly helpful in production.
Turning our attention to BizTalk, the BTS runtime engine uses its own version of System.Diagnostics.Eventing (http://msdn.microsoft.com/en-us/library/system.diagnostics.eventing(v=vs.110).aspx) for ETW. The namespace is Microsoft.BizTalk.Diagnostics found in the assembly Microsoft.BizTalk.Tracing.dll. There is a further adaptation of this assembly available at ttp://blogs.msdn.com/b/asgisv/archive/2010/05/11/best-practices-for-instrumenting-high-performance-biztalk-solutions.aspx.
BizTalk instrumentation framework was implemented by the AppFabric customer advisory team (CAT) as a best practice for instrumenting high speed BizTalk solutions. It acts as a wrapper on top of the BizTalk namespace providing a richer choice of tracing methods. Visit the link more details and its usage.
VeeN
btsbee.wordpress.com 