So, what exactly does OverOps do?
OverOps pinpoints the exact cause of critical exceptions in your application with the variable state for context. Armed with that information, you don’t have to waste countless hours on detective work sorting through logs or your APM to figure out what happened with your application and what precisely needs to be fixed.
For example, a programmer typically sees an exception with the related stack trace like the following. The stack trace does not show you a lot of information to help pinpoint what and why an exception was thrown in your application. In some cases you might be lucky enough to have logged the relevant information in your log file, but in most cases it’s either not logged or not relevant.
OverOps provides you with all the information you potentially would need to actually solve the problem.
- Without any foresight (no need to add additional logging statements, change code, add debug statements)
- No need to redeploy your application for troubleshooting purposes
- No need to increase your logging or try to figure out how to recreate the problem
- Fits within your existing processes and tooling — and ultimately actually improves your processes by enforcing quality gating before code promotion
Source Code View with variable and associated state
This is what the stack trace screen equivalent looks like in OverOps:
From left to right:
- The stack trace with indicators of your entry point, where the exception was thrown and where it was caught
- Shows the source code, frame over frame
- The variable state for each of the frames. Sensitive information is redacted
In the stack trace example above, the exception/stack trace complained about an unparsable date. Looking at it in OverOps, you can see that the code is checking a different date format than what is shown in your dateString variable.
Source Repository Integration
When OverOps is integrated with your repository system (Github, Gitlab, Bitbucket) we can even tell you which commit statement and which lines of code were changed and by whom.
When exposing the variable data, we provide a full set of data redaction features out-of-the-box which can be customized and enhanced to meet your needs. As such, no sensitive information is available or can be shared.
Independent of your logging level settings, we catch all of your logging statements. So even if logging is turned off in your production environment, you will be able to see them in OverOps. This illustrates a superior level of insight into what your application is doing, without having to pay the typical performance tax when logging is turned on.
Sometimes the issue is not code-related but environment-related. We provide access to all environment-related information without you having to make any changes in your code or application.
Uncaught and swallowed exceptions
We capture all exceptions including uncaught and swallowed exceptions and classify them accordingly. That allows you to also see exceptions that typically are hidden from you and which may potentially cause issues you are not even aware of.
Are you wondering how many NullPointerExceptions, IndexOutOfBoundExceptions or IllegalArgumentExceptions you have and what is causing them? Now you can find out.
We also capture all relevant statistical information about the events including:
- How many times these issues occur
- The error rate of each event
- When it was first seen and last seen
- Which deployment introduced these events.
You might be surprised how often certain errors might occur in your production system. We have seen where some errors occur 100+ million times within 24 hours and 1 billion times within a week!
Even if you don’t have 100+ million errors, in general you should be keeping an eye on what impact these higher volume errors might be having on your resources (CPU, Memory, Disk – when logging- A.K.A.”performance”), and the associated costs, especially when running in the cloud.
If you are used to troubleshooting issues via your log files and are using log aggregators, OverOps provides you with “tiny links” in your log entries. Those allow you to jump straight to the event within OverOps. The link provides you all the context around this log entry to help you resolve your issues much faster than using traditional methods.
When a new version is deployed, we can show which events never occurred prior to this version. This tells you that these events were introduced with this new version so you can quickly review them and determine what is causing them. In this way, you can fix them before they potentially impact any of your customers.
This is a great feature when using OverOps in your pre-prod environments or as part of your CI/CD pipeline process. You can even make your build process fail if this occurs to ensure you release good quality code to your production environments. Be sure to provide deployment information to use this feature!
OverOps can also be integrated into your CI/CD solution like Jenkins. You can add OverOps Quality Gates to your process which would allow, for example, to fail builds based on criteria such as how many new errors were encountered. These thresholds are all configurable.
Static Code Analysis example, with SonarQube
If you use a static code analysis tool such as SonarQube, OverOps can be integrated with it so that you get a complete view of your code through both static (e.g., SonarQube) and dynamic analysis (i.e., runtime with OverOps). Beyond just doing a static code analysis of your code, OverOps adds context on issues driven by runtime data issues in your code. You would never get this insight doing static code analysis alone.
OverOps allows you to continue to accelerate innovation, without sacrificing quality. If you have further questions, reach out here for a guided tour or to request a consultation. And learn how companies like Comcast and British Telecom rely on OverOps to ensure their customer-facing applications remain reliable.