Ruby on Rails

Ruby on Rails is supported out-of-the-box by AppSignal. To install follow the installation steps in AppSignal, start by clicking 'Add app' on the accounts screen.

The AppSignal integration for Rails works by tracking exceptions and performance in requests. When an error occurs in a controller during a request AppSignal will report it. Performance issues will be based on the duration of a request and create a timeline of events detailing which parts of the application took the longest.

Active Job

Support for Active Job for all adapters is available in Ruby gem 2.11.0 and newer.

See our Active Job page for more information.

Error reporting during start-up

By default AppSignal does not report errors that occur during the start/boot of your application. To do get notified when these errors occur, adding the following to your file, around the line that requires the environment.rb file.

# begin require ::File.expand_path("../config/environment", __FILE__) rescue Exception => error Appsignal.send_error(error) raise end

The errors that occur here will not be grouped under an incident with an action name.

Background jobs

AppSignal supports ActiveJob for several background job libraries, such as Sidekiq. Please see the full list of Ruby library integrations for more details.

Backtrace cleaner

With the Rails integration, AppSignal will run the backtrace of each exception through the Rails backtrace cleaner. This cleaner gives you the option to modify or filter out unwanted backtrace lines, removing clutter and noise from the backtrace.

You can add or remove filters and silencers to the default configuration.

Filters will mutate the given line. An example would be to remove the Rails.root prefix.

Silencers will remove the line from the backtrace, if the given expression returns true. You can add these additional backtrace cleaner rules in an initialize.

For example:

# config/initializers/backtrace_cleaner.rb bc = Rails.backtrace_cleaner bc.add_filter { |line| line.gsub(Rails.root.to_s, '<root>') } bc.add_silencer { |line| line.index('<root>').nil? and line.index('/') == 0 } bc.add_silencer { |line| line.index('<root>/vendor/') == 0 }

For more information about the backtrace cleaner, see the Rails BacktraceCleaner documentation.

Error reporter

Support for the Rails error reporter was added in AppSignal Ruby gem version 3.4.1.

AppSignal reports errors raised via ActiveSupport::ErrorReporter by default. ActiveSupport::ErrorReporter was introduced in Rails 7.0 to standardize custom error reporting.

  • Errors reported with the Rails.error.handle method are reported to AppSignal.
  • Errors reported with Rails.error.record are not reported to AppSignal to avoid reporting the error twice when it's being reported by our Rails error reporting middleware.

You can disable this functionality with the enable_rails_error_reporter configuration option.

# Recorded by AppSignal Rails.error.handle do raise "some error" end # NOT recorded by AppSignal Rails.error.record do raise "some error" end

All errors reported this way are reported as separate errors from the request transaction they occurred in. We do this because the error did not get reraised and did not cause a visible server error for the user.

Namespace and action from the current transaction

When reporting errors, we try to determine the namespace and action name in which it takes place, such as a controller or background job, on a best-effort basis. This means that the incident namespace and action name will not always be set or be accurate.

Rails controllers and Active Job jobs will be accurately reported. However, for other libraries like Sidekiq jobs, no action name is currently set when reporting errors with Rails.error.handle.

To report the namespace and action name, we rely on the currently active transaction to have this information available. If you customize the transaction namespace using Appsignal.set_namespace or action name using Appsignal.set_action, make sure this is called before Rails.error.handle. If the namespace and/or action are set using these methods, it will copy the namespace and action name from the request/job's transaction to the new transaction for the reported error. In practice this means moving set_namespace and set_action from after_action callbacks to before_action callbacks.

Please note that this also changes the namespace and action name for the transaction reported for the main request, meaning that normal errors, and errors reported using the error handler, are grouped on the same incident action name.

# Rails controller example using a before_action callback class ExamplesController < ApplicationController before_action do Appsignal.set_namespace("custom_namespace") Appsignal.set_action("CustomizedActionName#index") end def index # The error reported here will have the # "custom_namespace" namespace and # "CustomizedActionName#index" action name Rails.error.handle do raise "some error" end end end

Namespace and action from the context

If you want to change the reported error's namespace and action name without changing them on the request, you can customize this on the error reporter call.

# The error reported here will have the "custom_namespace" namespace # and "CustomizedActionName#index" action name Rails.error.handle(:context => { :appsignal => { :namespace => "custom_namespace", :action => "CustomizedActionName#index" } }) do raise "some error" end

Tags from the current transaction

By default, the request/job's transaction tags are copied to the error reporter's error transaction. The same limitation as for namespace and action names applies: make sure the tags are set before Rails.error.handle is called.

# Rails controller example using a before_action callback class ExamplesController < ApplicationController before_action do Appsignal.tag_request(:tag1 => "value1", :tag2 => "value2") end def index # The error reported here will have the same tags set # as in the `before_action` callback Rails.error.handle do raise "some error" end end end

Tags from context

You can add tags to a reported error by using context in the handle call:

Rails.error.handle(:context => { :tag1 => "value1", :tag2 => "value2" }) do raise "some error" end

The same tagging limitations apply as for using Appsignal.set_tags.