Introducing Automated Enterprise Routing: Finding the Right Person for the Right Bug

 ● 22nd Dec 2016

5 min read

Assigning the right bug to the right dev just became a whole lot easier

One of the main key points we focus on here at OverOps, is being able to cut through the operational noise of millions of shallow log events. By doing that, we’re able to filter out the most critical issues, and proactively alert the right developer with a much higher-depth of information.
Let’s see how OverOps Enterprise Routing solves this problem.

Automated Error Routing

The issue routing problem revolves around 3 main points:

  • De-duplicate all events
  • Filter out all the noise
  • Alert the right developer about what’s relevant to him

Log files contain millions of lines, and sifting through them in order to find the most important issue usually takes a lot of time. And even if you do find what you’re looking for, how can you find the right developer to handle it?
We’ve made it easier for you to assign the right exception, bug or any issue to the right team that can handle it. Meet Enterprise Routing.

Reducing Log Noise Through Custom Views

Enterprise Routing takes us a big step towards reducing the noise from the logs, and helps in delivering the right notification to the right developer. Even if the company has hundreds of developers and engineers that are in charge of the code.
This new feature significantly strengthens our capabilities that enable users to filter out noisy information, and control the exact channels and rules by which an alert is sent through.
What powers these new capabilities is our “Views Engine“. A view is essentially a query you can make using our dashboard. Such a query can be:

  • Show me only AmazonExceptions
  • Show me all events from the “consumer” microservice
  • Show me all events coming from user-facing Servlet transactions / entry points in the app

As we prepared the ground for this feature, we added the ability to filter events by pattern keyword search (e.g. all events whose pattern contain the word – “Salesforce”). We also added the ability to filter events by the code package, in which their containing code is defined (e.g. show me only events coming from code in the “com.acmecorp.db_layer” package, as that is the layer in the app of which I’m the owner).
Once a filter is defined, with just a few clicks it can be saved as a persistent View which acts as a “saved search”. This view can either be private or shared with the team. Views are visible in the “Views” pane to the left of the events chart / grid in the dashboard.

View examples: Last day, NPE+AMAZON, etc.

View examples: Last day, NPE+AMAZON, etc.

Once a filter has been saved as a view comes the fun part – now you can take actions on it. These actions include creating an alert and setting where the alert goes to (e.g. alerts in this view should go to this JIRA project, or that Slack channel).
Alternatively, you can mark events in this filter as benign or noisy, hiding them from the dashboard (e.g. “I’m using the Hibernate DB library and it throws a lot of uninteresting caught exceptions – filter them out – they’re very noisy”).
You can filter out data by simply defining a filter in the the dashboard and clicking “Hide” in the grid toolbar. You can also create a set of saved filters / views, and define what happens when a new error matching that filter is introduced into the system -> if and to whom should an alert be sent.

The Auto-hide UX enables users to filter out noise quickly

The Auto-hide UX enables users to filter out noise quickly

Making Routing Smarter

A very practical example for this filtering option would be that of a microservices application, which may contain dozens of microservices owned by different teams. With Enterprise Routing, each filter / view you define (e.g. “show me errors from these three microservices – “data-broker”, data-publisher”, “price-calculator”) can have its own alerting rules.
For example, users can define:

  • Any new error in the “publisher” microservice goes into this JIRA project
  • New errors from the “credit card processing” package in the code go to team A’s Slack channel (vs .team B’s)
  • An increase of Amazon errors beyond threshold X goes to this Hipchat room.

This creates a very strong mechanism, by which large organizations can very easily map out where events and alerts go to – ensuring the right people get the right alerts.
The experience is very easy to use. After creating a filter in the dashboard, save it as a View and the new “alerting-wizard”, accessible by clicking the “Save View” button in the dashboard grid toolbar, will pop up.


The new Alerting UX enables users to easily control where alerts for a specific view are routed to (JIRA project, Slack channel etc..)

This wizard lets you decide whether to send an alert into one of the default channels, or select a specific JIRA, Slack or Hipchat channel into which alerts affecting this view will be sent to.

Automated Error Routing is just around the corner, check it out.

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