![]() |
Emploi
|
![]() |
Start-up
|
![]() |
Evénements 01 | ![]() |
Avis d'expert | ![]() |
Vidéos | ![]() |
Indicateurs
|
![]() |
Distribution
|
![]() |
Telecharger Pro
|
![]() |
Livres blancs | |||||||||||||||||||||












La plupart des problèmes de connexion aux applications ne sont pas détectés par les consoles centrales de supervision. Mais signalés par les utilisateurs. Dans ce contexte, les frameworks traditionnels – type Performance Manager (ex-Patrol) ou HP Openview – qui supervisent des ressources matérielles et logicielles ont clairement montré leur limite. Les éditeurs sont donc à la recherche d'une vision davantage déportée du côté de l'utilisateur.
Ils proposent des outils capables d'analyser plus finement les requêtes applicatives qui remontent vers les serveurs et passent au peigne fin les couches hautes du réseau. Ces nouveaux boîtiers, capables de relever et de décoder les transactions traversant le réseau, relancent la pertinence d'une telle approche.
Quelques ténors de l'administration – CA et HP notamment via les rachats respectifs de Wily et Mercury – ont acquis cette technologie dite de sniffer protocolaire. Elle complète d'autres solutions plus anciennes comme les “ robots ” à agents actifs ou les agents passifs installés sur le poste de travail.
Inventé par des start-up, le sniffer protocolaire se présente sous la forme d'un boîtier (appliance) raccordé à un port miroir du routeur, situé à l'entrée du centre de données. Ce boîtier relève l'ensemble du trafic Web, décode les requêtes applicatives passant dans le réseau IP (couche 7 du modèle OSI), et recompose les transactions.
“ La mesure du temps passé entre l'entrée et la sortie de ces requêtes, au niveau du routeur, aide le boîtier à calculer le temps de réponse ”, explique Gilles Portier, responsable avant-vente chez Compuware. Ces solutions se cantonnent souvent à l'observation des protocoles HTTP et HTTPS. La solution Vantage Agentless Monitoring, de Compuware, est capable de repérer des requêtes applicatives supplémentaires – XML, Soap, Jolt, SQL, entre autres – dans la couche haute du réseau.
Les données, recueillies en temps réel, sont ensuite transmises à un serveur qui les consolide. Il fournit des rapports réguliers relatifs à la performance de telle ou telle application. Si l'entreprise souhaite une gestion plus proactive des incidents, elle détermine un seuil déclencheur d'alerte. Une procédure facilitée par le mode opératoire des mesures de temps de réponse, découpées selon les grandes composantes du système d'information : poste client, réseau, serveur d'application, application. L'utilisateur de la solution bénéficie d'une première indication sur l'origine du problème.
Chez certains éditeurs, cette technologie est couplée à des outils de diagnostic orientés serveur d'application. Objectif : résoudre encore plus rapidement l'incident. CEM (Customer Experience Manager), de Wily/CA, par exemple, se combine à Introscope, la console de supervision des applications Web Java. L'administrateur est alors en mesure de basculer de l'interface utilisateur de CEM à celle d'Introscope.
Scénario classique : une fois la transaction défaillante repérée dans CEM, l'administrateur sera redirigé directement au niveau de l'objet mis en cause dans le serveur d'application en cliquant sur le lien Introscope. Il pourra même aller jusqu'à cerner les composants de la machine virtuelle java (JVM) qui posent problème. “ Introscope effectue en effet un javascripting des pages HTML qui redescendent vers le poste client, note Eric Serra, consultant avant-vente chez Wily/CA. Les bouts de code rajoutés par Introscope aident à obtenir cette intégration au niveau transactionnel entre les deux produits. ”
La grande force de ces boîtiers est de donner une vision exhaustive des requêtes applicatives générées sous forme de graphes ou de rapports. Cet outil offre aux exploitants la capacité d'évaluer l'effet d'un incident à l'échelle d'une entreprise. “ Cette solution formalise le problème ”, résume Gilles Portier. Et surtout d'en prendre la mesure, en sachant si un temps de réponse trop long touche quelques utilisateurs ou la totalité d'une unité géographique de l'entreprise. Dernière qualité : cette solution n'est pas intrusive puisqu'elle scrute un port miroir.
Son utilisation requiert tout de même un certain effort d'analyse de la part de l'utilisateur de l'outil afin de sélectionner les transactions pertinentes et de repérer les processus métier critiques dans l'ensemble du trafic Web. Autre limite : les boîtiers ne rendent pas compte des activités de l'utilisateur, car ils se placent au niveau du serveur Web.
De fait, les entreprises ont intérêt à l'utiliser en complément d'autres technologies de mesure de l'expérience de l'utilisateur. A commencer par les robots capables de rejouer des transactions préprogrammées, qui constituaient la technologie de référence avant l'arrivée des boîtiers de surveillance du trafic IP. En témoigne la pléthore d'éditeurs qui possèdent ce produit.
Concrètement, ce robot se matérialise souvent sous la forme d'un PC, localisé à un endroit stratégique de l'entreprise, sur lequel est développé un script qui rejoue des scénarios préenregistrés à intervalles réguliers. La comparaison avec le temps de réponse des transactions étalon aide à vérifier que la qualité de services est au rendez-vous. Il est ainsi possible de mesurer la qualité de service de l'application vingt-quatre heures sur vingt-quatre, et de la comparer à une mesure type. Le département de production peut alors contracter des engagements de services avec les utilisateurs (SLA).
En revanche, le coût de maintenance et d'administration de ces produits s'avère parfois rédhibitoire. Quand l'application surveillée évolue, il faut modifier le script, et l'investissement consenti dépendra du nombre de robots déployés à l'échelle de l'entreprise. Les entreprises se contentent alors d'un échantillonnage. C'est-à-dire qu'elles installent ces robots à des endroits stratégiques pour quelques unités géographiques clés.
Ces robots sont souvent recommandés par les éditeurs pour la surveillance des applications non prises en compte par les boîtiers sniffers protocolaires. “ Si l'on mesure l'activité pour un client lourd SAP, on utilisera un robot. S'il s'agit d'un client Netweaver, un boîtier sans agents ”, dit Gilles Portier.
La technique de supervision via des agents passifs placés sur le poste client est celle qui colle le mieux à l'activité l'utilisateur. Un morceau de code installé sur le PC observe les événements : saisie au clavier, déplacement de la souris, etc. Cet agent peut être programmé pour superviser les transactions clés et mesurer le temps de réponse. Et quel que soit le type d'interface : client lourd Win32 ou navigateur Internet Explorer. Le coût de déploiement et de maintenance des différents scripts génère un coût d'utilisation conséquent. Mais le degré de granularité et les métriques vont souvent au-delà du simple temps de réponse de la transaction.
C'est aussi la seule technique capable d'enregistrer complètement les actions de l'utilisateur et les erreurs. Cette supervision du poste de travail est pourtant délaissée par les ténors de l'administration. Certaines start-up (Knoa, PremiTech, le français Auditec, ou Reflectent, rachetée par Citrix) remettent néanmoins au goût du jour cette approche tombée en désuétude.
Produit : Customer Experience Manager
Commentaires : CA a acquis cette technologie par le biais du rachat de l'éditeur Wily, qui avait lui-même phagocyté la start-up Timestock. L'outil phare de Wily, Introscope, orienté diagnostic des transactions sur les plates-formes J2EE, s'intègre à cet outil.
La solution de CA est constituée de deux éléments : le boîtier TIM qui analyse le trafic. Il est relié à un serveur collectant les métriques des transactions et générant des rapports.
Produit : Vantage Agentless Monitoring
Commentaires : technologie développée à l'origine par la société Adlex, acquise par Compuware en 2005. Elle a été fondée avec l'aide d'un groupe d'investisseurs privés dont Roger Marino, cofondateur d'EMC. Elle est capable de décoder une grande variété de requêtes applicatives.
Produit : True Sight
Commentaires : fondé en 1997, cet acteur indépendant canadien a noué de nombreux partenariats avec des éditeurs gravitant dans l'univers de la supervision d'infrastructures dont IBM/ Tivoli et NetQoS.
Produit : Real User Monitor
Commentaires : HP ne disposait pas de cet outil jusqu'à l'acquisition de Mercury en 2006. La solution de ce dernier a été développée à l'origine par la société Beat Box Technologies.
Produit : NetQoS Performance Center
Commentaires : fondée en 1999, cette société américaine s'est concentrée, dès l'origine, sur la surveillance du réseau pour mieux analyser la performance des transactions. Sa technologie, NetQoS Superagent, mesure les temps de réponses au travers du réseau, des serveurs et des applications.
Produit : Foglight Experience Monitor
Commentaires : en dehors de cette technologie, l'éditeur dispose de robots en mesure de rejouer des transactions et d'un outil capable d'enregistrer les actions des utilisateurs (Foglight Experience Viewer), issu du rachat de la start-up Xaffire.
Produit : Tealeaf CX Solutions
Commentaires : Tealeaf est une spin off de SAP installée à San Francisco. Son produit est sorti des laboratoires de R&D de l'éditeur de progiciel intégré. Le fondateur et le CTO en sont d'ailleurs issus. Cette solution est davantage destinée aux experts fonctionnels qu'aux acteurs de la production.
Le sniffer protocolaire : le plus polyvalent
Les produits mis sur le marché se concentrent souvent sur les protocoles HTTP et HTTPS. D'où une utilisation qui se cantonne aux applications Internet ou Intranet. En revanche, il s'agit de la technique la plus aboutie pour observer des applications B to C à grande échelle et obtenir une vue exhaustive des transactions pénétrant dans le centre de données.
C'est aussi la seule technologie capable de corréler lenteur d'une application et nombre d'utilisateurs touchés. Elle s'adresse aux acteurs de la production, mais aussi à des personnes au profil fonctionnel.
Le robot jouant des transactions étalonnées : pour les applications les plus critiques
L'utilisation de cette technologie est freinée par son coût de maintenance. Il convient de maintenir les scripts qui rejouent les transactions simulées. Pour cette raison, elle est souvent utilisée pour les transactions majeures des applications les plus critiques.
Elle reste donc réservée aux VIP de l'entreprise ou aux applications utilisant des interfaces clients lourds. Elle autorise néanmoins à la DSI, via l'étalonnage des transactions rejouées, à s'engager sur des niveaux de services (SLA) vis-à-vis des utilisateurs finaux.
Les agents passifs sur le PC : une analyse fine mais limitée au poste de travail
C'est l'approche qui se place réellement du point de vue de l'utilisateur final. Mais elle ne peut convenir à l'analyse des performances des applications de commerce électronique (B to C) en raison de la nécessité d'installer des agents. Dans ce contexte, on lui préférera les “ sniffers protocolaires ”.
Elle s'utilise mieux, en revanche, dans un contexte d'utilisateurs internes. Les métriques précises recueillies aident à revenir sur les manipulations effectuées par l'utilisateur avant que la transaction n'échoue.
Jean-Pierre Garbani est vice-président de Forrester Research.
“ L'avantage à ceux qui décodent tous les protocoles ”
“ Tous les acteurs de la gestion de performance des applications possèdent plus ou moins la même technologie de collecte. Ils l'ont souvent acquise grâce au rachat de start-up, lors de la vague d'acquisitions observée en 2005. La différenciation entre les produits se situe plutôt au niveau des rapports statistiques qu'est capable de délivrer la solution. En général, les boîtiers se focalisent sur le protocole HTTP/HTTPS. Le produit de Compuware se distingue par sa capacité à décoder tous les protocoles applicatifs utilisant TCP/IP. ”
“ Identifier avant tout le maillon faible de la chaîne ”
“ Il reste difficile de corréler en temps réel des événements. Même si des éditeurs comme Quest sont capables de fournir un monitorat de bout en bout, avec une console spécifique pour chaque maillon de la chaîne applicative, on reste limité par l'impossibilité d'aligner les différentes informations dans le temps. On ne peut pas corréler en temps réel, par exemple, le temps de réponse d'une transaction et la charge CPU si le relevé est effectué dans un intervalle de temps différent. L'intérêt de ces solutions est avant tout de cerner le maillon de la chaîne qui pose problème et de proposer une surveillance relativement exhaustive des transactions. ”
Laurent Dupire est consultant à la direction technique du secteur public chez Atos Origin.
“ Nous avons testé l'outil de Compuware afin de voir si l'application Helios, développée pour la direction générale de la comptabilité publique, collait bien dans sa globalité aux utilisateurs, et de dresser une cartographie de la performance. Les robots avec agent actif ne répondent pas à ce besoin. Il s'agit de donner des indicateurs précis quant à la disponibilité et la performance de l'application. Au bout d'une journée, la solution livre une liste des transactions les plus lentes et restitue les performances sous forme de rapport pour des personnes non techniques. L'écrémage des transactions les plus lentes améliore la maintenance de l'application. Les qualités de cette solution proviennent de son caractère non invasif et des informations très factuelles qu'elle restitue. ”
















