Présentation d’AppDynamics

logoappdynamics
Dans le milieu de la performance,  les principes « Ne devinez pas, mesurez », « Diagnose before Cure ! », « Measure, Don't Guess ! » sont de rigueur.

Il existe même un anti pattern nommé « Shot in the dark ».

Tous ces principes nous disent qu’il est important de superviser notre environnement de test lors de la réalisation d’un test de performance. Et pas seulement lors d’un test de performance, car comme tout test, ce n’est qu’une simulation avec ses imperfections (couverture de test incomplète, plate-forme de test non iso prod, etc.) et donc il est important de superviser son environnement de production sous peine de mauvaises surprises.

Pour réaliser cette tâche, de nombreux outils existent comme Nagios, Zabbix, Quest FogLight, Centreon, etc.

Plus particulièrement les APM (Application Performance Monitoring).

Dans le monde Java, les plus connus de nos jours sont Compuware Dynatrace, NewRelic et AppDynamics.

Dans cet article nous allons voir une partie des possibilités offertes par AppDynamics pour la partie Java.

Présentation d’AppDynamics

AppDynamics est un outil de supervision.

AppDynamics est composé de plusieurs parties :

  • Contrôleur : une application web qui centralise/agrège/affiche les métriques récupérées par les agents ;
  • App Agent : un agent qui s’attache à votre JVM afin de récupérer les métriques applicatives ;
  • Machine Agent : un agent qui récupère les métriques systèmes (mémoire, processeur, réseau) de vos serveurs ;
  • AppDynamics Geo Server : pour la partie end-user monitoring.

AppDynamics étant un produit riche et en constante évolution, je vous laisse aller sur leur site pour avoir plus d’informations.

Ses avantages sont :

  • un overhead acceptable pour un environnement de production ;
  • une instrumentation du code nous permettant d’aller jusqu’à la méthode Java/SQL posant des problèmes de performance ;
  • une interface graphique simple et complète ;
  • facilité d’installation ;
  • mise en œuvre rapide (plein de choses sont déjà configurées) ;
  • richesse fonctionnelle ;
  • l’historisation des données.

Passons à son installation.

Installation

Il existe deux modes d’installation.
Le mode SAAS et le mode locale.

Pour le mode SAAS, le contrôleur est installé chez AppDynamics alors que pour le mode locale, c’est à nous de l’installer sur notre infrastructure de supervision.

Le contrôleur se présente sous la forme d’un exécutable qu’il suffit d’exécuter pour l’installation de  l’application, le serveur d’application et la base de données.

Il faut prévoir une machine assez puissante pour héberger le contrôleur. Pour information AppDynamics recommande un serveur quad core à 1.5Ghz minimum avec 4Go de mémoire et 50GB d'espace disque pour superviser une seul application avec au plus dix JVM. Et cela peut aller jusqu’à un processeur 24 core à 2.5 GHz minimum avec 32Go de mémoire pour une énorme infrastructure à superviser.

Maintenant il nous reste à installer les agents qui se présentent sous la forme d’un fichier zip.

Dans un premier temps, décompressons les fichiers ZIP.

Pour le Machine Agent, il faut :

  • paramétrer le fichier conf/controller-info.xml pour que l’agent accède au contrôleur ;
  • exécuter la commande java -jar machineagent.jar.

Pour les App Agent, il faut :

  • paramétrer le fichier conf/controller-info.xml pour que l’agent accède au contrôleur ;
  • configurer votre JVM pour que l’agent AppDynamics soit lancé en même temps (ajout de -javaagent:/javaagent.jar dans les paramètres de la JVM).

Go pour la pratique

On va utiliser l’application démo PlantsByWebSphere (boutique en ligne) livrée avec IBM WebSphere 8.5.

Le contrôleur AppDynamics a été installé et il nous reste à installer l’App Agent.

Dans notre exemple on utilisera la JVM J9 d’IBM et donc il faut bien prendre l’App Agent correspondant.

Modifions le fichier conf/controller-info.xml.
Pour la deuxième partie de l’installation de l’App Agent, on peut modifier directement le fichier de configuration de lancement de notre application ou utiliser la console d’administration d’IBM WebSphere.

Pour la solution 2, voilà la démarche.

Se connecter à la console d’administration.

AppDynamics_001_WAS

Sélectionner son serveur dans « WebSphere application servers ».

Sélectionner « Process Definition » dans la section « Process Management ».

AppDynamics_002_WAS

Sélectionner « Java Virtual Machine » dans la section « Additional Properties ».

AppDynamics_003_WAS

Dans le champ « Generic JVM arguments » ajouter -javaagent:/home/ra77/AppDynamics/AppServerAgent-ibm/javaagent.jarAppDynamics_004_WAS

Dernière étape, sauvegarder la nouvelle configuration et relancer IBM WebSphere.

Et voila, notre application apparaît dans AppDynamics.

AppDynamics_005_dashboard

Simulons un peu de charge avec Apache JMeter.

En un coup d’œil on a une vision globale de notre application.
AppDynamics_006_dashboard

En particulier de tous les flux.
AppDynamics_007_dashboard

De la répartition par temps de réponse des transactions.
AppDynamics_008_dashboard

Et l’évolution par rapport au temps.
AppDynamics_009_dashboard

En un clic on peut avoir la liste des exceptions.
AppDynamics_010_exception

Un clic de plus et on a la stacktrace.
AppDynamics_011_exception

Et du contexte de l’application lorsque cette exception a été levée.
AppDynamics_012_exception

Dans notre cas, c’est l’expiration de la session utilisateur. Bien sûr un filtre sur les exceptions récupérées par AppDynamics peut être définis afin de séparer les exceptions « normales » des vrai exceptions.

De même, la liste des transactions lentes (en définissant un SLA manuellement ou en laissant AppDynamics  les définir lui-même par apprentissage) peut être obtenue rapidement.

Ce petit test de charge est concluant et on se retrouve avec plein d’informations (exceptions, requêtes lentes, etc.) à transmettre aux autres équipes (développement, exploitation, architecture, etc.).

AppDynamics agrègent les métriques et donc leurs granularité diminue avec le temps. Donc si on comparer finement de test espacé de plusieurs mois, il faudra penser à soit mettre toutes les informations nécessaire dans notre rapport, soit exporter les données d'AppDynamics (par exemple avec leur API REST).

Après leur analyse, les développeurs nous demandent plus d’informations sur la mémoire de la JVM.
Malheureusement on n’avait pas activé les logs GC sur notre environnement.

Ce n’est pas grave (même si les logs GC apportent plus d’informations qu’AppDynamics) car il est possible de récupérer un certain nombre d’informations sur la mémoire de la JVM pendant le test.

Dans un premier temps, on se positionne sur la bonne période.
AppDynamics_013_periode

Enfin les informations sur la mémoire de la JVM sont disponibles.
AppDynamics_014_memoire

Les développeurs ont fini de corriger les sources des exceptions et nous demandent le top dix des requêtes les plus lentes.
En un clique, AppDynamics nous donne cette information.

AppDynamics_015_top10

La majorité des problèmes a été résolue et un nouveau test de charge est réalisé.
Plus aucune transaction lente n’est relevée par AppDynamics.

Afin de confirmer le résultat de notre test de charge (absence de problème de performance), on vérifie dans les « Periodic Transaction » (les transactions qu’AppDynamics récupère automatiquement et de manière périodique) que les transactions qui posaient problème ne le font plus.

AppDynamics_016_periodic

Lors d’un test, on nous demande d’afficher les JMX de WebSphere pour vérifier s’il y a du tuning à faire pour la prochaine période de solde.

Pas de problème, AppDynamics a un « Metric Brower » où il y a tous les JMX nécessaires.

AppDynamics_017_JMX1

« Comment ça tous les JMX, il en manque plein ».

On lui répond « Enfin tous les JMX configuré par défaut dans AppDynamics »

AppDynamics_018bis_JMX2.1

« Mais on peut en avoir d’autres et même en temps réel ».

AppDynamics_018_JMX2

« C’est beaucoup mieux mais est ce possible de les avoir dans le « Metric Brower » afin de superposer un certain nombre de métrique sur le même graphique ? »

On lui répond « Bien sûr que c’est possible ».

AppDynamics_019_JMX3

Après quelque temps, nous devenons « le spécialiste AppDynamics » et tous les projets supervisés par AppDynamics passent par nous.

Afin de gagner du temps (et espérer pouvoir partir en vacances) nous faisons un dashboard par application afin d’autre personnes puissent utiliser simplement AppDynamics.

Et voila qui est fait.

AppDynamics_023_Dasboard

Notre notoriété augmente et commercial/marketing/etc demande des rapports.

AppDynamics_020_rapport01

Malheureusement ces rapports utilisent des termes techniques et non fonctionnels.

Pas de problème, il suffit de renommer nos « Business Transactions » (détectées automatiquement par AppDynamics et/ou ajoutée par nous-mêmes en configurant AppDynamics.

Avant on a ça.

AppDynamics_021_rapport02

Après (on en profite pour enlever les transactions inintéressantes comme /ibm/console).

AppDynamics_022_rapport03

Nouvelles demandes, on voudrait connaître le nombre de connexions et de commandes.

Encore une fois, AppDynamics peut le faire sans avoir besoin d’un autre outil.

Allons voir les développeurs (à moins qu’on ait accès au code source) pour avoir plus d’informations sur le morceau de code qui réalise les connexions et celui qui réalise les commandes.

AppDynamics_024_IP01

Bien sûr, ces nouvelles métriques sont disponibles dans les dashboard et le « Metrics Browser » d’AppDynamics.

Par exemple, on peut voir l’évolution du nombre de commande par minute.

AppDynamics_025_IP02

Le service marketing est impressionné et nous demande la moyenne d’article dans un panier. Cela tombe bien, car avec tous ces nouveaux chiffres, nous allions faire une refonte de nos scripts de test de charge afin qu’ils soient plus réalistes.

Modifions notre métrique « Commande » afin de répondre à cette nouvelle demande et attendons un peu qu'appdynamics collecte les informations.

AppDynamics_026_IP03

Dans notre exemple, le nombre d’articles dans un panier ne varie pas, car notre script de test ne charge ne met qu’un seul article en panier par commande.

Depuis quelque temps, en production, des problèmes apparaissent lors de l’envoi de mail. Malheureusement les logs ne sont d’aucune utilité.
En regardant avec AppDynamics, on a un peu plus d’informations mais pas assez pour aider les développeurs à résoudre le problème.
Après discussion avec les développeurs, on récupère la liste des informations (contenu du message et l’identifiant de la commande) dont ils ont besoin.

On paramètre AppDynamics afin qu’il récupère ces informations et  c’est reparti, on laisse AppDynamics collecter tout seul.

AppDynamics_027_userData

À l’aide de toutes ces nouvelles informations nous modifions nos scripts de test de charge. On exécute ces nouveaux scripts sur notre application en ne changeant aucun paramètre.

Il est important, si c’est possible, de ne faire qu’un changement à la fois entre deux exécutions de scripts afin de faciliter la comparaison de nos deux tirs.

Tout se passe bien jusqu’à l’arrivée d’une nouvelle version de l’application. À des moments et à heure fixe la nuit, l’application est ralentie. La régularité des problèmes de performance nous fait penser à un processus qui se déclenche lors de nos tests.
Malheureusement les métriques systèmes fournies par AppDynamics ne sont pas suffisantes pour notre problème.

AppDynamics_028_hardware

Heureusement AppDynamics a une architecture ouverte qui lui permet de récupérer des métriques externes. Pour cela nous installons un plugin (il en existe quelque uns sur Internet mais on peut aussi le développer soit même) qui va récupérer les métriques systèmes de chaque processus tournant sur notre serveur.

Attention à bien valider l’overhead de la récupération de ces métriques.

Et nous voilà avec nos métriques supplémentaires.
AppDynamics_029_hardware2

Il ne nous reste plus qu’à laisser AppDynamics récolter ces métriques et à les analyser au petit matin.

Conclusion

Comme nous venons de le voir, AppDynamics est :

  • puissant ;
  • extensible ;
  • accessible a des gens non techniques ;
  • un moyen de mieux communiquer entre chaque équipe ;
  • utilisable en production.

Et surtout, une fois bien configuré, nous permet d’être plus productif.

Et encore nous n’avons pas exploré toutes ses possibilités qui, entre les mains de quelqu’un d’expérimenté, peuvent faire la différence entre deux équipes.

Une réponse à to “Présentation d’AppDynamics”

Laisser un commentaire

Merci d'effectuer cette opération simple pour valider le commentaire *

Mots-clés
RSS Feed