|
Application Logs
Are application logs good practice? By application log I'm referring to a log of functions or areas of the program that were executed. Logs of errors that have occured etc etc.
I think they would be useful in a debugging environment but not necessarily in production although I can list several commercial applications with logs.
I'd like to hear to some opinions on application logs.
Dave B.
Monday, October 13, 2003
Like most things in life, a moderate approach to logging is the way to go. I wouldn't log everything that occurs within an application, but it does make sense to log errors at a minimum. You might want also want to log database updates to some degree.
Mr. Metropolis
Monday, October 13, 2003
Most of the "enterprise" applications we work with have logs broken out by type (sql, api, error, etc.). Also, many have log levels, so minimally logged versus everything. This gives everyone options.
m
Monday, October 13, 2003
How do you debug a problem in the field without a log?
You need information to debug.
How would you debug attacks without security logs?
And logs aren't just for debugging. Weblogs are mined for a lot of good info.
coder
Monday, October 13, 2003
The problem with logging is that it can take an enormous amount of time to implement and also slow the code down, bloat the code, complicate the code, and contain bugs itself if not done right.
A good log is beautiful when trying to reproduce a problem but often the time spent working on implementing logging could be better spent on finding and fixing bugs so you don't need the log in the first place. It's not uncommon for logging to become an excuse such as refusing to look at a problem report until a log is attached or making the claim that it must be working right because the log doesn't show any problems.
On the other hand, in some cases logging is almost essential. For example, if you provide an API for customers, it can be a pain trying to understand their code when they have problems (assuming you can convince them to give you code in the first place). A log of all calls to your API (including parameters and return values) can greatly simplify support in these cases. Also, in an environment such as the web, logging is essential or you might not ever know a problem exists.
The key to logging is striking the balance between too much and too little. Too little logging and it's essentially useless -- too much logging and you can quickly get to the point where the costs exceed the benefits.
It would be nice if development environments provided better support for automatic logging. Under Windows, debug symbols and Dr. Watson logs can be a great asset if you know how to use them. I wish there was more support for things like this.
SomeBody
Monday, October 13, 2003
>The problem with logging is that it can take an enormous
> amount of time to implement
That is counter to my experience. Logging is relatively
simple to implement. There are probably numerous
packages for your environment anyway.
>slow the code down
Have the logging queued to a task that does logging
in the background. Even when doing printf style
formatting we are talking micro seconds.
>bloat the code
Logging can be done in one line. It doesn't bloat anything.
> complicate the code
Not really. Not any more than those pesky method
signatures.
> contain bugs itself if not done right.
Very seldom and you usually catch it right away. If you
follow the rule of not having active code in logging statement then you'll probably never have a problem.
>often the time spent working on implementing logging
> could be better spent on finding and fixing bugs so you
> don't need the log in the first place
This is the XP position and is one without merit IMHO
in deployed environments. Even if your code is perfect,
the environment is changing around you.
>On the other hand, in some cases logging is almost essential.
In simple programs don't worry about it. But in any
group or enterprise class system it is a requirement.
coder
Monday, October 13, 2003
How are you doing logging in one line of code? Obviously, you need at least one line of code for everything you log plus the extra space for the strings. I've seen extensive logging DOUBLE the size of the build target.
I do think that some level of logging is a good idea but it's important not to get carried away. I've introduced logging to a product that turned out to be incredibly beneficial for support so I'm certainly not saying 'never log anything'.
If you want some good examples of bad logging, take a look at C:\ on a Windows machine sometime. For some reason, certain developers have decided that C:\ is the proper place to put their log files. Winzip.log is a particularly entertaining one. Mine is about 500 KB, mostly consisting of the useful message "WzToolBar::NotifyHandler()". My favorite is some unidentifiable file called trace.txt that contains the interesting fact that "the bool is 1".
SomeBody
Tuesday, October 14, 2003
Application logs can be very useful if managed correctly. The thing to be careful about is that it's very easy for an 'application log' to become a debug trace... They're different.
I ranted about the overuse of debug traces a while ago;
http://www.lenholgate.com/archives/000033.html
The key thing to remember is that the target audience of an application log are the people that need to support the application. This may or may not be the development team. Debug tracing that accumulates whilst the application is being developed is generally not that useful as an application log for support people...
In general I find it useful for the support team to 'own' the contents of the application log. If they find information in it useful it stays, if they dont find it useful it gets adjusted or removed...
Len Holgate (www.lenholgate.com)
Tuesday, October 14, 2003
>How are you doing logging in one line of code?
In C++ :
log(code, "this is a object=" << obj1 << " another=" << obj2);
That task id, line# etc are automatically set.
>I've seen extensive logging DOUBLE the size of the
>build target.
If i can do it in embedded systems with limitted
memory i'm sure it can be done elsewhere.
If you are saying don't go overboard, then we can
agree. But the don't log, fix bugs instead , is
far more dangeous than too much logging.
coder
Tuesday, October 14, 2003
>If you want some good examples of bad logging
That fact that some people do some things badly
has nothing to do with what you should or can do.
This should be some sort of falacy.
>The thing to be careful about is that it's very easy for an >'application log' to become a debug trace...
The keys are resource constraints and having separate logs.
If you want a log just for customer related items then
great. More debug related to the event can be put
in another log. The only reason not to record the trace
of every action in a program is simply resources.
>If they find information in it useful it stays, if they
>dont find it useful it gets adjusted or removed...
When trying to find a serious problem everyone gets
pulled in. Different data will mean different things to
different audiences. A register value means a lot to
some people, but means nothing to me, etc.
coder
Tuesday, October 14, 2003
Ah logging, a topic near and dear to my heart. I use a logging class that I've been developing since 1998. I take it with me from project to project, and incorporate it into whatever I'm working on. As you can imagine, it's pretty robust, since I've been using it in virtually everything I've done for the last five years. Here are my observations.
First, (obviously) get or make a good logging class, and use it in everything you work on. If it's "too hard" to include in your existing software, then you know where you need to start with improvements to the logging class!
Second, I don't agree with taking a moderate approach to logging. Log everything that doesn't *measurably* slow down performance *significantly*. Yes, I'm advocating slightly slowing down performance (gasp!). In my experience, users don't generally care if it takes 0.75 seconds versus 0.70 seconds to complete some task; but if you can fix a bug in five minutes using your log, as oppossed to two days otherwise, they seem to love that (go figure). If we're honest, most of the pressure to make our programs faster is not coming from the users.
Does my logging class make my executables bigger? Yup. But in my environment (Windows), so what? The benefits outweigh the disadvantages by about a factor of 1000. I can find virtually any bug in one of my logged programs almost instantly by looking at the log. Hunting bugs in an unlogged program is for amateurs; I don't like to waste my time (and the customer's money) that way. Each saved hour of my time can be used to buy a user a 120 Gig drive on which to store the logfile (and my "bloated" executable).
The idea that logs are not useful in production seems odd to me. Where else *would* they useful? In the debugger I can *see* the bug - why would I need a log? Logs in production are a wonderful, wonderful thing.
Logging by severity levels is something that always *seems* like a good idea when you're starting out with a logging class, but two factors make it a waste of time, IMHO. First, processor and disk speed has progressed to the point that only logging "critical"-level messages to save on performace is no longer much of a factor. I mean, how long does it take to write 80 chars to a file nowadays? Second, the minute you set the logging level to "critical", sure enough some user will have an error that would have been trivial to debug, if only the logging level had been set to "Lowest".
Having said that, though, it *is* very handy to log by *error type* - fatal, warning, info, or whatever lingo you prefer. I've never tried logging the "flavor" (SQL, API, etc.), and I'm not sure I can imagine a scenario in which having that info would help me. Probably depends on what you're doing.
"SomeBody"'s objections to logging strike me as straw men. Yes, a good logging class can take an enormous amount of time to implement; personally, that's why I started five years ago. Slowing the code down, and the old reliable bogeyman "code bloat", I've already addressed. What about the fact that the logging class can contain bugs itself?
Well, sure, all code contains bugs. But a logging class is not going to present you with mind-numbing scenarios that require an all-nighter to figure out. It's just a logging class, after all. No, the kinds of bugs you will encounter are (based on my personal experience) either (a) dereferencing NULL pointers like an idiot, and (b) formatting/data type issues, like sending an "int" to an "sprintf"-type function, but using "%s" instead of "%d". Both types of bug are instantly fixable.
"... often the time spent working on implementing logging could be better spent on finding and fixing bugs so you don't need the log in the first place." I totally disagree; this sounds like extreme cowboy optimism to me. Years of actual practice have taught me that logging makes debugging easier by several orders of magnitude. And implementing logging is not hard; someone already supplied a one-liner.
"It's not uncommon for logging to become an excuse such as refusing to look at a problem report until a log is attached or making the claim that it must be working right because the log doesn't show any problems." Well, the former is quite reasonable: how hard is it to email me the damn log? The latter is something only a retarded monkey would ever say; flog them until they stop, or hire less retarded monkeys.
Some features that I've personally found useful in a logging class:
o Make it easy to find error-level messages in the log; for example, tag them with "$E!".
o Make the logfile "circular", in the sense that, at program startup, the file is truncated *from the top* to stay within a specified maximum size.
o Have an API that will return the last line logged. This is handy for using that text in a message box, for example.
o The fields that I've found useful to log are the timestamp (down to the millisecond), the process id, the severity, the source code filename and line, and the message itself. There's lots of other things that could be logged each time, but these meet my needs; your mileage may vary.
Grumpy Old-Timer
Tuesday, October 14, 2003
> Second, I don't agree with taking a moderate approach to logging.
I agree with this, and with most of Grumpy's other comments.
Generally, logging helps a lot more than it hurts.
I prefer the open source logging toolkits, however.
Portabella
Tuesday, October 14, 2003
 Recent Topics
Fog Creek Home
|
