I've never written programs which make significant use of logging. The most I've done is to capture stack traces when exceptions happen.
I was wondering, how much do other people log? Does it depend what kind of application you are writing? Do you find the logs actually helpful?
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.
There are two reasons logging is performed:
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.
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.
I came from a winforms N-Tiered application that logged everything.
It wasn't very useful.
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.
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):
I think, logging can become more significant if we love digging out statistic informations in it.
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, ...
Another point from an admin perspective: Think about log rotation.
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...
Logging is useful for the information you cannot get by other programs:
Note: You want at least TWO log files.
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
public void sendEmail(String sender, String recipient) {
try {
...
} catch (Exception e) {
throw new RuntimeException("sendEmail(sender="+sender+", recipient="+recipient+")");
}
This approach essentially enhance your call stack with parameter values, and may allow you to analyze the situation just with the stack trace and not having to see the log files.
It most certainly depends on they type of system you are building.
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.
I would also recommend that all non-trivial app employ multi-level logging.
For the reasons others have stated, it's an invaluable tool for solving problems with the application.
In some cases, logging is essential, for example in financial applications and other domains which require activity logs, for security, usage metrics and auditing.
