Introducing Auto-Archive: Not All Exceptions are Actual Errors

 ● 26th Aug 2016

4 min read

One of OverOps’s most powerful capabilities is its ability to deduplicate log errors and exceptions within the JVM in real-time. This means that instead of searching and querying millions of log lines to see which errors are happening the most, are new or increasing, this information is now provided directly by the JVM. Accurate analytics for each error show when it began, how often does it happen in any of your applications, and last but far from least – how often does it happen out of the calls into the code.

But that’s not all there’s to it

Last month we released a new feature which provides automatic classification of errors into categories such as new ones introduced today / this week, JVM errors (you definitely want to fix those) and also the ability to define groups of errors that are of specific importance for you.
For us at OverOps, AWS exceptions (including the notorious ProvisionedThroughputExceededException) are really critical, so we set up a special view just for that along with a Slack alert that tells our team exactly when they happen (see also how Cotiviti is using Slack integrations).
This provides us with a powerful capability to make sure our production environments are 100% clean of both code defects such as NullPointerException through the JVM view, and AWS errors through our custom AWS error view. We’ve also enhanced that with the ability to define views as either public or private – set up views for areas in the code you’re in charge of or team-wide errors such as DB, AWS or JVM errors which are critical for everyone.

Introducing auto-archive

Today we’re adding a new feature built on top of this deduplication engine that enables us to do the opposite thing – automatically muting all the errors and events we’re not interested in, using a new feature we call Auto-archiving.
With this feature you can easily decide which groups of errors you want to mute – meaning they will not appear in your dashboard or trigger alerts. For example if you’re using Hibernate and your code is throwing a large amounts of NoResultException errors that are caught by your application, you may want to hide them from the dashboard, so you can focus on new or other types of errors that are impacting your application. The same can be true if you’re trying to mute JRuby, JSP, Spring or any type of framework exception or log event that’s benign.
Using Log analytics to mute these out can prove to be a hard one – you need to create a RegEx query to identify all the types of events you want to mute which in itself can be tricky. The situation becomes more sticky if you want to differentiate between errors further such as wanting to see uncaught exceptions of this type, or those matching some other parameters that make them important (like ones coming from a critical area in the code).
Supporting this has been one of the biggest requests from our users, and we’re happy to deliver this new Auto-archiving feature to you today. The premise is super simple – you can now accurately define which errors you don’t want to see according to their type (log error, warn, uncaught exception,..), location in the code, app transaction, origin application / server and more.
It’s just one click away: simply define the filter for the events you’re not interested in and click “Auto-Archive”. From that point on these events will automatically go into the “Archive” folder, and will not appear in the dashboard. Mission accomplished!
You can see exactly which rules you’ve previously defined under the Auto-Archive folder on the left and change them at any time. You can click each folder to see exactly what’s in it, and restore the events in it back into the main “Inbox” at any time.

The before shot – noisy errors are taking most of the volume. I want them out from now on.

The after shot – I created an “Auto-archive” rule, and from now on I’ll only see and be alerted on the stuff that really matters to me.
There’s nothing we like more than delivering features quickly based on your requests, so let us know which other features you’d like us to work on – be it small or big in either the comment section below, via twitter, FB, our support site or with a nice postcard from your summer vacation – we promise to write back! 🙂

As a co-founder and CTO, Tal is responsible for overseeing OverOps' product and engineering strategy. Previously, Tal was co-founder and CEO at VisualTao, acquired by Autodesk Inc. (ADSK). Following that, Tal was the Director for the AutoCAD global Cloud and Mobile product line. Plays Jazz drums and Skypes, sometimes simultaneously.

Troubleshooting Apache Spark Applications with OverOps OverOps’ ability to detect precisely why something broke and to see variable state is invaluable in a distributed compute environment.
Troubleshooting Apache Spark Applications with OverOps

Next Article

The Fastest Way to Why.

Eliminate the detective work of searching logs for the Cause of critical issues. Resolve issues in minutes.
Learn More