We're hoping to do a sort-of AMA in the future about rebuilding Sentry (and the open source approach), but if anyone has any questions about the new version I'm happy to answer them.
Sentry looks cool. I have previously tested Rollbar and Airbrake, but was deeply unsatisfied with both.
The big problem I have with all these services is that you need set up each application individually: Each one is a silo, with its own notification settings, API key, and so on. We have dozens of apps (several products + lots of microservices), so this is just unacceptable. I looked into whether I could use a single API key with Rollbar or Airbrake, and simply tag each event with the name of the sender, but it turns out this is not feasible. They don't even have APIs that let you programmatically configure apps remotely.
How does Sentry compare?
(Many other SaaS services suffer from the same issue; for example, Semaphore, which we use for CI, requires a build script for each project. We worked around this by letting the build script be a single curl command that pipes a remote script to bash, shared across all projects. But hardly ideal.)
David, I've been a Sentry customer for years and I rely on it. But one feature I miss dearly is having a 1 day graph that shows me the health of my servers based on a single count.
A few months ago the top-right dashboard lost its total count and I had to rely on hovering over the graph bars to see what the numbers looked like. I generate a hundred exceptions in a day (on a good day), and I like to use that count to gauge if anything is wrong. A bad day can generate hundreds of exceptions and I like to have an easy way to spot those days.
The dashboard view kind of gives that, but there is no single number of exceptions that I can use. And I greatly miss being able to have that count and graph on the same list of exceptions.
Can you bring back that 1 day graph, complete with a total exception count?
How do you see yourself stacking up against Rollbar https://rollbar.com which has a free tier and unlimited users for paid plans? What makes your product more valuable?
I already implemented releases a few weeks ago. They're great, thanks for that!
I'm wondering what the reasoning is behind suggesting I upload source artifacts to you as part of a release. The blog post even specifically calls out Go, which is what the majority of our application is written in. So from my understanding, uploading artifacts would allow the Sentry UI to show me exactly where we did a Sentry Dump?
On the same topic, our current deploy flow makes it a bit hard to upload specific code changes per release. It would be great if Sentry could get the code from Github directly (assuming that I login and give you access to the repo)
Thanks for Sentry, we use it daily and would have a much harder time tracing errors and monitoring overall application health without it.
There really should be a requirement that SaaS services supported some kind of load/dump configuration API, where you can deal with raw config. The admin UI should be completely optional.
Most SaaS vendors don't have APIs that cover all parts of the service. Some do have decent APIs -- for example, we store our DNS records in files and use Gandi's APIs to update our zones, using a custom script (with some nice diffing capabilities), and we do some automatic configuring of Mailgun -- but APIs are always stateful and never declarative, which means that a client will always have to issue half a dozen calls to diff and converge its state. It's painful.
Do you have any numbers about what percentage of your customers running Sentry on their own nodes instead of just using cloud version that you provide?
Our goal is the next 60 days, but the realist in me is saying "sometime this year". We have an ever changing list of things we want to accomplish still as part of the 8.0 push:
Regarding future capabilities of Sentry, we're not quite ready to talk about most of it publicly yet, but we'll making some drastic improvements in the very near future.
> Awesome, I've just upgraded our instance to 7.7.0 - when will 8.0 be available on Pip?
"Soon", but you can install it from the github master already. Since we generally deploy right out of master the upgrades are fine to and from there as well.
Of note, we're actively hiring someone to come help us expand our mobile offering. If you're in SF (or interested in being) and like what we're doing, take a peek:
@David, after upgrading from 7.7.0 to 8.0.0.dev0, sentry health api /_health/?full=1 reports
{"healthy":{"CeleryAppVersionCheck":false,"CeleryAliveCheck":false},"problems":["Background workers haven't checked in recently. This can mean an issue with your configuration or a serious backlog in tasks.","Celery workers are referencing a different version of Sentry (8.0.0.dev0 vs 7.7.0)"]}
and the website has two red bars for these warning, but the reporting mechanism seems work well, and there are no warning/error records in logs.
Do these warnings have serious problem? how can I fix these warnings? (I've totally removed old sentry files in /usr/local/lib/python2.7/site-packages/sentry* and made a fresh installation)
Same goals, different approach. Our JS support is extremely mature at this point and you'll find that out of the box we'll do a great job at catching errors in your application. In many situations you won't even need to do anything beyond toss in a couple script tags.
That said we also support a lot of advanced scenarios:
I'd really love to be able to use Sentry to collect errors in a closed .NET web app that just spams a log file. Is there a collector/raven for just tailing files (on Windows), configurable via RegEx or other parser definition? Right now we use a custom grok filter for Logstash and dump it all into Elasticsearch, but the Sentry UI sure would make life easier when something goes wrong and we have to figure out why.
There's not. The primary reason is that Sentry doesnt really match up well to traditional logging. A lot of we do involves highly structured data, and simply wouldn't be usable without that.
It helps to think of Sentry more like classic crash reporting more so than modern logging. We want (and need) to know precisely what a stacktrace is, which piece is the function name, the line number, etc.
[+] [-] zeeg|10 years ago|reply
We're hoping to do a sort-of AMA in the future about rebuilding Sentry (and the open source approach), but if anyone has any questions about the new version I'm happy to answer them.
[+] [-] lobster_johnson|10 years ago|reply
The big problem I have with all these services is that you need set up each application individually: Each one is a silo, with its own notification settings, API key, and so on. We have dozens of apps (several products + lots of microservices), so this is just unacceptable. I looked into whether I could use a single API key with Rollbar or Airbrake, and simply tag each event with the name of the sender, but it turns out this is not feasible. They don't even have APIs that let you programmatically configure apps remotely.
How does Sentry compare?
(Many other SaaS services suffer from the same issue; for example, Semaphore, which we use for CI, requires a build script for each project. We worked around this by letting the build script be a single curl command that pipes a remote script to bash, shared across all projects. But hardly ideal.)
[+] [-] conesus|10 years ago|reply
A few months ago the top-right dashboard lost its total count and I had to rely on hovering over the graph bars to see what the numbers looked like. I generate a hundred exceptions in a day (on a good day), and I like to use that count to gauge if anything is wrong. A bad day can generate hundreds of exceptions and I like to have an easy way to spot those days.
The dashboard view kind of gives that, but there is no single number of exceptions that I can use. And I greatly miss being able to have that count and graph on the same list of exceptions.
Can you bring back that 1 day graph, complete with a total exception count?
[+] [-] willtheperson|10 years ago|reply
[+] [-] robbiet480|10 years ago|reply
I'm wondering what the reasoning is behind suggesting I upload source artifacts to you as part of a release. The blog post even specifically calls out Go, which is what the majority of our application is written in. So from my understanding, uploading artifacts would allow the Sentry UI to show me exactly where we did a Sentry Dump?
On the same topic, our current deploy flow makes it a bit hard to upload specific code changes per release. It would be great if Sentry could get the code from Github directly (assuming that I login and give you access to the repo)
Thanks for Sentry, we use it daily and would have a much harder time tracing errors and monitoring overall application health without it.
[+] [-] lobster_johnson|10 years ago|reply
There really should be a requirement that SaaS services supported some kind of load/dump configuration API, where you can deal with raw config. The admin UI should be completely optional.
Most SaaS vendors don't have APIs that cover all parts of the service. Some do have decent APIs -- for example, we store our DNS records in files and use Gandi's APIs to update our zones, using a custom script (with some nice diffing capabilities), and we do some automatic configuring of Mailgun -- but APIs are always stateful and never declarative, which means that a client will always have to issue half a dozen calls to diff and converge its state. It's painful.
[+] [-] buremba|10 years ago|reply
[+] [-] ryanpetrich|10 years ago|reply
[+] [-] crudbug|10 years ago|reply
[+] [-] ddorian43|10 years ago|reply
[+] [-] voltagex_|10 years ago|reply
[+] [-] wheaties|10 years ago|reply
[+] [-] nathancahill|10 years ago|reply
Happy to have been using Sentry for a long time now. Excited for the new release.
[+] [-] jbrooksuk|10 years ago|reply
Will Sentry ever be useful for activities such as tracking occurrences of an event?
[+] [-] zeeg|10 years ago|reply
https://github.com/getsentry/sentry/milestones/8.0%20Release
Regarding future capabilities of Sentry, we're not quite ready to talk about most of it publicly yet, but we'll making some drastic improvements in the very near future.
[+] [-] the_mitsuhiko|10 years ago|reply
"Soon", but you can install it from the github master already. Since we generally deploy right out of master the upgrades are fine to and from there as well.
[+] [-] zeeg|10 years ago|reply
https://www.getsentry.com/jobs/00790FFCE6/
[+] [-] songchao|10 years ago|reply
and the website has two red bars for these warning, but the reporting mechanism seems work well, and there are no warning/error records in logs.
Do these warnings have serious problem? how can I fix these warnings? (I've totally removed old sentry files in /usr/local/lib/python2.7/site-packages/sentry* and made a fresh installation)
Thanks!
[+] [-] akurilin|10 years ago|reply
[+] [-] zeeg|10 years ago|reply
That said we also support a lot of advanced scenarios:
- Embedded/shipped code (i.e. PhoneGap, React-Native)
- Minified code via sourcemaps (use webpack? it "just works")
- Private source code (sourcemaps uploadable via artifacts, authentication tokens)
One thing that trackjs does and we don't is provide "breadcrumbs". In reality we haven't seen it be that useful, but it's something we're exploring.
[+] [-] spdustin|10 years ago|reply
[+] [-] zeeg|10 years ago|reply
It helps to think of Sentry more like classic crash reporting more so than modern logging. We want (and need) to know precisely what a stacktrace is, which piece is the function name, the line number, etc.
[+] [-] sul4bh|10 years ago|reply
[+] [-] zeeg|10 years ago|reply
You can't install via standard channels yet (effectively you need to install from GitHub), but otherwise there's no major concerns.
[+] [-] boundlessdreamz|10 years ago|reply
* Can't filter by additional data sent by you.
* Can't filter by Browser names instead of browser versions (i.e all Firefox instead of Firefox 35,36 etc)
* Can't ignore errors created by bots and old browsers.
[+] [-] breakingcups|10 years ago|reply
[+] [-] songchao|10 years ago|reply
[deleted]