35 ms·

I think the biggest problem with Sentry is that it will sample exceptions (I wonder if there's a way to switch this off with $$$?), meaning that I can't rely on

by nawitus 10y ago

I think the biggest problem with Sentry is that it will sample exceptions (I wonder if there's a way to switch this off with $$$?), meaning that I can't rely on it to view and examine every instance. Sometimes you need to fix things manually which requires every exception to be saved. Since I want to get every single exception logged, Sentry feels quite useless and I wouldn't select it for my next project. Other than that it has been a fantastic tool.

zeeg 10y ago
We're working on improving this. It's a tradeoff we made early on as our primary customers have always been very large tech companies (meaning lots of errors). In those cases individual events have little to no meaning, and what you really care about is the aggregate view. That's very different than if e.g. you're a payments provider, and you literally need to know every transaction that erred, but that's also quite a different use case. In my opinion, you'd want to guarantee those errors are logged elsewhere (traditional audit logs), and utilize Sentry primarily for the workflow and alerting features.
- nawitus 10y ago
  But if I need another tool for logging those errors, I could use the same tool for both use cases, which would make Sentry unnecessary? Ideally speaking a Sentry exception is the last escape hatch - if we can't handle something in code at least the error is sent somewhere so that developers can handle the issue. Following this the philosophy I'd like to follow is that every time I get a Sentry exception, I'll make a new ticket in Jira "handle error x, see link to Sentry", and ultimately there wouldn't be any errors sent to Sentry.
  - thedz 10y ago
    FWIW my company uses both Splunk and Sentry, I've found myself using them to combo together quite nicely
deleted 10y ago
[deleted]
mikepurvis 10y ago
If you run your own instance, you can turn off sampling: https://docs.getsentry.com/on-premise/server/config/#data-sampling https://docs.getsentry.com/on-premise/server/config/#data-sa...

by nawitus 10y ago

zeeg 10y ago

We're working on improving this. It's a tradeoff we made early on as our primary customers have always been very large tech companies (meaning lots of errors). In those cases individual events have little to no meaning, and what you really care about is the aggregate view. That's very different than if e.g. you're a payments provider, and you literally need to know every transaction that erred, but that's also quite a different use case. In my opinion, you'd want to guarantee those errors are logged elsewhere (traditional audit logs), and utilize Sentry primarily for the workflow and alerting features.

nawitus 10y ago
But if I need another tool for logging those errors, I could use the same tool for both use cases, which would make Sentry unnecessary? Ideally speaking a Sentry exception is the last escape hatch - if we can't handle something in code at least the error is sent somewhere so that developers can handle the issue. Following this the philosophy I'd like to follow is that every time I get a Sentry exception, I'll make a new ticket in Jira "handle error x, see link to Sentry", and ultimately there wouldn't be any errors sent to Sentry.
- thedz 10y ago
  FWIW my company uses both Splunk and Sentry, I've found myself using them to combo together quite nicely

deleted 10y ago

[deleted]

mikepurvis 10y ago

If you run your own instance, you can turn off sampling: https://docs.getsentry.com/on-premise/server/config/#data-sampling https://docs.getsentry.com/on-premise/server/config/#data-sa...