The importance of good logging
Lately, as you may have noticed through my other posts, I’ve been doing a lot of migration and DevOps. I’ve had my fair share of problems and the fact that I was able to skim through the logs for clues helped me put everything into production.
I want to discuss in this post the importance of good information logging whether it is general information for the user or errors occurring in the application.
Often we see applications not having any logs or the logs they provide are poor in content. Every system is different; not every system is configured the same way and/or has the same applications installed. Here are some points that should be followed by every developer when it comes to logging.
1. Do log
This is trivial for some, but not applied enough. You should not suppress your exceptions and you should alert your user (if needed be) when something critical happens. This can help the user make sure he/she runs your application in the best state possible. You want your users to be reactive. When you suppress your errors, you are hiding what could potentially be a disaster waiting to happen. You want your users to continue using your software, not stop using it because something happened. They won’t have trust in it anymore.
You should also log informational messages that could help you see patterns and potentially enhance your application. This can also be useful for you to understand the system in which your application is running if ever you need to debug something. Like I mentioned earlier, every system is different.
2. Log useful information
I’ve seen in the past that some people were logging too much information. Having too much information in the logs is hard for a user to understand what is happening (or has happened) because he/she has to skim through the log and decipher what has been logged. Always ask yourself this question when considering if you should log a piece of information or not: if you were to read it, would you find it useful? Could it help you fix a problem? Could it give you insight on the system and the application state? If some of your answers are no, then don’t log it. It won’t be useful for anyone else and only creates noise.
Understand the level of logging (INFO, WARNING, ERROR, FATAL) and use them according. I can understand that not everyone may agree on what exactly goes into those logging types, but you have to go with the majority. If most of your team is okay with your definitions, go with that.
3. Do not log pieces of information everywhere.
Try to pick where you log your information. You may want to log more serious information in the Windows Event log or syslog default messages, but consider logging information in a centralized place using readable text (meaning and obviously don’t encrypt your logs!). When your users try to analyze what is going on, if everything is in the same place, they much quicker can get a grasp of the symptoms. When you information all over the place, it is hard to understand the big portrait of a situation.
4. Provide a section for a user to export logs
I’ve seen this in some applications I’ve used in the past. It had a support section for users and would allow them to export a compressed set of logs. The logs consisted of different information about the system and the pieces of the application that they deemed important for their analysis. They thus can go over this information and try to find clues. This can be very useful when the user does not have physical access to the server/machine.
5. Provide some documentation on how to access your logs
Help your users know where they can find all the useful information so that they can monitor your software. Some may want to create custom alerts by writing custom scripts to alert them. Some may want to check them once in a while to see if there’s something critical they should be aware of and act.
Conclusion
Some may argue that logging is expensive. It could be; but it all depends on how you do it. It is far worse not logging anything and not able to fix a problem for a user than logging and losing a little bit of performance (which in my opinion is negligible if you don’t log every single action).
If you want to alleviate the user from skimming through the logs, try developing a health check system that checks certain important aspects of your applications. It could be done in the background at once at startup and at predefined intervals.
Hopefully these points can help us create a better sense of peace for our users when something happens or help us enhance our applications by finding information that we wouldn’t have seen otherwise.
Update: 2017-03-16
I want to add on this by providing concrete implementations of logging for ASP.NET Core
Here are some excellent articles on how to integrate certain logging facilities into your application:
Gunnar Peipman posted on how to integrate SysLog logging for users who have ASP.NET Core applications running under a *nix distribution: http://gunnarpeipman.com/2017/03/aspnet-core-syslog/
Damien also posted on how to integrate elmah.io (ELMAH stands for Error Logging Modules and Handlers) : https://damienbod.com/2017/03/16/asp-net-core-error-management-with-elmah-io/
He also posted on how to integrate ElasticSearch and NLOG: https://damienbod.com/2016/08/20/asp-net-core-logging-with-nlog-and-elasticsearch/
Hisam Bin Ateya posted on how to Integrate JavaScript Logging with ASP.NET Core Logging APIs: http://www.hishambinateya.com/integrate-javascript-logging-with-asp.net-core-logging-apis
