Make sense

3 Ways to Make Sense of Errors & Logging

Craig Ferril Insights for Dev Managers Leave a Comment

Errors and log files are two of the most important tools a developer have to try and find the source of a problem.  If you’re like most developers, your approach to capturing and utilizing errors and logs is fairly straightforward. You probably send log output to a file or a log aggregation product. You may notify on the occurrence of errors, either sending emails directly from your code, or via an error monitoring product.

What’s lacking from these approaches is something a bit more holistic, comprehensive, and contextual. The trouble comes in two forms:


Free Download

  • There’s often way more noise than signal if you’re solely relying on logs to track, isolate, and make sense out of your errors, especially if an error is being thrown over and over again, or if you’re dealing with log files across numerous servers
  • If you’re focused primarily on errors, either emailing on error occurrences or using an error monitoring program, that approach removes the relevant logs from the picture altogether, leaving you without the context you need to determine root cause.

In this final article of a three part series on simplifying and evolving your application troubleshooting, I’ll cover 3 ways you can make sense of your errors and logs together:

  1.      Aggregation – If you’re developing an application that runs on a single server, finding all of your logs isn’t an issue for you.  But it’s far more likely that you have applications hosted on multiple servers for purposes of availability, scalability and redundancy, making it more difficult to easily (and centrally) access errors and logging data. Tools exist to aggregate logs in various standard formats (assuming you have access ), which is a good step in the right direction, given the potential for numerous separate logging files, as well as log file rotation and retention issues. The right answer is to implement a solution that aggregates logs and errors with development in mind. That way, you can be sure you are collecting every piece of information necessary and have it presented in a way that’s geared toward developers.
  2.      Error De-duplication – While aggregation ensures that all of your logs and errors end up in a central location, that can lead to a lot of noise that hides the truly valuable insights that are hiding in your logs. Taking a step beyond simply aggregating log statements, toward deriving fast insights from your logs and errors, means implementing a strategy that de-duplicates errors and provides additional information anchored to each incident of the error, without forcing you to wade through an endless stream of error statements in a log. Treating individual errors as first-class items of interest, rather than just yet another line in the log file, gives you top-level visibility, enables you to configure effective notification and resolution strategies focused on a specific exception, and, with the right platform, gives you an anchor point for seeing only the log statements related to that error (rather than sifting through all log statements to find the ones that matter). This all adds up to a strategy that filters out all the noise and focuses your efforts in on just what you care about.
  3.      Analysis – Even if you can aggregate your data and associate the error and logging data together, you still are left with a very long chronological list of stuff your application did (and didn’t do – thus, the exceptions).  There are still several needs to be addressed before we can truly say we can make sense of this data set – issues like seeing the frequency of errors, tying exceptions on one server with methods and processes on another, being able to search quickly through this massive data set, and even just being able to quickly jump to a particular point in time – all of these, and more, need to be part of the solution to properly make sense of the data you have.

While errors and logs are often instrumental to diagnosing application issues, getting the most out of them isn’t easy. If you’re using a narrowly focused tool or rolling your own solution, it’s likely you’re either struggling to quickly get to the data you need when you need it, or you’re trying to find a needle in a haystack (or, perhaps more apt, a needle in a needle stack). Creating effective error notifications, error de-duplication, log aggregation and analysis, and seamless correlation between errors and just the log statements that are relevant presents an especially difficult challenge. Getting it right requires tremendous custom development, a mix of custom development on top of a product that offers a partial solution, or possibly adopting multiple solutions that each only solve part of the problem. That is, of course, unless you use Stackify Smart Error and Log Management!

Photo Credit: Windell Oskay