Skip to main content
Présenté par Chris Oliver pour GoRails. Republié sur AppSignal le 25 septembre 2026. Vous avez travaillé pendant des mois sur l’idée de votre application. Vous la déployez en production, et testez l’inscription ainsi que les autres fonctionnalités pour vous assurer que tout fonctionne. Puis vous lancez votre produit. Les inscriptions commencent, ce qui est une bonne chose. Mais des messages de clients arrivent alors dans votre boîte mail avec des plaintes :
  • Les pages se chargent très lentement.
  • Quand j’essaie de réinitialiser mon mot de passe, l’email pour terminer le processus n’arrive jamais.
  • L’application est-elle cassée ?
C’est à ce moment que vous remarquez qu’il vous manque de la visibilité sur la production, et que vous réalisez que vous devez vous inscrire à AppSignal. Chris installe le gem appsignal dans une application Ruby on Rails déployée sur Hatchbox. Il le configure à la main pour que vous puissiez voir ce que fait chaque option. Puis il la déploie, et utilise AppSignal pour trouver une erreur rencontrée par ses utilisateurs.
Vous voulez qu’un agent de codage IA se charge de l’installation ? Suivez Configurer une nouvelle application avec l’IA.

Ce que ce tutoriel couvre

  • Ajouter le gem AppSignal pour Ruby et exécuter la commande d’installation.
  • Choisir les environnements qui remontent des données à AppSignal.
  • Garder votre Push API key hors de votre repository grâce aux credentials chiffrées de Rails.
  • Ignorer les actions et namespaces bruyants, et signaler une révision à chaque déploiement.
  • Vérifier que les données arrivent, puis investiguer la première erreur réelle rencontrée par vos utilisateurs.

Prérequis

Installer AppSignal

Une fois inscrit, choisissez le framework ou le langage utilisé par votre application. Dans ce walkthrough, il s’agit d’une application Ruby on Rails déployée sur Hatchbox. Le flux de configuration IA d’AppSignal peut aussi l’identifier à partir de l’environnement de votre application et exécuter l’installation. Ou faites à l’ancienne, comme dans ce walkthrough, et installez tout manuellement depuis le flux d’interface d’AppSignal :
  1. Sélectionnez d’abord Add app, puis choisissez Ruby & Rails.
  2. Ajoutez le gem d’intégration AppSignal pour Ruby à votre Gemfile comme ceci :
  3. Exécutez bundle install pour télécharger et installer le gem AppSignal pour Ruby.
  4. Enfin, configurez-le avec la Push API key de votre organisation.
La commande d’installation vérifie votre Push API key. Elle demande ensuite si vous voulez un nom plus convivial pour votre application, et quel fichier de configuration utiliser. Ce walkthrough refuse le renommage et choisit le fichier de configuration Ruby, si bien que config.name conserve le nom détecté par l’installateur. L’assistant envoie ensuite une erreur d’exemple à AppSignal. Il vérifie votre installation en attendant que cette erreur arrive. Pour les commandes et les prérequis les plus récents et détaillés, consultez également la documentation sur l’installation d’AppSignal pour Ruby.

Utiliser le fichier de configuration Ruby

La commande d’installation écrit vos réponses dans config/appsignal.rb. Comme la configuration est un fichier Ruby, chaque modification que vous faites est enregistrée dans votre repository Git. Cela aide si vous voulez plus tard changer des choses ou les annuler. Par défaut, AppSignal ne s’active que dans les environnements development et production.
Généralement, les environnements de développement servent à tester et à casser des choses. Vous pourriez par exemple remplacer l’environnement par défaut "development" par "staging". Vous pouvez alors détecter les erreurs et les corriger avant qu’elles n’arrivent en production.

Stocker les credentials en toute sécurité

Exécutez rails credentials:edit pour ouvrir votre éditeur, collez votre Push API key AppSignal, et enregistrez-la comme secret. Copiez ensuite le contenu de config/master.key dans votre presse-papiers. Sur macOS, exécutez cat config/master.key | pbcopy. Allez ensuite dans votre environnement d’hébergement, par exemple Hatchbox, et définissez-le comme variable d’environnement RAILS_MASTER_KEY.

Ignorer les actions, les namespaces, et configurer un fichier de révision

Les nouvelles applications Rails ont une route par défaut appelée /up, que vous pouvez voir dans config/routes.rb. Elle est intégrée à Rails et renvoie un statut 200 ou 500 pour montrer si votre application fonctionne. C’est utile pour les vérifications d’uptime et de santé effectuées par votre load balancer afin de vérifier que votre application est bien active. Votre load balancer sollicite cette route toutes les quelques secondes. Vous n’avez pas toujours besoin de remonter cette route, ni les autres routes très sollicitées, à AppSignal. Autrement, laissez AppSignal collecter des données et surveiller votre application pendant les 24 heures suivantes. Regardez ce qu’elle rapporte, et ajustez-la plus tard.
Ignorez les métriques et les messages Action Cable liés au namespace action_cable. Cela peut être utile car les WebSockets dans Action Cable de Rails génèrent probablement une quantité considérable de bruit. Disons que votre application Hatchbox envoie constamment des événements en temps réel et des messages de log aux navigateurs. Cela pourrait épuiser votre quota AppSignal si ce namespace est actif. Enfin, votre déploiement Hatchbox écrit un fichier de révision qui contient le SHA de votre commit Git. config.revision lit ce fichier, si bien qu’AppSignal relie toutes les métriques, erreurs, logs et tout autre élément remonté à ce déploiement. Utilisez ce fichier pour suivre les erreurs que vous corrigez et pour lesquelles vous déployez des changements. Si elles reviennent après votre déploiement, AppSignal vous indique que ces erreurs n’ont pas vraiment été corrigées.
Voici le fichier complet de notre walkthrough.
Committez la configuration et poussez-la vers votre repository :

Déployer votre application

Après avoir enregistré dans votre repository Git, passez à votre plateforme de déploiement et de gestion de serveur, comme Hatchbox. Assurez-vous que la valeur de votre master key Rails correspond à config/master.key, puis déployez votre application. Vous devriez voir un environnement production s’ajouter à AppSignal. Il apparaît à côté de votre environnement development et de l’erreur de démonstration que vous avez envoyée lors de l’installation. Une fois votre déploiement prêt, AppSignal affichera les métriques et les requêtes de votre application sur les dashboards. Passez à l’environnement production pour observer les requêtes arriver.

Retrouver l’erreur signalée par vos utilisateurs

Vous pouvez ensuite essayer de reproduire l’erreur rencontrée par vos utilisateurs, comme l’email de réinitialisation de mot de passe qui n’est jamais arrivé :
  1. Allez sur vos dashboards et vérifiez le graphique « Error rate (%) ». AppSignal sépare les requêtes web des background jobs, comme Solid Queue, dans leurs propres namespaces.
  2. Sélectionnez Errors > Issue list et ouvrez l’erreur que vous voulez examiner de plus près. Elle affichera le message d’erreur et la backtrace, par exemple « Make sure your API key is set ».
  3. Dans Hatchbox, définissez la clé API Resend manquante dans vos Environment Variables, et enregistrez-la. Cela fait disparaître l’erreur rencontrée par vos utilisateurs. Dans ce walkthrough, la clé manquante appartient à Resend, le service par lequel l’application envoie ses emails. Créez une clé API dans Resend avec un accès en envoi pour tous les domaines, puis définissez-la dans Hatchbox. Tant que vous n’avez pas vérifié de domaine, un compte de test Resend ne livre qu’à sa propre adresse de test. Envoyez la réinitialisation de mot de passe à delivered@resend.dev, et vérifiez que l’email arrive dans votre dashboard Resend.
  4. Revenez dans Errors > Issue list d’AppSignal et, dans les Settings de votre erreur, définissez son statut sur « Closed ».
Les dashboards AppSignal affichent aussi un marker pour chaque déploiement et révision que vous effectuez. Vous pouvez voir les erreurs entre les déploiements. Le throughput indiquera si les choses ont ralenti après le déploiement d’une nouvelle fonctionnalité. Il y a bien plus encore que vous pouvez faire et investiguer dans votre application avec AppSignal. Les Intelligence dashboards sont aussi générés automatiquement pour les fonctionnalités Rails détectées par AppSignal. Dans ce walkthrough, il a détecté qu’Active Job envoyait des emails, et a généré des dashboards pour Action Mailer et Active Job. Chacun a son propre dashboard, montrant ce qui se passe dans cette partie de votre application Rails. Pour approfondir votre framework et votre langage de choix, consultez la documentation AppSignal pour Ruby. Elle explique comment AppSignal s’intègre à votre application et vous offre de la visibilité dessus.

Transcription

Transcrit à partir de la vidéo et légèrement édité. Les sous-titres automatiques ont mal compris plusieurs noms de produits et d’API, et ceux-ci ont été corrigés.
0:00 Imaginez ça : vous travaillez depuis des mois sur l’idée de votre produit, et elle est enfin prête. Vous l’avez déployée en production, vous vous êtes inscrit, vous avez tout testé, et ça a l’air de fonctionner parfaitement. Alors vous l’envoyez à vos amis, à votre famille, à votre newsletter, à vos comptes de réseaux sociaux, pour essayer d’obtenir des utilisateurs, et les gens commencent à s’inscrire, ce qui est une bonne chose.0:18 Jusqu’à ce que vous receviez des messages de gens disant : « Hé, cette page se charge vraiment lentement », ou des choses comme : « Hé, j’ai essayé de réinitialiser mon mot de passe », et l’email n’est tout simplement jamais arrivé. « C’est cassé ? Qu’est-ce qui se passe ? » Et vous réalisez : « Je n’ai aucune visibilité sur la production. Qu’est-ce que je fais ? » Eh bien, vous vous inscrivez à AppSignal.0:39 Alors aujourd’hui, nous allons installer AppSignal sur notre application Procrastinate ici, et nous allons commencer en nous inscrivant, bien sûr, à AppSignal, puis en l’installant dans notre application. Maintenant, quand vous faites ça, vous pouvez choisir de suivre le framework ou le langage de votre choix, pour nous, c’est Ruby on Rails, mais je recommanderais simplement d’utiliser leur prompt IA pour ça.1:00 Ils ont donc de la documentation et un prompt et tout est prêt, donc vous pouvez simplement copier-coller ça, le déposer dans Claude Code ou Codex ou ce que vous utilisez, et ça fera l’installation pour vous. Bien sûr, ça peut aussi configurer des choses, donc vous pouvez lui demander d’ajuster des paramètres, mais nous allons le faire à l’ancienne, manuellement, pour que vous puissiez voir exactement ce qui se passe en coulisses.1:24 Tout ce que nous avons à faire, c’est ajouter la bibliothèque, donc bundle add appsignal va télécharger et installer le gem Ruby d’AppSignal pour que nous puissions l’utiliser, et ensuite, bien sûr, nous devons le configurer pour utiliser notre clé API. Et c’est ce que cette commande d’installation va faire : elle va vérifier notre clé API, nous demander si nous voulons un nom plus convivial pour notre application, nous dirons non, puis comment nous voulons la configurer.1:47 Nous allons utiliser le fichier de configuration Ruby, donc tout ce que nous faisons sera enregistré dans notre repository Git, ce qui sera pratique plus tard quand nous changerons ça, peut-être que nous voudrons annuler certaines choses ou autre, et ça va envoyer une erreur d’exemple. Continuons donc avec cet assistant, et vous en apprendrez un peu plus sur le fonctionnement d’AppSignal, mais ensuite il va vérifier l’installation, il cherche cette erreur d’exemple qui est passée lors de notre installation.2:13 Pendant que ça se fait, ouvrons config/appsignal.rb et regardons quelle est sa configuration par défaut. D’abord, ça ne s’active que si on est dans l’un de ces environnements préconfigurés, donc development et production. Bien sûr, nous sommes en development sur notre machine locale, mais en production sur un serveur, nous aurons l’environnement production.2:36 Maintenant, je ne me soucie pas particulièrement de suivre les erreurs en development, parce que je casse souvent des choses en construisant des fonctionnalités, et ça enverrait des métriques et des erreurs et tout à AppSignal, et je n’ai pas besoin de ça, je ne vais pas vraiment les regarder. Donc je vais supprimer ça, et je pourrais le remplacer par staging, par exemple, et ça permettra à mon environnement staging de signaler les erreurs et tout, pour que je puisse les attraper et les corriger avant qu’elles n’arrivent en production, par exemple.3:03 Ensuite, vous pouvez bien sûr aussi le renommer ici, et votre Push API key est ce qui vous permet d’envoyer des données à AppSignal. Là, nous voulons en fait la retirer, nous ne voulons pas qu’elle soit codée en dur, donc nous allons écrire Rails.application.credentials.dig(:appsignal, :api_key). Ce que ça va faire, c’est utiliser les credentials chiffrées de Rails, pour que nous puissions stocker ce secret en toute sécurité dans les credentials chiffrées de notre repository Git.3:35 On va donc aller dans notre autre onglet ici et taper rails credentials:edit, ça va ouvrir notre éditeur, on descend tout en bas et on ajoute les clés correspondantes, AppSignal API key, et on colle ce secret. On sauvegarde ça, et ensuite tout ce qu’il nous reste à faire, c’est prendre la sortie de config/master.key, et je suis sur un Mac donc je peux utiliser pbcopy pour le copier dans le presse-papiers, et ensuite vous allez dans votre environnement d’hébergement.4:07 Pour nous, c’est Hatchbox, et vous allez définir RAILS_MASTER_KEY comme variable d’environnement avec cette valeur. Alors allez-y et faites ça, j’ai déjà configuré la mienne donc je n’ai pas besoin de le faire, mais nous allons continuer ici dans la configuration d’AppSignal.4:23 Il y a quelques autres choses que vous pourriez vouloir prendre en compte en configurant votre config AppSignal. L’une d’elles, c’est que vous voudrez probablement faire quelque chose comme ignorer le health controller, l’action show. Alors ouvrons notre fichier routes pour que vous voyiez exactement ça.4:44 Dans une nouvelle application Rails, depuis l’arrivée de Kamal, vous avez maintenant une route par défaut appelée /up, qui va vers un controller intégré à Rails qui dit simplement : « Hé, ton application Rails tourne. » C’est utile pour les vérifications d’uptime ou de santé par votre load balancer ou autre, et donc cette route ne fait pas vraiment grand-chose, mais elle est utile. C’est donc important, et elle sera sollicitée souvent, surtout si elle est derrière un load balancer qui fait des health checks actifs.5:13 Cette route est juste sollicitée toutes les quelques secondes pour dire : « Es-tu toujours en vie ? Es-tu toujours en vie ? » Oui, je suis toujours en vie, mais nous n’avons pas vraiment besoin que ces données soient remontées à AppSignal, donc j’aime bien les ignorer. D’autres routes qui pourraient être très sollicitées et que vous voulez ignorer, vous pourriez les ajouter ici, mais je dirais de laisser ça tranquille et de voir ce qui se passe en production, de voir quelles données AppSignal collecte sur les quatre prochaines heures ou 24 heures, peu importe, et ensuite vous pourrez ajuster les choses plus tard.5:44 Et bien sûr, vous pouvez utiliser l’IA pour analyser ça et ensuite ajuster les choses en conséquence. Pareil pour ignorer les erreurs, normalement je n’ajouterais rien à cette liste à moins de vraiment savoir qu’il y a quelque chose de spécifique que nous voulons ignorer, parce qu’évidemment nous voulons suivre les erreurs et les corriger, donc nous voulons en collecter le plus possible, surtout pour quelque chose comme les erreurs.6:06 Une chose que nous ne voulons peut-être pas collecter, c’est si nous ignorons des namespaces, nous pouvons dire que tous les messages et métriques Action Cable liés à ça, nous voulons les ignorer, donc tout ce qui est dans ce namespace dans AppSignal sera ignoré. Et c’est important parce que si vous utilisez les WebSockets dans Action Cable de Rails, le framework pour ça, ça va probablement générer énormément de bruit.6:33 Donc dans notre application Hatchbox, nous envoyons constamment des événements en temps réel et des messages de log au navigateur, et donc quand nous installons AppSignal et que ce n’est pas activé, nous épuisons notre quota vraiment très vite. Vous voudriez donc probablement laisser ça de côté pour votre installation initiale, puis revenir ajouter ce genre de chose plus tard, après une heure ou deux, ou une journée, peu importe. Une fois que vous avez eu le temps de voir ce que nous remontons réellement, ce qui est vraiment sollicité, si nous épuisons notre quota et notre plan AppSignal, alors nous pouvons ajuster ça.7:09 Bon, enfin et surtout, je veux mentionner config.revision. Donc, la façon dont Hatchbox déploie, on crée un fichier de révision qui montre ou contient le SHA du commit Git que vous avez déployé. Il y a plusieurs façons d’y accéder. Chaque hébergeur est un peu différent. Certains utilisent des variables d’environnement, nous aussi. Mais vous pouvez aussi personnaliser ça, par exemple en lisant le fichier, le fichier de révision, et faire en sorte que ce soit écrit comme le déploiement auquel toutes ces métriques ou erreurs ou tout autre élément remonté à AppSignal sont liés.7:45 C’est très utile parce que si vous corrigez une erreur et que vous déployez un changement censé la corriger, et que l’erreur réapparaît après ce déploiement, AppSignal peut alors vous prévenir et dire : « Hé, tu n’as pas vraiment corrigé ça. Tu pensais l’avoir fait, mais on l’a revue. » Et c’est peut-être un cas limite différent ou autre, mais ça vous aide à garder une trace de tout ça.8:04 Donc une fois que vous êtes notifié d’une erreur, si elle se produit cent fois, vous n’allez pas recevoir cent notifications. Mais si vous déployez et qu’elle revient, alors vous serez notifié à nouveau. Vous savez donc que : « Hé, ça n’a pas vraiment été corrigé. » Et c’est très, très utile à savoir.8:20 Ce sont donc quelques-unes des personnalisations par défaut que j’aime faire. Donc on va faire un git add de tous ces changements, et on va écrire git commit -m "Add appsignal". Et on va pousser ça vers notre repository Git, et on peut passer à notre application sur Hatchbox et déployer ces changements.8:40 Maintenant, dans votre environnement, rappelez-vous, j’ai mentionné que vous voulez avoir votre master key Rails définie, et on veut juste vérifier que cette valeur correspond exactement à ce qu’on avait dans notre presse-papiers ici, avec config/master.key, et c’est exactement la même chose. Donc une fois que ce déploiement est terminé et réussi, on pourra recharger notre application, elle redémarrera automatiquement bien sûr, mais on devrait alors voir un environnement production s’ajouter à AppSignal.9:12 Alors regardons ce qui a été créé jusqu’ici. Nous avons un environnement development pour AppsignalExample, l’application sur laquelle nous travaillons, et nous avons une erreur qu’il a signalée ici. Et si on regarde la liste des erreurs, on voit une Appsignal::Demo::TestError. C’est bien sûr l’erreur de test que la commande d’installation a envoyée. C’est ce qu’elle cherchait pendant qu’elle vérifiait l’installation, et elle l’a trouvée, donc tout était bon.9:40 C’est excellent. Notre déploiement a maintenant réussi. Rafraîchissons donc la page et voyons si des métriques sont envoyées à AppSignal. J’ai l’environnement development, mais maintenant on devrait voir un environnement production ici en haut, et on peut passer à celui-ci, et on devrait voir que des requêtes arrivent maintenant. J’ai fait par exemple trois requêtes par minute ici, ce qui est un bon signe que tout est bien branché.10:05 Essayons maintenant de reproduire cette erreur et de voir si elle apparaît aussi. On va sur « mot de passe oublié », on met notre adresse email, et on envoie ça. Pas d’erreur 500, rien de tel. Alors peut-être qu’il se passe quelque chose en arrière-plan, et on peut aller voir AppSignal et regarder s’il a capté quelque chose qu’on n’a pas vu visuellement en tant qu’utilisateur.10:24 Et maintenant on peut voir qu’une erreur est bien arrivée, et on a une erreur dans le namespace background. Donc ça a automatiquement séparé notre serveur Rails des background jobs, dans notre cas, Solid Queue. Et donc ça les a séparés, et vous pouvez aussi les voir ici dans des couleurs différentes. Comme ça s’est passé en arrière-plan, c’est une ligne bleue, et on peut aussi aller voir la liste des erreurs et creuser exactement ce qui n’allait pas.10:50 Nous utilisons Resend pour les emails, et il semble qu’on ait une erreur Resend. Alors cliquons dessus et regardons quel était le message d’erreur. « Make sure your API key is set. » Oh, j’ai complètement oublié de mettre ça. Donc pour nous, on peut aller sur Resend, créer une clé API, et on aura un AppSignal.11:11 Example, c’est le nom. On va lui donner un accès complet ou un accès en envoi pour tous les domaines, et ensuite on va copier ça et le mettre dans notre environnement. Donc je sais que c’est censé être une clé API Resend, on colle ça, on sauvegarde les changements, et on devrait maintenant être prêt, et on devrait pouvoir envoyer cet email et le faire fonctionner avec succès.11:35 Alors maintenant, essayons ça à nouveau, et je me suis rappelé que j’ai besoin d’utiliser une adresse email spéciale pour Resend pour tester, sans avoir encore de domaine valide, parce que je suis juste sur leur compte de test. Donc on va envoyer un email à delivered@resend.dev. Et dans leur dashboard, on devrait maintenant voir que « reset your password » vient d’arriver. J’ai juste créé ce compte pour qu’on puisse tester avec, mais on peut confirmer que maintenant nos background jobs fonctionnent et n’envoient plus d’erreurs, et qu’ils utilisent bien ma vraie clé API Resend.12:07 Donc cette erreur peut être considérée comme résolue, on peut y aller et la fermer nous-mêmes, mais on peut aussi voir que lors d’un autre déploiement, il y aura un autre point ici en bas, qui va collecter chaque déploiement qu’on fait, avec l’heure et la révision Git aussi. On pourra donc voir ça au fil du temps et voir les erreurs entre chacun de ces déploiements, et on peut aussi voir le throughput, pour que vous puissiez voir que les choses ont peut-être beaucoup ralenti après le déploiement d’une certaine fonctionnalité.12:38 Peut-être qu’on a dû corriger un problème de performance ou autre. Bien sûr, ce n’est que la partie visible de l’iceberg, AppSignal permet de faire bien plus que ça. Et par exemple, en rafraîchissant la page, on peut déjà voir leurs nouveaux dashboards pour Action Mailer et Active Job qui ont été générés automatiquement pour nous parce qu’il a détecté qu’on utilisait Active Job pour envoyer des emails.12:56 Donc ces deux fonctionnalités de Rails ont leurs propres dashboards spéciaux qui vous permettent de voir et d’obtenir des informations sur exactement ce qui se passe dans ces parties de vos applications Rails. Alors jetez un œil à la documentation pour approfondir votre framework et votre langage de choix, et voyez comment AppSignal peut mieux s’intégrer et vous donner de la visibilité sur vos applications.

À propos de ce tutoriel

Ce tutoriel suit, étape par étape, un screencast GoRails sur l’installation d’AppSignal dans une application Rails déployée sur Hatchbox, par Chris Oliver. Le screencast est l’œuvre originale. GoRails le publie, ainsi que le reste de la série, sur gorails.com.