Considerations for useful trace messages in C# .NET

I am trying to work up an error and logging framework, and while I think I have the errors well in hand at this point, I'm a little more sketchy some other things by virtue of having never tackled the problem before. The part I'm having most trouble with right now is trace messages, which are obviously not the same thing as outright errors and shouldn't be handled the same way. Of course, when I try to think about the way they should be handled, I draw a blank.

What are some things that you've found helpful in your trace messages, whether for debugging or filtering things later? Obviously, there are some things like the level (Info, Alert, Warn, Critical), the messa开发者_如何学运维ge, the AppDomain, but what else?

For a little background to the setup, the logging framework I'm working on will live in our application class libraries and put information into a database table, MSMQ line, or flat logging file (application configurable).

Please DO NOT suggest ready-made products like log4net, the Enterprise Library, ELMAH, or anything like that as answers to this question. We have already considered each popular addition and discarded them as not useful to our needs. If you'd like to suggest pieces of data from these products that's fine, but a lot of places I've asked for input on get hung up on recommending things that we have spent weeks vetting and discarding instead of answering the question. I am hoping Stack will show some more class.

For logging purposes I'd consider including the user logged in, timestamp and domain specific information (which you'll have to decide for yourself). For trace messages for debugging, I'd include the class/method and values of variables and parameters that could be troublesome.

I like to use the pattern of using different trace levels for things that "belong" in those levels. For example, in the case of a web service which handles requests and federates other requests out to other servers, i might log the fact that i received a request as 'Informational', whereas i might print out the contents of the full request as 'Verbose'.

I basically categorize different types of events with different levels, sprinkle various levels throughout the codebase, and then consumers of the framework / product can choose 'Verbose' mode to see every last parameter of each request and response object, vs 'Informational' to simply be able to see the flow of requests / responses.

Obvoiusly erroneous events ( non- OK status code received ), based on their severity, should either be a 'Warning' or an 'Error'. I like to think of things that cause the process to abort ( e.g. all external servers are down, i can't possibly fulfil your request ) as 'Error' worth, and things that are worth noting but don't interrupt workflow ( e.g. 1 replica of external server is unavailable or it's round trip response exceeds some latency threshold ) as 'Warning' worthy.

Some additional cool things i've done is put a method in your Logger implementation that automatically knows who the caller of the Logger.WriteLine(...) is and prints it accordingly:

    /// <summary>
    /// Any additional layers between this log class and calling classes will cause 
    /// this stack trace to return incorrect 'calling' method name
    /// </summary>
    /// <returns></returns>
    private static string GetCallingMethod()
    {
        var stack = new StackTrace();
        var className = string.Empty;
        var methodName = string.Empty;
        foreach ( var frame in stack.GetFrames() )
        {
            className = frame.GetMethod().DeclaringType.FullName;
            methodName = frame.GetMethod().Name;
            if ( className != typeof( Logger ).FullName )
            {
                break;
            }
        }
        return string.Format( "{0}.{1}", className, methodName );
    }

I think some of this depends on what your applications do. For example if your application is database intensive I would think you would definitely want to log your sql statements. Any dynamic input from the user can also be helpful as debug logging. Datestamps are always helpful when looking at logs. Stacktraces on errors like others have mentioned. There are other instances but these are a couple. I'm curious though about why you ruled out ready made products like log4net etc. If you asked this question before online I'd be curious to see links.