-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ECHO-1987] Add a Sentry error handler #68
Conversation
|
||
default_options = { } | ||
|
||
::Sentry.with_scope do |scope| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we use Sentry
in our gem then we should probably mark this as a project's dependency (eventboss.gemspec
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really, it's optional plugin, which makes Sentry will be required only when it's added in configuration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this still is a dependency on the gem - it uses Sentry API that is valid for the specific range of Sentry versions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, but what if I use Rollbar, not a Sentry? My whole project would have Sentry downloaded and required when then. As this is plugin, we don't force you to that feature. Unfortunately, as gem creators, we don't have options for checking the dependency, so you should take care about it by yourself. In that case you probably have it in your decencies, because you have to have it configured. Only version validation is still missing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see this that way - Sentry is clearly dependency here. Its compatibility needs to be ensured somewhere - either in the client app or the gem side.
I see no harm that user needs to download all the gems related with our plugins if we decided to keep them within the repo - it's still better that leave things unsecured in hope that nothing will blow up :)
We can still create some other gems like eventboss-extensions
where all the plugins would be downloaded if the user really wants to. We could provide event greater granularity by exposing things likeeventboss-rollbar
etc.
The third option would be to inform users that there's a hook for custom error handlers so that you can attach one if you want - in respect to your Gemfile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is not a place for this Eventboss::ErrorHandlers::Sentry
:
- This class introduces external dependancy
Sentry
and it's unnecessary:
What if I'm using rollbar? Then I wouldn't need to load additional gem. - Scenario when I'm having different implementation and I don't want to use this one - unnecessary require.
What I would suggest is to just simply pass lambda to error_handlers
in Eventboss
initializer:
Eventboss.configure do |config|
config.eventboss_app_name = ['EVENTBUS_APP_NAME']
config.logger = Rails.logger
config.error_handlers << lambda do |exception, context = {}|
# code
end
config.log_level = Rails.configuration.log_level
end
And dependency to Sentry
only lives in your application
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that anyway by default these files from error_handlers
are not loaded. So far nor Rollbar neither AirBrake gems were not marked as eventboss dependency.
As eventboss
user I would like to delegate anything to this lib. With lambda approach every client app would need to get dig into what can be in context
which basically requires digging deep into eventboss, sqs etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As eventboss user I would like to delegate anything to this lib. With lambda approach every client app would need to get dig into what can be in context which basically requires digging deep into eventboss, sqs etc.
That's fair point! I think we can proceed with class like this 👍
|
||
::Sentry.with_scope do |scope| | ||
scope.set_tags( | ||
context.merge(eventboss_context, default_options) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would remove default_options
as it adds no value to merge an empty Hash :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, I would rather do this:
context.merge(eventboss_context, default_options) | |
eventboss_context.merge(context) |
But let's do like this to have the same way as it was in rollbar:
context.merge(eventboss_context, default_options) | |
context.merge(eventboss_context) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Applied 👍
scope.set_tags( | ||
context.merge(eventboss_context, default_options) | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AdamMarkowski What do you think about segregating the event data this way:
scope.set_tags( | |
context.merge(eventboss_context, default_options) | |
) | |
scope.set_tags(eventboss_context) | |
scope.set_context('context', context) | |
) |
Tags - As they are both indexed we will be able to filter and search Sentry issues by the tags.
Context - We cannot search them, but they are viewable on the Sentry issue page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that tags fits here, as they are :worker_id, :pooler_id and :processor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nnnande I chose set_tags
here because we have the ability to search through them, as opposed to context where we cannot - is it ok for you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, sounds reasonable - being able to filter stuff by tags will help with no doubts @AdamMarkowski
|
||
default_options = { } | ||
|
||
::Sentry.with_scope do |scope| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really, it's optional plugin, which makes Sentry will be required only when it's added in configuration.
class Sentry | ||
def call(exception, context = {}) | ||
eventboss_context = { component: 'eventboss' } | ||
eventboss_context[:action] = context[:processor].class.to_s if context[:processor] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's copied since airbrake. It's not beneficial as the information is in processor param.
eventboss_context = { component: 'eventboss' } | ||
eventboss_context[:action] = context[:processor].class.to_s if context[:processor] | ||
|
||
default_options = { } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
copy pasta :)
|
||
::Sentry.with_scope do |scope| | ||
scope.set_tags( | ||
context.merge(eventboss_context, default_options) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, I would rather do this:
context.merge(eventboss_context, default_options) | |
eventboss_context.merge(context) |
But let's do like this to have the same way as it was in rollbar:
context.merge(eventboss_context, default_options) | |
context.merge(eventboss_context) |
4a79b05
@AdamMarkowski @wojtih @rapsad it's released:
444 |
Jira: https://airhelp.atlassian.net/browse/ECHO-1987
To make the Sentry integration easier for applications leveraging Eventboss.