Des erreurs sont inévitables. Même avec un outil d’observabilité, trouver la source d’une erreur n’est pas aussi simple qu’on pourrait le penser. Pensez à une cour inondée. Vous remarquez que de l’eau coule près de votre tuyau, mais la cause de l’inondation est en fait une fissure quelque part dans votre conduite d’eau principale. Si vous supposiez que le tuyau qui fuit était la cause de l'inondation, vous vous retrouveriez avec un tuyau réparé mais une pelouse ruinée : une erreur coûteuse.
L’analyse des erreurs vous amène à la source du problème afin que vous puissiez le résoudre avant que l’inondation ne se produise. Lorsqu'une équipe effectue un nouveau déploiement ou qu'un service échoue en amont, vous devez approfondir vos recherches avant de mettre en œuvre des solutions. Il n’y a pas de place pour les hypothèses dans l’analyse des erreurs.
Objectifs
Cette série de didacticiels vous montre comment résoudre les erreurs critiques, puis vous guide pour réduire votre nombre global d'erreurs. Ce document explique comment naviguer dans notre fonctionnalité de boîte de réception des erreurs , notamment comment :
- Choisissez un service pour commencer l'analyse des erreurs
- Choisissez un groupe d'erreurs qui indique une panne
Prérequis
Pour monitorer les performances de votre application, vous utiliserez un agent créé spécifiquement pour la langue de votre application. Cliquer sur un logo vous envoie vers un programme d'installation guidé dans l'interface utilisateur de New Relic où vous serez guidé dans l'installation et la configuration de l'agent.
Une fois que vous avez installé un agent, accédez à one.newrelic.com et sélectionnez votre application. Si vous ne voyez pas encore beaucoup de données, éloignez-vous un instant et laissez l'agent collecter des données en temps réel pendant l'exécution de votre application. Ce didacticiel suppose également que vous avez une certaine familiarité avec , même si vous n'avez pas encore créé votre première alerte.
Détectez et suivez les erreurs dans votre application
Maintenant que vos applications sont instrumentées, New Relic capture des données sur vos services. Cela inclut des données sur les occurrences d’erreurs dans votre application.
Pensez à l’utilisateur final
Les alertes vous informent qu'un problème existe : il s'agit de l'eau sur votre pelouse. Mais les alertes ne vous fourniront pas tout le contexte. C'est là qu'intervient votre boîte de réception d'erreurs.
Imaginez que vous êtes responsable de certaines applications sur un site de commerce électronique. Vous avez reçu deux alertes pour deux composants, une pour la vérification et une pour la recherche d'inventaire. Vous recevez uniquement des rapports indiquant que la fonctionnalité de recherche échoue pour l'utilisateur final, mais le composant de paiement fonctionne correctement. Vous pouvez penser que la fonction de vérification est plus importante, mais il est essentiel de séparer vos croyances de vos pratiques d'observabilité.
Cette pratique s’applique même si l’utilisateur final n’a rien signalé. Lorsque vous constatez que des services échouent, vous pouvez vous poser les questions suivantes :
- L’utilisateur final rencontre-t-il un problème ?
- À quoi devrait ressembler leur expérience ?
- Quel comportement connaissent-ils actuellement ?
Déterminer quels services signalent des erreurs
Voyons à quoi cela pourrait ressembler dans la pratique. Lorsque vous consultez la page All entities , vous remarquez que quatre services émettent une alerte.
Après vous être posé les questions de la première étape, vous savez que :
L'utilisateur final a du mal à effectuer des actions d'achat.
Votre site ne doit afficher que les articles en stock.
Votre site affiche tous les produits, afin que les clients puissent acheter les articles en rupture de stock.
Vous avez identifié que
api-gatewayest une dépendance critique pour votre inventaire. C'est ici que vous commencerez votre analyse des erreurs.
Localisez ce qui a changé
Vous avez votre point d’entrée dans votre système, vous pouvez donc maintenant examiner les erreurs affectant votre application. Depuis la page récapitulative api-gateway , cliquez sur l’onglet Errors sous Triage. Votre page d'erreurs filtre vos données pour une vue contenant uniquement les erreurs.
Il y a au moins six groupes d'erreurs signalés dans api-gateway. Les groupes d’erreurs apparaissent entre une douzaine et des milliers d’occurrences dans votre application.
Au premier abord, cela semble manquer de granularité, mais votre série chronologique vous donne suffisamment d’informations pour indiquer ce qui a changé au fil du temps. Nous allons décomposer cela :
- En se basant uniquement sur le nombre d’occurrences, votre premier instinct pourrait vous dire de commencer par
ActivemModel:::ValidationErrorcar il compte 4 000 occurrences. Cependant, si vous examinez les séries chronologiques, vous constaterez que leurs pics et leurs creux sont relativement cohérents. Cela pourrait être une erreur attendue, mais regardons les cinq autres. - Le groupe d’erreurs
Net::OpenTimeOutprésente un modèle similaire et constitue en fait quatre des six groupes de rapports. Dans chaque groupe d’erreurs, vous pouvez voir des pics et des creux cohérents qui s’étendent avant l’incident. Avec le même nom et des modèles similaires, nous pouvons en déduire qu’il s’agit également d’une erreur attendue. - Notre dernière option est
JsonapiClient:::Notfound. CommeActivemModel:::ValidationError, il a une forme distincte et fournit des rapports cohérents. Bien que le phénomène ne se reproduise pas souvent, la série chronologique est suffisamment anormale pour qu'il soit intéressant de creuser un peu plus profondément.
Ajuster la série chronologique
Pour être sûr, ajustez le paramètre de temps pour afficher les tendances des 12 dernières heures :
Avec l'ajustement, vous voyez que ActivemModel:::ValidationErrora un modèle inchangé de pics et de creux, mais votre JsonapiClient:::Notfound a augmenté considérablement au cours de la dernière heure. C'est un bon point de départ.
Savoir quand quelque chose s’est produit est un élément essentiel pour se rapprocher de la source. Ayant une compréhension complète de l’espace du problème, vous pouvez maintenant creuser la source.