I’ve seen a bunch of production killers caused by debug logging.
Why does debug logging suck? Because it’s debug, stupid:
1) It’s usually extremely verbose.
2) It opens you up for potential security violations. Who know what that contractor put into a debug statement?
3) It’s not meant to be performant. In other words, it’s slow. Like sloth-slow.
The only time you should ever use debug logging is during development. Even then, debug logging just means “I was too lazy (or proud) to step through my shitty code in the debugger”. It’s logging overkill. Most of the problems I’ve seen are caused by different threads all trying to access non-threadsafe code at the same time.
Either way, logs fill up with useless crap. That crap fills up your disk, etc. It marginalizes the stability of your software. So following are few quick pointers.
- Never let your users know it’s available. Once you do, it’s on forever.
- Better yet, just don’t create debug log messages. Do one of these instead:
- Create a no-op method for your debug messages in production. Use a “Production” configuration tag to determine when your code is in a production environment. Don’t log when in production mode. [Good]
- Create a single logging class and always use it. Compile out the debug messages when building Release software. [Better]
- Create integrated performance counters in your code that instrument key metrics like methods calls /sec and average method call execution times. Identify and instrument the key methods in your software. This way, you can track your software performance in real time, regardless of your environment. [Best]