How much to log within an application and how much is too much?

Question

Just wondering how much people log within their applications???

I have seen this:

"I typically like to use the ERROR log level to log any exceptions that are caught by the application. I will use the INFO log level as a "first level" debugging scheme to show whenever I enter or exit a method. From there I use the DEBUG log level to trace detailed information. The FATAL log level is used for any exceptions that I have failed to catch in my web based applications."

Which had this code sample with it:

Public Class LogSample

   Private Shared ReadOnly Log As log4net.ILog = log4net.LogManager.GetLogger(GetType(LogSample))

   Public Function AddNumbers(ByVal Number1 As Integer, ByVal Number2 As Integer) As Integer

      Dim intResults As Integer

      Log.Info("Starting AddNumbers Method...")
      Log.Debug("Number1 Specified: " & Number1)
      Log.Debug("Number2 Specified: " & Number2)

      intResults = Number1 + Number2

      Try

         intResults = Number1 + Number2

      Catch ex As Exception

         Log.Error("Error Adding Nubmers.", ex)

      End Try

      Log.Info("AddNumbers Method Complete.")

      Return intResults

   End Function

End Class 

But this just seems to add so much to the method. For instance a class that would normally be maybe 7 lines of code suddenly becomes 12 lines of code. The method also loses some of its clarity and simplicity.

But in saying that the benefit of having the logging in place can be good. For instance performance monitoring in a production system, chasing down aberrant bugs in production (not that you would have all this logging turned on all the time.

Hence I am wondering what people do? Cheers Anthony

Answer 1

It's more the art side of programming.

You don't want to log everything. But you will want to log the most crucial parts of the system.

Just think about your program in a broad sense and try to identify which information you will want in case something breaks in production.

For a start, all the core logic modules of your application should have logging functionality. The decorative parts e.g. UI/animation shouldn't need logging.

IMHO, logging every method entry/exits is overkill and will also produce a noise especially since you can just embed a stack trace.

And for performance, use a profiler.

Answer 2

...hey, do I get a badge for being quoted as the topic in a SO question? 8^D

But seriously though, one thing I want to clarify about the logging comment above is that part of my justification for the "verbose" logging is based on the fact that I'm leveraging the features of log4net itself.

In the sample I provided, that method logs on a daily basis in WARN mode. Which means that the only thing that gets logged "by default" is if an exception occurs. If I get a call from one of my clients about having an error in the application, they don't have to read me some cryptic message on the screen, I jump in the log and can see what's going on. Most of the time, the answer is right there.

What happens if the answer isn't readily available? Log4net allows me to update my configuration file (no re-compilation necessary, no need to get access to some special system file on the web server with the sysadmin's approval) and go into INFO mode. Now you start seeing a second layer of logging. Maybe the code never made it to a certain loop. Maybe the data retrieval had an empty record set. This second level of debugging is helpful, and the log only gets slightly larger. Once this is done, I can change the config again and go back to the light logging.

Naturally if things are REALLY crazy, then I go to the full debug level, and I want to know what each variable is reporting, what DataRows I'm dealing with, and what is going on in the application. At my current place of work, we don't have the ability to do remote debugging into our web applications, and we can't always tap into the production database without potentially augmenting data, so having this full debug is the next best thing.

I agree with the majority of folks out there that excessive logging can really bring down an application and cause more problems than it is worth. If wouldn't recommend this kind of verbose logging in an application either unless the application warranted it for security reasons. However, being able to leverage verbose logging when needed and without having to recompile my code IS a HUGE benefit in my opinion and if you have a framework that can allow for it easily (such as log4net), then I say get nice and verbose and it is easy enough to mentally filter out the log code references if you're having to go back into the code itself.

I apologize if I sound defensive or ranting, I don't mean that in any regard. I just wanted to provide a bit more background into how and why I setup my logging using log4net in the method mentioned. 8^D