Design – Build – Run: Applied Practices and Principles for Production-Ready Software Development

21.1. Tracing

Part of establishing a timeline for an incident invariably involves analyzing log files and trace files, as well as other outputs from the solution. The tracing is no different from events for quality purposes. There are good trace entries, bad trace entries, and downright ugly trace entries. When you see a trace entry that doesn't include the most vital piece of information, you hold your head in your hands and cry "WHY?"

An optimal level of tracing should be a part of the production system and included within the performance requirements. Personally, I don't think it's very good to say, "The system runs at 100 miles an hour with everything switched off." There really needs to be tracing to ensure that issues can be resolved when they occur — unless, of course, the event has everything you need. The tracing also needs to maintain code quality and readability while providing adequate output.

In many cases tracing can further demonstrate the 80/20 rule. Consider the following example pseudo code (which is for demonstration purposes only):

Authenticate( string username, string password ) { status = false; // method entry trace if( DiagnosticProvider.IsTracing( Activity.MethodEntry ) ) { DiagnosticProvider.Trace( TraceType.MethodEntry, CLASS_NAME, METHOD_NAME, username ); } // obtain user if( DiagnosticProvider.IsTracing( Activity.ObtainAccount ) ) { DiagnosticProvider.Trace( CLASS_NAME, METHOD_NAME, Information, Activity.ObtainAccount, username, password ); } if( AccountProvider.GetUserByUsername( ...