Module: Gitlab::ErrorTracking
- Defined in:
- lib/gitlab/error_tracking.rb,
lib/gitlab/error_tracking/repo.rb,
lib/gitlab/error_tracking/error.rb,
lib/gitlab/error_tracking/logger.rb,
lib/gitlab/error_tracking/project.rb,
lib/gitlab/error_tracking/error_event.rb,
lib/gitlab/error_tracking/detailed_error.rb,
lib/gitlab/error_tracking/error_collection.rb,
lib/gitlab/error_tracking/processor/sidekiq_processor.rb,
lib/gitlab/error_tracking/processor/grpc_error_processor.rb,
lib/gitlab/error_tracking/stack_trace_highlight_decorator.rb
Defined Under Namespace
Modules: Processor, StackTraceHighlightDecorator Classes: DetailedError, Error, ErrorCollection, ErrorEvent, Logger, Project, Repo
Constant Summary collapse
- CUSTOM_FINGERPRINTING =
Exceptions in this group will receive custom Sentry fingerprinting
%w[ Acme::Client::Error::BadNonce Acme::Client::Error::NotFound Acme::Client::Error::RateLimited Acme::Client::Error::Timeout Acme::Client::Error::UnsupportedOperation ActiveRecord::ConnectionTimeoutError Gitlab::RequestContext::RequestDeadlineExceeded GRPC::DeadlineExceeded JIRA::HTTPError Rack::Timeout::RequestTimeoutException ].freeze
Class Method Summary collapse
- .configure ⇒ Object
-
.log_exception(exception, extra = {}) ⇒ Object
This should be used when you only want to log the exception, but not send it to Sentry.
-
.track_and_raise_exception(exception, extra = {}) ⇒ Object
This should be used when you want to passthrough exception handling: rescue and raise to be catched in upper layers of the application.
-
.track_and_raise_for_dev_exception(exception, extra = {}) ⇒ Object
This can be used for investigating exceptions that can be recovered from in code.
-
.track_exception(exception, extra = {}) ⇒ Object
This should be used when you only want to track the exception.
- .with_context(current_user = nil) ⇒ Object
Class Method Details
.configure ⇒ Object
20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
# File 'lib/gitlab/error_tracking.rb', line 20 def configure Raven.configure do |config| config.dsn = sentry_dsn config.release = Gitlab.revision config.current_environment = Gitlab.config.sentry.environment # Sanitize fields based on those sanitized from Rails. config.sanitize_fields = Rails.application.config.filter_parameters.map(&:to_s) config.processors << ::Gitlab::ErrorTracking::Processor::SidekiqProcessor config.processors << ::Gitlab::ErrorTracking::Processor::GrpcErrorProcessor # Sanitize authentication headers config.sanitize_http_headers = %w[Authorization Private-Token] config. = .merge(program: Gitlab.process_name) config.before_send = method(:before_send) yield config if block_given? end end |
.log_exception(exception, extra = {}) ⇒ Object
This should be used when you only want to log the exception, but not send it to Sentry.
If the exception implements the method `sentry_extra_data` and that method returns a Hash, then the return value of that method will be merged into `extra`. Exceptions can use this mechanism to provide structured data to sentry in addition to their message and back-trace.
107 108 109 |
# File 'lib/gitlab/error_tracking.rb', line 107 def log_exception(exception, extra = {}) process_exception(exception, extra: extra) end |
.track_and_raise_exception(exception, extra = {}) ⇒ Object
This should be used when you want to passthrough exception handling: rescue and raise to be catched in upper layers of the application.
If the exception implements the method `sentry_extra_data` and that method returns a Hash, then the return value of that method will be merged into `extra`. Exceptions can use this mechanism to provide structured data to sentry in addition to their message and back-trace.
64 65 66 67 68 |
# File 'lib/gitlab/error_tracking.rb', line 64 def track_and_raise_exception(exception, extra = {}) process_exception(exception, sentry: true, extra: extra) raise exception end |
.track_and_raise_for_dev_exception(exception, extra = {}) ⇒ Object
This can be used for investigating exceptions that can be recovered from in code. The exception will still be raised in development and test environments.
That way we can track down these exceptions with as much information as we need to resolve them.
If the exception implements the method `sentry_extra_data` and that method returns a Hash, then the return value of that method will be merged into `extra`. Exceptions can use this mechanism to provide structured data to sentry in addition to their message and back-trace.
Provide an issue URL for follow up. as `issue_url: 'gitlab.com/gitlab-org/gitlab/issues/111'`
84 85 86 87 88 |
# File 'lib/gitlab/error_tracking.rb', line 84 def track_and_raise_for_dev_exception(exception, extra = {}) process_exception(exception, sentry: true, extra: extra) raise exception if should_raise_for_dev? end |
.track_exception(exception, extra = {}) ⇒ Object
This should be used when you only want to track the exception.
If the exception implements the method `sentry_extra_data` and that method returns a Hash, then the return value of that method will be merged into `extra`. Exceptions can use this mechanism to provide structured data to sentry in addition to their message and back-trace.
96 97 98 |
# File 'lib/gitlab/error_tracking.rb', line 96 def track_exception(exception, extra = {}) process_exception(exception, sentry: true, extra: extra) end |
.with_context(current_user = nil) ⇒ Object
40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 |
# File 'lib/gitlab/error_tracking.rb', line 40 def with_context(current_user = nil) last_user_context = Raven.context.user user_context = { id: current_user&.id, email: current_user&.email, username: current_user&.username }.compact Raven.() Raven.user_context(user_context) yield ensure Raven.user_context(last_user_context) end |