Sentry 8 is here • Hacker News Board

Re: Sentry 8 is here

#31

Post by duggan » Thu, Oct 08, 2015, 9:56 PM UTC

atombender wrote: post #26

zeeg wrote: post #21

Earlier quoted context omitted.

We're pretty similar in a lot of ways. It's definitely a pain point, but from a UX perspective its tough to solve. In theory you could manage a lot of things with the API (most of our UI runs off the API these days). Even with the limitations, we have many people with hundreds of projects, and the general problems we see are more around notification settings than anything else. The usual suspect is that people are ge…

I see. What I don't understand is why settings need to be so granular. For example, our company uses Slack. All notifications go to Slack. There's no need for per-project settings because it's all just one room. At some point we will probably want some projects to go to other rooms, but that's a coarse-grained exception, not something that warrants a per-project setting. Also, if you need per-person notification sett…

This is basically how Datadog works. Unfortunately they do service monitoring rather than exception tracking, but certainly lessons can be learned from them.

Hands down the best designed operations product I've used.

Re: Sentry 8 is here

#32

Post by zeeg » Thu, Oct 08, 2015, 9:58 PM UTC

voltagex_ wrote: post #28

zeeg wrote: post #2

David from Sentry here. 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.

Can I come work for you?

We're always looking to expand the team, though our team is small so we may not always have open roles.

That said feel free to throw your hat into the ring:

https://www.getsentry.com/jobs/

Re: Sentry 8 is here

#33

Post by zeeg » Thu, Oct 08, 2015, 9:59 PM UTC

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:

https://www.getsentry.com/jobs/00790FFCE6/

Re: Sentry 8 is here

#34

Post by mattrobenolt » Thu, Oct 08, 2015, 10:01 PM UTC

robbiet480 wrote: post #30

zeeg wrote: post #2

David from Sentry here. 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.

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 th…

> 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?

For Go, you ultimately compile your application into a binary. This binary doesn't have the source code, but it does retain references to the filenames and line number in the binary's metadata. What this means is, if you send along a stack trace to us, we can tell you that information, but we can't show you what the actual line of code is, or what the surrounding code is. By uploading the sources to us explicitly, then baking in the release version into your compiled binary, we can map those up and show you a stack trace that includes source code. This is relatively the same idea with any modern JavaScript. Typically a project is compiled down into a minified version, or run through a transpiler, etc, and the original sources aren't accessible to us. So it's then necessary to upload to us so we can map things up.

> 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)

We have plans for VCS integrations in the future (GitHub included) that would likely work with releases so we can just use the working directory at a current sha.

Re: Sentry 8 is here

#35

Post by akurilin » Thu, Oct 08, 2015, 10:13 PM UTC

For js error tracking, how does this compare to trackjs now?

Re: Sentry 8 is here

#36

Post by robbiet480 » Thu, Oct 08, 2015, 10:15 PM UTC

mattrobenolt wrote: post #34

robbiet480 wrote: post #30

Earlier quoted context omitted.

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 th…

> 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? For Go, you ultimately compile your application into a binary. This binary doesn't…

Hey Matt, thanks for replying.

So right now when we have a need to send a stacktrace (error or panic) we use Raven-Go's NewStacktrace to create a stacktrace and attach it to the packet we send up. In the UI I see the exception with surrounding lines.

What makes releases different from what we already do? Or, do they do the same thing, but the difference is crafting the stack trace in our code vs just upload the code and letting you figure it out?

Re: Sentry 8 is here

#37

Post by zeeg » Thu, Oct 08, 2015, 10:16 PM UTC

akurilin wrote: post #35

For js error tracking, how does this compare to trackjs now?

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:

- 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.

Re: Sentry 8 is here

#38

Post by mattrobenolt » Thu, Oct 08, 2015, 10:24 PM UTC

robbiet480 wrote: post #36

mattrobenolt wrote: post #34

Earlier quoted context omitted.

> 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? For Go, you ultimately compile your application into a binary. This binary doesn't…

Hey Matt, thanks for replying. So right now when we have a need to send a stacktrace (error or panic) we use Raven-Go's NewStacktrace to create a stacktrace and attach it to the packet we send up. In the UI I see the exception with surrounding lines. What makes releases different from what we already do? Or, do they do the same thing, but the difference is crafting the stack trace in our code vs just upload the code…

> So right now when we have a need to send a stacktrace (error or panic) we use Raven-Go's NewStacktrace to create a stacktrace and attach it to the packet we send up. In the UI I see the exception with surrounding lines.

Yeah, so raven-go will check for the source files on disk first. You must keep your source files along with the binary. :)

Re: Sentry 8 is here

#39

Post by chromakode » Thu, Oct 08, 2015, 10:31 PM UTC

zeeg wrote: post #37

akurilin wrote: post #35

For js error tracking, how does this compare to trackjs now?

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: - Embedded/shipped code (i.e. PhoneGap, React-Native) - Minified code via sourcemaps (use webpac…

Sentry's sourcemap support is one of my favorite features. After spending years poring over cryptic minified exception messages, I finally set up Sentry for my latest JS frontend. It's glorious to get a nicely formatted traceback containing actual source code lines.

Re: Sentry 8 is here

#40

Post by spdustin » Thu, Oct 08, 2015, 10:42 PM UTC

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.