Passer au contenu principal
Il n’y a pas de question stupide. Sur cette page, vous trouverez les réponses à celles qu’on nous pose le plus fréquemment. Si vous avez besoin d’une aide supplémentaire, consultez notre page d’assistance

​
Sommaire

​
Premiers pas

​
J’ai besoin d’aide pour démarrer. Où commencer ?

Si vous découvrez AppSignal ou souhaitez en savoir plus sur la configuration des fonctionnalités d’AppSignal, veuillez lire nos guides

​
Bibliothèques AppSignal

​
Quels langages de programmation AppSignal prend-il en charge ?

AppSignal prend en charge les langages de programmation Node.js, Ruby et Elixir. Nous proposons également des packages JavaScript pour capturer les erreurs côté client dans les navigateurs pris en charge.

​
Filtrer les données

​
Comment ignorer les actions dans mon application ?

Vous pouvez ignorer des actions pour cesser d’enregistrer les données de certaines actions, requêtes, tâches en arrière-plan, etc.

​
Comment ignorer les erreurs dans mon application ?

Vous pouvez ignorer des erreurs (en fonction de leur nom) pour empêcher AppSignal de les signaler et de vous alerter.

​
Comment filtrer les données envoyées à AppSignal ?

Pour découvrir comment filtrer les données envoyées à AppSignal, consultez l’un des guides suivants :

​
Quelle syntaxe regex ignore_logs prend-il en charge ?

ignore_logs prend en charge un sous-ensemble limité de la syntaxe des expressions régulières : ^ (début de chaîne), $ (fin de chaîne) et .* (joker). Les constructions regex complètes telles que les classes de caractères ([.]) ne sont pas valides et sont silencieusement ignorées. Pour faire correspondre une ligne de log exacte, encadrez-la avec ^ et $. Pour faire correspondre un préfixe, utilisez ^ suivi du texte littéral. Pour faire correspondre n’importe où dans le message, utilisez .* autour de celui-ci. Consultez le guide ignore logs pour la référence complète de la syntaxe.

​
Comment supprimer les logs envoyés par appsignal-wrap ?

appsignal-wrap transfère par défaut stdout et stderr vers AppSignal. L’option de configuration ignore_logs ne s’applique pas à appsignal-wrap. Pour supprimer la sortie, passez --no-stdout et/ou --no-stderr à la commande appsignal-wrap : 
appsignal-wrap --no-stdout --no-stderr your-api-key -- your-command
Ces drapeaux sont uniquement disponibles en CLI et ne peuvent pas être définis via des variables d’environnement. Consultez la documentation appsignal-wrap pour la liste complète des options.

​
Comment ajouter une instrumentation supplémentaire à mon application ?

Une instrumentation supplémentaire peut être ajoutée à votre application pour vous donner plus de visibilité sur ses performances en mesurant la durée d’événements distincts. Découvrez comment dans la documentation de notre Ruby Gem et de notre package Elixir.

​
Quelle est la différence entre setRootName et setName ?

setName et setRootName renomment tous deux les spans, mais à des niveaux différents. setName définit le nom d’un span individuel tel qu’il apparaît dans la chronologie de l’échantillon de performance, tandis que setRootName définit le nom de la transaction racine — ce que vous voyez dans la vue d’ensemble des performances et la liste des transactions. Un bon modèle consiste à appeler setRootName une fois sur votre gestionnaire le plus externe (par exemple, `${request.method} ${pattern}` pour produire un titre comme GET /users/:id), et à utiliser setName avec setCategory sur les spans internes tels que les middlewares, les loaders et les actions, afin qu’ils apparaissent comme des événements clairement étiquetés dans la décomposition de la chronologie. Pour en savoir plus sur le nommage et l’ajout de spans, consultez le guide d’instrumentation Node.js.

​
Comment exécuter plusieurs applications sur un même hôte ?

Par défaut, AppSignal est configuré en supposant qu’une seule application s’exécute sur un hôte. Si vous exécutez plusieurs applications sur un même hôte, des comportements inattendus peuvent survenir, comme des données rapportées pour une autre application. Pour configurer AppSignal pour plusieurs applications sur un même hôte, le répertoire de travail d’AppSignal doit être configuré. Pour en savoir plus sur la configuration du répertoire de travail, consultez notre guide pour exécuter plusieurs applications sur un même hôte

​
Quels systèmes d’exploitation AppSignal prend-il en charge ?

Veuillez consulter notre page Systèmes d’exploitation pour la liste complète des systèmes d’exploitation pris en charge et des packages requis.

​
Comment déboguer un problème avec l’intégration AppSignal ?

Veuillez consulter notre guide de débogage pour un guide complet sur le débogage des problèmes d’intégration AppSignal. Vous pouvez également consulter notre page Problèmes connus pour les problèmes susceptibles d’être présents dans votre version de l’intégration AppSignal.

​
AppSignal prend-il en charge Windows ?

AppSignal ne prend pas en charge Windows, et il n’est pas prévu d’ajouter la prise en charge de Windows. Cependant, nous nous efforçons de rendre les bibliothèques AppSignal installables sur Microsoft Windows sans erreurs ni problèmes de compilation.

​
Pourquoi l’installation de la gem AppSignal Ruby échoue-t-elle avec une erreur JSON::Fragment ?

Cette erreur se produit lors de l’installation d’appsignal 4.x avec Ruby 3.0 et versions antérieures. La gem json incluse comme dépendance dans AppSignal 4.x a introduit JSON::Fragment, une constante uniquement disponible à partir de Ruby 3.1. Sur les versions plus anciennes de Ruby, la compilation de l’extension native échoue avec : 
uninitialized constant JSON::Fragment (NameError)
La solution recommandée est de mettre à niveau Ruby vers la version 3.1 ou ultérieure, ce qui vous permet d’utiliser la version actuelle d’AppSignal 4.x sans restrictions. Si vous ne pouvez pas mettre à niveau Ruby immédiatement, vous pouvez épingler AppSignal 3.x comme solution temporaire : ajoutez gem "appsignal", "~> 3.0" à votre Gemfile et exécutez bundle update appsignal. AppSignal 3.x fonctionne avec Ruby 2.7 et Ruby 3.0, mais ne reçoit pas les nouvelles fonctionnalités de la branche 4.x, alors prévoyez de mettre à niveau Ruby dès que possible.

​
Comment configurer AppSignal dans une application Hanami ?

AppSignal ne se configure pas automatiquement dans Hanami comme il le fait dans Rails. Utilisez un fichier de configuration Ruby (config/appsignal.rb) plutôt que l’ancien fichier YAML (config/appsignal.yml) — le format YAML est obsolète et sera supprimé dans la prochaine version majeure de la gem. Créez config/appsignal.rb avec : 
Appsignal.configure do |config|
  config.activate_if_environment(:development, :staging, :production)
  config.name = "Your App Name"
  config.push_api_key = "your-key-here"
end
Assurez-vous ensuite que config.ru charge l’intégration après Hanami : 
require "appsignal"
require "hanami/boot"

Appsignal.load(:hanami)
Appsignal.start

run Hanami.app
Si vous avez un fichier config/appsignal.yml existant, supprimez-le ou ajoutez une section development avec active: true — la présence des deux fichiers provoque des conflits. AppSignal ne démarre pas dans l’environnement development par défaut ; activate_if_environment l’active explicitement. Consultez la documentation d’intégration Hanami pour la configuration complète.

​
Pourquoi les erreurs dans Phoenix LiveComponent ne sont-elles pas capturées par AppSignal ?

AppSignal capture les erreurs Phoenix en écoutant les événements de télémétrie de Phoenix. Lorsqu’un LiveComponent gère directement des événements de formulaire, Phoenix utilise un chemin interne qui n’émet pas ces événements de télémétrie, de sorte que l’erreur n’est jamais signalée. Pour signaler les erreurs depuis un LiveComponent, utilisez Appsignal.send_error/2 pour les envoyer manuellement : 
rescue e ->
  Appsignal.send_error(e, __STACKTRACE__)
  reraise e, __STACKTRACE__
end
Vous pouvez également déplacer la logique susceptible de lever une exception hors du template du composant vers ses callbacks handle_event/3 ou update/2, où la télémétrie de Phoenix s’active. Cette lacune a été corrigée en amont dans phoenix_live_view. Mettre à jour vers la dernière version permet à AppSignal de capturer ces erreurs automatiquement.

​
Compte utilisateur

​
Comment activer l’authentification à deux facteurs (2FA) pour l’application AppSignal ?

Veuillez consulter notre page Authentification à deux facteurs pour plus d’informations sur l’activation de la 2FA.

​
Pourquoi mes codes d’authentification à deux facteurs (2FA) ne fonctionnent-ils pas ?

Si les codes de votre application d’authentification sont rejetés lors de la connexion, la cause la plus fréquente est un décalage d’horloge sur l’appareil qui les génère. Les codes d’authentification à deux facteurs sont basés sur le temps (TOTP), donc l’horloge de cet appareil doit être précise — cela se rompt souvent après un changement de fuseau horaire. Activez la date et l’heure automatiques (par le réseau) sur l’appareil, puis essayez le code nouvellement généré. Si vous ne parvenez toujours pas à vous connecter, utilisez l’un des cinq codes de récupération que vous avez sauvegardés lors de l’activation de la 2FA pour contourner l’authentification à deux facteurs. Consultez Authentification à deux facteurs pour en savoir plus sur les codes de récupération.

​
Quelles adresses IP AppSignal utilise-t-il ?

Actuellement, l’API Push d’AppSignal utilise les adresses IP suivantes : 
185.191.3.93
185.191.3.94
185.191.3.125
185.191.3.126
Actuellement, les webhooks d’AppSignal proviennent des adresses IP suivantes : 
185.191.3.107
185.191.3.72
185.191.3.116
185.191.3.84
Nous ne recommandons pas d’autoriser des adresses IP spécifiques. Elles peuvent changer, et d’autres peuvent être ajoutées à l’avenir, par exemple lorsque nous devons faire tourner nos équilibreurs de charge ou ajouter rapidement des serveurs. Si vous décidez d’autoriser nos adresses IP, veuillez envoyer un e-mail à notre équipe d’assistance, nous ferons de notre mieux pour vous avertir des changements à venir.

​
Erreurs et performances

​
Pourquoi mon problème de performance est-il toujours marqué comme fermé ?

Le statut Ouvert ou Fermé d’un problème est déterminé par ses paramètres de notification, et non par le fait que le problème sous-jacent se produise toujours. AppSignal marque un problème comme Ouvert lorsqu’il envoie une notification à son sujet. Les problèmes de performance utilisent par défaut le paramètre « Ne jamais notifier », aucune notification n’est donc envoyée — c’est pourquoi ils restent Fermés. Pour qu’un problème de performance s’ouvre lors de nouvelles occurrences, modifiez son paramètre de notification, soit par problème, soit en mettant à jour la valeur par défaut au niveau de votre organisation. Consultez Paramètres de notification pour savoir comment le configurer.

​
Comment voir le nombre d’erreurs par namespace ?

Pour voir le nombre d’erreurs par namespace, créez un graphique Nombre qui utilise la métrique transaction_exception_count (le décompte par AppSignal des erreurs enregistrées dans une application), filtré par le tag namespace :
  1. Ouvrez l’application que vous souhaitez mesurer, accédez à Dashboards et ajoutez un nouveau graphique.
  2. Sélectionnez l’onglet Number.
  3. Définissez la métrique sur transaction_exception_count.
  4. Ajoutez le tag namespace et saisissez le nom du namespace (par exemple, web ou background).
  5. Définissez le type d’agrégation sur Total value.
  6. Créez le graphique.
Le graphique affiche le nombre total d’erreurs pour ce namespace sur la période sélectionnée lors de sa consultation. AppSignal stocke les données d’erreurs séparément par application, il n’y a donc pas de total unique pour toutes les applications — créez un graphique par namespace par application, et additionnez vous-même les décomptes si vous avez besoin d’un chiffre global.

​
Pendant combien de temps les données de surveillance de disponibilité sont-elles conservées ?

La surveillance de disponibilité stocke les métriques à la minute pendant 30 jours et les métriques horaires pendant 5 ans. Pour visualiser les tendances de disponibilité quotidiennes sur une période plus longue — par exemple, une année complète — utilisez le sélecteur de dates dans la vue surveillance de disponibilité pour sélectionner une plage de dates personnalisée.

​
Comment trouver la cause des requêtes API lentes ?

Commencez par Performance → Slow API requests. Les requêtes sont triées par impact — la combinaison de la durée et de la fréquence — donc les premières entrées sont les plus probablement responsables. La sélection d’une requête affiche sa durée moyenne, son graphique de temps de réponse, son débit et la liste des actions qui la contiennent. Pour les requêtes de base de données, consultez Performance → Slow queries. Chaque requête est triée par impact, et en sélectionner une montre quelles actions la déclenchent. Pour trouver les requêtes N+1, ouvrez Performance → Issue list. Les actions marquées du tag N+1 contiennent des appels répétés à la base de données. Ouvrez un échantillon et consultez la chronologie de performance — les événements marqués x2, x5, etc. indiquent que la même requête est répétée au sein d’une seule requête. Pour une procédure pas à pas guidée, consultez Trouver les requêtes de base de données lentes et Trouver les requêtes HTTP lentes.