La surveillance des applications

Connu pour ses logiciels de tests, Mercury dispose également d'une offre intégrée de surveillance des architectures multiniveaux.

En rachetant Mercury, l'été dernier, HP ne s'est pas uniquement offert le roi du test logiciel. L'éditeur d'origine israélienne dispose, en effet, d'un arsenal d'outils de surveillance des applications et de leurs performances, symbolisé par la console Business Availability Center (BAC, ex-Topaz). Cet arsenal gomme certaines carences de la gamme HP Openview, issue du monde des réseaux, qui se cantonne peu ou prou à la supervision des serveurs et des systèmes. La technologie de Mercury repose donc sur celle développée pour ses logiciels de tests. Ce qui, en théorie, sert à réutiliser en production les scripts de mesure de comportement des applications développés au cours des tests.

Les multiniveaux inspectés à la loupe

La console BAC est une solution non intrusive assez complète et intégrée pour surveiller les applications multiniveaux. Elle se présente sous la forme d'une seule plate-forme à installer avec différents modules, baptisés moniteurs, à activer dans l'optique d'une surveillance des différents éléments de la chaîne applicative. Côté poste client, la suite comprend des modules de supervision de l'activité (réelle ou simulée) de l'utilisateur. La brique de supervision des données techniques de l'infrastructure, System Availability Management (SAM), met en corrélation la remontée d'événements issus de l'infrastructure et l'analyse des transactions. Le module Mercury Diagnostics facilite l'analyse des transactions passant au niveau des serveurs d'applications et des requêtes SQL. Cette solution requiert l'installation d'agents sur les serveurs en [e-mail]

Mercury garde sous contrôle l'architecture SAP Netweaver

Business Process Monitor et Client Monitor sont capables de rejouer des transactions types dites synthétiques, à intervalles réguliers, au niveau d'une interface web comme d'un client lourd. Ces robots circonscrivent un problème à une zone du système d'information, en analysant le temps passé par la transaction entre chacun des composants (postes clients, serveur web, serveur d'applications, et base de données).

Le module System Availability Management (SAM) remonte les données techniques de l'infrastructure (incidents sur un serveur, etc.) et les met en corrélation avec les informations transactionnelles. SAM se connecte aux frameworks traditionnels comme HP Openwiew ou CA Unicenter. Il peut aussi simplement s'appuyer sur Sitescope, l'outil de surveillance sans agents de Mercury, qui recueille les données de performances et de disponibilité.

Le module Diagnostics suit individuellement les requêtes. Des agents installés sur les serveurs - ici sur le serveur d'applications WAS, de SAP, - collectent les métriques au niveau des JVM (temps d'exécution des méthodes Java notamment). Pour l'analyse des transactions passant par le noyau ABAP, le module se synchronise sur les ' logs ' de CCMS (Computer Center Management System), de SAP, et les duplique. Au final, l'outil suit le chemin parcouru par une requête et sait quel jeu d'essai ABAP ou quelle méthode Java pose problème.

Diagnostics assure également la surveillance des requêtes SQL. En complément, le module SAM s'interface à la console dadministration du SGBD (Oracle, SQL Server, etc.) et recueille les informations techniques (logs, contentions, etc.). Une version récente de Diagnostics, spécifique à Oracle, sert à observer les requêtes directement dans la base de données.