• Cartographie
• Transactions métier
• Profiling
• Erreurs
• Perception utilisateur
• Comportement utilisateur
• Supervision SQL
• System monitoring
• Satisfaction utilisateur
  • Seuils APDEX
  • Formule APDEX
  • Catégories de temps de réponse
  • APDEX et satisfaction utilisateur
• Alertes
  • Paramètres de seuil
  • Déclenchement d’alerte
  • Configuration d’une alerte
• API REST
• X Apps
• Rapports
• Intégration LDAP

Cartographie

Les interactions de vos services monitorés avec l’écosystème qui les entoure sont présentées sous forme cartographique dans l’onglet Map.

La cartographie répartit les composants horizontalement en trois parties :

• À gauche figurent les points d’entrée : les technologies en jeu pour exécuter les transactions. Leur dénomination est plus ou moins précise suivant les technologies : HTTP, WS, Servlet, RMI …
• Au milieu figurent vos services monitorés ; si l’application est en cluster, un composant apparaît ici pour chaque service de votre application.
• À droite figurent les composants externes utilisés pour exécuter les traitements (base de données, web services …).

Les liens ont une couleur et une forme qui varie en fonction de l’importance d’une interaction relativement à l’ensemble des interactions. L’épaisseur matérialise le nombre de transactions, la couleur la latence moyenne.

Les liens entre les points d’entrée (gauche) et les services monitorés (centre) correspondent à des appels de transactions entrantes. Les liens entre les services monitorés (centre) et les composants externes (droite) correspondent à des appels de transactions sortantes.

Il est possible de visualiser l’évolution du nombre d’appels et des latences sur les transactions entrantes et/ou sortantes d’un élément de la cartographie simplement en le sélectionnant.

Transactions métier

Grâce aux informations collectées par la sonde dans les principales couches techniques (base de données, appels distants, …), Nudge-APM apporte une vision précise du fonctionnement interne de chaque transaction métier et de son évolution dans le temps.

Ces informations sont restituées selon plusieurs axes d’analyse dans le tableau de bord des transactions métier, ce qui permet d’identifier rapidement l’origine d’un incident ou d’une dérive des temps de réponse.

Nudge APM vous aide à aller plus loin en vous donnant une vision sur les fonctionnalités les plus consommatrices. Muni de ces informations, vous êtes en mesure de concentrer vos efforts sur les fonctionnalités qui ont un impact négatif sur la performance globale de votre application.

Profiling

Ayez une vision au plus près du code

Nudge APM, en plus de superviser vos applications, vous permet d’avoir une vue au plus près du code pour un diagnostic précis. La solution permet d’identifier les points chauds et les goulots d’étranglement.

Un point chaud ou un goulot d’étranglement est immédiatement visible, vous découvrez en un coup d’oeil le code concernée et vous pouvez ainsi avoir une vue détaillée des méthodes/fonctions mises en jeu et utilisées par les appels de vos utilisateurs.

Le profiling est représenté sous forme de graphe et de tableau détaillé classé par méthode dans lesquelles le traitement passe le plus temps :

La fonction profiling expose :

• Un graphe visuel qui permet de comprendre en un coup d’oeil le temps passé dans chaque méthode (un bloc plus large correspond à un temps passé plus long)
• L’emplacement dans le code (classe, méthode/fonction, numéro de la ligne)
• Temps local = Temps passé localement dans la méthode, c’est à dire à ne pas être en cours d’invocation d’autre méthode
• Temps total = Durée cumulée de traitement de la méthode y compris le temps passé à invoquer d’autres méthodes
• Le nombre d’appels à la transaction, avec leur temps moyen observé sur la période, le nombre d’échantillons et l’impact de la sonde sur votre JVM (overhead)
• Le détail des méthodes sélectionnées pour une observation et un diagnostic plus fin

Profiling du code avec un surcoût autour de 1% : Grâce à sa fonctionnalité de profiling par échantillonnage qui consiste, entre autres, à prendre une photo à intervalle régulier de la pile d’exécution des Threads, Nudge APM est capable d’évaluer les points chauds dans le code sans impacter les temps de réponse perçus par les utilisateurs de l’application.

De plus, cette fonction ne requiert aucune modification de votre code.

Plus de précisions sur le profiling :

1. Des informations générales sur la transaction métier concernées :
   • Le nombre de fois où cette transaction a été exécutée
   • Le temps moyen de l’ensemble de ces transactions sur la période observée
   • Le nombre d’échantillons recueilli
   • La surcharge de Nudge (son overhead), autour de 1%
2. Tableau des méthodes : Cette fonctionnalité permet d’avoir une vision rapide de la (ou des) classe(nt) qui ralentisse(ent) votre application.
   Classement des méthodes selon le temps passé par chacune et leur impact sur l’ensemble des temps de réponses :
   • classe
   • méthode
   • ligne dans le code
   • temps passé dans chaque méthode
3. L’impact d’une méthode sur l’ensemble de la transaction C’est très pratique de voir en un coup d’oeil l’impact d’une méthode sur l’ensemble de la transaction.
   En passant la souris sur le graphique, la méthode s’illumine et en cliquant sur la méthode, vous retrouverez dans le tableau “Élément sélectionné” :
   • la classe concernée
   • la méthode
   • la ligne dans le code
   • l’impact en % de “Temps local” = Temps passé localement dans la méthode, c’est à dire à ne pas être en cours d’invocation d’autre méthode

Le profiling est actuellement uniquement géré par l’agent Java.

Erreurs

Les agents Nudge APM ne se contentent pas de capter et analyser les temps de réponse des transactions; elles qualifient également les transactions en fonction de leur réussite ou échec.

Afin de faciliter le diagnostic des échecs, le cas échéant, la sonde capte des informations contextuelles disponibles au moment de l’identification de l’incident telles que, en Java, les stacktraces des exceptions et des causes à l’origine de l’incident.

Les Erreurs et leurs causes peuvent être consultées depuis l’onglet Transaction après avoir sélectionné une transaction particulière. L’écran est composé d’un graphique de répartition des erreurs dans le temps. Il regroupe les erreurs contextuellement à leur nature (code http, classe d’exception …). Le cas échéant, il est possible de visualiser la pile d’exécution complète de l’exception et de ses causes.

Perception utilisateur

L’agent Nudge APM dispose d’une option permettant d’injecter du code javascript dans les pages générées par l’application afin de mesurer le chargement de la page tel qu’il est perçu par l’utilisateur et ce grâce à l’API standard W3C HTML5 Navigation Timing. Ce code javascript est inoffensif pour les navigateurs non compatibles HTML5.

Nudge APM permet de visualiser les métriques suivantes collectées depuis le navigateur :

• Durée des redirections (code HTTP 302)
• Durée des résolutions DNS
• Durée de la connexion TCP
• Durée de la requête HTTP/HTTPS
• Durée de la réponse HTTP/HTTPS
• Durée de traitement du DOM
• Durée de l’événement onLoad

La capture des informations de perception utilisateur est gérée actuellement par l’agent Java lors de l’utilisation de certaines technologies liées au développement de pages web.

Comportement utilisateur

Vous avez la possibilité à travers Nudge APM de suivre la navigation d’un utilisateur du début jusqu’à la fin de sa session pour :

• Comprendre le contexte d’un utilisateur donné afin de diagnostiquer l’origine d’un problème,
• Analyser le comportement de vos utilisateurs afin de détecter des anomalies comportementales sur votre application (ces données sont disponibles par l’API REST pour une exploitation “analytics”),
• Optimiser les paramétrages des serveurs d’applications afin de répondre aux besoins de vos utilisateurs,
• Vous rapprocher de vos équipes métiers et/ou Marketing; en exploitant vos données APM pour comprendre comment vos utilisateurs se comportent et quelles sont leurs habitudes sur votre application (rapprocher la technique du marketing !)

Pour accéder à ces nouveaux indicateurs clés, il suffit de vous rendre sur l’onglet : Sessions.

Découvrez la liste de vos utilisateurs avec des informations (triables) très pertinentes par colonne, telles que :

• L’adresse IP ou le nom DNS,
• Le navigateur,
• L’OS,
• L’instant du premier appel (date et heure d’arrivée sur l’application),
• La durée de la session,
• Le nombre d’appels,
• Le nombre d’erreurs

Vous avez également la possibilité de faire apparaitre ou disparaitre les colonnes, selon vos besoins.

Pour ensuite analyser le comportement d’un utilisateur spécifique (dans le cadre d’une session), cliquez sur Détails :

La session de votre utilisateur apparaîtra sous forme d’une vue chronologique, et vous pouvez alors zoomer sur chaque transaction pour faire apparaître ses détails, en cliquant directement sur la transaction concernée :

Au clic sur la transaction, les informations suivantes apparaissent :

• Nom de la transaction associée (potentiellement lié à la configuration d’un filtre
• Code de la transaction associée (nom technique initial avant application d’un éventuel filtre),
• Satisfaction (basée sur l’indicateur configurable lié à l’APDEX,
• Début et Fin,
• Durée,
• Adresse IP ou DNS,
• Type d’OS,
• Navigateur,
• Type de transaction,

Pour les transactions ayant un temps de réponse frustrant et pour celles qui aboutissent en erreur, des informations détaillées sont disponibles.

Des informations de contexte de la transaction sont indiquées avec notamment le type de transaction, De plus, si la transaction provient d’un appel HTTP, vous aurez le détails des paramètres HTTP liés à la transaction.

Vous pouvez observer et analyser dans le détail les différentes “couches” appelées par cette transaction. Pour chaque couche, il est remonté des informations précises à propos des appels déclenchés par la transaction :

• La requête ou l’identifiant technique de l’appel (par exemple, la requête SQL si concerne une interaction avec une base de données)
• Début et fin pour l’ensemble des appels,
• Le nombre d’appels,
• Le nombre d’erreurs,
• Le temps cumulé,
• Durée moyenne,
• Durée minimum,
• Durée maximum

Ces informations sont conservées au plus 1 mois.

Supervision SQL

Nudge APM est en mesure de vous fournir des informations détaillées liées aux interactions avec les bases de données telles que :

• la liste des requêtes lentes et l’évolution de leur temps d’exécution dans le temps,
• le lien entre ces requêtes et les transactions métiers,
• la répartition par JVM,

La récupération des données et le parcours des ResulSet peut également être source de latences dans les transactions métiers. Là encore, Nudge APM est en mesure de vous fournir des pistes pour optimiser vos applications (veuillez vous référer à la configuration de l’agent Java sur ce sujet).

• Avec une application Java, l’agent gère automatiquement de nombreux drivers de base de données, incluant tous les drivers conforme JDBC (la liste complète des bases de données gérées est ici).
• Avec une application PHP, l’agent gère automatiquement tous les drivers conforme PDO (incluant MySQL par exemple).

System monitoring

Le suivi des ressources partagées (CPU, mémoire, i/o, pools …) est une fonctionnalité classique des outils de supervision. Une surveillance système est fournie par les agents applicatifs.

Nul besoin d’installer un agent ou un service spécifique pour disposer d’informations sur la santé de la machine hôte.

Pour activer la surveillance système, suivez les documentations de configuration des agents :

• Pour une application Java
• Pour une application PHP, cette surveillance est activée par défaut

Satisfaction utilisateur

Le standard de mesure APDEX (Application Performance Index permet de définir de façon claire la satisfaction de l’utilisateur pour ce qui concerne le temps de réponse de celle-ci.

Nous traiterons désormais uniquement de la capacité d’une application à répondre rapidement et les autres aspects liés à la satisfaction utilisateur ne seront plus évoqués dans cet article.

Cette mesure s’applique avec la mesure de temps de réponse d’un ensemble de requêtes sur une période de temps donnée.

Seuils APDEX

L’APDEX a besoin de deux paramètres qui définissent les exigences de temps de réponse liées à l’application :

• Le temps de réponse maximum au delà duquel l’expérience utilisateur est qualifiée de “tolérable”. Avec un temps de réponse inférieure à ce seuil, l’expérience utilisateur est qualifiée de “satisfaisante”. Nous nommerons cette valeur ‘T’.

• Le temps de réponse maximum au delà duquel l’expérience utilisateur est qualifiée de “frustrante”. Ce temps de réponse est supérieur au précédent paramètre ‘T’. Nous nommerons cette valeur ‘F’.

Formule APDEX

L’APDEX est une mesure comprise entre 0 et 1 et dont le calcul se base sur les deux paramètres précités.

La formule pour le calcul de cette mesure est la suivante :

Apdex = (#Sat + (#Tol / 2)) / #Total

Où :

• Sat est le nombre de requête dont le temps de réponse est inférieur à 'T'
• Tol est le nombre de requête dont le temps de réponse est supérieur à 'T' et inférieur à 'F'
• Total est le nombre total de requête. Si #Fru est le nombre de requête dont le temps de réponse est supérieur à 'F', alors nous aurions #Total = #Fru + #Tol + #Sat.

L’APDEX est donc une pondération sur le nombre de requêtes en fonction de leur temps de réponse.

Catégories de temps de réponse

Le temps de réponse étant discriminé en 3 ensembles : satisfaisant, tolérable et frustrant.

APDEX et satisfaction utilisateur

Les paramètres 'T' et 'F' sont des seuils de satisfaction en rapport au temps de réponse de l’application.

Avec ces seuils et des mesures de temps de réponse, nous pouvons donc mesurer la satisfaction de l’utilisateur concernant la capacité de l’application à répondre rapidement.

L’APDEX est un ratio avec une valeur comprise entre 0 et 1. Ainsi, pour rendre l’information plus compréhensible, il est aisé de la convertir en un pourcentage (en multipliant simplement par 100). Ce pourcentage est corrélé au nombre de requête par le biais de la pondération définie par l’APDEX. Ce n’est pas exactement un pourcentage de requête satisfaisantes mais reste un pourcentage lié au nombre de requêtes de certains types (satisfaisante / tolérable / frustrante). Cela peut être utilisé comme une référence à partir de laquelle on observe l’amélioration ou la dégradation du système.

Cette illustration graphique de Nudge APM est un indicateur lié au temps de réponse d’une application.

Alertes

Les alertes sont liées à des engagements de qualité de service (Service Level Agreement). Elles permettent de formaliser la notion de qualité de service (QoS) sur une application ou un serveur.

Paramètres de seuil

Concrètement, un seuil d’alerte est défini par un ensemble de paramètres :

• la métrique à suivre (temps de réponse, remplissage d’un file system ..)
• le périmètre de contrôle (une transaction, toutes les transactions, un serveur, tous les serveurs..)
• un seuil (5 secondes, 80%, taux d’erreurs ..)
• une plage de contrôle (tous les jours entre 8h et 18h, uniquement le week-end ..)
• destinataires (liste d’adresses emails, lien URL ..)

Lorsque ce seuil est dépassé, une alerte est levée.

Nudge APM permet de définir des seuils d’alerte à un niveau fixe ou par référence à une tendance.

Voici quelques exemples :

• temps de réponse d’une transaction métier supérieur à 2 secondes en moyenne pendant plus de 5 minutes.
• remplissage d’un file system à plus de 90%.
• taux d’erreurs supérieur à 50% par rapport à la semaine écoulée.

Déclenchement d’alerte

Que se passe t-il lorsqu’une alerte se déclenche ?

• un mail de début d’alerte va être envoyé aux adresses configurées.
• une icone va apparaitre sur la courbe principale de l’onglet « Vue Globale » de votre application.
• un message sera également visible dans le panel « Évènements Notables » de l’onglet « Vue Globale ».
• l’alerte sera signalée dans l’onglet « Evènements » de votre application.

Configuration d’une alerte

Veuillez vous référer à la page dédiée à la configuration d’une alerte.

API REST

L’API REST de Nudge APM vous donne accès à l’ensemble des données présentes sur le tableau de bord.

Avec l’API vous pouvez ainsi :

• Récupérer l’ensemble des métriques présentes sur Nudge APM à la granularité voulue (pour les intégrer à des tableaux de bord existants par exemple)
• Automatiser des actions (création d’application, ajout d’utilisateurs, etc.)
• Gérer vos applications (suppression d’application, changer le niveau APDEX d’une transaction, etc.)

L’api REST est disponible en cliquant sur le button API une fois connecté à l’interface PH-Nudge APM

Veuillez vous référer à cette page pour plus d’information sur l’API REST

X Apps

Avec un suivi de transactions entre plusieurs applications contrôlées, les transactions peuvent être suivies à travers celles-ci. C’est ce que nous appelons le Cross-apps.

Le suivi de transaction est automatiquement activé avec l’agent Java pour de nombreux protocoles de communication.

Rapports

Nudge APM permet d’envoyer et de recevoir des rapports pour suivre la performance de vos applications.

Vous construisez vous même le contenu des rapports avec les différents widgets présents sur Nudge APM selon les besoins de vos interlocuteurs qu’ils soient :

• Développeurs,
• Architectes,
• Chargé de support clientèle,
• Gestionnaire de l’infrastructure,
• DevOps,
• Manager SI,
• …

Veuillez vous référer à la page de configuration des rapports pour en savoir plus.

Avec une installation sur place, il vous est possible de personnaliser l’apparence des rapports (avec le logo de votre société par exemple).

Intégration LDAP

Cette fonctionnalité est uniquement disponible pour une installation sur place ( on-premises ).

Elle permet aux utilisateurs d’utiliser leurs identifiants et mots de passe usuels pour se connecter au portail Nudge APM. Ils n’auront aucun besoin de créer un compte ou de s’inscrire.

Le portail Nudge APM gère l’authentification par le biais d’une connexion à votre service d’authentification compatible LDAP.

Veuillez vous référer à la page de configuration de l’intégration LDAP pour en savoir plus.