New OverOps feature: Public and private views
Yogi Berra once said – “You can observe a lot by watching”, and what’s true for Major League Baseball is more than certainly true for DevOps nowadays. Our main challenge in building and operating complex applications is to watch the right things – be it something that we broke in a recent release, or a web service that’s no longer playing well with our application and causing us some major heartburn.
OverOps’s goal is to help you see the cause behind issues that impact your application in production with the full source code and variable state leading to them as quickly as possible. The challenge is with applications firing thousands or millions of errors over the course of a day to distill and classify them into meaningful numbers. Things become especially challenging when classifying these errors requires parsing them out of our log files, which requires tremendous amount of work and configuration to deduplicate into something you can consume.
— Takipi (@takipid) August 18, 2016
TL;DR: watch the 30 second video
Real-time log deduplication
To overcome this, OverOps uses JVM micro-agents to detect and deduplicate all errors and exceptions at the code executes in real-time vs. parsing them from logs as an infinite stream of unstructured log messages. This has the effect of reducing millions of events into dozens of contextual, code-related analytics that can be easily visualized to see exactly which errors are impacting your applications at any time.
Creating your Own Public / Private Views
But if that’s not neat enough, you can now go one step further and use the dashboard’s filters system to save, reuse and share views. In essence this enables you to ask the dashboard any question, such as show me errors only from specific code transactions or locations, or target specific types of log errors or exceptions, and visualize them directly. This creates a powerful way to isolate and inspect any aspect of your environment to know whether they’re functioning correctly or breaking.
A few examples of views you can easily define:
- See what broke today in app X – you can create a view to show new errors introduced over the last day in application X by limiting the built-in “New today” view to a specific application and save it as a new view.
- Whack all the NullPointers – another easy view to setup is filter the error type to NullPointerExceptions and setup an alert whenever one is introduced, so you can fix it right away. These little moles can have a huge impact on both the stability of your application and the size of your logs.
- Visualize business critical errors – you can choose to focus on a set of specific log errors (e.g “Failed to complete transaction”, “Salesforce error”,..) within the context of your app and save that as a view to visualize and be alerted on.
A view can be set to be private only to you, or as one that will be shared and visible between all teammates accessing that environment. Once you’ve setup a view you can also receive alerts via Slack, PagerDuty and more whenever a new error starts, or the volume of the errors exceeds a target threshold.
Click here to learn more about Dashboard views, or add your questions and comments in the section below – we’d love to hear them! 🙂