So we\'ve discussed logging in passing at my place of work and I was wondering if some of you guys here could give me some ideas of your approaches?
Typically our scenar
Is it better to go all the way and log everything across multiple attempts/days, or log only what you need to (given hdd is cheap).
The fact harddrives are cheap really isn't a good reason to verbosely log everything possible, for a few reasons.. For one, with a very busy application, you really don't want to slow it down and tie up disc-writes writing logs (harddrives are pretty slow). The second point, and the more important one - there's really very little to gain from terabytes worth of logs.. For development, they can are useful, but you don't need to keep more than a few minutes of them..
Some logging is of course useful, having different levels is about the only way to go about it - for example debug() info() only get logged if requested (in a config, or command line flag), then maybe warning() and error() get sent to a log file
For most of the things I've written (smallish scripts) I generally just have a debug() function, that checks if --verbose is set, and prints the message.. That way I can shove debug("some value: %s" % (avar)) when needed, and not have to worry about going back and removing debugging print() statements everwhere.
For web applications, I generally just use the web-server logs for statistics, and the error log. I use things like mod_rewrite's log when needed, but it would be idiotic to leave this enabled beyond development (as it creates many many lines on each page request)
I suppose it depends on the application itself, but generally, for big applications use multiple levels of logs that can be activated when needed. For smaller things, a --verbose flag or equivalent, for web applications, log errors and (to a point) log hits.
Basically, in "production" log only the information you can use, in development log everything you could possible need to fix problems.