I've been using both Bugsnag and Sentry for years and I would recommend both of them and as Tom Maiaroto mentioned "they are roughly the same". Bugzilla is a different kind of animal, that is more of an issue tracker like Jira or Redmine.
Despite what Tom Maiaroto wrote, we're using these tools more for the backend and less for the frontend, so I am going to give a brief insight into how we use them in our Telemetry stack for monitoring the backend.
Sentry and Bugsnag are advertising themselves as Application Monitoring, but their definite focus is on Error Monitoring. This is what they originally were made for and this is were they shine.
A typical confusion is that we think they are mutually replaceable with APM tools like NewRelic's or Datadog's APM. Albeit both are doing very similar things, there are several significant differences:
- NewRelic/Datadog APMs are sampling exceptions, so you don't have a "complete catalog" of your errors
- Sentry and Bugsnag are collecting very detailed data (stack trace, HTTP request, user, device, host, etc) of each exception, thus you'll exactly know when, where, how many times and to whom those errors have happened.
The focus of those APMs is broader and can give you a much bigger picture like distributed tracing, logs, processes on the hosts at the given moment just to name a few. But they are not designed to give you a laser focus on each specific error.
So the bottom line is that they are complementing each other.
Sentry is more affordable especially if you have more than 5 users. I personally prefer Bugsnag because of the cleaner UI. But at the end of the day, they're both very valuable and lovely gadgets in our toolbox and help us a lot being on top of our systems
Some good points here. Though I would add that Sentry does allow you to adjust the sample rate so you can gather less (and sometimes you actually do want this because of cost). Also, Datadog APM's default sample rate value is 1 (or 100%), so it does capture everything, though you can reduce that as well.
That said, I agree that you will likely find the need for multiple tools at one point or another as Attila here is saying. There's definitely complimentary tools.
I've been using Sentry lately. I've used all of them over the years and they are roughly the same. They're going to give you insight into exceptions being thrown on your JavaScript apps. They also support other languages as well and server side issues. In my opinion the frontend JS app bug monitoring is the primary draw here as there already exists so many backend logging and monitoring tools. In fact, I think these tools are also lagging when it comes to the backend, but they are of course trying to expand their product offering and it makes sense to connect frontend with backend to see an entire request lifecycle. Many of the backend tooling and services actually went the other way around and are lacking for the frontend. No one really seems to have nailed it.
I like sentry lately because they have recently brought online performance monitoring. With that and their current solutions, it's a very powerful and easy to use tool to gain insight on not only bugs to be addressed but also bugs and performance over time - from release to release. So you can track how your releases are having an affect.
If you are already entrenched in one tool, I'm not sure if it's worth switching. It depends on if you had any historical data you wanted to keep and how much work it is to switch. These tools are generally rather effortless to set up. Getting the source maps to Sentry can be a bit of a pain, but once you're set there with a process you don't need to think about it again.
