Skip to main content
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.

Ce qu’AppSignal instrumente pour Rails

Dans les applications Rails, AppSignal instrumente automatiquement les composants et événements Rails suivants :
  • Requêtes de contrôleur (Action Controller) : AppSignal signale les échantillons de performance et les exceptions, regroupés par action de contrôleur, par exemple UsersController#show. Les échantillons peuvent inclure les paramètres de requête filtrés, les données de session, les en-têtes, le chemin de la requête, la méthode de la requête, l’ID de la requête, le statut de la réponse et le queue time, lorsqu’il est disponible.
  • Rendu des vues (Action View) : AppSignal signale des événements pour le rendu des templates (render_template.action_view) et le rendu des partials (render_partial.action_view) dans la chronologie de la requête.
  • Requêtes de base de données et chargement des modèles (Active Record) : AppSignal signale des événements pour les requêtes SQL (sql.active_record) et l’instanciation des modèles (instantiation.active_record) dans la chronologie de la requête.
  • Background jobs (Active Job) : AppSignal signale l’exécution des jobs, les événements de mise en file d’attente, le queue time, les arguments du job, la queue, la priorité, l’ID Active Job, l’ID du job du provider et les métriques de statut des jobs.
  • Canaux WebSocket (Action Cable) : AppSignal signale les actions de canal, les callbacks de subscribe et les callbacks d’unsubscribe.
  • Traitement des mailers (Action Mailer) : AppSignal signale un compteur action_mailer_process pour chaque événement process.action_mailer, avec des tags pour le mailer et l’action.
  • Reporter d’erreurs Rails : AppSignal signale les erreurs envoyées via ActiveSupport::ErrorReporter, avec des tags de sévérité et de source.
  • Runners Rails : AppSignal signale les erreurs des runners Rails. Les performances nécessitent une instrumentation manuelle.
Les requêtes vers l’endpoint de health check de Rails, Rails::HealthController#show, sont ignorées par défaut via l’option ignore_actions. Les erreurs levées pendant le démarrage de l’application, avant l’exécution des initialiseurs, ne sont pas signalées par défaut. Consultez Signalement des erreurs depuis les initialiseurs.

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.
Ensuite, dans l’initialiseur :
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.
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 :
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.
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.

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.

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

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

Attributs de span

Mode collector uniquement : ceci s’applique lorsqu’AppSignal pour Ruby s’exécute en mode collector. Cela n’a aucun effet dans les autres cas.
Le span de la requête porte :
  • http.request.method — la méthode de la requête.
  • url.scheme, url.path et url.query — l’adresse demandée.
  • http.response.status_code — le statut avec lequel votre application a répondu.
Un span pour une requête qui a levé une erreur porte aussi error.type, la classe de l’erreur. Chaque requête Active Record enregistre son propre span, qui comporte :
  • db.system.name — la base de données sur laquelle la requête s’est exécutée, comme postgresql ou mysql.
  • db.query.text — la requête, avec ses valeurs supprimées.

Tracing distribué

Mode collector uniquement : ceci s’applique lorsqu’AppSignal pour Ruby s’exécute en mode collector. Cela n’a aucun effet dans les autres cas.
Une requête qui arrive avec un en-tête de requête traceparent poursuit la trace qu’il désigne. La requête apparaît au sein de la trace du service appelant, sous la requête qui l’a provoquée. Vous pouvez suivre une requête lente depuis ce service jusque dans cette application, sans changer de trace. Les clients HTTP pris en charge par AppSignal démarrent la trace. Une requête sans cet en-tête en démarre une nouvelle.