Mick McGuinness
Mick McGuinness AP co-founder & DBmarlin Product Manager

4 Scary Stats Prove why Logs are not the Answer

4 Scary Stats Prove why Logs are not the Answer

In this article we explore 4 scary statistics which prove that logs are insufficient for troubleshooting application issues in production.

Today, nearly every organisation has undergone a change in the way they deliver software to production. The introduction of CI/CD pipelines has created efficiencies that allow us to innovate faster, collaborate more easily and most importantly, remove human error, all through automation. However, avoiding the risks of increasing your release frequency can be a challenge.

But when it comes to debugging and troubleshooting our applications, we still rely on age-old technology in the form of logs!

That is not to say that logs are bad and with the advent of Log Management solutions such as Splunk, SumoLogic and ELK, the information buried in log files spread across many disparate machines can now be surfaced.

Logs alone, however, are inadequate for troubleshooting application problems since they often lack the information you need. Quite often the troubleshooting process can involve turning on more and more logging in order to solve a tricky problem and that takes a lot of time.

Here are some of the reasons, (the scary statistics mentioned in the title), why that is the case:

  1. 20% of errors never make it to the logs in production
    Research shows that 20% of catch blocks are empty! That means swallowing the exception without any trace. These are the silent killers of Java applications.
  2. Nearly ⅔ of Logging Statements are turned off in production
    INFO and DEBUG logging accounts for 57.8% of logging statements and these are turned off in production. And in pre-prod environments where these are turned on, you will probably find you can’t reproduce the issue.
  3. More than 50% of logging statements don’t include ANY information about the variable state at the time of an error
    52.2% of log messages don’t include any variables and 33.5% include only 1 variable. Considering the number of variables likely to be in scope that could have been responsible for the error then chances are, the logs won’t have the detail you need.
  4. Developers Spend 25% of Their Time on Troubleshooting
    A recent OverOps survey showed that 40% of developers spend 10-30% of their time debugging production issues while 9% reported that they spent more than 50% of their time troubleshooting. This is wasted time which could have been better spent innovating and adding that latest killer feature to your application.

For more details on these shocking stats and the research studies behind them, see the latest blog from OverOps who have a solution to this problem https://blog.takipi.com/5-shocking-stats-that-prove-logs-are-inadequate/

If you would like to hear more about OverOps start by downloading our eBook “Solving Java Application Errors in Production”

Or if you’d prefer to get started right away with a trial and start fixing production issues without trawling through log files, then click below.