Erreurs

AppSignal capture les exceptions levées par votre application, les regroupe pour faciliter le tri, et vous alerte lorsque quelque chose nécessite votre attention. Les erreurs sont étroitement liées aux traces : une erreur se produit généralement à l’intérieur d’une requête, d’une tâche en arrière-plan ou de l’exécution d’un script, et la trace environnante vous donne le timing et le contexte dont vous avez besoin pour la déboguer.

​

Comment AppSignal regroupe les erreurs

Lorsque votre application signale une exception, AppSignal la regroupe en un problème avec d’autres occurrences du même type d’erreur sur la même action et le même namespace. Un seul bug qui se déclenche des milliers de fois devient un seul problème à trier, et non des milliers d’alertes distinctes. Chaque problème conserve un ensemble d’traces : des occurrences représentatives avec le backtrace complet, les métadonnées de requête (telles que le hostname, la révision et le chemin de la requête) et tous les tags que vous ajoutez.

​

Voir les erreurs introduites par un déploiement

Le filtre Pick a revision sur la page des erreurs permet de limiter la liste des erreurs à un déploiement ou à une période. Ouvrez-le pour choisir une portée, comme By Revision (deploy), ou By Timeframe, qui couvre une plage de temps. Par défaut, le filtre est réglé sur All errors, qui liste tous les problèmes survenus du plus récent au plus ancien. Sélectionnez New errors pour ne lister que les erreurs qui y sont apparues pour la première fois :

• Most recent revisions : erreurs apparues pour la première fois depuis les révisions les plus récentes par service.
• A specific revision : erreurs apparues pour la première fois dans ce déploiement.
• A timeframe : erreurs apparues pour la première fois dans cette plage de temps. Choisissez une heure de début et de fin, ou un préréglage comme Last 24 hours ou Last 7 days.

Lorsque New errors est sélectionné, le libellé du filtre l’indique, par exemple New in revision a1b2c3d ou New in timeframe. Le bouton reste activé lorsque vous choisissez un autre déploiement ou une autre période. Il fait également partie de l’URL de la page, de sorte qu’un lien que vous partagez ouvre la même liste. Les marqueurs de déploiement indiquent à AppSignal quand chaque déploiement a eu lieu. Tant que vous ne les ajoutez pas, AppSignal comptabilise tout ce qui s’est passé depuis la création de l’application comme un seul déploiement. New errors sur Most recent revisions liste alors toutes les erreurs. Choisissez plutôt une période. Les outils d’IA que vous connectez à AppSignal MCP, comme Claude Code ou Cursor, peuvent obtenir la même liste. Ils utilisent le paramètre new_only de l’outil get_exception_incidents.

​

Tri et notifications

Chaque problème peut être assigné à un membre de l’équipe, doté d’un état et d’une gravité, et configuré avec ses propres paramètres de notification. AppSignal vous notifie via vos canaux configurés (e-mail, Slack et autres intégrations) lorsqu’une nouvelle erreur est détectée.

​

Namespaces

Les erreurs sont regroupées par namespace, afin que vous puissiez séparer les requêtes web des tâches en arrière-plan. Les namespaces par défaut sont Web et Background, et vous pouvez en configurer des personnalisés. Voir Namespaces pour les détails.

​

Alertes sur les taux d’erreur

Au-delà des notifications par erreur, la Anomaly detection peut vous alerter lorsque le taux d’erreur d’une application ou d’un namespace dépasse un seuil que vous définissez.

​

Signaler des exceptions gérées

Si vous interceptez vous-même une exception, vous pouvez toujours la signaler à AppSignal avec les méthodes auxiliaires fournies par votre SDK. Les noms exacts des helpers varient selon le SDK, mais l’objectif est le même : conserver l’erreur attachée à la trace, ou l’envoyer avec un contexte utile.

• Ruby : report_error, set_error, et send_error
• Elixir : Appsignal.set_error/2 et Appsignal.send_error/3
• Node.js : setError() et sendError()
• Python : set_error et send_error
• PHP : Gestion des exceptions
• JavaScript front-end : Gestion des erreurs

​

Ajouter du contexte de débogage

Pour faciliter l’investigation des erreurs, ajoutez plus de contexte avec :

• Tagging
• Liens de backtrace
• Performance / tracing

​

Voir aussi

• La gem Ruby debug : points d’arrêt, exécution pas à pas et la pile d’appels : utilisez la gem Ruby debug pour examiner un problème pendant que vous le reproduisez localement.
• params.expect : les strong parameters dans Rails 8 : Rails 8 ajoute params.expect pour autoriser et exiger des paramètres en une seule étape. Il rejette les formes de paramètres inattendues en tant que requêtes invalides.