I was looking for an article online that explains clearly how to idiomatically do logging in golang. What is the best practice?
This is the article that I found by googling golang logging. It turned out not to be how-to article, but rather an opinion about what should developers log when writing their applications. Here are some thoughts about the article. I agree with some of the author’s opinions while I don’t with others.
First of all, you have to understand that I spent years mainting services running on applications that other people wrote for years. Focusing on the logging part, different developers or different companies have different logging policies. Depending on the logging policy, ease of use (in my case this means ease of maintaining, troubleshooting and fixing the application when somethis goes wrong) differs a lot. My point is, the way I think about logging is deeply linked to my server/application maintenance career.
Having said that, let’s go back to the article. So the authors focuses mainly about what log levels are really needed when writting apps and implemenenting some type of logging for the app. It looks like the article itself is focused on golang, but the way it’s written makes it look like a more general opinion about logging in general. A few points:
Warnings are not needed
Nobody reads warnings, because by definition nothing went wrong. Maybe something might go wrong in the future, but that sounds like someone else’s problem.
That’s right. What does warning mean? Should I restart the application? Should I keep on monitoring the logs until something really wrong happens? For me warning has always been a confusing log level. Even in real life, I found some warnings quite confusing. In mountains in Japan, you see a lot of places with warnings like “be aware, falling rocks here” . I’m like okay, no matter how carefully I drive, there is nothing I can do if a big rocks falls on my car at full speed, I can’t even see it coming… Okay I’m not saying that that warning should not be there in the first place, I think it’s just a way to tell us that there is a danger when driving on these mountains roads. But anyways, it’s confusing.
For applications, it’s less of a danger, so I really think that warnings are not needed at all. As the authors says, either it’s an info, or an error.
However, there are still exceptions I think. It all depends on what the application does, in what environment does the application run, does it need to worry about the conditions under which it’s running? So generally speaking, warnings not a must, but look at the pros and cons, the requirements of the app, the systems it relies on, the people who will use it to make a good decision on this.
How about errors?
Two things that caught me.
Error handling and logging are closely related, so on the face of it, logging at error level should be easily justifiable. I disagree.
If you choose to handle the error by logging it, by definition it’s not an error any more — you handled it. The act of logging an error handles the error, hence it is no longer appropriate to log it as an error.
Hmmm… So logically speaking, what our author is saying kind of makes sense. But wait, for the programmer, maybe write a code to log an event that actually describes an error is handling the error. But what about the guy who is going to use your application? For somebody who’s maintaining a service that is using your application, if something bad happens the first thing to do is try to find out what happened. Knowing what went wrong is the most straight forward way to fix an issue. How do I know what went wrong? The first thing to do is abviously look at the log files. What happened before the application crashed? Given a situation like this, it would be best to know the difference between an error (something abnormal that happened at runtime ) and an info.
Let me illustrate this with two examples:
Exmaple 1
2017-12-06 23:42:22+09 hostname app1 [INFO] Application started successfully
2017-12-06 23:44:53+09 hostname app1 [INFO] Could not retrieve message id:483jei435 from database
2017-12-06 23:45:33+09 hostname app1 [INFO] Putting message to queue
Exmaple 2
2017-12-06 23:42:22+09 hostname app1 [INFO] Application started successfully
2017-12-06 23:44:53+09 hostname app1 [ERROR] Could not retrieve message id:483jei435 from database
2017-12-06 23:45:33+09 hostname app1 [INFO] Putting message to queue
If for example, not being able to retrieve the message from the database is the beginning of the an issue, one could trace this root cause easily my doing a
grep ERROR app.log
right? If the developer decided that error log level is not actually needed, how could we trace this root cause with exmaple 1? If you know the details of the app, then it might be really easy. However, in production the developer is not usually the first or second tier to investigate the issue. Somebody else will be looking at the log files. I say, errors should be meaningful, that is they happen only something went wrong, and may need some action. In the example above, even if the application did not crash, one could need to select all the messages that could not be retrieved from the database and do something about the failed transactions, etc …
Anyways, I think it’s too opiniated to say, errors are not needed. Think about the actual production environment in which the app will run, who will maintain it, a solution to easily find where a problem may have happened. There are many things, other than the code itself, to think about when desiging logging into your apps. That’s what I think… Or did I miss something in the original article?