Sentry

1. Stackdriver is no longer a product on it's own. It's the "Monitoring" feature in Google cloud. If you're on Google cloud - it's the easiest way to set up logging.
2. Datadog is one of the 3 most expensive tools for logging, It's a SaaS product like Splunk and New Relic. Only use them if you have high budget and consider your logs at least as holy as the bible.
3. Sentry is not related to logging, but it can report errors and crashes in your application. Mixing up those tools tells me you're not really familiar with monitoring in general. I suggest learning a bit more, it's easy to get monitoring wrong and ending up shipping and storing masses of useless logs. Good luck.

We never needed anyone dedicated to setting up or maintaining Sentry. My small team of developers handled it themselves. The documentation was easy enough to get it set up, and the most important part is deciding who should get notifications. I would highly suggest setting up a slack channel (if you use Slack) and set up the integration to notify there.

It's definitely something your developers should do, although I would give setting up the logs to a more senior developer, as you need to know what stuff are useful logs and what are not.

In any way, logging is one of the things that needs to be done in iterations, so you make the basic setup, then observe for a while, then tweak it later on to increase the useful logs and remove the useless ones, and so on, until you get what you need.

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

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.