Dépannage avec la page de résumé APM

Identifiez les points sensibles avec des tuiles récapitulatives

Avant de plonger dans les détails, il est important de regarder d’abord les tuiles récapitulatives en haut de la page. Ces vignettes vous alertent immédiatement de tout problème, vulnérabilité ou panne de déploiement de votre système. Si les tuiles en haut de votre page affichent un état vide, cliquez sur Set up now pour activer chaque tuile.

Problèmes

Un moyen important de suivre les comportements inhabituels de votre système consiste à utiliser des alertes. Disons que vous souhaitez savoir quand le taux d’erreur de transaction pour Checkout-service dépasse 10 %. Vous créeriez une condition d’alerte et définiriez les règles qui déclencheront un incident. Un ou plusieurs incidents créent un problème. Cette tuile affichera tous les problèmes de votre service.

Dans cet exemple, vous avez déjà configuré votre condition d'alerte afin que lorsque vous scannez vos tuiles récapitulatives, vous voyiez immédiatement que votre système présente deux problèmes critiques. Cliquez sur la tuile pour afficher les détails de chaque problème critique, l’incident qu’ils contiennent et leur entité associée.

Dernier déploiement

Le marqueur de déploiement vous aide à monitorer les résultats de chaque mise à jour que vous apportez à votre service. Cette mosaïque montre le changement du taux d’erreur et du temps de réponse déclenché par votre dernier déploiement.

À partir de 15 minutes après un déploiement, cette mosaïque affichera une comparaison entre les données collectées avant et après le déploiement. Si vous avez activé une nouvelle fonctionnalité il y a 45 minutes, cette vignette affichera une comparaison entre les 45 minutes avant et 45 minutes après. Pendant les trois premières heures suivant un déploiement, cette mosaïque affichera uniquement une comparaison du temps écoulé depuis l'activation avec le temps correspondant avant l'activation. Après trois heures, la tuile utilise la comparaison standard de 3 heures.

Pour une plage horaire personnalisée, cliquez sur la tuile pour accéder à la page principale de déploiement et utilisez le sélecteur d'intervalle de temps qui s'y trouve.

Pour cet exemple, votre dernier déploiement a déclenché une augmentation de 27 % du taux d’erreur et une augmentation de 5 % du temps de réponse. Cliquez sur la tuile pour afficher votre dernier déploiement et toutes les erreurs, journaux, alertes et tendances associés.

Niveaux de service

Les niveaux de service permettent de mesurer les performances d'un service du point de vue de l'utilisateur final. Lorsqu'un budget d'erreur d'un niveau de service est dépassé, vous verrez ces types incident :

• Non-compliant signifie que vous avez consommé tout le budget d'erreur pour cette période. Soyez donc prudent si vous devez déployer et prévoyez du travail pour améliorer vos SL.

• At risk Cela signifie que votre budget d'erreur est presque épuisé et que vous devez être plus prudent pour le reste de la période.

  Pour cet exemple, vous avez déjà configuré votre niveau de service et vous avez dépassé votre budget d'erreur dans deux cas. Cliquez sur la tuile pour voir quelles entités ne sont pas conformes et approfondir votre budget d'erreur.

  

  vulnérabilités

  La gestion des vulnérabilités fournit une vue d'ensemble de toutes les vulnérabilités de votre logiciel. Chacun de vos agents ou services intégrés, comme Java, .Net ou Github Dependabot détectera automatiquement les vulnérabilités connues de New Relic à suivre.

  Ici, vous pouvez voir que vous avez activé la gestion des vulnérabilités et que 3 Critical et 9 High vulnérabilités ont été détectées pour votre service de monitoring. Cliquez sur la tuile pour visualiser l'impact de vos vulnérabilités.

  

Passez en revue vos indicateurs clés

Y a-t-il un problème avec votre Checkout-service? Quels systèmes sont concernés et comment ?

Apdex

Le premier élément à prendre en compte lors de l’enquête sur une panne de service est votre score Apdex. Votre moniteur de score Apdex mesure la satisfaction globale des clients avec votre application. Votre score recherche une combinaison de performances, comme le temps de réponse ou le débit, et le taux d'erreur.

Apdex est une norme industrielle qui mesure la satisfaction de vos utilisateurs vis-à-vis des temps de réponse de votre application/ service Web. Il est représenté par un score de 0 à 1. Plus votre score est proche de 1, meilleures sont les performances de votre application. La valeur par défaut pour une expérience satisfaisante est de 0,5 seconde, mais vous pouvez définir un objectif différent dans Paramètres.

Votre score Apdex est généralement divisé selon les couleurs suivantes :

• < 0.5 - Gray: Les performances de votre application sont plus que critiques et nécessitent une action immédiate.

• 0.5-0.7 - Red: Il y a des problèmes de performances critiques dans votre application et une action immédiate est nécessaire.

• 0.7-0.85 -Orange: Votre application évolue dans une direction négative et nécessite une enquête plus approfondie.

• 0.85-0.95 - Blue: C'est la gamme Apdex idéale. Ce score signifie que vous avez parfaitement ajusté votre Apdex T à votre application et que vos performances sont saines.

• > 0.95 - Blue: Si votre score Apdex se situe dans cette plage, cela signifie que votre Apdex T est peut-être réglé un peu trop haut et que vous n'obtenez pas une lecture précise des performances de votre application. Vous devriez envisager de réduire votre Apdex T.

  Conseil

  Si vous avez un score Apdex de 0, cela peut être dû au fait qu'une requête a été renvoyée avec une erreur. Chaque requête comportant une erreur obtient automatiquement un score de 0 sur Apdex.

  Pour cet exemple, après avoir ouvert votre entité Checkout-service dans APM, vous voyez que votre score Apdex a chuté et oscille autour de 0,6. Le graphique est rouge.

  Vous savez maintenant avec certitude que les plaintes de vos clients sont fondées : il y a un problème quelque part dans votre stack.

  Pour en savoir plus sur la façon de comprendre votre score, consultez Apdex : mesurer la satisfaction des utilisateurs.

  transaction web

  

  D'après les rapports des clients, vous savez que le bouton Pay now échoue dans votre application, mais vous n'êtes pas sûr de la cause réelle de l'erreur. Vous avez vérifié Apdex et il montre une faible satisfaction des utilisateurs.

  L'étape suivante consiste à déterminer quelle partie du processus de paiement est défectueuse en examinant le Web-transactions de votre application.

  Chez New Relic, une transaction est définie comme une unité de travail logique dans une application logicielle. Plus précisément, il fait référence aux appels de fonctions et aux appels de méthodes qui composent cette unité de travail. Pour APM, il s'agira souvent d'un Web de transactions, qui représente l'activité qui se produit à partir du moment où l'application reçoit une demande Web jusqu'au moment où la réponse est envoyée.

  Le temps de transaction Web est divisé en trois parties :

• Segment bleu : toutes les transactions

• Segment jaune : opérations de base de données

• Segment vert : services externes

  Conseil

  Si vous essayez de monitorer une application asynchrone, votre temps de réponse (la ligne bleu foncé) pourrait éventuellement être inférieur au temps de réponse de chaque segment individuel (transactions, base de données et externes). Cela peut se produire car une application asynchrone peut traiter plusieurs requests en même temps. Il est donc possible qu’une transaction se « termine » alors que certaines requests sont encore « ouvertes ».

  Une transaction lente peut être un indicateur fort que quelque chose se comporte de manière anormale, alors jetez un œil au graphique et voyez si certains domaines de votre service prennent plus de temps que la normale pour répondre. Les transactions lentes ressembleront à des pics sur le graphique.

  Vous pouvez également utiliser notre outil de marqueur de déploiement pour vérifier si votre équipe a constaté un changement au moment où les clients ont commencé à se plaindre du fait que le bouton Pay Now prenait beaucoup de temps à charger.

  Un marqueur de déploiement apparaît sous la forme d’une épingle grise sur chaque graphique. Vous pouvez survoler l'épingle pour obtenir des informations générales ou cliquer sur le marqueur pour un aperçu plus approfondi du déploiement.

  débit

  

  En examinant les temps de réponse pour Checkout-service vous pouvez également étudier le débit. Throughput est un moyen de mesurer la quantité de travail gérée par votre application. Le débit vous aide à comprendre si le travail est réparti uniformément entre vos hôtes et votre conteneur. Les problèmes de performances peuvent souvent être le symptôme d’un manque de ressources.

  Pour les besoins de cet exemple, vous voyez que le débit est un peu plus élevé que d’habitude. Si votre débit est très élevé pendant une période de dégradation du service, cela peut indiquer que votre application traite plus de travail qu'elle ne peut en gérer.

  D'un autre côté, un faible débit pourrait indiquer que votre application ne gère pas beaucoup requests. Cela pourrait simplement signifier qu'il n'est pas beaucoup utilisé ou qu'un service qui appelle votre application est défectueux et requests ne sont pas traitées.

  Erreurs

  

  Maintenant que vous avez identifié les transactions lentes et analysé votre débit, il est temps d'examiner les erreurs. Le graphique Errors vous montre le pourcentage de transactions qui ont entraîné une erreur.

  Dans le contexte de APM, les erreurs représentent les événements TransactionError et ErrorTrace.

  Dans ce cas, vous voyez un pic dans Web errors à peu près au même moment où le temps de réponse Web de votre transaction a augmenté. Vous voyez également un marqueur de déploiement vous alertant d’une modification apportée par votre équipe à votre système.

  Vous voyez maintenant une tendance autour de cette récente déploiement : diminution de la satisfaction des utilisateurs, augmentation du temps de réponse, du débit et des erreurs.

  Utilisez la liste déroulante pour passer à une vue des utilisateurs impactés. Pour savoir comment suivre les utilisateurs impactés, consultez la boîte de réception des erreurs.

  Pour en savoir plus sur la gestion des erreurs, consultez Gérer les erreurs.

Situer le problème dans un contexte plus large

Quelles parties de votre stack sont en difficulté ? Le problème a-t-il été causé par des changements dans l'entité qui appelle votre service ou qui est appelée par votre service ?

Logs

Le graphique du log vous donne une vue récapitulative du log de votre application signalé via notre fonctionnalité de logs en contexte . En cliquant sur Logs, vous accédez à l'UI complète du log.

Pour cet exemple, après avoir examiné vos métriques clés, vous savez que vous avez un problème avec un déploiement récent qui a affecté Web-transaction fois, ce qui a entraîné un pic d'erreurs et une faible satisfaction des utilisateurs. Maintenant, vous voulez savoir comment cela a affecté le reste de votre service.

Avec les logs en contexte, vos logs individuels sont étiquetés avec l'entité ou le service auquel ils sont liés. Sur le graphique du log, vous pouvez sélectionner Log patterns (top 10) pour afficher des groupes de logs identiques jusqu'à la chaîne unique identifiant.

Pour en savoir plus sur le fonctionnement log patterns , consultez Modèles de journaux.

Tracing distribué

Le graphique Distributed tracing insights montre les entités en amont et en aval susceptibles d'entraîner une augmentation du temps de réponse, du taux d'erreur ou du débit de votre service.

Par exemple, supposons que vous souhaitiez étudier une augmentation du temps de réponse pour un service, mais que le pic soit lié à un appel externe. Si le traçage distribué a enregistré une entité en aval qui a provoqué une latence pour votre service, vous pouvez afficher ce changement dans les performances dans cette liste. Cliquez sur le bouton View trace pour voir une traces distribuée qui montre les changements de performances.

Vous pouvez en savoir plus dans nos docs traçage distribué informations détaillées.

infrastructure

Faites maintenant défiler jusqu’à la section Infrastructure de la page de résumé de l’APM. Ici, vous verrez un tableau qui répertorie chaque hôte connecté à l'application Checkout Service et un enregistrement de leur temps de réponse, débit, taux d'erreur, pourcentage CPU. et le pourcentage de mémoire.

Pour cet exemple, nous suggérons de vérifier s'il y a eu des changements dans le pourcentage du processeur autour du même déploiement récent qui ont entraîné une augmentation des temps de réponse et un taux d'erreur élevé.

Apprenez-en davantage sur la manière d’étudier les données d’infrastructure sur la page de résumé de l’APM ici.

Faites passer votre enquête au niveau supérieur