.svg)
We all want our application to run as smoothly as possible, but that’s not always the case. Once the application is up and running, we need to know if and when errors or exceptions are thrown. That’s why there are numerous error tracking tools in the market.
What is an error tracking tool? What can you actually do with it? What are the differences between the tools? Answers to these questions, along with some other relevant questions are waiting for you in the following post. Get ready to squash some bugs.
Deploying fast and frequently might introduce a errors, exceptions and bugs into our application, and it’s best to identify them before your users do.
We’ve brushed the dust off our older error tracking tools post to see how they evolved, upgraded and changed during the past few months. We’ve pointed out some key features, pricing and special additions, so you’ll know which one is right for you.
We won’t beat around the bush. We started out as an error tracking tool, and we think we’re pretty good at it. OverOps was created to give developers a simple answer to a topic shrouded with mystery: When, where and why does code break in production. The OverOps Platform analyzes your application at runtime to deliver actionable code-level insights and context into the quality of software across the SDLC.
Among other things, these end-to-end insights enable companies to prevent unsafe code from being promoted into production and solve issues quickly in any environment. (There’s much, much more – learn more about the rest of the cool things we do here.)
OverOps offers support for all JVM languages, that includes Java, Scala, Clojure and Groovy, along with support for web containers and frameworks.
OverOps was built for Java production environments, and offers a simple installation process. Since it runs as a Java agent, there’s no need for code or build changes, just attach a Java agent to your JVM.
If you still prefer going through your log files each time an error occurs, OverOps adds a link to each error that takes you directly to a web based dashboard, showing the complete source code for every frame in its stack trace with the variable values that caused it. You can prioritize by how often errors happen across your cluster, if they involve new or modified code, and whether that rate is increasing.
On the dashboard itself, you can customize alerts based on frequency of errors, filter errors by application, code location, time, transaction and tier, and see error frequency and impact over time.
Bottom line: OverOps is the only tool that gives you the complete source code running within the JVM at the moment of error, with variable and object state across the entire call stack. Plus, by aggregating OverOps’ unique data points, teams can better understand the quality of their applications at all stages of the SDLC. Learn more.
The error tracking and monitor tool offers full-stack error monitoring for “all apps in any language”. It captures stack traces for exceptions and messages for log files, that are sent into Rollbar’s dashboard.
The dashboard presents all new and reactivated errors in your application (or items, as Rollbar calls them), that can be viewed via the occurrence graph. The detailed view includes how many times each error happened, the amount of unique IPs that were affected by it and whether it was critical or not.
While Rollbar can capture any uncaught errors, if you’re interested in capturing caught exceptions as well, you’ll have to manually send them to the dashboard.
Rollbar has a long list of supported languages, that include JavaScript, Angular, Node.js, Python, Ruby, Django, PHP, Clojure, .NET, Android, iOS, Haskell, Drupal, Rails and many many more.
On the Java side you’ll need to use java-rollbar, a set of Maven modules that allows reporting issues to Rollbar in anything that can use Java. It’s important to mention that Java support is still under development, and Rollbar states that this library was written by “someone who knows C# much better than Java”.
One of the things that caught our eye is Rollbar Zero. Just like the concept of emptying your email, the company encourages you to go over and “clean” every error that occurred. You can mute or hide certain items that you know about, define the severity of each error and get a notification if an error reoccurs. Each error can be sent to a team member to be taken care of, leaving the dashboard clean and error free.
If you want to see an error through the eyes of your system, Replays creates a rerun of GET requests that include the same URL, headers, cookies and other information needed to reproduce it. In addition, Person Tracking lets you see the event history for each user you’re interested in.
Bottom line: Rollbar has an impressive offering for numerous languages and frameworks, which is nice, but it requires some code changes to work, which might be a hassle to you.
Raygun offers 2 services: Real User Monitoring (aka Pulse) and Crash Reporting. Pulse monitors sessions, performance issues, and bottlenecks, each with an option to set up an alert when they occur inside the code. It has a separate dashboard, that also informs you about loading times from specific countries, browsers, and devices.
Crash Reporting aims to give instant notifications on errors and issues inside the app, and in this dashboard, you’ll be able to see diagnostic reports and relevant needed data.
Here you’ll find support for .NET, Android, Drupal, Go, iOS, JavaScript, Node.js, PHP, Python, Ruby, Unity, and more.
If you’re looking for Java support, you need to add the Raygun4Java library to your application. This library will let you send exceptions right to Raygun’s dashboard. It’s a bit of a hassle, but there’s an extra explanation inside Raygun’s documentation.
In order to keep your dashboard clean, Raygun presents multiple occurrences of a bug or an error in a single group, for faster handling or ignoring. The dashboard offers Trend Graphs that show how errors in your application change over time, and you can mark errors or instances with tags to know where they came from.
Every error group lets each team member see the status updates, comments, and other information, and the dashboard counts the number of users affected by each error.
In addition, each error can be marked with custom tags, that in turn will send some more information whenever an exception occurs. The full-text search option lets you search through the collected data, for easy recovery later on. You can also use webhooks and send notifications to third-party APIs, or your very own system.
Integrations
Bottom line: The dashboard looks clean and informative, and the option to choose between 3 different options according to our personal needs is something that can be useful for independent developers or small startups.
What started as a tiny bit of open-source code grew to become a full-blown error monitoring tool, that identifies and debugs errors in production. You can use the insights to know whether you should spend time fixing a certain bug, or if you should roll back to a previous version.
The dashboard lets you see stack traces, with support for source maps, along with detecting each error’s URL, parameters, and session information. Each trace can be filtered with app, framework, or raw error views.
JavaScript, Node.js, Python, Go, PHP, Ruby, C#, Objective-C, and even Swift.
Raven is the Java client for Sentry, and it relies on popular logging libraries in order to capture and convert log files. The library takes that information and sends the relevant details into a Sentry instance. The company highly recommends using one of the supported logging frameworks to capture and send messages to Sentry.
You can catch errors in real-time as you deploy, and every error includes information about software, the environment, and the users themselves. If you believe your users are a key point for understanding errors, Sentry lets you prompt users for feedback whenever they encounter errors. That allows comparing their individual experience to the data you already have.
Bottom line: Sentry has an open approach in which we can ask our users questions about the application, while the rest of the information is based on what you can get directly from your log files.
Rackspace’s Airbrake offers a web-based dashboard to capture and track the exceptions and errors in your application. The dashboard gives a pretty straightforward view of resolved and unresolved errors, the information about each one of them, and a nice overview graph. Each error includes the environment in which it happened when it was first identified, the error type, and more.
Ruby, PHP, JavaScript, .NET, Python, Django, Node.js, iOS, Swift, Android, Go, Angular, Flask, and some other names.
You can use Airbrake with Java through Maven and log4j, or by adding the Airbrake jar to your classpath. If you want to send uncaught exceptions to Airbrake, you need to use setUncaughtExceptionHandler as presented in the example below:
Airbrake lets you see the stack trace and metadata for each error, and they are grouped by type, users, and environment variables. That way, it’s easier to identify where exactly each error was created within the code.
There’s also a view for when each error was fixed and deployed, so you’ll know if they are new to the current cycle, or if they’ve re-occurred after they’ve been fixed. There’s also an option to see which team member caused which error, or which one is responsible for fixing them.
Bottom line: We don’t really like to enter our credit card before we get to try out a product, and with all these alternatives it might be a reason to pick other tools over Airbrake.
Bugsnag lets you monitor and capture the various errors and exceptions inside your application, and try to distinguish itself by focusing on the tools you need in order to solve them. Or in other words, the company acknowledges that once you’ve identified an error, you’ll need tools and workflows in order to fix them.
The dashboard gives an overview of all errors, with an option to filter out the unresolved ones. It groups errors that has a similar origin in the code and helps visualize and compare the different error trends over time with graphs.
Android, Go, iOS, .NET, Node.js, PHP, Python, Ruby, Unity.
You can add Bugsnag to your Java application using Gradle, Maven or through manual jar installation. There’s also an option to add Java using Spring and Spring boot projects, and you can view the full process here.
The dashboard has a few features that include an option to snooze errors until they meet custom conditions or a mute option in case they’re not important/critical for you. Each error comes with data about the number of users affected by it, how many times it happened, and their stage.
The error status menu gives some extra information by showing the progress of the errors, and the activity feed specifies the full history of each error over time.
Bottom line: Bugsnag can save us time since it goes over the log files for us and create a dashboard of the errors and exceptions while offering a better workflow while doing so.
StackHunter alerts via email whenever failures happen inside your application, giving the relevant details for analyzing and understanding each error. The information includes breakdowns by day, hour, user, location, and type, along with the number of times this error occurred.
Each error includes the stack trace, HTTP request, JVM properties, JMX attributes, and of course, when and where it first happened. StackHunter watches for uncaught exceptions, along with errors logged through Log4J, Logback, and their own API.
On the Java side, it’s a tool made specifically for capturing Java exceptions. It supports JDK 6 or higher, and requires Servlet 2.5 or higher container. Installation is pretty easy, and once you unpack the install package all you need to do is deploy the war file from server/stackhunter.war to your webserver.
StackHunter tracks exceptions by automatically hooking into Log4J and Logback, which allows capturing exceptions you’re already logging. And the tool offers a single, self-hosted, web-based interface in which you can view all exceptions.
If you want to get into specific information, you can see all of your application’s exceptions, filter out unique exceptions, or view which ones affected the users or sessions. Also, similar exceptions are grouped together, so you’ll know what you should focus on.
Bottom line: StackHunter is a small beta tool made specifically for Java and basic as it is, it gets the job done.
Deployments come and go, but errors and exceptions are here to stay. At least until we can hunt them down and fix them, that is. Error tracking tools are a key point in the application life cycle, and each one can introduce a whole new way of using our app, that we didn’t think of before.
There are a lot of options out there, and while they all focus on helping us find errors, each has its own pros and cons that might be critical for our app. If possible, we’d recommend taking advantage of the free trials offered and testing out these tools in your staging environment. Change isn’t easy, but it might help you make a better application for your users.
Using other tools we didn’t write about? Have anything else to add about one of the tools we wrote about? We would love to hear you out in the comments below.
Sign up for our free plan, start building and deploying with Harness, take your software delivery to the next level.
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
.svg){kind=small}
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.
.png)
