Why Isn't Logging Obvious?

Logging is an assumed easy win. Logs just appear. However, when prod has its first incident, diving into the logs often turns into a mess of finding various system components, deciphering confusing log lines, and trying to piece together enough data to replace missing logs. Why don’t we log well?

Logging, to most devs and ops folks, is an assumed easy win. Logs just… appear. However, when a new product has its first incident, diving into the logs to do troubleshooting often turns into a chaotic mess of finding various system components, deciphering confusing or vague log lines, and trying to piece together enough data to cover systems that were missing logs altogether. Why don’t we log well?

Let’s break down some of the assumptions many of us have around logging, discuss how we can make logs more useful, and attempt to answer the question of why logging–and logging well–isn’t obvious.

Logging isn’t always intuitive. It takes planning to do logging well. We have a lot of assumptions around logging, and we need to examine those assumptions to understand how we can find a shared common communication across teams.

While I work for a logging management provider, I will not be mentioning LogDNA in my talk other than saying I work there in an intro (I probably will be wearing a LogDNA shirt, though, and may have their logo on my slides somewhere tiny since they’d be paying for me to be there). I want to make clear that this isn’t a vendor pitch. I just like to talk about logging.