Il y a 12 ans -
Temps de lecture 3 minutes
14 Avril – Soirée Monitoring Pragmatique d’Applications Java avec le Fondateur et CTO d’AppDynamics
Cyrille Le Clerc et Pablo Lopez ont le plaisir de vous inviter Jeudi 14 Avril à 19h00 pour une « Soirée Monitoring d’Applications Java avec le Fondateur et CTO d’AppDynamics » .
Nous avons profité du passage en Europe de Jyoti Bansal pour organiser avec les équipes d’AppDynamics un événement autour du monitoring de la « vraie vie » .
A l’heure où l’architecture des applications d’entreprise devient de plus en plus complexe et distribuée, l’outillage dans le domaine du monitoring et du troubleshooting est un élément clé du système d’information. Notre objectif est que chacun en retire des idées immédiatement applicables et se forge une vision des problématiques que les systèmes de monitoring gèrent aujourd’hui et traiteront demain.
Après avoir consulté des Dev et des Ops des secteurs Telcos, Finance, Retail et Voyage, nous avons établi un programme reprenant des cas de notre vie quotidienne illustrés dans une application transactionnelle de eCommerce « réaliste » (1) que nous avons déployée en cluster sur 5 serveurs Amazon EC2., que nous soumettrons à diverses déconvenues courantes.
Programme
- 15 minutes de présentation de la nouvelle génération de systèmes de monitoring d’applications Java (AppDynamics, dynaTrace, JXInsight)
- 60 minutes de démonstration de cas concrets de monitoring :
- Installation et configuration : mise en place du monitoring, auto découverte, déclaration d’indicateurs applicatifs, ajout de nouveaux serveurs au cluster,
- Mise en place de tableaux de bord pour les équipes d’exploitation mais aussi de marketing et de développement,
- Monitoring durant les situations de crise : tableaux de bord « sur mesure » temporaires pour le management, le marketing et les équipes de troubleshooting,
- Monitoring au service du marketing : nous simulerons la mise en place de la sécurisation 3-D Secure des paiements carte bleue en mode A/B Testing,
- La place dans l’infrastructure du système de monitoring : synergies et chevauchement avec les serveurs d’application, les systèmes de gestion de logs, etc
- La vision de Jyoti Bansal sur les tendances du monitoring d’application, ce à quoi nous devons nous attendre
- Les internes des systèmes de monitoring de nouvelles génération :
- « java agent embarqué » versus « agent autonome » versus « sans agent »,
- les tableaux de bords, comment faciliter leur développement et leur utilisation à l’heure des widgets Open Social ?
- scalabilité des systèmes de monitoring à l’heure où le nombre de serveurs s’envole.
- Coktail avec Jyoti et son équipe.
N’hésitez pas à nous proposer des questions ou des cas d’utilisation que nous ajouterons à nos préparations (cleclerc@xebia.fr et plopez@xebia.fr).
Bio
Jyoti Bansal est fondateur, CEO et CTO d’AppDynamics. Il a auparavant été Principal Architect de Wily Introscope.
AppDynamics a été fondé en 2008. Cette solution de monitoring est utilisée par des clients de la génération Internet aux infrastructures avant-gardistes comme NetFlix (1700 JVM sur Amazon EC2) mais aussi des clients plus traditionnels comme l’opérateur télécoms Swisscom, l’assureur Provinzial Insurance ou l’agence de voyage Priceline.com.
Organisation de la soirée
La soirée se déroulera dans les locaux de Xebia au 156, boulevard Haussmann, 75008 Paris, à partir de 19h00.
Les inscriptions peuvent se faire :
- Par mail : info@xebia-training.fr
- Par téléphone : 01.53.89.99.93
(1) Nous avons retenu Spring Travel enrichie par les Spring Payment Services et une brique « Anti Fraude » pour montrer les appels inter applications java. Le code source est disponible sous licence Apache ici .
Publié par Pablo Lopez
Pablo est directeur technique chez Xebia et formateur Hadoop certifié par Cloudera au sein de Xebia Training .
Publié par Cyrille Le Clerc
CTO de Xebia, Cyrille est aussi committer sur le projet Apache CXF. Après être récemment intervenu sur les sites web et les plateformes de web service à fort traffic d'opérateurs de télécommunication, Cyrille est actuellement responsable de la mise en place d'une grille de données inter-continentale pour une grande institution financière française. Après 7 ans chez IBM Global Services et 5 ans chez Xebia, Cyrille a une expérience variée allant du monde commercial aux écosystèmes Open Source dans des approches aussi bien très cadrées et contractuelles que légères et agiles. Cyrille est aussi blogger sur blog.engineering.publicissapient.fr et speaker dans des conférences (In Memory Data Grids & NoSQL, applications prêtes pour la production, etc).
Commentaire
31 réponses pour " 14 Avril – Soirée Monitoring Pragmatique d’Applications Java avec le Fondateur et CTO d’AppDynamics "
Published by Cyrille Le Clerc , Il y a 12 ans
Nous sommes désolés d’organiser cet événement le même jour que l’anniversaire des JDuchess mais Jyoti Bansal n’était disponible que ce soir là.
Cyrille (Xebia)
Published by Ellène Dijoux , Il y a 12 ans
Ca peut arriver et on ne peut maîtriser pas l’agenda des autres. C’est une belle opportunité et j’espère que ce sera une belle soirée :)
Sinon pour ceux qui sont intéressés par la soirée anniversaire Duchess France il reste encore quelques places, dépêchez-vous ;)
Ellène (Xebia & Duchess France)
Published by Chris SK , Il y a 12 ans
Mais qu’est ce qu’il a ce 14 Avril. Soirée Paris Android User Group, Anniversaire des JDuchesses et Excellente soirée monitoring chez Xebia. Vraiment difficile.
Faudra songer à faire un #hashtagbattle.
Published by Cyrille Le Clerc , Il y a 12 ans
@Chris SK,
Vous nous flattez :-). Ca nous motive pour préparer plus encore !
Cyrille
Published by Hassan , Il y a 12 ans
Bonjour,
Merci pour la présentation d’hier.
Malheureusement c’était un peu trop light je trouve, surtout sur le cas de test, j’aurais préféré un problème plus réaliste comme la détection ‘préventive’ d’un memory leak, ressource non relâchées, un goulot d’étranglement dû à un problème de synchronisation des Threads…
A quand une présentation Dynatrace, Introscope ou OEM Grid Control? du sérieux quoi?
Merci encore une fois.
A+
Published by Cyrille Le Clerc , Il y a 12 ans
@Hassan,
Nous sommes désolés que la présentation vous ait laissé sur votre faim.
Est-ce que AppDynamics est moins sérieux qu’Introscope, Dynatrace ou OEM ?
Pour Dynatrace, nous sommes convaincus par nos expériences que les deux produits sont du même ordre.
Pour OEM Grid Control, nous ne savons nous prononcer car nous ne connaissons pas.
Enfin, pour Introscope, nous avons en tête des fonctionnalités que nous savons mettre en oeuvre sur AppDynamics, Dynatrace ou Hyperic mais pas sur Introscope :-).
Une démonstration avec des cas plus réalistes ?
Nous nous sommes concentrés les fonctionnalités apportées par cette nouvelle génération de systèmes de monitoring d’application. Nous aurions pris le même cas d’utilisation avec Dynatrace.
Nous vite sommes passés sur le « tableau de bord pour les exploitants » qui nous semblait peu différent de ce qu’offrait déjà la précédente génération de systèmes de monitoring ou les solution plus simples orientées JMX (Hyperic, etc).
C’est sur ce tableau de bord que serait apparue la fuite mémoire que vous évoquez, par exemple grâce à l’indicateur du temps de garbage par minute. Cette information est très simple à collecter, même avec « jstat » (YGCT et FGCT).
Pour la ressource non relâchée, nous aurions utilisé des compteurs de nombre de threads, de « file handles » ou d’éléments actifs par pool (jdbc, jms, etc) ; ces informations nous semblent accessibles sans difficulté avec tout type d’outil de monitoring.
Le problème de goulet d’étranglement lié à des points de synchronisation me semble aussi relever du tableau de bord exploitant avec des indicateurs qui montreraient que le débit n’augmente pas alors que la CPU est peu sollicitée par exemple.
Nous sommes encore désolés de n’avoir pas répondu à toutes vos attentes,
Pablo et Cyrille
Published by Hassan , Il y a 12 ans
Bonjour,
C’est pour ça que j’ai parlé de la détection préventive (Que je souligne bien) :)
Un TDA, MAT, GCViewer, VisuelVM… combinées avec les options de la JVM et les kills qui vont bien sont capables à eux seuls de résoudre beaucoup de problèmes de production sans couter un sous.
Je trouve que la vraie valeur ajoutée d’un outil de Monitoring est dans la détection des problèmes de production avant qu’ils surviennent : Ce sont ses algorithmes intelligents qui font sa force…
Par contre j’ai une petite question d’ordre technique, l’Id de correlation est-il vraiment passé dans le header, on ne modifie pas le code pour appeler le code de l’agent?
Merci encore une fois.
Published by Cyrille Le Clerc , Il y a 12 ans
@Hassan,
Positionnement des Application Performance Monitoring (APM) systems
Pour revenir sur le positionnement d’AppDynamics par rapport à Dynatrace ou JXInsight, je vous recommande le billet de William Louth JXInsight/OpenCore Competitive Comparison. C’est certes partisant et William Louth est souvent un peu trop critique envers ses concurrents à mon goût mais c’est très instructif. On voit bien les enjeux des APM.
Propagation du correlation-id
AppDynamics propage automatiquement les ids de correlation entre serveurs sur le protocole HTTP et JMS entres autres (cf. Supported application environments and frameworks).
Dans l’application démo d’hier soir, l’agent AppDynamics a enrichi les requêtes http/soap (client CXF – java.net.URLConnection) de la couche « e-commerce » et a récupéré ce correlation-id dans la couche « anti-fraud » (servlet CXF) sans que je n’ai rien à faire.
Si votre protocole de communication n’est pas supporté en « out-of-the-box », vous pouvez utiliser l’API AppDynamics pour propager vous même le correlation-id. Je vois déjà le cas d’usage de traitements multi threadés qui utiliseraient un ExecutorService.
J’avais montré dans la démo le « get-correlation-id » pour afficher cet information dans mes logs (
ITransactionDemarcator.getUniqueIdentifierForTransaction()) ; c’est assez simple. En revanche, le « set » semble plus compliqué (setUniqueIdentifierForTransaction(String), addCurrentThreadToTransaction(), removeCurrentThreadFromTransaction(), endContinuingTransaction(), etc). Il y a des exemples fournis avec l’API (dans le zip de AppServerAgent), ca semble suffisant pour de l’intra jvm (cf exemple MultiThreadedExecutor.java) mais j’ai l’impression qu’il faut plus d’informations pour faire de l’inter jvm.Cyrille
Published by Cyrille Le Clerc , Il y a 12 ans
Pour les personnes intéressées, voici le code, la présentation (keynote + pdf + omnigraffle), le plan jmeter (couche e-commerce) et les tests SOAPUI (couche anti-fraud) d’hier :
http://xebia-france.googlecode.com/svn/training/xebia-spring-travel/trunk/
http://xebia-france.googlecode.com/svn/training/xebia-spring-travel/trunk/xebia-spring-travel-ecommerce/src/site/
Il faut que je committe les dernières versions (notamment le tweak JMX Tomcat pour gérer les firewalls et le NAT-ing d’IP d’Amazon EC2), j’essaierai de la faire ce soir.
Cyrille
Published by Hassan , Il y a 12 ans
J’ai ‘aspiré’ le trunk, je fais mon analyse et je vous tiens au courant :)
A+
Published by Cyrille Le Clerc , Il y a 12 ans
Je viens de committer les dernières versions.
Cyrille
Published by Cyrille Le Clerc , Il y a 12 ans
La présentation est disponible sur slideshare : Java Application Monitoring with AppDynamics’ Founder
Published by Hassan , Il y a 12 ans
Bonjour,
Je reviens sur le forum pour partager avec vous mes tests de l’outil AppDynamics, notamment les points sur lesquels nous avons échangé dans les posts précédents.
Voici le scénario de test :
Infra : Une machine Red Hat 5 / Weblogic 10.3.4 / JDK 1.6 update 23 / tcpmon et quelques outils
Domaine : 1 serveur d’admin + 2 serveurs managés sans cluster et sur la même machine.
Mon objectif était de vérifier ces points :
– S’il y a bien un transfert du correlation-id inter JVM, et donc si Appdynamics est capable de retracer la pile d’appels complète sans toucher au code de l’application.
– Voir dans le cas d’un appel Http ou tout protocole ‘lisible’ où est-ce qu’il place le token (le correlation Id)
– Vérifier la détection des problèmes courants comme le timout du JTA, le thread stuck, Rollback d’une transaction ejb par exemple…
Bon je vais être bref, on pourra échanger sur les détails des tests après.
Test 1 : Démarrage d’appdynamics :
–> Bug : Si des patchs sont installés sur Weblogic la page d’accueil de la console Appdynamics est remplie de logs comme celui en bas et elle est donc inutilisable : Impossible de voir la cartographie des serveurs ou quoi que ce soit :
WebLogic Server Temporary Patch for xxxx Mon Aug 09 15:28:06 MDT 2010 ImplVersion: 10.3.4.0
–> Test 2 : Les EJB
– Appel EJB Local : J’ai mis le fameux Sleep dans mon Ejb et là j’ai bien une alerte Slow Request et la pile d’appel m’emmène jusqu’à l’intérieur de mon Ejb, nickel !
– Appel EJB Remote (Voilà un vrai test pour voir si le correlation-Id sait voyager ou pas :) ) :
J’ai fait un appel ejb sur du t3, ça ne marche pas c’est normal c’est un protocole propriétaire.
Le même sur sur de l’iiop, ça ne marche pas non plus ! Et là pas d’excuse pour Appdynamics c’est du standard.
Test 3 : Du JMS.
D’abord tout ce qui est problème JNDI, un MDB qui essaie de se connecter sur une file inexistante… Appdynamics ne le voit pas, la console weblogic remonte bien l’alerte mais lui il ne voit rien :) Ok on va dire que c’est pas son travail et il y a des outils pour ça…
Je fais le même test du sleep à l’intérieur du MDB, je n’ai aucune alerte dans Appdynamics !
Bon je force un peu le réglage du timeout dans le MDB, le JTA craque, il fait son rollback et appdynamics ne voit toujours rien :)
Je regarde le contenu du message que Weblogic a pris le soin de garder au chaud dans la file pour voir s’il y a une trace d’ajout d’éléments d’appdynamics : Aucun, je vois bien la property timeout que j’ai passé dans le message au MDB mais aucune trace de tags ou propriétés d’Appdynamics.
Test 4 : Là retour à la base, est-ce qu’il y a un correlation Id déjà qui sort de la JVM?
J’ai fais un test avec un appel Http d’une servlet depuis un HttpClient en passant par mon tcpmon, aucune trace du correlation id, et là vraiment pas d’excuse mon protocol est « Humain readable » et je ne vois les traces d’Appdynamics.
Test 5 : Je ne suis pas allé jusqu’à tester d’autres aspects de la prod comme la réservation des ressources, le classloader, la synchronisation des threads, les risques de fuite de la mémoire… puisque je sais à l’avance qu’il n’est pas fait pour.
Voilà mon idée était de découvrir ce produit par le test. Si quelqu’un d’autre a pris le temps de regarder l’outil de près qu’il partage avec nous :)
Si je me suis planté dans un test ou si vous êtes intéressés par mon appli de Test n’hésitez pas à me le signaler :)
@Cyrille
Par contre je reviens sur l’une de vos remarques :
« ces informations nous semblent accessibles sans difficulté avec tout type d’outil de monitoring. »
Je ne suis pas du tout d’accord, ces problèmes sont très récurrents en production, et demandent des fois beaucoup d’expertise et de technicité pour les résoudre (Déjà pour les détecter), et d’ailleurs ils font l’objet de tous les ouvrages qui traitent du monitoring et de l’optimisation de la JVM, sans parler de la détection préventive que tous les outils essaient de vendre et rares sont ceux qui savent faire…
Hassan
Published by Cyrille Le Clerc , Il y a 12 ans
@Hassan,
Merci pour toutes ces informations et tous ces tests.
Nous sommes très surpris par vos résultats. Même si notre démonstration utilisait Tomcat / CXF, nous avons en tête un dès plus gros chiffres d’affaire français sur le web qui utilise App Dynamics avec succès dans une configuration similaire à la votre : Weblogic / ejb-t3 / jms-activemq / http-client-axis sur plus de 50 serveurs.
Nous détaillerons cette topologie et le bon fonctionnement de ce monitoring dès que possible.
Cyrille et Pablo
Published by William Louth , Il y a 12 ans
Hassan. AppDynamics is really only suitable for very low hanging fruit – such things that could be detected with crude approaches such as stack dumps or simply looking over code. A lot of what is claimed is just not there or in a form that is only applicable in a very narrow context.
Any engineer that takes a product sold by a man in a cape going by the name of AppMan seriously needs to reconsider a change in profession, ;-). Seriously all of this « put out fires in 15mins » and « 3 clicks and its slowed » could only ever work if you are monitoring an application that was developed by newcomers and never tested before being pushed into production.
These claims belittle the efforts of people like myself who are designing and developing solutions that fully recognize the complexity and scalability that exists within the problem domain. I have never let on in my designs or blogs that all production problems can be solved so easily. This job involves knowledge acquisition, problem analysis and experimentation (instrumentation, measurement, collection => models). That’s never going to be done by those with very little performance engineering experience in 15 mins or with 3 clicks. This is the reality and buying such tools does not change it.
Published by Hassan , Il y a 12 ans
J’avais quatre convictions que j’ai essayé de défendre et de prouver à travers mes posts précédents :
1 – On ne peut pas positionner Appdynamics au même niveau que Dynatrace et OEM Grid Control. Ce serait comme comparer les premières versions de jcreator avec un eclipse bourré de plugins ou un netbeans.
2 – On ne peut pas prétendre qu’on peut avec un outil comme Appdynamics suivre aussi facilement une transaction complète dans un environnement complexe et distribué. Dynatrace propose la technologie PurePath qui n’est pas si simple à imiter.
3- Ce n’est pas par ce-que Appdynamics ne sait pas faire beaucoup de choses, comme les problèmes que j’ai cités auparavant, qu’on essaiera de convaincre tout le monde qu’ils sont sans importance, et qu’on les remontent pas juste parce-qu’ils sont faciles à détecter :)
4- Je ne vois pas trop la valeur ajoutée d’Appdynamics, c’est quoi son idée? Un outil de plus? Qu’est-ce qu’il vend au juste?
Moi personnellement il ne m’a pas convaincu.
Cordialement,
Published by Cyrille Le Clerc , Il y a 12 ans
@William,
First of all, it is an honor to have the founder and principal architect of a very technical software editor coming on our site. I have been reading your opinions for years.
We are a bit sorry not having been clear enough on the purpose of our presentation: we wanted to outline the break through innovations of this new generation of Application Performance Monitoring systems.
We feel that this generation of APM allows us to correlate the technical performance points with the impact on the business. That we can nowdays share use APM dashboards for the business teams.
Even better, that we can use APM metrics to evaluate business impacts of new features (canary testing, etc). That we can secure deployments of new features thanks to immediate feedbacks on the business indicators.
To summarize, we think that this new generation of Application Performance Monitoring systems is important to shorten the time to market.
We don’t want to start a flame war saying which one is the best between AppDynamics, DynaTrace and JXInsight (enumerated by alphabetical order ;-) ), we just think that they offer very interesting new opportunities to projects.
Cyrille
Published by Hassan , Il y a 12 ans
@William
I agree with you, but an optimization engineer, even very experimented, needs good tools to work quickly and cleanly, and I am persuaded that it is not with appdynamics that he will do that well…
Published by Pablo Lopez , Il y a 12 ans
@Hassan
Voici les tests réalisés ce matin avec un AppDynamicsLite fraichement téléchargé.
J’ai déployé le serveur et les agents très simplement, sans procéder à aucun tuning ni à aucune modification.
Pour répondre à votre premier message, et aux fonctionnalités « manquantes » :
Je n’ai pas eu de soucis de monitoring sur une version lourdement patchée de Weblo 10. Peut être avez vous une incompatibilité entre un patch Weblo et la version Lite (Test n°1)
L’appel vers un EJB en T3 est bien tracé en tant qu’appel RMI (Test n°2).
Copie d’écran :
En repassant coté Tomcat (je fais le test sur une architecture réelle), je vois bien les appels HTTP, ActiveMQ et Webservices (Tests n°3 et 4).
Copie d’écran :
Pour mémoire, la version Lite de AppDynamics ne permet de monitorer qu’une seule JVM instrumentée à la fois. Elle n’injecte donc pas d’ID de Correlation dans les communications inter JVMs (Test n°4). Seule la version standard/complète d’AppDynamics injecte ces ID de Correlation.
Concernant votre dernier message, je voudrais prévenir tout quiproquo en comparant Dynatrace à la version standard (ie complète) d’AppDynamics, pas à sa version Lite.
Pour avoir testé les deux, les fonctionnalités offertes par les versions complètes de ces logiciels sont proches, y compris la technologie « PurePath », basée sur le même principe d’injection d’Id de corrélation dans toutes les communications inter-jvms.
Pour répondre à votre question finale, en effet, AppDynamics n’est qu’un logiciel de monitoring « de plus ». Le but de la soirée, comme l’a rappelé Cyrille, était de présenter les nouvelles tendances des logiciels de monitoring, famille à laquelle appartiennent JxInsight, Dynatrace et AppDynamics.
Donc si vous avez déjà trouvé un logiciel dont les fonctionnalités et le modèle de cout vous conviennent, vous pouvez en effet décider que tout autre logiciel est superflu.
Published by Richard Hallier , Il y a 12 ans
Bonjour à tous,
J’ai lu avec attention les commentaires ci-dessus à propos d’appDynamics.
Je voudrais simplement apporter ma vision des choses sur cet outil que j’ai pu déployer en production sur une plateforme de services d’un grand opérateur. J’ai désigné moi-même la plateforme dans une architecture distribuée (JEE5, WS, remote EJB, JMS, …), j’ai donc une vision pleine et entière du système global à monitorer.
@Hassan 20/04/2011 19:31
Test 1/ Je ne peux rien dire sur la partie weblogic, car notre infrastructure repose principalement sur du JBoss
Test 2/ Nous n’avons aucun pb de propagation du correlationId par ejb remote (rmi). Je voudrais juste nuancer cet aspect car nous avons du forcer une instrumentation (interceptor custom) pour que cela fonctionne, notre version de jboss-remoting y étant peut-être pour quelque chose ! Ca m’a permis d’apprécier le support super réactif de l’équipe appdynamics
Test 3/ Pour le MDB avec une queue non existante, je ne suis pas sur que ca soit du ressort d’appDynamics, cela dit, ca se verrait sur le dashboard avec aucune activité pour le MDB.
Sur l’autre partie, nous monitorons sans problème les MDB.
Test 4/ Aucun soucis de notre coté, mais cela est sans nul doute du à la version light comme le souligne pablo
Test 5/ Je ne sais pas si la version light que vous semblez utiliser embarque les fonctionnalités que l’on retrouve sur la version pro comme le tracking des memory leak, la surveillance des ressources (thread pool, db connection pool, …), …
Je pense que vos tests seraient plus proches de la réalité sur une version pro en trial par exemple.
@Hassan 21/04/2011 23:38
Point 1/ AppDynamics se rapproche bcp de dynatrace tout en étant un peu plus light et plus orienté env de prod pour moi. Je ne connais pas Grid control.
Point 2/ Je pense pouvoir arguer du contraire avec notre expérience d’appDynamics en prod, mais cela reste mon appréciation.
Point 3 et 4/ Mon retour d’expérience sur ce produit est positif. Il nous a amené principalement 2 choses :
– visibilité : découpage en Business Transaction (vision utilisateur), infrastructure, garantie des SLA sur des BTs
– des temps de résolution d’anomalie (exception, temps de réponse, pb de confs, …) réellement raccourcis. En combinant un bon système d’alerte et un contexte d’exécution suffisamment riche (suivi de la BT dans le flux distribué, callgraph, requêtes sql exécutées, contexte jvm (heap & co)).
J’aime aussi la façon dont sont configurés les déclenchements de session diagnostic (automatiquement ou non).
Le support est aussi réactif et pointu.
Donc franchement pour l’instant, je suis satisfait même si il reste toujours des points à améliorer.
Désolé pour mon post qui ressemble à un bouquin, mais j’avais pas mal de posts à rattraper :)
Richard Hallier
Published by Alain Hélaïli , Il y a 12 ans
Bonjour à tous,
Ca serait un grand plaisir pour moi de vous montrer à nouveau en quoi dynaTrace n’est pas vraiment un outil du même ordre…
La prise en compte du cycle de vie de l’application (poste du développeur, PIC avec intégration JUnit/Selenium/Watir et autres à partir de Maven/Ant/MSBuild, plateforme de test avec intégration outil de load test LoadRunner/JMeter/etc et enfin production avec la possibilité de monitorer la plateforme depuis la couche applicative jusqu’à l’hyperviseur ESX VMware en passant par l’OS), la couverture technologique (Java, .Net, C/C++ et navigateur Web IE/Firefox) sont des éléments absolument uniques.
Quant à la technologie PurePath, ce n’est pas juste un moyen de taguer des messages. C’est aussi, entre autre, la possibilité partager le contexte technique et fonctionnel d’un incident. C’est la capture de la transaction problématique et de toutes les métriques systèmes puis son envoi automatisé pour l’analyse immédiate ou post-mortem.
Parler des nouvelles tendances du monitoring devrait impliquer qu’on examine un peu les processus de résolution des problèmes de production dans les organisations actuelles : qui utilise la solution de supervision et qui corrige le problème applicatif? Les ops d’un coté, les développeurs et architectes de l’autre. Et qu’est ce qu’ils continuent d’échanger comme information avec la plupart des solutions? Des screenshots et des logs, pas beaucoup plus.
Cordialement,
Alain Hélaïli, alain.helaili at dynaTrace.
Published by Hassan , Il y a 12 ans
Bonjour à tous,
@Richard, @Pablo :
Merci pour ce partage, oui effectivement j’ai utilisé la version disponible en téléchargement sur le site. Je ne savais pas qu’il existe deux versions : Une version complète et une autre version light d’entrée de gamme, j’avoue que sur ce coup je suis un peu habitué à la politique d’Oracle : Pas de clés, pas de verrous, télécharge le produit, fais tes tests et quand tu décides de l’utiliser en production tu passes à la caisse.
Sur le bug des patchs, je vous enverrai une capture d’écran.
Sur les autres tests, je ne peux pas vous contredire puisque je n’ai pas encore testé la version complète du produit, mais d’après ce que j’ai compris dans vos messages ça marche sans problème, tant mieux :)
Par contre, juste pour satisfaire ma curiosité, est-ce quelqu’un saura me dire comment les deux JVM échangent le correlation-Id (Dans le cas d’un JMS, un EJB et un WS) ? Merci d’avance.
Hassan
Published by noureddine , Il y a 12 ans
Bonjour,
je suis étonné que vous ne parlez pas de l’outil de Hp Diagnostics qui me semble être un sérieux concurrent aux différents outils présentés.
Published by Cyrille Le Clerc , Il y a 12 ans
@Noureddine,
Nous sommes désolés pour cette omission, nous n’avions plus en tête Hp Diagnostics. A notre décharge, ce n’est pas le produit le plus médiatique de notre éco-système :-) .
@Alain,
Merci pour cette proposition. Si nous refaisons une soirée sur des tendances des Application Performance Monitoring (APM) systems, nous vous contacterons avec plaisir.
Au risque de nous répéter, l’objet de cette soirée n’était pas de comparer les produits les uns aux autres mais de mettre en avant des possibilités apportées par cette nouvelle génération de systèmes de supervision. App Dynamics nous a proposé que Jyoti Bansal fasse un crochet par Paris en revenant de la conférence JAX London ; nous avons sauté sur l’occasion.
Cyrille
Published by Cyrille Le Clerc , Il y a 12 ans
@Hassan,
Pour l’échange des correlation-id, App Dynamics instrumente des différents protocoles (header ‘singularityheader’ en JMS et en HTTP).
Une fois l’id de correlation échangé entre les agents, c’est le serveur central qui retrace le chemin de passage des requêtes. Je viens de demander à Jyoti comment le serveur App Dynamics comprend dans quel ordre les agents sont traversés. J’imagine que l’heure des serveurs est une information trop fragile et trop sensible à des décalages pour être utilisée.
Cyrille
Published by noureddine , Il y a 12 ans
@Cyrile
On ne choisie pas un outil aussi critique avec un TCO qui peut être assez élevé parce qu’il est médiatique ;)
Mais vous avez raison il n’est pas très connu, c’est plus les SI qui ont déjà la suite HP BAC (Ex topaz) qui s’intéressent à cet outil.
Vous pouvez me donner svp plus de précision sur ce que vous appelez « nouvelle génération de systèmes de supervision. » (la différence avec « l’ancienne génération ») ?
Published by Cyrille Le Clerc , Il y a 12 ans
@Noureddine,
J’ai demandé à Jyoti les slides de la présentation qu’il nous a fait sur les caractéristiques de cette nouvelle génération d’APM. Jyoti avait bien respecté notre souhait de parler de la génération de logiciel et pas seulement de faire de la publicité pour son produit ; je pense que sa présentation sera suffisante.
Dans les grandes lignes, cette nouvelle génération de systèmes de monitoring de la performances des applications (APM) a les caractéristiques suivantes :
* Java Friendly : la version standard du produit sait monitorer du Java. Plus de justification du genre « nous n’avions plus d’argent pour payer les plugins Apache et Tomcat, nous ne pouvons faire que des ‘ps’ et monitorer les logs » (1)
* Java Component Friendly : en plus de savoir monitorer des indicateurs JMX, ces APM savent monitorer des composants java, des méthodes, des exceptions. Pour ce faire, ces APM utilisent le plus souvent un agent java,
* Multi Application Layer Aware : nos applications sont de plus en plus interconnectées (souvent en http), leurs dépendances ne se limitent plus à des base de données. Ces APM savent tracer les requêtes au travers des couches applicatives ; le plus souvent grâce auxes correlation-id dont nous discutions avec Hassan (voir supra),
* J’ajouterai enfin une nouvelle approche des tableaux de bord avec la facilitation d’encapsulation de ces tableaux de bord dans des wiki et/ou des tableaux de bord plus globaux (dashboard hudson pour les Devs, etc). App Dynamics est par exemple encore limité sur ce point et nous pressentons que les API Widget Open Social prendront un rôle croissant sur ce sujet.
Cyrille
(1) J’ai entendu cette justification il y a 18 mois sur un gros site web français ;-) je ne donnerai bien évidemment pas de nom sur l’outil mais nous avons colmaté en installant Hyperic HQ Open Source Edition.
Published by Cyrille Le Clerc , Il y a 12 ans
@Hassan,
Jyoti m’a répondu pour les correlation-id et l’identification de l’ordre des serveurs traversés. App Dynamics ne repose pas sur l’heure de la machine mais sur une autre technique qui est un « secret maison ».
Nous en avons discuté entre xebians hier soir lors de notre conclave mensuel :-) Notre hypothèse est :
correlation-id=request-id + server-id + increment
avec :
* request-id : généré par le premier serveur « appdynamics-agent-inside »
* server-id : l’id du serveur « appdynamics-agent-inside » pour que tous ses successeurs comprennent de qui provient la requete (ca permet le chainage). La valeur de « server-id » est écrasée sur chaque serveur.
* increment : qui permet de comprendre les réentrances avec probablement un aspect multi-dimensionnel pour supporter les branchements en Y
Cependant, cette approche sous entend que la valeur du correlation-id n’est pas exactement la même à sur chaque serveur et mon envie d’utiliser ce correlation-id dans les logs se trouve complexifiée : il faut extraire l’équivalent de la « request-id » pour faire des recherches de logs multi-serveurs :-(
@Noureddine,
Jyoti nous recommande cette video et ce billet. Je les regarderai dès que j’aurais quelques minutes et un accès non firewallé à youtube :-)
http://www.youtube.com/watch?v=-RrYc55vtCI
http://www.appdynamics.com/blog/2011/01/21/key-questions-to-ask-apm-vendors/
Cyrille
Published by Hassan , Il y a 12 ans
Personnellement je décroche dès que j’entends cette phrase : « Secret maison ».
Généralement ce n’est pas un bon signe :)
Published by William Louth , Il y a 12 ans
Its been a while but I did follow-up on the discussions related to transaction management in a blog entry.
BTM 2.0 – Behavioral Trait Metering & Metrics
http://williamlouth.wordpress.com/2011/05/13/btm-2-0-behavioral-trait-metering-metrics/
Again tracing as a means for transaction analysis is fundamentally flawed though to those new to performance measurement and analysis I understand its initial allure which generally is short lived once you get more experience.
There are ways to do this without having to tag-and-trace which scales both at runtime in analysis mode.
http://opencore.jinspired.com/?page_id=3645
I am sure some on this thread might think to refute some of this. If that is indeed the case I would like to propose a experiment (actually a challenge) at a customer site. We both bring along our solutions and expertise and apply them to a very interesting and demanding environment i.e. low latency securities trading platform.
Are you up to going head-to-head with our Intelligent Activity Metering engine and expertise?
http://opencore.jinspired.com/?page_id=3843
Published by Madhukar , Il y a 9 ans
Why we will use singularityheader