Code to logging ratio? [closed]

Question

What is the ideal code to logging ratio? I'm not used to writing logs as most of the applications I've developed have not had much logging.

Recently though I've changed job, and I've noticed that you can't see the application code for the calls to log4net. I appreciate that this is useful but surely having too many debug statements is just as bad as not having any at all?

There are logging statements that tell you when every method starts and finishes and what they are returning. and when pretty much anything is done.

Would it not be easier to have some addon that used reflection to add the logging statements in at compile time so they didn't get in the way as you were trying to look at the code?

Also in these days of powerful IDEs and remote debugging is that much logging really nescisary?

Answer 1

Since log4net does a great job at not clogging up the resources, I tend to be a little verbose on logging because when you have to change to debug mode, the more info you have, the better. Here's what I typically log:

DEBUG Level

• Any parameters passed into the method
• Any row counts from result sets I retrieve
• Any datarows that may contain suspicious data when being passed down to the method
• Any "generated" file paths, connection strings, or other values that could get mungled up when being "pieced together" by the environment.

INFO Level

• The start and end of the method
• The start and end of any major loops
• The start of any major case/switch statements

ERROR Level

• Handled exceptions
• Invalid login attempts (if security is an issue)
• Bad data that I have intercepted forreporting

FATAL Level

• Unhandled exceptions.

Also having a lot of logging details prevents me from asking the user what they were doing when they got the error message. I can easily piece it together.

Answer 2

When you come across a bug during the beta release of your application and can't reproduce it, you know that you should have done excessive logging. Same way if a client reports a bug but you can't reproduce it an excessive logging feature can save the day.

Answer 3

I must confess that when started programming I more or less logged all details as described by "Dillie-O".

Believe me... It helped a lot during initial days of production deployment where we heavily relied on log files to solve hundreds of problems.

Once the system becomes stable, I slowly started removing log entries as their value add started diminishing. (No Log4j at those point in time.)

I think, the ratio of code-to-log entries depends on the project and environment, and it need not be a constant ratio.

Nowadays we've lot of flexibility in logging with packages like Log4j, dynamic enabling of log level, etc.

But if programmers doesn't use it appropriately, such as when to use, when NOT to use INFO, DEBUG, ERROR etc. as well as details in log messages (I've seen log message like, "Hello X, Hello XX, Hello XXX, etc." which only the programmer can understand) the ratio will continue to be high with less ROI.

Answer 4

That much logging is not necessary. There's no reason (in production) to know when each method starts and ends. Maybe you need that on certain methods, but having that much noise in the log files makes them nearly impossible to analyze effectively.

You should log when important things happen such as errors, user logins (audit log), transactions started, important data updated... so on and so forth. If you have a problem that you can't figure out from the logs, then you can add more to it if necessary... but only if necessary.

Also, just for your information, the adding logging in at compile time would be an example of what is called Aspect Oriented Programming. Logging would be the "cross cutting concern".

Answer 5

When you have a customer scenario (i.e., someone whose machine you don't get physical access to), the only things that are "too much logging" are repainting functions and nearly anything called by them (which should be nearly nothing). Or other functions that are called 100's of times per second during operation (program startup is ok, though, to have 100's of calls to get/set routines logged because, in my experience, that's where most of the problems originate).

Otherwise, you'll just be kicking yourself when you're missing some key log point that would definitively tell you what the problem is on the user's machine.

(Note: here I'm referring to the logging that happens when trace mode is enabled for developer-oriented logs, not user-oriented normal operation logs.)

Answer 6

I personally believe that first of all there is no hard and fast rule. I have some applications that log a LOT, in and out of methods, and status updates through the middle. These applications though are scheduled processes, run hands off, and the logs are parsed by another application that stores success/failure.

I have found that in all reality, many user applications don't need large amounts of logging, as really if issues come up you will be debugging to trace the values there. Additionally you typically don't need the expense of logging.

However, it really depends on the project.