Dans la première partie de ce didacticiel, nous avons choisi un groupe d’erreurs à étudier plus en détail. Dans la deuxième partie, nous allons étudier une nouvelle page qui affiche les attributs, les logs et la trace de l'erreur.
Cette partie du tutoriel vous guide à travers deux pistes recommandées pour analyser une erreur, vos logs et votre trace d'appels.
Objectifs
Ce document s'appuie sur le problème décrit dans le document Répondre aux pannes de service de cette série de didacticiels. Dans ce document, vous allez :
- Localisez le code d'erreur associé à une API défaillante avec les logs
- Utilisez trace d'appels pour trouver où dans votre code l'erreur se produit
Localiser la source d'une erreur avec log et trace d'appels
Le résumé des erreurs raconte l’histoire derrière vos groupes d’erreurs. Selon la manière dont vous avez configuré New Relic, chaque service peut afficher différents types d’informations sur une erreur. Par exemple, si vous avez désactivé le tracing distribué, vous ne verrez pas autant de détails sur les services externes dans votre trace.
Ouvrir la fenêtre des détails du log
En regardant notre exemple, l'agent APM a extrait les logs liés à api-gateway, nous donnant des données d'événement sur notre erreur :
Notre capacité de logs en contexte formate vos informations de logs, bien que vous ayez également la possibilité d'examiner le log non formaté.
Trouvez le point de défaillance de votre système
Selon la nature du log, vous aurez peut-être plus ou moins de détails de logging à trier. Étant donné que vous avez passé du temps en amont à identifier le service le plus proche de la panne et à choisir le groupe d’erreurs probable, vous avez le temps de lire vos logs.
D'après vos logs, votre problème est :
Une erreur de dépassement de délai :
error.error.code: ETIMEDOUTEn rapport avec l'API de vos clients :
error.endpoint: customers-api-internalIndépendant du type de requête envoyée à l'API des clients :
error.request: /api/customers/search/Kirlin/-/Vous avez suffisamment de contexte pour relier tout cela. Vous concluez qu'il y a une défaillance de dépendance : tous les appels à l'API des clients expirent et provoquent l'échec requests en amont de
api-gateway.
Trouvez le point d'échec dans votre code avec trace d'appels
Lorsque vous exécutez votre code, New Relic capture vos exceptions ou erreurs d’exécution et les organise dans une vue en cascade. Ce sont vos traces d'appels. Selon la langue utilisée, ces traces d'appels fournissent des messages détaillés et les emplacements de vos points de défaillance.
Alors que vos logs vous indique la cause de l'erreur, votre trace d'appels identifie le lieu. Vous pouvez utiliser ces traces d'appels pour trouver exactement où dans votre code une erreur se produit, puis connecter ces erreurs à l'équipe propriétaire.
Ouvrir dans votre IDE depuis New Relic
Pour ouvrir votre code depuis New Relic, vous devez installer CodeStream. Il s'agit d'une fonctionnalité facultative mais fortement recommandée qui vous permet d'ouvrir votre IDE directement à partir de trace d'appels :
Quelle est la prochaine étape ?
Réagir à une erreur et trouver la cause directe d’une panne n’est qu’une partie de la gestion des erreurs dans votre application. Maintenant que nous avons expliqué comment décrire, diagnostiquer et trouver la source d'une panne, vous pouvez acheminer les erreurs vers les équipes concernées.