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
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.
...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
You are right that this does make the code more difficult to read and maintain. One recommendation is to consider looking into an AOP (Aspect oriented Programming) tool to separate your logging logic from your application logic. Castle Windsor and Spring are two that come to mind within the .Net community that you may want to research.
From a security standpoint logging can be an interesting topic. I wrote a blog entry on CSO Online a while back in the wake of a couple of DDOS attacks. This is the section where I talked about logging, hope it helps a bit:
Techniques such as log throttling, write only logs, and using log servers can strengthen the retroactive security of a system. After a possible DDoS attack has occurred the company will no doubt want to investigate the attack. An investigation is only possible if the correct level of logging has been used. Too much and the logs will quickly become filled, which could be the reason for the DoS in the first place. Too little and the logs will be worthless because they don’t contain enough information to catch the criminal.
At a bare minimum you should log errors and calls to external component... The sample you provide is what I would call TOO much loggings... There is no point of logging that you're in a start of a method, or in the end of a method, or even the params that were passed to the method... Its a waste of disk space, You log file will get very big in no time...
It is not easy to decide how much logging is enough. Too much logging code in a function as in your example buries the actual logic code. Too many log entries makes the log noisy. But too little of logs is not very helpful!!
For .NET, you can use the AOP library, PostSharp, to help log the entering and exiting of a function together with values of the arguments and more.
For help with determining how much to log your application, check out this article "System Logging and Log Analysis" by Marcus Ranum.
Hope this helps.
来源：https://stackoverflow.com/questions/231903/how-much-to-log-within-an-application-and-how-much-is-too-much