Logging levels probably aren’t the most exciting thing in this world. But then again, neither is banking. And yet both things are fundamental to the people who use them as a tool.
Application logging is one of the most important things you can do in your code when it comes to facilitating production support. Your log files serve as a sort of archaeological record of what on earth your codebase did in production. Each entry in a log file has important information, including a time stamp, contextual information, and a message. Oh—and generally, something called a logging level.
So what are logging levels?
Well, put as simply as possible, they’re simply a means of categorizing the entries in your log file. But they categorize in a very specific way—by urgency. At a glance, the logging level lets you separate the following kinds of information:
- Hey, someone might find this interesting: we just got our fourth user named Bill.
- OH NO SOMEONE GET A FIRE EXTINGUISHER SERIOUSLY RIGHT NOW.
For the most part, this distinction helps in two ways. First, you can filter your log files this way during search. And second, you can control the amount of information that you log. But we’ll get to that in a bit.
Logging Levels: Why Do We Do It?
When it comes to logging, you have two essential and opposing forces, if you will. On the one hand, you want to capture every last detail you can because this might prove useful during troubleshooting or auditing your system. But on the other hand, all of that logging consumes resources. You can eat up disk space, overload people reading the logs, and even start to slow down your production code if you go overboard.
So logging requires either a balance or a way to get both the proverbial signal and the noise. And logging levels look to help with this by making your situation configurable on the fly.
Here’s a helpful metaphor, perhaps. Imagine you have an android friend and you ask him about what he did today.
“Well, I woke up, inhaled, moved my nose three inches to the right—”
“No! Too much information. Go from granularity 10 down to 3.”
“I woke up, had breakfast, caught a taxi…”
Usually, you don’t need to know everything the android did. But if he starts malfunctioning, you might want to go back to “granularity 10” to zoom in on the problem as narrowly as possible.
Logging levels work this way. Often you’ll only want to know if there are problems or warning conditions. But sometimes you’ll really want to dial up the information for troubleshooting purposes.