I'd be curious to hear if any HN readers are using Sentry and how they like the service. We started as primarily Python based, so it's especially interesting if you're using it for another language/platform.
- I could search w/ meaningful results
- I could group by exception type.
- I had a better method of seeing the different input data that caused the exception (without next/next/nexting).
- there were lots more information around my source code.
I could probably come up with a few more if I were pressed to. All that said, we'll continue to pay for the service b/c its useful to our business.
I second the need to have a view that shows the exception group and displays the differences between input data. I use it extensively with other log levels and treat it as a log aggregator (especially for INFO). However, it's really hard to view the variables within the input data which is necessary for any entries that are not one-off exceptions. Otherwise it's a wonderful service.
We (http://www.fool.com) are currently using Sentry with a few Django sites, a few Wordpress sites and (very sparingly) with some C# code. There have been a few hiccups here and there with the UI, but we have been extremely happy with the service so far.
As a side note, we also have a legacy internal log error application that we also use, but it is nice to not have to deal with any of that infrastructure :).
We use the open source version in our wing of the Broad Institute for our external web application (python based), and we're absolutely thrilled with it.
We're a Atlassian/JIRA shop internally, and the JIRA plugin. It's not better than having a bug free product, but it is amazingly reassuring to the customer when they contact us with an error and we're already looking at the stack trace and fixing the problem.
We love sentry. We made the switch from Hoptoad/Airbrake, because the pricing based on event volume rather than number of projects. We use it to track a group of small-scale Rails applications - which are growing in number, but reasonably low traffic.
I love everything about it, looking forward to having a poke around the new design!
My company uses the open source version with a django app, and it's pretty effective. We actually hacked it up a little to add support for sending a Session (same with Raven) because a lot of our errors were related to that, but as a whole its a pretty effective tool.
We're using the hosted version of Sentry with out Django app. Absolutely loving it. Started playing around with the free version a while back and really glad to have the hosted service now.
> "The cost of running and deploying your own server just to monitor the errors maintenance in your application for a lot of users isn’t really practical – there’s a lot of and cost involved with maintenance and upkeep"
I don't really understand this, we just stick it on our app/db servers alongside our other applications. The cost is $0 and it takes about 5 mins to set up, it's just a Django app.
It quickly becomes expensive if you're routinely sending a measurable amount data to it.
Disqus has two physical servers dedicated to it. Both of them are larger than any of the web/worker machines getsentry.com runs. On top of those costs, they also have the upkeep cost of running those servers, doing software upgrades, and, if anything goes wrong, debugging things.
Obviously Disqus isn't a great example, since we built the software and know how to run it, but companies much smaller than Disqus don't really have the reason to invest the money or time into setting up infrastructure to support it.
Delicious is using Sentry on their new JavaScript-centric site, and for the amount of data they're sending, they'd be spending a lot more on hosting costs and infrastructure maintenance. It's not ideal for everyone (some companies push a lot of data through Sentry), and we don't necessarily aim to serve someone who may be sending millions of events in a day.
What we typically see is that most people are sending somewhere between 5,000 and 50,000 events, which is right about the size where it's not practical to host the instance yourself. It definitely beats maintaining RabbitMQ, Redis, Memcache, Celery, WSGI, Postgres, and soon, Elastic Search.
I've played with the hosted service as well as hosting Sentry myself. I only played with the latter version for 20 minutes but I didn't know how to get it up and running such that I could actually use it in the same way the getsentry.com was. (this was last week, before the UI redesign)
Is there something obvious I was missing?
This all being said, I'm very impressed with exception reporting at getsentry.com!
The term bug tracker initially threw me as well. For me at least, this term is safely ensconced as equivalent to 'ticket management' in the domain of software development.
I'm not sure what the best term for this other kind of "bug tracking", but almost certainly it should be something else.
It's very similar to Crashlytics with the primary difference being Sentry's very strong focus on web applications (initially) and our slowly expanding support for desktop and mobile applications
(This was recorded before we annotated sourcemap data, but the original error here was actually in a minified javascript file)
Also, of note, there's some things that don't fully function when you're viewing a public event without full access. One of those things happens to be the graph on that link.
