♪
I. 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 (beaucoup de choses sont déjà configurées) ;
- richesse fonctionnelle ;
- l'historisation des données.
Passons à son installation.
II. 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 programme exécutable qu'il suffit de lancer 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 4 Go de mémoire et 50 GB d'espace disque, pour superviser une seule application avec au plus dix JVM. Et cela peut aller jusqu'à un processeur 24 core à 2.5 GHz minimum, avec 32 Go 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).
III. 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 :
1- Modifier directement le fichier de configuration de lancement de notre application.
2-Utiliser la console d'administration d'IBM WebSphere.
Pour la solution 2, voilà la démarche.
Se connecter à la console d'administration.
Sélectionner son serveur dans « WebSphere application servers ».
Sélectionner « Process Definition » dans la section « Process Management ».
Sélectionner « Java Virtual Machine » dans la section « Additional Properties ».
Dans le champ « Generic JVM arguments » ajouter -javaagent:/home/ra77/AppDynamics/AppServerAgent-ibm/javaagent.jar
Dernière étape, sauvegarder la nouvelle configuration et relancer IBM WebSphere.
Et voilà, notre application apparaît dans AppDynamics.
Simulons un peu de charge avec Apache JMeter.
En un coup d'œil, on a une vision globale de notre application.
En particulier de tous les flux.
De la répartition par temps de réponse des transactions.
Et l'évolution par rapport au temps.
En un clic on peut avoir la liste des exceptions.
Un clic de plus et on a la stacktrace.
Un clic on a le contexte de l'application lorsque cette exception a été levée.
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éfini afin de séparer les exceptions « normales » des « vraies 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 de nombreuses informations (exceptions, requêtes lentes, etc.) à transmettre aux autres équipes (développement, exploitation, architecture, etc.).
AppDynamics agrège les métriques et donc leur granularité diminue avec le temps. Donc, si on compare finement des tests espacés de plusieurs mois, il faudra penser à soit mettre toutes les informations nécessaires 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.
Enfin les informations sur la mémoire de la JVM sont disponibles.
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 clic, AppDynamics nous donne cette information.
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.
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.
On lui répond : « Enfin, tous les JMX configurés par défaut dans AppDynamics »
« Mais on peut en avoir d'autres et même en temps réel ».
« C'est beaucoup mieux, mais est-ce possible de les avoir dans le « Metric Brower » afin de superposer un certain nombre de métriques sur le même graphique ? »
On lui répond : « Bien sûr que c'est possible ».
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 que d'autres personnes puissent utiliser simplement AppDynamics.
Et voilà qui est fait.
Notre notoriété augmente, et commercial/marketing/etc. demandent des rapports.
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ées par nous-mêmes en configurant AppDynamics.
Avant nous avions cela.
Après (nous en profitons pour enlever les transactions inintéressantes comme /ibm/console).
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 que l'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.
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 commandes par minute.
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.
Dans notre exemple, le nombre d'articles dans un panier ne varie pas, car notre script de test de 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 mails. 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.
À l'aide de toutes ces nouvelles informations, nous modifions nos scripts de test de charge. Nous exécutons 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 à heures fixes 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.
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 quelques-uns sur Internet, mais on peut aussi le développer soi-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.
Il ne nous reste plus qu'à laisser AppDynamics récolter ces métriques et à les analyser au petit matin.
IV. Conclusion▲
Comme nous venons de le voir, AppDynamics est :
- puissant ;
- extensible ;
- accessible à des gens non techniques ;
- un moyen de mieux communiquer entre chaque équipe ;
- utilisable en production.
Et surtout, une fois bien configuré, il nous permet d'être plus productifs.
Et encore nous n'avons pas exploré toutes ses possibilités qui, entre des mains expérimentées, peuvent faire la différence entre deux équipes.
Nous tenons à remercier Jacques Jean pour sa relecture attentive de cet article et Francis Walter pour la mise au gabarit.