There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.
If this question can be reworded to fit the rules in the help center, please edit the question.

11 Answers
11

For the work I have done largely embedded applications, logging in an invaluable tool. At a minimum errors need to be logged with enough information to point to the line of code. Next, would be major function points across the application. Things such as the admin accessed the machine. We use a system that allows us to enable more verbose logging. This is usually developer specific. It may be used to assist the developer during testing of the feature or it may be to assist in diagnosing a customer problem.

I have personally used logging in all application I have developed. It has always led to a better understanding of flow of an application. Especially when in the hands of a customer. They never (rarely) limit their use cases to those you test against.

I don't think it depends on the kind of application: logging is useful in all (non-trivial) applications. Certainly, I guess, it can be more useful in some applications than others, but I don't think it's ever useless.

In particular, in the case of an error, a stack trace will tell you the state of the program at the exact point of failure, but you've got very little clue about the state just prior to the error. That information could be very useful in tracking down the problem, and logging can provide a useful insight into that. I think that's something that all but the most trivial of programs can benefit from.

Another use of logging, that might not be useful for all programs, is in statistics analysis. For example, your web server typically logs every request that comes in, and then there are many tools which can analyse those logs and produce graphs of your busiest times, most popular pages and so on. You can use that data to do capacity planning ("do I need a bigger server?") and so on.

In most server tasks logging is crucial, since the admin usually isn't there when things happen, so he has to check after-the-fact.

But, a guy at Google told me once that their server processes don't do logging; instead, they're 'instrumented'; that means that every process has hooks or ports (he didn't specify the mechanics) where other processes can latch to ask for parameters, and statistics. It's those monitoring processes that store lots of things to the logs, the advantage is that the information they get isn't "open a file", "write this", "fetch that"; they get things like "45,453 files open", "653 clients of service X", "344ms average response for query Y"

Certainly is a different approach, and one that I tend to keep in mind as I babysit my systems, even if they're some orders of magnitude smaller.

Diagnostic logging has been discussed by others already and I won't belabor the point much more. I'll just say you should strongly think about what happens if there's a log failure? Do you care enough to throw an exception up through the app or manage it another way? This is an "it depends" but logging info level messages probably should be skipped.

Audit logging is a business requirement. Audit logging captures significant events in the system and are what management and the legal eagles are interested in. This is things like who signed off on something, who did what edits, etc. As a sysadmin or developer troubleshooting the system, you're probably only mildly interested in these. However, in many cases this kind of logging is absolutely part of the transaction and should fail the whole transaction if it can't be completed.

Thinking about the two separately is helpful for me not only because one is "optional" and the other mandatory, but because depending on requirements, I may actually need to implement them separately. It can be a case (sometimes) that they are both fruit, but one is apples and the other oranges. Usually, a single logging framework can handle both though.

Sure, logging exceptions is great; but why log them to the client's machine when you can just email the exception to the dev team?

Logging information easily turns into an addiction whose value is rarely justified. For every situation where you can log gratuitously, it's better to collect targetted information and send it where you need it to go.

Can you still email them if your application crashes?
–
PemdasJan 16 '11 at 23:11

1

What if email is down?
–
user1249Jan 16 '11 at 23:30

2

what if the machine it is running on doesn't have an internet connection?
–
PemdasJan 17 '11 at 1:48

2

I don't believe that, which is why I am giving you a hard time. You basically said that all logs should be emailed to the dev team, which is frequently not possible.
–
PemdasJan 17 '11 at 2:09

2

@Pemdas It's simple: Where you can do it, it's preferable to just willy-nilly logging everything and not sending it to anyone. Logs only mean something if someone regularly checks them, and only if they're logging just enough to be useful. Too often I see developers log everything, and not even look at it. Shameful, really.
–
George StockerJan 17 '11 at 4:07

Capturing exception information is a must because it can be very helpful to some extent. But sometimes exception information is not enough especially if application user/client can't report an error with proper information.

Is logging limited only to capturing error information?

In my case (web application), I always log which page is visited, when, what they click, where the ip & browser, etc. I even log total load time for each page visit, so that I can know which pages are slow and need optimization. so I can say that I log as much as possible.

at first, I had no idea how significant it will be. but apparently it is very helpful in many things (other than debugging):

understanding user's behaviour

evaluating new feature's acceptance

distinguish between early adopters, scammers or potential customers

I think, logging can become more significant if we love digging out statistic informations in it.

Logging is useful for the information you cannot get by other programs:

Capture stack traces (you got that one)

Capture what data was being processed when your application crashed. Remember, debuggers only help if they are present when the crash happens.

Profiling information. If you cannot run a profiler on the production environment, extensive logging including timestamps can help you figure out where the time went. Even not being able to tell might help you identify that it is outside your program (e.g. garbage collection kicking in).

Statistics not being expected when writing the program. I have been asked to provide graphs of behaviour over time for intervals interesting for other reasons. The necessary data could be extracted from the log files with a bit of grep+awk+perl ninja tricks.

Note: You want at least TWO log files.

One at DEBUG level - providing all the information you can possibly imagine you will ever need (including INFO and above). If that is much too much, then consider having an additional TRACE level.

One at INFO level - providing the 10000 meter overview of the system. Important milestones go here.

The INFO one is always on. The DEBUG one is on when needed.

Write logging code anticipating that you may one day have to debug a situation where ALL you have is the log file, and doing it right may be the difference between getting fired and getting promoted.

For the extra mile, have all function calls add their parameters to any stack trace, in Java with

+1 for "Write logging code anticipating that you may one day have to debug a situation where ALL you have is the log file, and doing it right may be the difference between getting fired and getting promoted."
–
MarcieJan 17 '11 at 20:02

I'm a developer in a company whose products are deployed overseas. When a support team comes in asking about a problem definition, my only tools for diagnosis are my log files and a copy of the customer's database. Using the database and my development environment, I have the opportunity to reproduce the erroneous case, because I log the incoming data to my module and the related actions. If I can reproduce the error with the help of the data I gather, then I can fix it with debugging. If I had no log files, then I would have to depend on the customer's or the support team's description of what happens in what case (which has a big chance of misleading).

Secondly, logging gives me the chance to detect the bottlenecks of my module at the deployed site, since I log the date&time of certain actions and then I can have a look at which action consumes how much time.

In addition to that, suppose our solution consists of 6 modules and I'm seeing error logs in my log files about database timeouts. If these errors are logged in 5 of the other modules too, then the probability that this is an SQL server related issue gets bigger. If this is logged only in my module, then the probability that my queries are buggy gets bigger. I think these kinds of things are useful indicators.

About what kind of data I see in my log files depends on the configuration of the log level. If this is a new product, we set the log level to "All" to gather as much data as we can. But when we improve the product, we may prefer to keep the log level at "Error" to log only the error, but not the information level logs, etc...

If you are writing a stand-alone desktop application, such as a word processor, then you probably do not need any logging.

If you are writing an embedded system, then you cannot live without logging. Otherwise, when your embedded device freezes up, you have no idea why. You also need logging whenever your system involves multiple processes or multiple physical machines communicating with each other. Again, when the system hangs, you need to know which part of it died when and why. You need to be able to compare logs to determine whether or not the data made it across from one process to the other. By the same token, you need logging whenever your system is meant to run for extended periods of time without much direct user interaction.

Logging is always useful. But when implementing be aware it isn't necessarily you, who is going to read the logs. Perhaps it is some sort of an admin, an end-user, a customer, a support team, ...

So do not only log stacktraces, but also some additional information which can be interpreted by non-developers. When your application is maintained by some other groups, it is also helpful, to write some unique error codes to your logs. This might ease support, automation, ...