Any software engineer who has worked in a software development team or who has looked at their own code from a year or two (or ten) ago will know what I mean when I say that there are at least as many approaches to logging as there are people who log. Factor in what needs to be logged, where it needs to be logged to, who it is intended for, and whether i18n is a concern, and the combinatorial explosion can be quite amazing.
We’ve thought long and hard about this (that is our job after all), and come to the conclusion that the only approach that really, truly works is to celebrate the creativity of developers. Rather than bore you with best practices, we thought we’d inspire you with some of the most amazing things we’ve seen from the trenches. Think of this as our contribution to the worldwide brainstorming session that we’re all part of.
To whet your appetite for the eBook, here are some highlights:
Unique error codes are obviously invaluable, but rather than throw you into the maintenance hell that is maintaining your “error code catalog,” simply mash your keyboard until you have 20-30 characters. Research has shown that random keyboard mashing yields better collision statistics than MD5.
The best developers can be a little OCD, and jagged right edges on your log files can drive one to drink. Spend a little time to make sure all of your log lines are exactly the same length! If that requires padding, we suggest you use German compound nouns. As a starter for 10: Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz
Similarly, if you’re frequently tailing your log files, make them more interesting by centralizing all log output and adding white space before each line. Who doesn’t love watching their logs go by in the shape of a sine wave?
Sometimes, the wrong people can get their hands on your logs, so you need to balance understandability against security. Rather than using obvious names for your applications and variables, be creative! Who would ever guess that Cerberus is actually your secure, distributed Memcache layer on top of MySQL? Even better, rot13 everything you log! Or just the first half of each line!
When something serious happens, you may need to dive a little deeper into what is happening in your app. Rather than rely on old-school core dumps, why not just log your entire process memory in base64? That way, you can easily debug even the most complex problems.
In all seriousness, the last thing you want to be counting on is insight from enigmatic logs. That’s why I published The Pragmatic Logging Handbook, a practical resource that provides tips about how to log the right events in the right format for the right consumer.
Get pragmatic – not enigmatic – about logging. Otherwise the joke will be on you someday!