As can be seen from the last few posts (if you ignore the monsters one), I've been having a bit of a deep dive into the System.Diagnostics tracing classes, and especially the concept of activities (as glorified by WCF's Service Trace Viewer).
I needed a logging solution for a project at work. This was all about seeing if System.Diagnostics was up to the job. Here are the key points I see from this.
Boring Logging Solved
If your requirements are just for simple but flexible logging, then you're sorted. Knock yourself out.
Reducing Dependencies
I don't want my project to have to take on dependencies it doesn't need. It has to be downloaded to a client's desktop. I'd rather not have to download log4net, or Enterprise Library.
Asynchronous Logging
Unfortunately, logging is synchronous, which would mean a performance hit. You'll need to weigh up if this matters to you. Logging in a client application will likely not have as much of an impact as logging on a high volume server side app.
We can mitigate this by writing an asynchronous TraceListener. Or just use Enterprise Library's MSMQ trace listener. There goes point #2 above.
Logging Arbitrary/Ambient Data
You can enable the logging of certain types of standard data, such as process id, thread id and callstack, which is very useful. You can also use TraceSource.TraceData to output custom data, such as a customer identifier. If you always wanted to output the customer identifier (what I'm calling ambient data), you'll need to write a wrapper API.
The nice thing is that once the extra data has been serialised, Service Trace Viewer can search and filter on it, thanks to custom xpath expressions.
End to End Tracing
The value in being able to join up logging at the client side with logging at the server side and view them in a nice tool like Service Trace Viewer shouldn't be underestimated.
But sometimes end to end tracing isn't enough. If you're interested in knowing the steps a customer took to get to a certain point, you need to group all customer interactions into a form of session.
A simple solution would be to have a session identifier as the form of ambient data that always gets output. Then Service Trace Viewer could filter on this.
Another solution would be to write a particular event that ties the session identifier to a specific activity id, then correlate all the activity ids from that.
End to End Tracing Analysis
Which nicely brings me to the analysis of the end to end tracing.
Service Trace Viewer is a nice tool, but I think it's more of a visualisation/inspection tool than an analysis tool.
End to end tracing is a graph. To get all of the records in a single end to end call, I need to walk that graph and follow the transfer of activities. This is fairly straightforward when we're in an xml file that I'll need to process linearly anyway, but if we stored the data in a database? That'd make an interesting query...
But we can still mitigate this. There's nothing stopping storing a session identifier in each record, either at runtime or post processing.
File Formats
Hang on. Databases? Oh.
Service Trace Viewer only supports flat files.
And you can only use STV if you use the XmlWriterTraceListener.
Propogation of Activities/Context
This Just Works when you're using WCF, and is easy to implement if your not, and the gains in end to end tracing are very cool.
Custom Logging in Service Trace Viewer
It appears that WCF interacts so nicely with Service Trace Viewer by chucking out more information. WCF has built a whole load of plumbing on top of System.Diagnostics, all of which is internal, but it helps dump full exception details, give friendly names to activities and so on. I need to investigate this a bit more.
Finished...
It's clear that System.Diagnostics isn't the final word on tracing and logging, but it's certainly Good Enough, and given its extensibility, it's definitely a Good Start.
I wanted to be able to tick enough boxes that I could just use the logging out of the box, without having to go and evaluate any other frameworks. I think I've done that, but only just. Simple logging is handled, but I really like the activities idea. Yet to make it easy to use that, I think I'm going to have to write some wrappers. And if there's extra stuff to output to make Service Trace Viewer play nicer, then maybe that'll be a few more wrappers. That's a little disappointing.
Subscribe