Bad software is everywhere, and we're tired of it. Sentry is on a mission to help developers write better software faster, so we can get back to enjoying technology. If you want to join us Check out our open positions

Sentry SDK for Ruby

current version	build	coverage	downloads

Migrate From sentry-raven

The old sentry-raven client has entered maintenance mode and was moved to here.

If you're using sentry-raven, we recommend you to migrate to this new SDK. You can find the benefits of migrating and how to do it in our migration guide.

Requirements

We test on Ruby 2.4, 2.5, 2.6, 2.7, and 3.0 at the latest patchlevel/teeny version. We also support JRuby 9.0.

If you use self-hosted Sentry, please also make sure its version is above 20.6.0.

Getting Started

Install

gem "sentry-ruby"

and depends on the integrations you want to have, you might also want to install these:

gem "sentry-rails"
gem "sentry-sidekiq"
gem "sentry-delayed_job"
gem "sentry-resque"

Configuration

You can use Sentry.init to initialize and configure your SDK:

Sentry.init do |config|
  config.dsn = "MY_DSN"
end

To learn more about available configuration options, please visit the official documentation.

Performance Monitoring

You can activate performance monitoring by enabling traces sampling:

Sentry.init do |config|
  # set a uniform sample rate between 0.0 and 1.0
  config.traces_sample_rate = 0.2
  # you can also use traces_sampler for more fine-grained sampling
  # please click the link below to learn more
end

To learn more about sampling transactions, please visit the official documentation.

Integrations

• Rack
• Rails
• Sidekiq
• DelayedJob
• Resque

require 'sentry-ruby'

Sentry.init do |config|
  config.dsn = 'https://[email protected]/0'

  # To activate performance monitoring, set one of these options.
  # We recommend adjusting the value in production:
  config.traces_sample_rate = 0.5
  # or
  config.traces_sampler = lambda do |context|
    true
  end
end

use Sentry::Rack::CaptureExceptions

Otherwise, Sentry you can always use the capture helpers manually

Sentry.capture_message("hello world!")

begin
  1 / 0
rescue ZeroDivisionError => exception
  Sentry.capture_exception(exception)
end

We also provide integrations with popular frameworks/libraries with the related extensions:

• sentry-rails
• sentry-sidekiq
• sentry-delayed_job

More configuration

You're all set - but there's a few more settings you may want to know about too!

Logging with ActiveJob

By default, Sentry::SendEventJob will omit its arguments, since it amounts to a large and noisy Hash, which the Sentry frontend is designed to parse. If you want the arguments to be logged, ApplicationJob.log_sentry_arguments? must be truthy.

For example, the following ApplicationJob will only log Sentry arguments if ActiveJob's logger's level is debug or lower (i.e. more verbose).

class ApplicationJob < ActiveJob::Base
  def self.log_sentry_arguments?
    logger.level <= ::Logger::DEBUG
  end
end

Blocking v.s. Non-blocking

sentry-ruby sends events asynchronously by default. The functionality works like this:

1. When the SDK is initialized, a Sentry::BackgroundWorker will be initialized too.
2. When an event is passed to Client#capture_event, instead of sending it directly with Client#send_event, we'll let the worker do it.
3. The worker will have a number of threads. And the one of the idle threads will pick the job and call Client#send_event.

• If all the threads are busy, new jobs will be put into a queue, which has a limit of 30.
• If the queue size is exceeded, new events will be dropped.

However, if you still prefer to use your own async approach, that's totally fine. If you have config.async set, the worker won't initialize a thread pool and won't be used either.

About Sentry::BackgroundWorker

• The worker is built on top of the concurrent-ruby gem's ThreadPoolExecutor, which is also used by Rails ActiveJob's async adapter. This should minimize the risk of messing up client applications with our own thread pool implementaion.

This functionality also introduces a new background_worker_threads config option. It allows you to decide how many threads should the worker hold. By default, the value will be the number of the processors your machine has. For example, if your machine has 4 processors, the value would be 4.

Of course, you can always override the value to fit your use cases, like

config.background_worker_threads = 5 # the worker will have 5 threads for sending events

You can also disable this new non-blocking behaviour by giving a 0 value:

config.background_worker_threads = 0 # all events will be sent synchronously

Enriching Events

• Add more data to the current scope
• Add custom breadcrumbs
• Add contextual data
• Add tags

Resources

• 
• 
• 
• 
•