We primarily use MariaDB but use PostgreSQL as a part of GitLab , Sentry and Nextcloud , which (initially) forced us to use it anyways. While this isn't much of a decision – because we didn't have one (ha ha) – we learned to love the perks and advantages of PostgreSQL anyways. PostgreSQL's extension system makes it even more flexible than a lot of the other SQL-based DBs (that only offer stored procedures) and the additional JOIN options, the enhanced role management and the different authentication options came in really handy, when doing manual maintenance on the databases.
Last time we shared there information about our decision about using YouTrack over Jira actually we found much better solution that our team have loved. Linear is a minimalistic issue tracker that integrates well with Sentry, GitHub, Slack and Figma which are our basic tools. I would like to recommend checking out Linear as a potential alternative to "heavy" issue trackers, maybe at enterprises that may not work but when we're a startup that works awesome!
Sentry has been essential to our development approach. Nobody likes errors or apps that crash. We use Sentry heavily during Node.js and React development. Our developers are able to see error reports, crashes, user's browsers, and more, all in one place. Sentry also seamlessly integrates with Asana, Slack, and GitHub.
We decided to use Sentry as our application monitoring tool due to its various features such as being able to see event history and actions, tags about software versions, and error visualization. These features along with the large community support will allow us to analyze and identify errors within our application more efficiently.
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 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.
Hey everyone, I have installed the basic plan of Sentry and integrated it into our React application. I like how it shows errors etc, however, who would be the proper person to set up all the alerts and monitoring so it is useful to us? Is this something my developer can do? Is there a dedicated Sentry developer? Who can I contact to make this work for me?
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.