• Tristan Lozahic

Dynatrace comme outil d'audit puissant, gain de temps, gain d'expertise


Les expertises d'architecture sont souvent demandées pour aider une équipe à remettre en état et optimiser une application qui ne semble pas optimale.


Le premier principe est de faire auditer avec un œil nouveau un ensemble de services et une architecture que les exploitants voient toute la journée sans pouvoir prioriser les optimisations.


Le second est de permettre à une seule personne de regarder toutes les couches et de vérifier leurs communications, alors qu'une société répartit les tâches de gestion de ses couches à plusieurs équipes.


Pour réaliser un audit il faut sortir les statistiques des machines, celles des applications et regarder aussi les configurations, les logs et les flux, enfin faire tourner son petit cerveau d'expert pour imaginer où pourraient être les problèmes.


Aller chercher les statistiques d'activité est un processus long et complexe, voilà où Dynatrace peut nous aider à auditer de manière rapide et fiable et surtout archiver.


1 - Comment ?


Dynatrace a des agents déployés sur chaque machine.


Ceux-ci vont analyser la configuration matérielle, CPU, mémoire, et les processus de la machine, ses applications, les échanges réseaux qu'elle a avec d'autres, les WS, la mémoire utilisée, le CPU d'usage.


On peut, en parallèle de ce monitoring très complet, paramétrer des alertes sur les processus qui peuvent éventuellement nous intéresser plus que d'autres.


De plus Dynatrace monitore aussi la partie front, c'est à dire côté navigateur client, en enregistrant le temps que les requêtes mettent, les réponses, le temps d'affichage, ce que le navigateur utilise comme données, les appels a des librairies tierces par exemple. Les erreurs navigateurs (Js le plus souvent) on appelle cela le Real User Monitoring (RUM).


2 - Pour qui ?


Dynatrace s'adapte aussi bien à une petite infrastructure qu'à de grandes entreprises, il suffit d'ajouter autant d'agents qu'il y a de serveurs à monitorer. Mais avant tout il est conçu pour être déployé sur du bout en bout, c'est à dire, sur les machines Front, les serveurs d'application et les bases de manière à pouvoir suivre le chemin d'une transaction sur tout l'architecture.


Plus que la vision en couche la vision en flux donne à Dynatrace toute sa valeur ajoutée, permettant de suivre les transactions de manière unitaire dans toute l'architecture.


3 - La valeur ajouté ?


Explication par l'exemple :


Un client a des lenteurs qui sont remontées par les utilisateurs mais il ne sait pas si cela vient de sa base de données, de ses serveurs, du réseau ou des applications.


En temps normal pour déterminer d'où viendrait le problème, il doit regarder les logs serveurs, de BDD, voir aussi avec les équipes réseaux et coordonner toute ces informations ensuite, c'est long et humainement complexe.


Des temps de réponses longs peuvent être causés par beaucoup de choses, en regardant les connexions et les requêtes par zone géographiques, on peut constater que certains utilisateurs sont pénalisés par des connexions lentes dues à une utilisation nomade, toutes leurs requêtes ont des réponses lentes. Nous pouvons donc distinguer ces cas ci ci dessus où l'utilisateur est connecté directement sur le réseau d'entreprise. Les erreurs sur le réseau internes ne concernent que certaines requêtes qui font appel à des traitements avec BDD en arrière-plan.


En regardant les métriques serveurs CPU, Mémoire et disques on peut écarter un sous dimensionnement des machines qui seraient causes de ces problèmes, même si des erreurs disques sont vu sur le serveur de BDD, mais très ponctuellement.


La mesure du temps d'affichage dans le navigateur pour les utilisateurs que permet Dynatrace, nous confirme que les temps d'affichage Front sont bons.


On a donc pu constater que le réseau intranet était bon, que les machines étaient bien dimensionnées par rapport à la charge demandée.


En même temps on a pu constater que beaucoup d'erreurs Js étaient remontées par le navigateur, et que les latences existaient sur les écritures en base de données. Ces latences étaient rencontrées seulement pour certains processus, et sur certaines machines, BDD, serveurs de génération de documents.


En analysant plus finement ces processus dans Dynatrace, on accède à la Stack et aux exceptions renvoyées par le code (oui on voit les appels dans le code).


On peut lire le détail des exceptions, ici en Java mais il est aussi possible que dans d'autres langages, on constate que ces erreurs sont dues à des classes d'un framework Java non mis à jour et mal utilisées.

Mais aussi que les temps de traitement de documents étaient longs, malgré des machines correctement dimensionnées.


En parallèle Dynatrace a pu mettre en évidence un mauvais paramétrage des disques sur la base de données qui aggravait ces lenteurs et qui devait être corrigé pour éviter que celles-ci s'aggravent avec un volume de données qui augmentera dans le temps.


Bref, des analyses mises en avant pour l'outil en quelques heures, qu'un auditeur à l'habitude de trouver en plusieurs jours !


4 - Conclusion


Dynatrace a permis en monitorant quelques journées de faire un instantané de toute l'infrastructure et du comportement des applications à un instant T.


Et ensuite de mettre en corrélation très facilement toutes les erreurs qui n'auraient pas été mises en évidence comme étant la cause directe ou indirecte de ces lenteurs, Il recherche les "Root cause" et nous propose des zones d'erreur ou de lenteur pour nous accompagner dans notre diagnnstic.


Une installation des agents Dynatrace, suivie d'une analyse globale d'un expert Dynatrace ont évité a des DBA, des développeurs, des OPS de chercher sans vraiment savoir dans quelle direction et chacun de son côté.


Donc gain d'expertise et gain de temps.


NB : Dynatrace propose un déploiement en mode SaaS de 10 jours gratuits à titre de POC.





118 vues

Posts récents

Voir tout