You are gonna make bugs and they are gonna end in production. That is the fact. Now the question is did any of You ever had to read bug report from customer about what they did to produce that bug? Most of the time is a mess isn’t it? You can’t relay on that. You need your own trace of steps of what customer did in order to solve the issue quick. Hence we introduced logging.
Nowadays a lot of languages and platforms have auto logging of exceptions if they happen, but that is really not enough. First of all you don’t want to have uncaught exceptions being thrown around in you application. Second things is that sometimes just having exception messages is not enough. You don’t want to log only fatal fails. Other part of application before the fatal error occurs should be logged.
I was working on application 5 years ago and we had one customer that was always hitting one bug and only he was reporting it. All of his explanations to us about the bug and steps he did to produce it over the emails and phone was not enough for us to reproduce the issue. So we had to send a developer on sight to see it first person. Of course customer was doing some weird stuff with the application before hand that he never mentioned because he thought they are not important, but imagine how crazy it is to send a developer to see the issue on customers machine. What happens when you have several customers, spread all over the world. That is not solution. If we had correct log system set up on application we would have seen the problem even before the customer realized it’s a bug.
The point of this is to log all actions that can lead to a problem, not just a problem. That’s why we have several log levels, sorted by priority.
- emergency – This means system is unusable. Emergency level should never be triggered.
- alert – Action must be taken immediately. For example, website is down, database is not responding, etc… If this log is triggered, SMS alert should be sent to You.
- critical – Situation is critical, for example, one of your components is down, which is triggering an exception.
- error – Runtime errors that usually don’t require immediate reaction, but should be logged and monitored.
- warning – Unexpected occurrences that are not errors like using deprecated API, using undesirable things that are not necessarily wrong.
- notice – Normal but significant events.
- info – Interesting events.
- debug – Detailed debugging information.
One of the most important part of logging, which is sometimes overlooked, is security. When it comes to security logging is critical. It has to be done right. If user is doing something that is not what regular users do, you want to log his actions and his data (IP address, username, etc..). Especially if he manages to break the app, you want to have his exact steps traced back so that you can fix the issue. Miss-configured software that we use is also a security problem and with logs we can see if something is not working properly. Logging is so important to security that PCI DSS puts a big emphasis on it on their yearly inspections of the companies.
Logging is important part of analytics also. If You want to improve Your website or application, You can log what user clicks most often, where his pointer spends most of the time, and all kinds of things that can help you improve user experience. Just don’t use logging to intrude on users privacy, all data should be collected and stored anonymously.
Final though is that when ever something significant happens log it. Log flow of the app so that you can have better idea how Your software is used. Set your log service respecting the eight logging levels and as a consequence, have a more relaxed and stress free life.