Passer au contenu principal
Ruby on Rails est pris en charge d’emblée par AppSignal. Pour l’installation, suivez les étapes d’installation dans AppSignal, en commençant par cliquer sur « Add app » sur l’écran des comptes. L’intégration AppSignal pour Rails fonctionne en suivant les exceptions et les performances dans les requêtes. Lorsqu’une erreur se produit dans un contrôleur lors d’une requête, AppSignal la signale. Les problèmes de performances seront basés sur la durée d’une requête et créeront une chronologie des événements détaillant quelles parties de l’application ont pris le plus de temps.

​
Active Job

Consultez notre page Active Job pour plus d’informations sur le fonctionnement de notre instrumentation Active Job.

​
Action Cable

Consultez notre page Action Cable pour plus d’informations sur le fonctionnement de notre instrumentation Action Cable.

​
Configurer AppSignal dans un initialiseur

Nous recommandons d’utiliser notre fichier de configuration config/appsignal.rb ou les variables d’environnement pour configurer AppSignal. Par défaut, il n’est pas possible de configurer AppSignal depuis un initialiseur Rails, car AppSignal se charge avant les initialiseurs de votre application, afin de pouvoir signaler les erreurs survenant lors de l’initialisation. Pour configurer AppSignal dans un initialiseur Rails, configurez d’abord Rails pour qu’il démarre AppSignal après l’exécution des initialiseurs de l’application. 
# config/application.rb

# ...

module MyApp
  class Application < Rails::Application
    # Add this line
    config.appsignal.start_at = :after_initialize

    # Other config
  end
end
Ensuite, dans l’initialiseur : 
# config/initializers/appsignal.rb

Appsignal.configure do |config|
  config.ignore_actions = ["My action"]
end
N’appelez pas Appsignal.start dans les initialiseurs. La gem Ruby démarrera AppSignal automatiquement lorsque Rails aura exécuté tous les initialiseurs. Lorsqu’une application Rails est configurée pour démarrer AppSignal après le chargement des initialiseurs, il n’est plus possible de signaler les erreurs des initialiseurs lors du démarrage de l’application Rails.

​
Signalement des erreurs depuis les initialiseurs

Par défaut, AppSignal signale les erreurs qui se produisent dans les contrôleurs, les tâches Rake et les jobs Active Job. Il ne signale pas les erreurs qui se produisent lorsque l’application démarre, avant les initialiseurs Rails. Pour être notifié lorsque ces erreurs se produisent, ajoutez ce qui suit à votre fichier config.ru, autour de la ligne qui requiert le fichier environment.rb. 
# config.ru
begin
  require ::File.expand_path("../config/environment",  __FILE__)
rescue Exception => error
  Appsignal.send_error(error)
  raise
end
Les erreurs qui se produisent ici ne seront pas regroupées sous un incident avec un nom d’action.

​
Nettoyeur de backtrace

Avec l’intégration Rails, AppSignal exécutera le backtrace de chaque exception via le nettoyeur de backtrace Rails. Ce nettoyeur vous offre la possibilité de modifier ou de filtrer les lignes de backtrace indésirables, en supprimant l’encombrement et le bruit du backtrace. Vous pouvez ajouter ou supprimer des filtres et des silencieux à la configuration par défaut. Les filtres muteront la ligne donnée. Un exemple serait de supprimer le préfixe Rails.root. Les silencieux supprimeront la ligne du backtrace, si l’expression donnée renvoie true. Vous pouvez ajouter ces règles supplémentaires de nettoyeur de backtrace dans un initialiseur. Par exemple : 
# 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 }
Pour plus d’informations sur le nettoyeur de backtrace, consultez la documentation BacktraceCleaner de Rails.

​
Reporter d’erreurs

AppSignal signale par défaut les erreurs levées via ActiveSupport::ErrorReporter. ActiveSupport::ErrorReporter a été introduit dans Rails 7.0 pour standardiser le signalement personnalisé d’erreurs. Vous pouvez désactiver cette fonctionnalité avec l’option de configuration enable_rails_error_reporter. Si une transaction est active dans le contexte où une erreur est signalée via le reporter d’erreurs Rails, elle inclura les mêmes métadonnées et données d’échantillon que la transaction active : namespace, nom d’action, tags, données personnalisées, paramètres, etc. 
# In both scenarios, the error is reported by AppSignal
Rails.error.handle do
  raise "some error"
end

Rails.error.record do
  raise "some error"
end
Dans la version 3 de la gem AppSignal for Ruby, certains comportements étaient différents. Veuillez consulter la section comportement hérité de la gem Ruby 3 pour plus d’informations sur les différences.

​
Namespace et action depuis la transaction actuelle

Lors du signalement des erreurs, nous déterminons le namespace et le nom d’action dans lesquels elles se produisent, comme un contrôleur ou un job en arrière-plan, au mieux de nos capacités. Le namespace de l’incident et le nom d’action ne seront pas toujours définis ou précis. Si une transaction AppSignal est active (comme dans une requête web ou un job en arrière-plan), l’erreur signalée avec Rails.error.handle/record aura le même namespace, le même nom d’action, les mêmes tags, paramètres, données personnalisées, etc. que la transaction active. Si aucune transaction AppSignal n’est active, aucun namespace, nom d’action, tags, etc. ne seront définis par défaut.

​
Namespace et action depuis le contexte

Si vous souhaitez modifier le namespace et le nom d’action de l’erreur signalée sans les modifier sur la transaction AppSignal déjà active, vous pouvez personnaliser cela lors de l’appel au reporter d’erreurs. 
# 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 depuis la transaction active

Par défaut, les tags de la transaction de la requête/job sont copiés sur la transaction AppSignal de l’erreur du reporter d’erreurs depuis la transaction de la requête/job. 
# Rails controller example using a before_action callback
class ExamplesController < ApplicationController
  before_action do
    Appsignal.add_tags(: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 depuis le contexte

Vous pouvez ajouter des tags à une erreur signalée en utilisant context dans l’appel Rails.error.handle/record. Ces tags ne seront définis que sur l’erreur signalée avec les méthodes Rails.error.handle/record. 
Rails.error.handle(:context => { :tag1 => "value1", :tag2 => "value2" }) do
  raise "some error"
end
Les mêmes limitations de tagging s’appliquent que pour l’utilisation de Appsignal.add_tags.

​
Comportement hérité de la gem Ruby 3

Dans la gem AppSignal for Ruby version 3, le comportement de signalement d’erreurs est différent.
  • Les erreurs signalées avec la méthode Rails.error.handle sont signalées à AppSignal.
  • Les erreurs signalées avec Rails.error.record ne sont pas signalées à AppSignal pour éviter de signaler l’erreur deux fois lorsqu’elle est signalée par notre middleware de signalement d’erreurs Rails.
Toutes les erreurs signalées avec le reporter d’erreurs Rails sont signalées comme des erreurs distinctes. Elles n’incluent pas toujours les mêmes métadonnées et données d’échantillon d’une transaction AppSignal active. Consultez la section limitations d’héritage du contexte pour plus d’informations. 
# Reported by AppSignal
Rails.error.handle do
  raise "some error"
end

# NOT reported by AppSignal
Rails.error.record do
  raise "some error"
end

​
Limitations d’héritage du contexte

Dans la gem Ruby 3, l’héritage du contexte de la transaction active est limité. Les métadonnées et certaines données d’échantillon ne sont copiées que si elles sont définies au moment où Rails.error.handle/record est appelé. En pratique, cela signifie que les contrôleurs Rails et les jobs Active Job seront signalés avec précision. Pour d’autres bibliothèques comme les jobs Sidekiq, aucun nom d’action n’est défini lors du signalement des erreurs avec Rails.error.handle. Les tags définis après l’appel de Rails.error.handle/record ne sont pas signalés pour l’erreur signalée à l’aide de cet assistant.

​
Runners

AppSignal signalera automatiquement les erreurs à l’intérieur des runners Rails. Une configuration manuelle est également requise pour instrumenter les performances d’un runner. Nous recommandons de placer le code du runner dans un fichier séparé et de l’envelopper dans l’assistant Appsignal.monitor, comme dans l’exemple ci-dessous.
Bash
bin/rails runner path_to_file.rb

Appsignal.monitor(:namespace => :runner, :action => "Runner name") do
  # Some code
end
Si votre runner Rails s’exécute sur un conteneur qui n’est démarré que pour exécuter cette tâche, assurez-vous que l’option enable_at_exit_hook est définie sur true (ce qui devrait être la valeur par défaut sur les conteneurs). Cela garantira que les données sont vidées vers l’agent AppSignal avant que le runner ne s’arrête.