6 ms·
Logging is not a panacea. It's easy to swamp useful messages in tons of noise, so just logging whatever is not necessarily an improvement. Logging means code,
by emn13 14y ago
Logging is not a panacea.
It's easy to swamp useful messages in tons of noise, so just logging whatever is not necessarily an improvement. Logging means code, and more code means more work, less readability, and more bugs. In particular, logging somewhere, sometime means I/O, which opens up a whole new class of bugs you'd rather avoid. For instance, I've seen several systems go down simply because the disk space ran out.
Logging is also slow - his example of finding a cheapest path is a good example of this. These are well-studied algorithms that explore huge state spaces. Adding logging as he suggests can easily mean the application's running time is spent almost entirely logging. This might not be an issue: maybe you don't need this very often, or maybe the path's aren't very complex, so you can get away with huge overhead because systems are so fast anyhow. But often as not, you can't. And even when you can, you might be adding a trivial DoS vector for your app, or you might be needlessly limiting its applicablity.
If you have an error, it's nice to log whatever you can to help understand it. But the benefit of understanding the odd error more easily needs to be weighed against the non-trivial costs in time, readability, maintainability, disk space and runtime, particularly if you're pre-emptively logging before an error ever occors.
- henrik_w 14y agoGood points. As I added in the comments to the post, you should be able to turn the logging/tracing on or off on a running system. Furthermore, you need to be able to select what what should be logged, for example only messages to a certain mobile phone. Simply logging everything will swamp the system. My main point was this: if you don't get the results you expected, do you know where to start looking for the problem or not? If you have no idea, then there is not enough logging/tracing present in the program.
- rumcajz 14y ago"As I added in the comments to the post, you should be able to turn the logging/tracing on or off on a running system. Furthermore, you need to be able to select what what should be logged, for example only messages to a certain mobile phone." There's little to gain that way. If the logging was off when the problem happened, you have no logs. You can switch it on and try to reproduce. However, if you are able to reproduce, you can as well attach the process to the debugger and check what's happening. No logging needed.
- henrik_w 14y agoAttaching a debugger is not always an option - if you set break-points things will start timing out. Also, you can ask operations people to enable certain logging on a system, but you can't ask them to attach a debugger.
- AlisdairO 14y agoThis depends very much on the type of business you're running. If you're creating software to run yourself, fair enough (as long as your debugger is sufficiently low overhead). If you're selling (and supporting) software for other people, on the other hand, being able to get them to turn on logging on a certain class and try again is a godsend.
- arethuza 14y agoOne useful thing to do is to actually used log files to debug problems during development and testing so you check whether they are actually useful. You don't want to be looking at the structure of log files for the first time when you encounter a serious issue in production.
- codemac 14y agoLogging does not mean I/O. Logging to disk means I/O.
- jasonzemos 14y agoLogging means a I/O operation in some way or another to observe the message. If it's not the disk, it's a buffered stream with a syscall and all kinds of slow. Any other magic (using another thread to do the slow stuff, etc) risks the log message getting lost during a crash and the whole thing being useless.
- henrik_w 14y agoLosing logs at a crash may not be a big deal. It would still be useful if you don't crash. Also, if you can turn logging/tracing on and off dynamically, the average volume of output can still be quite manageable.
- emn13 14y agoYeah, logging certainly can work fine, it's just yet another source of breakage, so it's not necessarily always good.
- perbu 14y agoYou can log to a shared memory segment. You'll need a mutex on it and a writeev call to log to it. And it will survive an application crash.
- codemac 14y agoHell - log to one shared buffer per cpu/thread, and then avoid the mutex. Apparently when saying logging doesn't require I/O at runtime, you gotta talk it out a lot more before people get it.
- Millennium 14y agoBut the point of logs is to put them in a place where they can be observed. That means I/O pretty much by definition. You might put those logs out to the network, where some dedicated logging machine could handle storing them someplace, but that's still I/O.
- perbu 14y agoYou assume that logging has happen to disk. It does not. Look at Varnish. For every request it can log as much as 400 lines. Because the logging is done to memory the cost of logging is more or less zero. And since it is a circular buffer the memory cost is fixed. Since the memory is shared and available through the filesystem the log stays around if the application crashes.