Cette traduction automatique est fournie pour votre commodité.
En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.
L'agent Java d'APM fournit des informations détaillées sur les erreurs qui se produisent dans votre application. Cela vous donne des informations détaillées sur les domaines problématiques qui peuvent affecter les performances de votre applicationou l'expérience finale de l'utilisateur.
Configuration des erreurs attendues afin qu'elles n'affectent pas le taux d'erreur ou Apdex
erreur ignorée
Signaler des erreurs qui ne sont pas signalées automatiquement
Pour plus d'informations sur l'affichage de vos données d'erreur, consultez Analyse des erreurs. Pour obtenir un aperçu des données d’erreur dans tous les agents, voir Gérer les erreurs dans APM.
Exemples d’erreurs fréquemment signalées
L'agent Java signale des erreurs dans les scénarios suivants :
Rapport d'erreur
Comments
Erreurs non gérées (inclut trace d'appels)
Si une erreur non gérée se produit dans une transaction que l'agent Java traçait, l'erreur sera signalée avec la trace complète des appels.
Codes d'état HTTP (aucune trace d'appels)
Lorsqu'une transaction dans votre application génère un code d'état HTTP, par exemple, 400 pour une erreur client, elle signale l'erreur sans laisser de trace d'appels. Les raisons en sont les suivantes :
Le serveur application a détecté une condition d’erreur et a défini explicitement le code d’état.
OU
La logique du programme a détecté la condition d'erreur, il n'y avait donc aucun objet d'exception ni stack.
Afin d'inclure la trace d'appels avec ces types de transactions, vous devez utiliser un noticeError(...) appel d'API.
noticeError(...) appel d'API
Si l'agent Java effectue un appel explicite en utilisant l'appel d'API noticeError(...), l'erreur sera signalée, qu'elle se produise ou non dans une transaction. Les informations rapportées dépendent du paramètre utilisé dans l'appel d'API noticeError(...), comme décrit dans les Javadocs.
Erreurs non couvertes signalées à plus de 100 %
L'agent Java peut signaler des erreurs non limitées, qui sont des erreurs qui ne sont liées à aucune transaction. De ce fait, il est possible d’avoir une transaction dans une tranche de temps et plusieurs erreurs dans la même tranche de temps. Dans cette situation, New Relic afficherait alors un taux d’erreur over 100%.
Les erreurs signalées par ces versions de noticeError peuvent être configurées comme erreurattendue dans newrelic.yml. Les appels à cette API seront remplacés si l’erreur est configurée comme ignorée dans newrelic.yml. Pour plus de détails, voir Priorité de configuration des erreurs.
Utilisez ces noticeError() appels d'API pour signaler les erreurs qui ne sont pas signalées automatiquement et configurez-les comme erreur attendue dans newrelic.yml:
Les erreurs signalées par ces versions de noticeError remplaceront la configuration d'erreur attenduenewrelic.yml . Les appels à cette API seront remplacés si l'erreur est configurée comme ignorée dans le yml. Pour plus de détails, voir Priorité de configuration des erreurs.
Utilisez ces noticeError(...) appels d'API pour signaler les erreurs qui ne sont pas signalées automatiquement et configurez-les comme erreurattendue avec l'API (remplace configuration yml erreurattendue) :
Ignorer ou attendre des erreurs via le fichier de configuration
Dans les versions 3.40.0 ou supérieures, vous pouvez contrôler la manière dont les erreurs sont signalées en utilisant la configuration basée sur YAML. Cela vous permet d'ignorer les erreurs ou d'attendre des erreurs en fonction des codes d'état HTTP or en fonction d'une liste de noms de classes d'exception plus un message d'erreur facultatif.
Ignoring errors empêche que les classes ou codes d'exception spécifiés soient signalés à .
Expecting errors empêche les classes ou codes d'exception spécifiés d'affecter le application taux d'erreur et le score Apdex de votre . Cela vous permet de conserver les informations d'erreur à des fins de dépannage tout en évitant les alertes basées sur le taux d'erreur ou le score Apdex.
Ces paramètres sont dynamiques, donc l'agent en cours d'exécution remarquera les modifications apportées à newrelic.yml sans redémarrage JVM . Pour plus d'informations et d'exemples, consultez le fichier de configuration de l'agent Java.
configuration basée sur YAML pour la collecte des erreurs
configuration basée sur YAML pour la collecte des erreurs vous permet d'ignorer entièrement des erreurs spécifiques ou d'exempter erreurattendue d'affecter le taux d'erreur et le score Apdex de votre application . Vous pouvez marquer les erreurs comme ignorées ou attendues en fonction des critères suivants :
Une plage donnée de codes d'état HTTP, présentée sous forme de liste séparée par des virgules ou de plage en pointillés
Une liste séparée par des virgules utilisant le nom complet d'un package/ classe and une chaîne de message d'erreur fournie facultativement
Par défaut, l'agent Java inclut une section error_collector sous laquelle se trouvent toutes les options de configuration d'erreur basées sur YAML . La collecte des erreurs peut être activée ou désactivée comme suit :
error_collector:
enabled:true
Les erreurs qui ne présentent pas d’intérêt particulier peuvent être entièrement ignorées. En identifiant les erreurs à ignorer :
Ils ne seront pas signalés à l'APM.
Ils n'affecteront pas le taux d'erreur ou le score Apdex de votre application
Les erreurs qui font expected partie de application la logique APM métier d'une peuvent être empêchées d'affecter le taux d'erreur ou le score Apdex tout en étant signalées à . Cela vous permet de conserver les informations d'erreur dans l'UI à des fins de dépannage tout en évitant les alertes (basées sur le taux d'erreur et le score Apdex) causées par ces erreurs.
expected paramètre dans l'appel d'API noticeError(..)
expected_* configuration dans le YAML
Voici quelques exemples de résultats obtenus en combinant différents appels d'API et configurations YAML.
configuration YAML :
error_collector:
ignore_classes:
-"com.example.ErrorClass"
et
appel d'API:
noticeError(com.example.ErrorClass)
Résultat:
Le YAML ignore_classes remplace l'appel d'API noticeError et l'erreur est ignorée.
configuration YAML :
error_collector:
expected_classes:
-"com.example.ErrorClass"
ET
appel d'API:
noticeError(com.newrelic.Exception)
Résultat:
Le paramètre expected dans l'appel d'API noticeError est vrai par défaut et la configuration YAML expected_classes contient une classe d'erreur. Par conséquent, l'erreur est signalée et marquée comme expected.
Le paramètre expected dans l'appel d'API noticeError remplace expected_classes dans le YAML. Par conséquent, l’erreur est signalée comme normale (non marquée comme expected).
configuration YAML :
error_collector:
ignore_classes:
-"com.example.ErrorClass"
ET
configuration YAML supplémentaire :
error_collector:
expected_classes:
-"com.example.ErrorClass"
Résultat:
Le YAML ignore_classes/ignore_messages remplace le YAML expected_classes/expected_messages, donc l'erreur est ignorée. Ce même principe s’applique à ignore_status_codes et expected_status_codes.
Examiner le log pour obtenir des détails sur les erreurs
Vous pouvez rassembler vos données de log et d'application pour rendre le dépannage plus facile et plus rapide. Avec les logs en contexte, vous pouvez voir les messages de log liés à vos erreurs et les tracer directement dans UI de votre application.
Depuis la page Errors, cliquez sur une trace pour accéder à la pageError details.
Dans la page des détails de l’erreur, cliquez sur See logs.
Pour afficher les détails relatifs à un message individuel du log, cliquez directement sur le message.
Sous Error collection, pour Ignore ou Exclude expected errors, entrez le code HTTP ou la classe d'erreur pour les erreurs que vous souhaitez configurer.
Sélectionnez Save.
Pour plus d'informations sur la façon d'afficher l'erreur attendue dans l'UI, consultez Afficher l'erreur attendue.