l'agent APM signale automatiquement les données d'erreur pour le framework pris en charge. Pour optimiser les rapports d'erreurs et les alertes, vous pouvez gérer davantage les erreurs afin de :
- Détectez les erreurs que nous n'instrumentons pas par défaut.
- erreur ignorée que vous ne souhaitez pas du tout signaler.
- Filtrez le bruit des erreurs attendues afin de pouvoir vous concentrer sur les erreurs qui affectent les performances. (Agent Java, Ruby, Node, Python et .NET uniquement)
Conseil
Consultez notre didacticiel de suivi des erreurs en trois parties. Le didacticiel utilise un exemple de scénario pour une panne d'application afin de vous guider dans la réponse et la résolution des erreurs critiques.
Collecter les erreurs non instrumentées par défaut
L'agent APM inclut l'appel d'API pour signaler (ou « remarquer ») des erreurs. Ils sont utiles lorsque APM n'instrumente pas votre framework automatiquement ou lorsqu'il existe des erreurs particulières qui ne sont pas détectées pour votre framework pris en charge.
Pour savoir comment demander à un agent APM de signaler une erreur, consultez la documentation de l'API spécifique à l'agent :
- Go:
NoticeError() - Java:
NoticeError() - .NET:
NoticeError() - Node.js:
noticeError() - PHP:
newrelic_notice_error() - Python:
notice_error() - Ruby:
notice_error()
erreur ignorée
Parfois, l'agent APM génère une erreur que vous ne souhaitez pas signaler, comme des erreurs contenant des informations sensibles comme des erreurs de connexion d'utilisateur. Si vous ne souhaitez pas qu'une erreur soit signalée à notre collecteur, vous pouvez ignorer l'erreur et l'agent APM supprime entièrement l'erreur.
Conseil
Pour Java, .NET, Ruby, Node.js, Go et Python: si vous souhaitez signaler des erreurs à APM mais que vous ne voulez pas que ces erreurs affectent votre Apdex ou votre taux d'erreur, marquez-les plutôt comme attendues.
Il existe deux manières d'ignorer l'erreur : via la agent configuration ou via configuration côté serveur dans UI l':
Erreur attendue (Java, Node.js, (Python, Ruby, Go et .NET uniquement)
Pour l'agent APM ci-dessous, vous pouvez marquer les erreurs comme prévues. Ces erreurs seront signalées à APM et pourront être visualisées, mais elles n'affecteront pas l'Apdex ou le taux d'erreur (ou la condition d'alerte basée sur le taux d'erreur).
Pour configurer les erreurs comme prévu, consultez la documentation spécifique à l'agent :
Si des erreur attendues sont activées, la page Error analytics d'APM aura, par défaut, un filtre appliqué avec error.expected l'attribut défini false sur, ce qui signifie qu'erreur attendue ne sera pas affichée. Pour afficher l'erreur attendue, désactivez le filtre error.expected .
Pour visualiser l'erreur attendue, requêtez vos données:
- Pour afficher les graphiques des erreurs attendues, créez une requête pour l'attribut
error.expected. - Pour créer une condition d'alerte pour une requête NRQL , utilisez l'attribut
error.expected.
Empreintes d'erreur avec la boîte de réception des erreurs
La boîte de réception des erreurs regroupe intelligemment les occurrences d'erreurs pour réduire le bruit et mettre en évidence les erreurs importantes.
Les événements d'erreur sont regroupés dans un groupe d'erreurs lorsqu'ils partagent la même empreinte. Bien que nos règles gérées soient capables de fournir un regroupement automatique des erreurs en fonction d'un ensemble prédéfini de modèles, il est impossible de reconnaître toutes les combinaisons possibles. Pour cette raison, les clients peuvent également définir leur propre empreinte digitale via une fonction de rappel s'ils constatent que nos règles gérées ne regroupent pas les occurrences avec précision.
Pour configurer une logique d’empreinte digitale personnalisée, consultez la documentation spécifique à l’agent :
Afficher les erreurs dans l'UI
Entre autres endroits, les données d'erreur apparaissent dans ces parties de l'UI:
- Page d'analyse des erreurs: affiche des graphiques détaillés et une analyse visuelle des erreurs.
- Page APM Overview : affiche une vue d'ensemble de votre application, qui inclut les erreurs.
- condition d'alerte: peut être basée sur le taux d'erreur.
- L'événement
transactionError: contient des données d'erreur sous-jacentes, qui peuvent être utilisées dans une requête NRQL .