This is the step by step guide to install and configure Sentry Raven logger in the Ruby on Rails project in 2023.
Let's learn all about configuring Sentry for Ruby on Rails monitoring...
Sentry is a realtime application monitoring and error tracking software which one can visit anytime via a web browser.
Applications can communicate with Sentry via the HTTP protocol, sending data about their crashes and exceptions.
Developers subscribe to Sentry's notifications and can almost instantly react to production problems by easily pinpointing them via sophisticated UI, which provides a complete set of data necessary for the job.
- It is free to use up to 5000 API requests per month.
- It gathers more data than the default Ruby on Rails logger.
- It provides an intuitive UI, which is more comfortable to work with than primitive log files.
Ruby on Rails is provided with a basic logger that writes to the selected file, or files. Reading a single file with the constantly appended massive stack traces is a primitive way to monitor the application.
Sentry collects and aggregates Ruby on Rails application crashes and exceptions data, with an additional context, such as a suspected release that started to cause the problem.
Via a sophisticated Sentry web UI developer can browse errors by the latest, most occurrent and multiple additional pieces of information provided.
I cannot stress enough how crucial it is that your Ruby on Rails application is hooked up with an advanced logging and monitoring system such as Sentry from its day one on production.
Follow the instructions below to create your Sentry account and set up the Ruby on Rails project for further monitoring.
- Sign up on the official Sentry website Sign up form on the Sentry official website
- In the second onboarding step, select "Rails" platform Select 'Rails' platform in the Sentry setup
- From the third onboarding step copy your Sentry DSN "Copy Sentry DSN")
The DSN abbreviation stands for Data Source Name and is autogenerated for every project that you are going to hook into your Sentry account.
It allows you to keep all the logs in one place, which comes very handy especially for multiple services monitored daily.
If you use our Ruby on Rails Template, your job is done here, all you gonna do is paste your Sentry DSN into the second step of the Hix on Rails project initialization wizard.
Otherwise, if you sadly did not automate that part of your life yet, follow steps below for Ruby on Rails Sentry configuration.
- Open your projects
Gemfileand paste the
gem 'sentry-rails'so they're available for every environment.
- In a command-line navigate to the project's directory, enter
bundle installand while it runs go to the next step.
- Create the
config/initializers/sentry.rbfile and paste the minimal configuration required, replacing the value with previously copied Sentry DSN.
Sentry.init do |config| config.dsn = 'YOUR_SENTRY_DSN_GOES_HERE' end
This is a minimal setup required to hook up your Ruby on Rails application
with your newly created Sentry account, via the dedicated
It is overall a better idea to not store credentials in your project
repository and use dedicated environmental management instead. For example, if
you use a
dotenv-rails gem, it is a
better idea to provide your DSN via the
Sentry.init do |config| config.dsn = ENV['SENTRY_DSN'] end
Let's see what other configuration options are worth tweaking while monitoring Ruby on Rails project with Sentry.
With the minimalistic setup, we started to report Ruby on Rails application exceptions to the Sentry.
Sentry default configuration with the DSN passed at this point is:
Sentry.init do |config| config.app_dirs_pattern = nil config.debug = false config.background_worker_threads = Concurrent.processor_count config.backtrace_cleanup_callback = nil config.max_breadcrumbs = BreadcrumbBuffer::DEFAULT_SIZE config.breadcrumbs_logger =  config.context_lines = 3 config.include_local_variables = false config.environment = environment_from_env config.enabled_environments =  config.exclude_loggers =  config.excluded_exceptions = IGNORE_DEFAULT.dup config.inspect_exception_causes_for_exclusion = true config.linecache = ::Sentry::LineCache.new config.logger = ::Sentry::Logger.new(STDOUT) config.project_root = Dir.pwd config.propagate_traces = true config.sample_rate = 1.0 config.send_modules = true config.send_default_pii = false config.skip_rake_integration = false config.send_client_reports = true config.auto_session_tracking = true config.trusted_proxies =  config.dsn = ENV['SENTRY_DSN'] config.server_name = server_name_from_env config.instrumenter = :sentry config.before_send = nil config.before_send_transaction = nil config.rack_env_whitelist = RACK_ENV_WHITELIST_DEFAULT config.traces_sample_rate = nil config.traces_sampler = nil config.enable_tracing = nil end
By default, whenever provided a valid DSN, Sentry will work automatically in every Ruby on Rails environment, where the defaults are test, development, and production.
That's overkill for the development environment, so my advice is to further configure it after checking if it works.
Sentry.init do |config| config.enabled_environments = %w[production staging] end
This way an automated test suite and development of new features won't eat up your quota.
Another closely related option that is wisely deduced by Raven is current environment detection.
- First, Sentry tries to get
- Next, if first is absent, it tries
You can customize it via the current environment configuration flag.
Sentry.init do |config| config.environment = 'staging' end
Whatever you'll set here, will be visible in the Sentry environments dropdown.
Sentry filtering by environments
Error logging is not the primary task of most of the web applications,
including Ruby on Rails. It is good to keep it asynchronous, and Sentry does
that by default with the newest gem. The
async option exists for backward
compatibility reasons only, and is not recommended in new projects.
Sentry.init do |config| config.background_worker_threads = 5 end
Sentry for Ruby on Rails provides two configuration options for data sanitization.
Sentry.init do |config| config.sanitize_fields = ["my_field", "foo(.*)?bar] config.sanitize_http_headers = %w[Referer User-Agent Server From] end
The field sanitization accepts a raw string and regex-like strings for striping the data from the requests sent to Sentry.
The second one allows you to filter out HTTP headers from the payload. A full list of potentially sensitive HTTP headers can be found in the RFC 2616.
Another option that might be especially useful for large applications is data sampling.
Sentry.init do |config| config.sample_rate = 0.5 end
A value of
0 will deny sending any events, and value of
1 will send every
single event, which is the default behavior.
Sentry is clever in deducing which release causes an exception. It takes the following in the given order of precedence.
- Commit SHA of the last git commit
- Last line of the application root REVISION file
- For Heroku, dyno metadata enabled via Heroku Labs It can be customized if you have some kind of custom release tracking system.
Sentry.init do |config| config.release = 'custom release string' end
The default settings may be configured smoothly with popular git remote providers such as Github and Gitlab for convenient linking to the guilty git commits and tags via Sentry UI.
Sentry is a powerful tool that helps you to keep the Ruby on Rails application well-maintained and is definitely worth using if you want to monitor every newly developed feature seriously.
With our Ruby on Rails template, all you need to do in order to have a fully configured Sentry logger is creating your account and copy-pasting the Sentry DSN into the project initialization wizard.