Une fois l'agent installé pour une application Java, ARMS commence à la surveiller. Sur la page Exception Analysis, filtrez et analysez les exceptions par nom, interface et hôte afin d'optimiser le code source à l'origine des erreurs.
Consultez l'analyse des exceptions
-
Dans la barre de navigation supérieure, choisissez .
Dans la zone de filtre rapide, filtrez le nombre d'exceptions et la liste des exceptions selon les critères Exception, Operation et Host.
-
Dans la zone du graphique de tendance, consultez le nombre de fois où une exception spécifique a été levée par l'application sur une période donnée. Les exceptions s'affichent sous forme de graphique empilé.
Cliquez sur l'icône
pour afficher les statistiques de la métrique sur une période précise ou comparer les statistiques de mêmes plages horaires sur différentes dates. Cliquez sur l'icône 
pour basculer entre un diagramme en barres et un graphique de tendance. -
Dans la zone de liste des exceptions, consultez les noms des exceptions, leur nombre, leurs pourcentages ainsi que leurs résumés.
Depuis la liste des exceptions, vous pouvez effectuer les opérations suivantes :
-
Cliquez sur Overview dans la colonne Actions pour ouvrir un panneau à droite. Ce panneau présente un aperçu de l'exception, incluant sa tendance de comptage, sa répartition par interface et instance, ainsi que la trace de pile de l'exception.
Cliquez sur Traces dans la colonne Actions pour consulter les détails de la trace. Pour plus d'informations, consultez Trace Explorer.
-
Documents connexes
Pour obtenir des informations détaillées sur les métriques de surveillance des applications, consultez Application monitoring metrics.
FAQ
Pourquoi le nombre d'exceptions dépasse-t-il le nombre de requêtes ?
Ce phénomène peut s'expliquer par les raisons suivantes :
ARMS enregistre une exception chaque fois qu'une méthode instrumentée en lève une. Si plusieurs méthodes instrumentées lèvent des exceptions lors d'un seul appel d'interface, ARMS les enregistre toutes, ce qui génère plusieurs entrées pour un unique appel.
Si la même exception se propage dans la pile d'appels à travers plusieurs méthodes instrumentées, chacune de ces méthodes peut enregistrer l'exception, entraînant plusieurs comptabilisations pour une seule occurrence.
Pourquoi le nombre d'exceptions change-t-il après une mise à niveau ?
Chaque version de l'agent peut augmenter ou diminuer le nombre de méthodes instrumentées. Par conséquent, le nombre d'exceptions capturées par ces méthodes peut également varier.
Pourquoi les exceptions non gérées s'affichent-elles ?
Dans de nombreuses méthodes au niveau du framework instrumentées par l'agent, les exceptions peuvent être interceptées et gérées en interne sans être propagées vers votre code métier. L'agent capture ces exceptions même si votre application n'en a pas conscience.
Par exemple, un appel à MongoDB utilisant MongoTemplate peut ne pas lever d'erreur dans votre application, mais des erreurs peuvent apparaître dans la console ARMS. En effet, MongoTemplate encapsule une logique de nouvelle tentative. Lorsqu'un appel de méthode MongoTemplate rencontre un délai d'expiration, il retente l'opération. Une exception n'est levée vers l'appelant qu'après l'échec de plusieurs tentatives. Ainsi, lorsque vous utilisez MongoTemplate pour accéder à MongoDB et qu'une nouvelle tentative sous-jacente se produit en raison d'un délai d'expiration, votre application peut ne pas voir d'exception, mais la console ARMS, si.
Pourquoi les traces de pile ne correspondent-elles pas aux exceptions ?
Pour améliorer l'efficacité du traitement et du reporting des données, l'agent ARMS génère une empreinte pour chaque exception basée sur son nom de classe, les trois premières lignes de sa trace de pile et les trois dernières lignes de sa trace de pile. Cette empreinte est ensuite encodée en une chaîne de 64 bits à l'aide de CRC64. Lors de la première occurrence, l'agent signale à la fois la valeur encodée et la trace de pile originale. Pour les exceptions identiques suivantes, seule la valeur encodée est signalée. Ce processus peut provoquer des incompatibilités dans deux situations :
Deux exceptions possèdent des traces de pile complètes différentes, mais partagent le même nom de classe d'exception ainsi que les mêmes trois premières et trois dernières lignes de leurs traces de pile. En raison de la logique d'empreinte, leurs valeurs encodées seront identiques, ce qui entraîne une incompatibilité.
Deux exceptions ont des noms de classe différents ou des trois premières et dernières lignes de traces de pile différentes, mais une collision de hachage se produit car CRC64 est un algorithme d'encodage non unique. Cela peut aboutir à la même valeur encodée pour des exceptions différentes.
Si l'une de ces situations se produit, augmentez le paramètre similar exception stack differentiation depth dans la section Exception Advanced Filtering Configuration de la page Custom Configuration. La page de configuration avancée du filtrage des exceptions comprend les paramètres suivants : Collect Plugin Exceptions (contrôle la collecte des exceptions provenant des plugins), Collect All Exceptions (instrumente les constructeurs d'exceptions pour capturer toutes les exceptions lorsqu'il est activé), Similar exception stack differentiation depth (valeur par défaut : 2 ; utilisé pour différencier les exceptions similaires en fonction de la profondeur de la pile), Exception Filtering Whitelist (les exceptions figurant dans la liste blanche sont exclues des graphiques liés aux exceptions), Exception Filtering Parent Class Inheritance (pris en charge uniquement sur l'agent v4.1.6 et versions ultérieures) et Exception Message Filtering.
Pourquoi les anciennes exceptions n'affichent-elles qu'un ID ?
Afin d'optimiser le volume de reporting des données, lorsqu'une exception survient pour la première fois, ARMS l'encode et envoie à la fois la valeur encodée et la valeur originale au serveur. Le serveur stocke cette correspondance, qui expire après 30 jours. Si une application fonctionne pendant plus de 30 jours, la valeur originale d'une exception peut ne plus être récupérable à partir de sa valeur encodée.
Pourquoi certaines exceptions ne s'affichent-elles pas ?
Par défaut, l'agent ARMS ne capture pas toutes les exceptions. Seules les exceptions levées par des méthodes instrumentées par l'agent ARMS sont collectées.
Si vous utilisez la version 4.1.12 ou ultérieure de l'agent, activez le plugin d'exceptions dans la section Agent Switch Settings de la page Custom Configuration. Après avoir activé ce plugin, ARMS collecte les données d'exception à chaque création d'une instance d'exception.