OverOps #Timers

New OverOps Feature – Add Timers to see root cause information when a method’s execution time exceeds a target threshold

They say timing is everything, and even if everything in an application’s logic works according to plan, some operations may take too long to execute ruining the user’s experience. For those cases, you want to be able to have full visibility into the cause of the slowdown. That’s why we added this new feature after receiving requests for more visibility into latency issues.

When users choose to turn on a Timer and set a target threshold (in milliseconds) for a method, OverOps tracks the time it takes from when the predefined method is called to when it reaches its return statement. If the execution time exceeds the given threshold, OverOps triggers an event showing the complete source-code and variable state even if the lag isn’t caused by an exception.

Creating your first Timer

To create a Timer, go to Settings and select Timers.

Access the Timer Settings in the dropdown Settings menu in the upper righthand corner of the OverOps application

In Timer Settings, you will be able to set a Timer on any location in the code across the cluster. Enter the class and method that you want to track and a threshold so that an alert will be sent if the execution time surpasses that target.

In Timer Settings, select the method and class that you want to track along with a threshold for the execution time

Timers can also be added and edited in several places around the OverOps dashboard, including directly on an existing event.

Once your Timers are set, all you need to do is wait for them to be triggered by exceeding the predefined threshold. When a measured method triggers an alert, it will show up as an event on the OverOps dashboard with all statistics available including the complete source-code and variable state, the last 250 DEBUG-level log statements, and the complete state of the JVM memory, CPU, threads, environment and OS.

View Timer events in the OverOps dashboard with access to the full stack and variable state at the time of latency

Common Use Cases

It’s hard to overstate how beneficial this feature can be to developers using OverOps in parallel with an APM (Application Performance Monitoring) tool like AppDynamics or New Relic.

With your APM tool, you can monitor your production environments, application loads and response time. In many cases, they also provide you with the stack trace so that you can get a general direction to what might be causing a delayed response. More often than not, though, this isn’t enough to get to the bottom of what’s really causing latency issues in your application.

OverOps’ Timers feature will give you the ability to take the information you get from your APM tool about a specific method and track it so that you can see the real root cause behind latency problems in staging and production code. That means you’ll be able to see not just the stack trace, but the complete source-code and variable state at the time of the slowdown.

Events in the OverOps dashboard include the full stack trace and variable state at the time an exception occurs. Now, with the Timers feature, you can also see this information for predefined methods during a slowdown

Click here to learn more about how to set up Timers, plus add your questions and feedback in the comments below! Are you interested in getting a personal walkthrough of the product? Request a demo.

Product Manager @ OverOps