.NET Brain Droppings

I'm a Microsoft Certified Architect (MCA)... Feel free to ask me about the program...

To Log or Not to Log... That is the question...

Ok, sorry for the extremely poor Shakespearian reference, but its late and I've drank one to many this evening =).  Anyway, as I'm flipping through my code, adding logging information via Log4Net, I wonder: Am I getting carried away?  I guess I'm really looking for advice from people out there with experience writing logging code; just how much logging code is enough.

I find myself wanting to write a log.info line for every executable line of code I have; and I know that's not right.  So here is the formula I'm currently using:

  • Create a logging entry at the beginning of each method that reflects the name of the method (e.g. _log.Info("Class::Method(hashcode)");
  • Create a logging entry for each "logical" unit of work (e.g. I can't really define what this is, but I know it when I see it in my code)
  • Create a logging entry for each error caught or thrown (e.g. _log.Error("Method puked", ex);)

I'll be the first to admit, this is a pretty rudimentary approach, but at this point, I'm not sure of a better one.  The Log4Net documentation is excellent in terms of how to use Log4Net, but it doesn't describe a logging strategy.

 

So for that logging strategy I'm turning to you, the .NET blogging community.  How do you use Log4Net in your apps?  Do you following a particular strategy/formula.  If you do please let me know, I'm sure there's a better way!

 

[Listening to: A rerun of The Practice : my wife talk about our upcoming trip to wine country : my dogs playing with their food]

Posted: May 25 2003, 07:12 PM by dbrowning | with 5 comment(s)

Comments

Jesse Ezell said:

That is definately way too much logging. What are you trying to accomplish? That is going to have huge effects on how you implement your logging.

If you are trying to track bugs, your time would be much better spent writing a good set of test cases than logging every single action that takes place. It's not that logging isn't helpful for tracking this as much as it isn't required. Test cases will find your errors before they turn up and are preventative, while logging only helps find errors after the fact. Besides, if you log the exception properly, you will get the entire stack trace anyway, which pretty much eliminates the need for the method entry logging.

Here are two categories for logging stuff:

1) Unexpected errors (not every exception thrown, just the ones that you don't expect... definately every unhandled exception though). This is used for bug tracking purposes.

2) Actions that need to be reported on or audited. Usually, the purpose here is to make sure you have a log of what administrators are doing--in case they decide to go postal one day--or to see usage trends for users or groups within the system.

# May 25, 2003 10:52 PM

Christopher said:

Don,

I have only gone into logging for exceptions. As Jesse points out, using test cases is better practice for error prevention, although I'm a novice in this arena - so no advice there.

The way I usually handle code that could or could not throw an error is to log it immediately with the call stack plus the method name/parameter name/value set that caused the snafu. Then I throw the error until it gets to my topmost container which in most cases is Application_Error for me. I show the user a nice friendly message and I log again.

Perhaps the only other logging I would consider would be things I consider to be significant user interaction - like "let me pay now" type stuff.
# May 27, 2003 8:47 AM

Mathew Nolton said:

it depends on what i am trying to do....don't you hate that answer.

with webservices, i found that putting a call at the beginning and the end of the call was helpful shortly after rollout to troubleshoot any issues that might occur with environmental setup; however, after rollout when the app was running smoothly it didn't offer much help if any.

i also have found that in some organizations where different teams handle the setup in different environments and you are creating the setup program...then log everything so you can track any issues that might come up later ( and whether or not they deployed the application correctly ... ).

at the end of the day, most of the logging i perform has to do with making sure the app has been deployed correctly in a compatible environment and that all of the pieces are talking to one another because some of the time the production environment isn't what we were told it was going to be.

-Mathew Nolton
# May 27, 2003 12:18 PM

Mathew Nolton said:

I also try to write out all exceptions to a log file or the event viewer
-Mathew Nolton
# May 27, 2003 12:19 PM

Don said:

Thanks for all the input guys. I spent the better half of yesturday working on this. I'm not sure I have the solution yet, but I can cite the major source I'm using as inspiration:
Beyond Software Architecture: Creating and Sustaining Winning Solutions by Luke Hohmann
# May 28, 2003 6:39 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)