> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Ruby on Rails

export const Compatibility = ({versions = [], label = "Available in"}) => {
  if (!Array.isArray(versions) || versions.length === 0) {
    return null;
  }
  const defaultPillStyle = {
    borderColor: "#d4d4d8",
    background: "#f4f4f5",
    color: "#3f3f46"
  };
  const pillStyles = {
    "AppSignal for Elixir": {
      background: "#f3e8ff",
      borderColor: "#d8b4fe",
      color: "#6b21a8"
    },
    "AppSignal for Front-end": {
      background: "#fef9c3",
      borderColor: "#fde047",
      color: "#854d0e"
    },
    "AppSignal for Go": {
      background: "#ccfbf1",
      borderColor: "#5eead4",
      color: "#115e59"
    },
    "AppSignal for JavaScript": {
      background: "#fef9c3",
      borderColor: "#fde047",
      color: "#854d0e"
    },
    "AppSignal for Node.js": {
      background: "#dcfce7",
      borderColor: "#86efac",
      color: "#166534"
    },
    "AppSignal for Python": {
      background: "#dbeafe",
      borderColor: "#93c5fd",
      color: "#1e40af"
    },
    "AppSignal for Ruby": {
      background: "#fee2e2",
      borderColor: "#fca5a5",
      color: "#991b1b"
    },
    "AppSignal for Rust": {
      background: "#ffedd5",
      borderColor: "#fdba74",
      color: "#9a3412"
    }
  };
  const getPillStyle = name => ({
    ...defaultPillStyle,
    ...pillStyles[name] || ({})
  });
  return <div className="not-prose my-4 rounded-lg border border-zinc-200 bg-zinc-50 px-4 py-3 text-sm dark:border-white/10 dark:bg-white/5">
      <div className="flex flex-wrap items-center gap-x-2 gap-y-1">
        <span className="font-semibold text-zinc-700 dark:text-zinc-200">
          {label}:
        </span>
        {versions.map((v, i) => <span key={`${v.name}-${v.version}-${i}`} className="inline-flex items-center gap-1 rounded-full border px-2 py-0.5 text-xs font-medium" style={getPillStyle(v.name)}>
            <span>{v.name}</span>
            <span className="opacity-70">
              {v.version}
              {v.exact ? "" : "+"}
            </span>
          </span>)}
      </div>
    </div>;
};

[Ruby on Rails](http://rubyonrails.org/) 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](https://appsignal.com/accounts).

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

<Compatibility versions={[{ name: "AppSignal for Ruby", version: "2.11.0" }]} />

Consultez notre [page Active Job](/ruby/integrations/active-job) pour plus d'informations sur le fonctionnement de notre instrumentation Active Job.

## Action Cable

<Compatibility versions={[{ name: "AppSignal for Ruby", version: "2.3.0" }]} />

Consultez notre [page Action Cable](/ruby/integrations/action-cable) pour plus d'informations sur le fonctionnement de notre instrumentation Action Cable.

## Configurer AppSignal dans un initialiseur

<Compatibility versions={[{ name: "AppSignal for Ruby", version: "3.12.0" }]} />

Nous recommandons d'utiliser notre [fichier de configuration `config/appsignal.rb`](/ruby/configuration/load-order#appsignal-rb-config-file) ou les [variables d'environnement](/ruby/configuration/load-order#5-environment-variables) pour [configurer AppSignal](/ruby/configuration).
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.

<CodeGroup>
  ```ruby Ruby theme={null}
  # config/application.rb

  # ...

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

      # Other config
    end
  end
  ```
</CodeGroup>

Ensuite, dans l'initialiseur :

<CodeGroup>
  ```ruby Ruby theme={null}
  # config/initializers/appsignal.rb

  Appsignal.configure do |config|
    config.ignore_actions = ["My action"]
  end
  ```
</CodeGroup>

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](#error-reporting-from-initializers).

## 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`.

<CodeGroup>
  ```ruby Ruby theme={null}
  # config.ru
  begin
    require ::File.expand_path("../config/environment",  __FILE__)
  rescue Exception => error
    Appsignal.send_error(error)
    raise
  end
  ```
</CodeGroup>

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][backtrace cleaner docs]. 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 :

<CodeGroup>
  ```ruby Ruby theme={null}
  # 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 }
  ```
</CodeGroup>

Pour plus d'informations sur le nettoyeur de backtrace, consultez la [documentation BacktraceCleaner de Rails][backtrace cleaner docs].

## Reporter d'erreurs

<Compatibility versions={[{ name: "AppSignal for Ruby", version: "3.4.1" }]} />

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`](/ruby/configuration/options#option-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.

<CodeGroup>
  ```ruby Ruby theme={null}
  # 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
  ```
</CodeGroup>

<Warning>
  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](#ruby-gem-3-legacy-behavior) pour plus d'informations sur les différences.
</Warning>

### 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.

<CodeGroup>
  ```ruby Ruby theme={null}
  # 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
  ```
</CodeGroup>

### 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.

<CodeGroup>
  ```ruby Ruby theme={null}
  # 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
  ```
</CodeGroup>

### 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`.

<CodeGroup>
  ```ruby Ruby theme={null}
  Rails.error.handle(:context => { :tag1 => "value1", :tag2 => "value2" }) do
    raise "some error"
  end
  ```
</CodeGroup>

Les mêmes limitations de tagging s'appliquent que pour l'utilisation de [`Appsignal.add_tags`](/guides/tagging#ruby).

### 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](#context-inheritance-limitations) pour plus d'informations.

<CodeGroup>
  ```ruby Ruby theme={null}
  # Reported by AppSignal
  Rails.error.handle do
    raise "some error"
  end

  # NOT reported by AppSignal
  Rails.error.record do
    raise "some error"
  end
  ```
</CodeGroup>

#### 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

<Compatibility versions={[{ name: "AppSignal for Ruby", version: "4.0.0" }]} />

AppSignal signalera automatiquement les erreurs à l'intérieur des [runners Rails](https://guides.rubyonrails.org/command_line.html#bin-rails-runner). 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`](/ruby/instrumentation/background-jobs), comme dans l'exemple ci-dessous.

```bash Bash theme={null}
bin/rails runner path_to_file.rb
```

<CodeGroup>
  ```ruby Ruby theme={null}
  Appsignal.monitor(:namespace => :runner, :action => "Runner name") do
    # Some code
  end
  ```
</CodeGroup>

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`](/ruby/configuration/options#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.

[backtrace cleaner docs]: https://api.rubyonrails.org/classes/ActiveSupport/BacktraceCleaner.html

[error reporter]: https://guides.rubyonrails.org/error_reporting.html