views:

125

answers:

4

This may be a stupid question, as most of my programming consists of one-man scientific computing research prototypes and developing relatively low-level libraries. I've never programmed in the large in an enterprise environment before. I've always wondered, what are the main things that logging libraries make substantially easier than just using good old fashioned print statements or file output, simple programming logic and a few global variables to determine how verbosely things get logged? How do you know when a few print statements or some basic file output ain't gonna cut it and you need a real logging library?

A: 

I know that a logging library is useful when I have more than one subsystem with "verbose logging," but where I only want to see that verbose data from one of them.

Certainly this can be achieved by having a global log level per subsystem, but for me it's easier to use a "system" of some sort for that.

I generally have a 2D logging environment too; "Info/Warning/Error" (etc) on one axis and "AI/UI/Simulation/Networking" (etc) on the other. With this I can specify the logging level that I care about seeing for each subsystem easily. It's not actually that complicated once it's in place, indeed it's a lot cleaner than having if my_logging_level == DEBUG then print("An error occurred"); Plus, the logging system can stuff file/line info into the messages, and then getting totally fancy you can redirect them to multiple targets pretty easily (file, TTY, debugger, network socket...).

dash-tom-bang
As an example, in Windows builds I can have a simple LogTarget implementation (aka "function") which calls OutputDebugString, and on a video game console I might have something which writes to the display. Both get a "default" TTY target as well.
dash-tom-bang
+2  A: 

There are used in environments where the requirements for logging may change, but the cost of changing or deploying a new executable are high. (Even when you have the source code, adding a one line logging change to a program can be infeasible because of internal bureaucracy.)

The logging libraries provide a framework that the program will use to emit a wide variety of messages. These can be described by source (e.g. the logger object it is first sent to, often corresponding to the class the event has occurred in), severity, etc.

During runtime the actual delivery of the messaages is controlled using an "easily" edited config file. For normal situations most messages may be obscured altogether. But if the situation changes, it is a simpler fix to enable more messages, without needing to deploy a new program.

The above describes the ideal logging framework as I understand the intention; in practice I have used them in Java and Python and in neither case have I found them worth the added complexity. :-(

Edmund
+1  A: 

They're for logging things.

Or more seriously, for saving you having to write it yourself, giving you flexible options on where logs are store (database, event log, text file, CSV, sent to a remote web service, delivered by pixies on a velvet cushion) and on what is logged at runtime, rather than having to redefine a global variable and then recompile.

If you're only writing for yourself then it's unlikely you need one, and it may introduce an external dependency you don't want, but once your libraries start to be used by others then having a logging framework in place may well help your users, and you, track down problems.

blowdart
+2  A: 

Logging helps debug problems especially when you move to production and problems occur on people's machines you can't control. Best laid plans never survive contact with the enemy, and logging helps you track how that battle went when faced with real world data.

  1. Off the shel logging libraries are easy to plug in and play in less than 5 minutes.
  2. Log libraries allow for various levels of logging per statement (FATAL, ERROR, WARN, INFO, DEBUG, etc).
  3. And you can turn up or down logging to get more of less information at runtime.
  4. Highly threaded systems help sort out what thread was doing what. Log libraries can log information about threads, timestamps, that ordinary print statements can't.
  5. Most allow you to turn on only portions of the logging to get more detail. So one system can log debug information, and another can log only fatal errors.
  6. Logging libraries allow you to configure logging through an external file so it's easy to turn on or off in production without having to recompile, deploy, etc.
  7. 3rd party libraries usually log so you can control them just like the other portions of your system.
  8. Most libraries allow you to log portions or all of your statements to one or many files based on criteria. So you can log to both the console AND a log file.
  9. Log libraries allow you to rotate logs so it will keep several log files based on many different criteria. Say after the log gets 20MB rotate to another file, and keep 10 log files around so that log data is always 100MB.
  10. Some log statements can be compiled in or out (language dependent).
  11. Log libraries can be extended to add new features.

You'll want to start using a logging libraries when you start wanting some of these features. If you find yourself changing your program to get some of these features you might want to look into a good log library. They are easy to learn, setup, and use and ubiquitous.

chubbard
In my language of choice (D) I feel like most of these would be trivial to implement myself, i.e. easier than finding, downloading compiling, configuring, learning, etc. a logging library. This is especially true if I only implement the ones I actually need at any given time and you factor in the value of making it do **exactly** what I want for my specific application, nothing more and nothing less.
dsimcha
@dsimcha - I agree that for the most part it is trivial to implement much of this functionality (I've done it myself several times at different employers). The problem with trivial code is that it still takes time to write, and if you want a substantial portion of the above lists it may make temporal sense to find, build, learn...
dash-tom-bang
@dsimcha you can download, learn, and configure a logging library in literally less than 15 minutes. And most of that is reading the how to. Can you really implement a logging library in less than 15 minutes that does 1/2 of the features I listed? Seriously even if you typed at an amazing speed I don't believe you. Plus once you put forth the effort to learn it you don't have to learn it again. Most of 15 minutes is just learning something new. Why reinvent the wheel for every project you start? Just adopt and start closer to delivering value and less time building support code.
chubbard
@chubbard: Because I get a wheel that does exactly what I want, no more and no less, and doesn't add the baggage of an external dependency to my project. There is always a reinvent vs. use existing library tradeoff w.r.t. these things, but IMHO the relative triviality of logging tips the overall balance in favor of reinvent, especially if you only really need a subset of these features, though if logging is included out of the box in the standard library, that might tip the balance back towards using an existing library.
dsimcha
@dsimcha I think you should at least spend some time and read about at least one library and see what it has to offer. You're obviously curious, and bothered to ask the question. Why not find out for yourself? Don't take my feature list as a comprehensive list of features. I think you'll at least find it enlightening. I just implemented my own logging library for android and adding log rolling alone was moderately involved (i.e. I spent more than 15 minutes on it).
chubbard