UFR IMA
Master 2 Pro Génie Informatique
Réalisation d'un système de gestion de notications dans
l'outil open source JASMINe pour superviser les grappes de serveurs
Java EE.
Cahier des charges
Équipe :
Jean-Pierre POUTCHEU Alina-Mihaela RADU Tianyi HAN
Maître de stage :
Julien LEGRAND - BullConsultant :
Thibault PARMENTIER - Object DirectClient :
Bull SAS - EchirollesDocument Cahier des Charges
Version 1.2
Commencé le 5 mars 2009
Dernière modication 14 août 2009
Statut Final
Client Bull SAS
Équipe Alina RADU
Jean-Pierre POUTCHEU Tianyi HAN
Responsable de la rédaction du document Alina RADU Tab. 1 La gestion des versions de ce document
Modication Auteur Date
v1.1 - Mise à jour des fonctionnalités - audit de B. Pelletier Alina Radu 10 juin 2009 v1.2 - Changements mineurs pour la cohérence des documents Alina Radu 14 août 2009
Tab. 2 L'historique des modications de ce document
Table des matières
1 Introduction 1
1.1 But et portée du document . . . 1
1.1.1 But . . . 1
1.1.2 Portée du document . . . 2
1.2 Cadre et objectifs du projet . . . 2
1.2.1 Cadre . . . 2
1.2.2 Objectif du projet . . . 2
1.3 Dénitions et acronymes . . . 2
1.3.1 Dénitions . . . 2
1.3.2 Acronymes . . . 3
2 Description générale 5 2.1 Description du système existant . . . 5
2.1.1 JOnAS . . . 5
2.1.2 JASMINe . . . 5
2.1.3 Description du nouveau module . . . 8
2.2 Analyse de la concurrence pour le module de gestion de notications 9 2.2.1 Oracle JRockit Mission Control (v3.0.3) . . . 9
2.2.2 JBoss Operations Network (v2.1) . . . 12
2.2.3 Comparaison entre les deux solutions étudiées . . . 13
2.3 Principaux problèmes rencontrés . . . 15
2.3.1 L'interface graphique . . . 15
3 Fonctionnalités 17 3.1 Préliminaires . . . 17
3.1.1 Kerneos . . . 17
3.1.2 Installateur graphique pour JASMINe Monitoring. . . 19
3.2 Module de gestion d'notications . . . 19
3.2.1 Création d'une notication - Must . . . 19
3.2.2 Gestion des notications - Must. . . 20
3.2.3 Rapport - sommaire notications - Must . . . 20
3.2.4 Stockage des notications - Must . . . 20
3.2.5 Proposition d'IHM . . . 20
4 Exigences non-fonctionnelles 23 4.1 Qualité du logiciel . . . 23
4.1.1 Maintenabilité . . . 23
4.1.2 Utilisabilité . . . 23
4.2 La gestion des risques . . . 24
4.2.1 Risque au niveau de l'IHM . . . 24
iv Table des matières
5 Contraintes de développement 25
5.1 Contraintes au niveau du temps . . . 25 5.2 Contraintes au niveau de l'équipe . . . 25 5.3 Contraintes au niveau des technologies . . . 25
Cahier des charges
Chapitre 1
Introduction
Sommaire
1.1 But et portée du document . . . . 1
1.1.1 But . . . . 1
1.1.2 Portée du document . . . . 2
1.2 Cadre et objectifs du projet . . . . 2
1.2.1 Cadre . . . . 2
1.2.2 Objectif du projet . . . . 2
1.3 Dénitions et acronymes . . . . 2
1.3.1 Dénitions . . . . 2
1.3.2 Acronymes . . . . 3
1.1 But et portée du document
1.1.1 But
Le cahier des charges est un document contractuel qui a pour objet de dénir précisément le produit à réaliser. Il décrit les fonctionnalités et caractéristiques du produit ainsi que les contraintes de développement et d'exploitation.
Les cours de Génie Logiciel associés à nos réexions, ainsi que les indications de notre maître de stage et notre consultant furent le point de départ à la rédaction de ce Cahier Des Charges.
Ce document est utilisé par les clients et les fournisseurs du produit. Il leur permet d'avoir une dénition unique et précise du produit.
Ce document sert de base :
• à l'évaluation du produit nal ;
• à la rédaction du plan de tests ;
• à la réalisation des documents suivants : Dossier de spécications externes ; Plan de qualité ;
Dossier de conception ; Dossier de gestion du projet.
2 Chapitre 1. Introduction 1.1.2 Portée du document
Ce document est destiné :
• à notre client : Bull SAS - Echirolles ;
• à l'équipe de dévéloppement JOnAS ;
• au jury du Master2 Pro GI pour l'évaluation du stage.
Le document sera révisé aussi par notre maître de stage, M. Julien Legrand et par notre consultant, M. Thibault Parmentier de Object Direct.
1.2 Cadre et objectifs du projet
1.2.1 Cadre
Le projet se déroule dans les locaux de l'entreprise Bull SAS à Echirolles, sous la responsabilité de M. Julien Legrand.
Bull se positionne comme un specialiste des systèmes d'information ouverts.
C'est un acteur majeur de l'open source pour les entreprises, notamment par son travail sur plusieurs projets du consortium OW2 (serveur d'application JOnAS, Ea- syBeans). Il est le premier fournisseur global en systèmes d'information d'origine europeenne. Bull est présent dans plus de 100 pays et est particulièrement actif dans le secteur public, la défense, la banque, l'industrie, la santé et les télécommu- nications.
1.2.2 Objectif du projet
L'objectif du projet consiste à la réalisation d'un système de gestion de noti- cations dans l'outil open source OW2 JASMINe pour superviser les grappes de serveurs Java EE. Notre travail consistera à spécier, implémenter et intégrer un nouveau module de gestion des notications dans l'outil JASMINe monitoring. Ce module sera utilisé pour notier l'administrateur du cluster des serveurs, en cas de problème dans son système. Les notications seront déclenchées par le moteur de règles open source Drools et persistées en base de données. On détaillera ces objectifs dans les sections suivantes.
1.3 Dénitions et acronymes
1.3.1 Dénitions
serveur d'applications - serveur ayant pour vocation l'exécution de logiciel, par opposition à un serveur mail ou d'impression.
notication - un message vers l'utilisateur qui l'avertit de l'occurence d'un évé- nement. L'notication peut être caracterisée par son :
état - acquitée ou non ; Cahier des charges
1.3. Dénitions et acronymes 3 gravité - des dierents niveaux de gravité seront prevus (Info, Debug, Error,
Fatal etc.) ;
message - un message spécique pour comprendre le but de l'notication ; cause - la source qui a déclenché la notication ;
heure et date - le moment du déclenchement de la notication.
ensemble de conditions - plusieurs conditions qui sont évaluées pour vérier si une notication se déclenche à un moment donné.
1.3.2 Acronymes
JASMINe - plusieurs interpretations possibles :
• Java Administration Servers Management for InterNet environment
• JAva SOA Management to Improve the admiNistration eciency JOnAS - Java Open Application Server
SOA - Service Oriented Architecture JRMC - JRockit Mission Control
OS - Operating System - Système d'exploitation
Cahier des charges
Chapitre 2
Description générale
Sommaire
2.1 Description du système existant . . . . 5
2.1.1 JOnAS . . . . 5
2.1.2 JASMINe . . . . 5
2.1.3 Description du nouveau module. . . . 8
2.2 Analyse de la concurrence pour le module de gestion de notications . . . . 9
2.2.1 Oracle JRockit Mission Control (v3.0.3) . . . . 9
2.2.2 JBoss Operations Network (v2.1) . . . . 12
2.2.3 Comparaison entre les deux solutions étudiées. . . . 13
2.3 Principaux problèmes rencontrés . . . 15
2.3.1 L'interface graphique. . . . 15
2.1 Description du système existant
2.1.1 JOnAS
Bull est leader du projet JOnAS au sein du consortium OW2. Bull en maîtrise le coeur et gère les contributions et la roadmap. Il contribue aussi aux composants externes utilisés dans JOnAS, comme Tomcat et Axis. JOnAS (Java Open Appli- cation Server) est un serveur d'application certié Java EE 5 depuis mars 2009. Le projet a débuté en 1998 et se place aujourd'hui en seconde position des serveurs d'applications libres, derrière JBoss. Dans sa version 5, JOnAS a la particularité de s'appuyer sur le modèle de composants OSGi, ce qui le rend adaptable dynamique- ment et lui confère une grande modularité et une grande souplesse : par exemple, le chargement et le déchargement de modules à chaud.
2.1.2 JASMINe
Pour répondre aux besoins croissants de performance et de haute disponibilité, les grappes de serveurs d'application se développent dans les systèmes d'information des entreprises. Elles soulèvent de nouveaux problèmes d'administration qui sont à la limite d'être gérables par l'humain de part leurs complexités :
6 Chapitre 2. Description générale
• le modèle N-tiers, Java EE et les machines virtuelles JAVA, les multiples instances d'une grappe augmentent considérablement le nombre d'entités lo- gicielles à administrer et le nombre d'événements à observer dans le système global ;
• les nombreuses possibilités de conguration et d'optimisation des perfor- mances oertes par ces intergiciels, couplées à la richesse des spécications Java EE, nécessitent le réglage d'une multitude de paramètres.
L'outil d'administration JASMINe répond à cette problématique en simpliant la vie des exploitants des plates-formes Java EE, composées par exemple des ser- veurs JOnAS, le serveur d'application open source d'OW2. Le système, doté de fonctionnalités évoluées et de comportements autonomes, vise à minimiser les coûts d'administration en :
• réduisant les erreurs de conguration : une grande partie des mauvais fonc- tionnements observés dans les environnements informatiques sont dus à des erreurs humaines de conguration des logiciels utilisés ;
• améliorant la réactivité en cas de dysfonctionnement : une intervention hu- maine pour détecter une anomalie, régler ou réparer un service logiciel im- plique un délai qui n'est pas toujours acceptable.
JASMINe est constituée de plusieurs modules assistant l'exploitant dans chacune de ses taches d'administration :
• Design/Deploy : outil de description d'architecture grappe Java EE et de déploiement de la grappe sur l'architecture physique ;
• Monitoring : outil de détection d'erreur permettant la remontée d'alertes ou de notications à l'exploitant ; il sert aussi à suivre des performances en temps réel ou hors ligne à partir de courbes graphiques ;
• Self-management : implémentation de comportements autonomes pour répa- rer ou optimiser une grappe.
Nôtre travail s'intègrera au sein du module JASMINe Monitoring.
Pour dénir les fonctions du nouveau module à réaliser, il est necessaire de com- prendre la structure de JASMINe Monitoring. JASMINe Monitoring est constitué de plusieurs modules :
Un bus de messages : l'Event-Switch reposant surMule, par lequel transitent toutes les communications.
Des sondes avec MBeanCmd, un utilitaire en ligne de commande qui permet de déployer des sondes sur des instances de serveurs et d'injecter les résultats dans l'Event-Switch.
Un moteur de règles : Drools, qui est l'éxécutant de la fonction d'auto-gestion.
Drools, ou JBoss rules, est un BRMS (Business Rules Management System), qui permet de déployer des règles de management dans une organisation ou une application.
Cahier des charges
2.1. Description du système existant 7
Fig. 2.1 Architecture de JASMINe Monitoring
Cahier des charges
8 Chapitre 2. Description générale
Fig. 2.2 La console EoS, achant un module de monitoring.
Une console web : JASMINe EoS (Eye of SOA). Comme son nom l'indique, EoS permet par exemple de visualiser les sondes déployées grâce à ses diérents modules (gure 2.2).
Les serveurs d'applications JOnAS orent des MBeans pour être surveillés.
MBeanCmd est un outil en ligne de commande, écrit en Java, pour interagir avec ces MBeans exposés par les serveurs J2EE. MBeanCmd peut envoyer des commandes aux MBeans, peut recevoir les resultats de la commande (par exemple la charge du CPU mésurée par un MBean de la JVM). Ces resultats peuvent être achés, enre- gistrés dans un chier ou peuvent servir pour construir des graphes. Ils sont aussi envoyés vers l'Event-Switch de JASMINe (cf. gure 2.2).
Dans l'Event-Switch, ces résultat sont dirigés vers dierents points de sortie, soit pour être persistés dans une base de données, soit pour être achés comme graphe (dans les modules QuickVisu ou Monitoring de la console web JASMINe EoS). Ces résultats seront aussi utilisés comme entrés pour le moteur de règles Drools qui executera des tâches spéciques, congurées par l'administrateur.
2.1.3 Description du nouveau module
Un type de tâche qui peut être dénie par l'administrateur est une notication.
Ces notications seront déclenchées par le moteur de règles open source Drools et persistées aussi en base de données. Un workow humain permettra de gérer le cycle Cahier des charges
2.2. Analyse de la concurrence pour le module de gestion de
notications 9
de vie de la notication et ses interactions avec l'opérateur (visualisation en détail, acquittement, etc.).
Des étapes préliminaires sont necessaires pour réaliser ce nouveau module :
• L'extraction du coeur de JASMINe EoS
• La réalisation d'un installeur pour JASMINe Monitoring Ces étapes seront detaillés dans la section 3.
2.2 Analyse de la concurrence pour le module de gestion de notications
2.2.1 Oracle JRockit Mission Control (v3.0.3)
Oracle JRockit Mission Control contient une suite d'outils pour monitoriser, gérer, proler et éliminer les fuites de mémoire dans les applications Java. Plus précis, ces outils sont :
une console interactive de gestion appelée Management Console, qui donne la possiblité de visualiser le garbage collector et d'autres statistiques de perfor- mance ;
un outil de performance à l'execution appellé Runtime Analyzer ; un outil d'analyse de memoire appellé Memory Leak Detector ;
un analyseur de latence qui montre d'une manière graphique les arrêts des les d'execution dûs à la synchronisation, les entrées et les sorties au niveau du système des chiers et du réseau, l'allocation de memoire et les pauses du garbage collector.
Dans JRMC, une alerte est un message vers l'utilisateur qui l'avertit de l'oc- curence d'un événement. Ces alertes peuvent être déclenchées quand la connection avec Oracle JRockit JVM a été perdue ou quand un attribut a atteint une certaine valeur ou limite, par exemple quand la mémoire utilisée depasse 90%. On peut aussi établir des contraintes pour limiter l'activation d'une règle. Par exemple, on peut empêcher JRMC d'envoyer des alertes la nuit ou entre certaines dates.
Pour ajouter une nouvelle règle de déclenchement pour une alerte, JRMC dispose d'un wizard qui permet de choisir l'attribut sur lequel on veut écouter. Cet attribut est choisi avec l'aide d'une browser de MBeans (Fig. 2.3). Le pas suivant est d'établir quelle est la limite pour le déclenchement de l'alerte et combien du temps (en se- condes) les conditions de la règle doivent être vraies pour déclencher l'alerte. Ainsi, on a la possibilité de préciser le temps (en secondes) entre deux déclenchements consécutifs. Une conguration nous permet d'établir si le déclenchement se passe sur un anc ascendant (on déclenche l'alerte quand la valeur de l'attribut monte) ou sur un anc descendant (on déclenche l'alerte quand la valeur de l'attribut descend).
Le wizard propose en suite des actions pour le déclenchement d'une alerte. Ces actions sont :
envoyer une alerte vers l'application : acher une notication dans la fenêtre Trigger Alerts Dialog. Dans cette fenêtre on peut aussi voir les détails de Cahier des charges
10 Chapitre 2. Description générale
Fig. 2.3 MBean Browser
Cahier des charges
2.2. Analyse de la concurrence pour le module de gestion de
notications 11
chaque alerte, sa date et heure, la règle de déclenchement, la source qui l'a déclenché et la valeur exacte de l'attribut à l'heure du déclenchement ; envoyer un avertissement dans la console (avec un System.out) ;
envoyer un mail à une adresse spécique (avec des options de CC et BCC) ; démarrer un enregistrement JRockit Runtime Analyser (JRA) - pour cette op-
tion on doit préciser le type d'échantillonnage souhaité (ce qu'on veut échan- tillonner, par exemple le garbage collector, les méthodes) et aussi la durée de l'enregistrement et le nom de chier où on veut déposer les résultats ;
créer une trace des les d'éxecution : thread stackdump, pour trouver des infor- mations sur l'activitée des les d'éxecution d'une application. Ces informations peuvent être utiles pour diagnostiquer l'application ou pour l'optimiser. Par exemple, les traces peuvent montrer des interblocages entre les les d'exécu- tions. Pour activer cette option, on est censé préciser la méthode de sortie (soit un chier de jurnalisation, soit une alerte système). Les traces ont lieu d'habitude dans le cas d'une erreur.
Fig. 2.4 Fenêtre Trigger - permet la dénition et l'édition des notications La dèrniere étape est optionnelle. On peut limiter le déclenchement d'une action ; par exemple on veut que l'action se déclenche tous les deux jours de la semaine, dans un interval de jours précis ou entre des heures spéciques. Dans la Figure 2.4 on peut observer la fenêtre principale pour denir et éditer les notications.
Cahier des charges
12 Chapitre 2. Description générale
2.2.2 JBoss Operations Network (v2.1)
JBoss ON est composé d'une console capable de monitorer des plate-formes, des serveurs et des services. Elle consiste d'un serveur et d'un agent. Le serveur administre, congure et contrôle toutes les resources. Il gére les événements qui sur- viennent, en générant des alertes et/ou déclenchant des operations qui correspondent à ces événements. La partie Monitoring de JBoss ON correspond dans notre sys- tème à JASMINe Monitoring. La partie que nous intéresse le plus est la partie de gestion de notications ou alertes dans JBoss ON. Le mécanisme d'alertes ore des notications pour des conditions dénies par l'utilisateur. Ce mécanisme est utilisé pour notier les administrateurs en cas de problèmes de performance ou d'échec d'opération.
Ces alertes peuvent être dénies à partir de chaque ressource (plate-forme, serveur ou service), en prenant en considération des paramètres spéciques. Par exemple, pour le système de chiers d'une platforme, les paramètres qu'on peut prendre en compte sont : Free Space, Used Percentage, Disk Reads, Disk Reads per Minute, Disk Writes, Disk Writes per Minute, Disk Read Bytes, Disk Read Bytes per Minute, Disk Write Bytes, Disk Write Bytes per Minute, Disk Queue, etc. Les types de ressources que peuvent être gérées sont :
plate-formes Java, Linux, Windows ;
serveurs Apache, JBoss, JMX, Postgres, Tomcat, IIS ; services Files System, Network Adapter, CPU.
En prenant l'exemple d'une plate-forme pour laquelle on surveille la carte réseau, on peut dénir une alerte et la nommer. Ensuite, on va établir l'ensemble de conditions dans lesquelles elle se déclenche. La notication peut se déclencher quand n'importe quelle condition de l'ensemble est vraie (option ANY) ou quand toutes les conditions de l'ensemble sont vraies (option ALL).
Quand on dénit une condition, la premiere étape est de dénir la If condition de l'alerte. Elle peut être de type Metric (par exemple, l'espace libre d'un disque dur devient plus petit que 50% de sa capacité). A noter que ce type de condition est le plus riche. D'autres types de conditions sont Trait et Availability. Alors que les mesures sont des données numériques et ont la tendance de se changer fréquemment, les traits sont plutôt statiques et peuvent être comparés avec la dernière valeurs mésurée pour ce trait. Par exemple, pour une plate-forme, on peut comparer la version actuelle de l'OS avec la dernière valeur mesurée. En ce qui concerne la disponibilité d'une ressource, l'administrateur est notié si la ressource change son état, de disponible à indisponible ou vice-versa.
Une option intéressante est l'Alert Dampening ou l'atténuation des alertes. Alert Dampening est une forme d'agrégation de plusieurs alertes. Au lieu d'être alerté chaque fois que l'ensemble de condition est evalué comme vrai, l'administrateur peut demander, par exemple, d'être alerté une fois chaque X fois que l'ensemble de conditions est vrai.
Une autre option est l'Action Filtering. On peut, après avoir déclenché l'alerte, la désactiver, pour ne pas déclencher d'autres alertes du même type jusqu'au moment Cahier des charges
2.2. Analyse de la concurrence pour le module de gestion de
notications 13
que le problème soit resolu.
La dernière partie de la dénition d'une alerte est la Notication. L'adminis- trateur doit être averti d'une manière ou de l'autre quand l'ensemble de conditions est vrai. En JBoss ON, les notications sont envoyée par mail ou par SNMP trap.
L'envoi de mail peut se faire par rôle. On peut dénir des rôles à notier. Chaque utilisateur a un rôle attribué. Le compte utilisateur correspond à une adresse mail où l'alerte est envoyée. L'alerte peut être aussi envoyée par compte utilisateur, sans pas- ser par rôle, ou directement en spéciant une adresse mail, sans qu'elle soit associée à un rôle ou à un nom d'utilisateur.
La journalisation des conditions est indispensable pour une application de telle sorte. Elle est responsable avec l'enregistrement du moment quand une condition d'alerte à été remplie ainsi que la valeur exacte du paramètre qui a declenché l'alerte.
L'alerte peut être activée ou desactivée. Quand elle est active, ses conditions de déclenchement sont veriées par le moteur qui traite les alertes. Si une alerte est inactive, elle n'est pas traitée par le moteur et ses conditions ne sont pas veriées.
Le même type d'alerte peut être dénie pour un événement. Les événements sont spéciques aux plate-formes :
Windows (Windows events) ;
Apache Server (les chiers de journalisation) ; JBossAS Server (les chiers de journalisation).
La source d'un événement est attachée à une ressource particulliere et elle dénit l'origine d'un événement. Une source typique d'événements est le chier de log d'une ressource. Pour le futur, JBoss ON envisage comme source pour les événements, aussi des notications JMX. Un événement est declenché chaque fois que les conditions d'une source sont remplies. L'événement signale les valeurs qui correspondent au critère établi. Par exemple, quand une entrée du chier de jurnalisation correspond à des contraintes de gravité est aux expressions régulières dénies, l'événement est signalé. Chaque événement a donc des niveaux de gravité associée (severity). Ces niveaux sont : Debug, Info, Warn, Error, Fatal. Dans la Figure 2.5on peut observer une suite d'événements, avec leurs sources, leurs types de gravité, le moment de déclenchement. On peut aussi acquiter les événements signalés. L'option qui nous concerne dans la dénition d'un événement est la dénition d'une alerte qui peut se déclencher à la suite d'un événement. Les conditions de l'alerte sont les mêmes que les conditions énumérées ci-dessus, mais, en plus, on peut choisir au lieu de Metric, Trait ou Availability, l'option Severity, pour déclencher l'alerte pour des événements avec une telle gravité.
2.2.3 Comparaison entre les deux solutions étudiées
Pour conclure, le MBeans Browser de JRMC ore une bonne vision sur tous les attributs qu'on peut surveiller. Dans notre application, on utilisera aussi une méthode similaire pour pouvoir naviguer parmi les attributs à monitorer. Les at- tributs seront classés par "théme" (des attributs de la JVM, des attributs phy- siques, de genre chargement du processeur, etc). Un problème observé dans les deux Cahier des charges
14 Chapitre 2. Description générale
Fig. 2.5 Evénements en JBoss ON
consoles est la manque de l'unité de mesure qui s'applique pour certains attributs.
Par exemple, quand on met une limite sur l'espace libre du disque dur d'un serveur, on ne sait pas exactement s'il faut la mettre dans Mo ou dans Go. L'application qu'on souhaite mettre en ÷uvre indiquera des unités de mesure qui se changeront selon l'attribut sélectionné.
Dans JRMC, l'assistant pour créer une nouvelle règle est facile à utiliser et l'édition d'une règle se fait dans la fenêtre principale des Triggers. Par contre, on ne peut pas ajouter plusieurs attributs, chacun avec sa propre limite pour créer une seule règle, comme dans JBoss ON. Même si, dans JBoss ON cette fonction est assez limitée (on peut choisir le déclenchement d'une alerte soit quand une des règles est vraie - ANY, soit quand toutes sont vraies - ALL), elle n'existe pas dans JRMC.
Dans notre produit, on souhaiterait pouvoir créer facilement des règles basées sur des expressions logiques, avec divers opérateurs. Exemple :
when Condition_1 AND (Condition_2 OR Condition_3) then Trigger_Alert où
Condition_1 : attribute_1 == 0
Condition_2 : attribute_2 matches ``expression``
Condition_3 : attribute_3 < limit
L'ensemble de conditions peut être trouvé vrai un grand nombre de fois dans un intervalle de temps. Une option intéressante peut être de déclencher la notication si dans un intervalle de temps precisé par l'utilisateur, l'ensemble de conditions est jugé comme vrai plusieurs fois. Donc par exemple, si dans les 5 dernierès minutes, l'en- semble de conditions est validé 10 fois, l'utilisateur peut decider d'envoyer une seule notication, et pas 10 notications diérentes. On voit cette fonctionalité comme op- tion pour le déclenchement d'une notication. Cette solution est implementée dans JBoss ON.
Une autre option qui pourrait être utile est de préciser pour chaque condition, un intervalle de temps dans lequelle elle est évaluée comme vraie pour être considerée vraie dans l'ensemble de conditions. Par exemple, pour un pic de CPU jusqu'à 100%, si le pourcentage reste le même pour 5 minutes, ça peut devenir la source d'une notication mais si le taux d'utilisation du processeur revient dans les limites établies après 10 secondes, l'administrateur peut considérer ce comportement comme normal.
Cahier des charges
2.3. Principaux problèmes rencontrés 15 On peut donner à l'administrateur la possibilité de pouvoir désactiver la noti- cation juste après le moment du déclenchement. Ce comportement est aussi imple- menté dans JBoss ON.
En ce qui concerne le type de notication à envoyer, JBoss ON ore des posibili- tés assez limités (on ne peut envoyer que des mails). Par contre, l'envoi de mail peut se faire par rôle. Dans le système déjà existant, la gestion des rôles n'est pas imple- mentée. Par contre, on proposera une diversité de types de notications à envoyer (fenêtre de type pop-up, mail, insertion dans un chier de jurnalisation). Cela va être réalisé par la généricité de l'objet Notication qui va pouvoir utiliser plusieurs protocoles.
Enn, le système de jurnalisation de l'application peut être completé par une base de données où les notications vont être stockées et sur laquelle on peut eectuer des requêtes par date, par degré de gravité de la notication, etc.
L'administrateur doit pouvoir acquiter les notications et regarder en détail ces notications.
2.3 Principaux problèmes rencontrés
2.3.1 L'interface graphique
Comme JASMINe Monitoring est un outil destiné au milieu industriel, pour l'administration des infrastructures fortement clusterisées, le niveau technique des administrateurs est élevé. Ces utilisateurs ont l'habitude de faire toutes les étapes - maintenance, diagnostique, réparation - de façon manuelle. Notre outil doit trouver un équilibre entre une interface graphique guidée, qui minimise la possibilité d'erreur humaine et le contrôle que ces utilisateurs souhaitent. Si cet equilibre n'est pas réalisé, l'outil risque d'être rejeté par les utilisateurs-cible.
Cahier des charges
Chapitre 3
Fonctionnalités
Sommaire
3.1 Préliminaires . . . 17
3.1.1 Kerneos . . . . 17
3.1.2 Installateur graphique pour JASMINe Monitoring . . . . 19
3.2 Module de gestion d'notications . . . 19
3.2.1 Création d'une notication - Must . . . . 19
3.2.2 Gestion des notications - Must. . . . 20
3.2.3 Rapport - sommaire notications - Must . . . . 20
3.2.4 Stockage des notications - Must . . . . 20
3.2.5 Proposition d'IHM . . . . 20
3.1 Préliminaires
3.1.1 Kerneos
La version courante de JASMINe EoS permet de visualiser des modules Flex, dé- diés à l'administration avancée de serveurs d'applications J2EE. L'idée est de rendre la console indépendante de JASMINe pour permettre le chargement de n'importe quel module Flex, d'où le projet Kerneos (coeur de JASMINe EoS). Voici une liste des objectifs visés :
• Indépendance du c÷ur (ne pas être lié avec JASMINe EoS) ;
• Chargement dynamique des modules Flex ;
• Dénition de la notion de module d'administration ;
• Mise en ÷uvre de l'interaction dynamique de ces modules avec le c÷ur.
Dans la gure 3.1 on peut observer l'évolution du système. Les modules déjà existents sont representés en bleu :
• QuickVisu - un module qui permet la visualisation rapide de l'état du système sur un graph ;
• MBeanCmd Manager - un module pour l'ajout des commandes MBeanCmd ;
• ConfEditor - un module pour créer des congurations de monitoring ;
• Monitoring - un module de visualisation plus détaillée du système.
18 Chapitre 3. Fonctionnalités
Fig. 3.1 L'évolutin de JASMINe EoS.
Cahier des charges
3.2. Module de gestion d'notications 19 Ces modules, ainsi que les classes qui construisent le c÷ur, constituent l'application JASMINe EoS. On souhaite la séparation de ces classes dans un nouveau projet, appelé Kerneos. Les modules de JASMINe EoS seront de tel façon indépendants du coeur.
Les modules en orange vont être ajoutés au système. Il s'agit de :
• Rules Manager/Editor - un éditeur de regles Drools pour implementer la fonc- tion d'administration autonome, réalisé par un autre stagiaire ;
• Notication Board - notre outil de géstion de notications.
• Notication Editor - l'outil d'édition de notications.
3.1.2 Installateur graphique pour JASMINe Monitoring
JASMINe Monitoring a des composants obligatoires (l'Event-Switch) et des com- posants qui ne sont pas obligatoires. Ces composants sont chargé par JOnAS à partir d'un plan de déploiement. Un plan de déploiement est un chier XML qui décrit une suite de ressources qui doivent être deploiées dans l'ordre donné. Ces ressources sont de type archive Java EE ou des bundles OSGi. Un premier but de l'installeur est de générer le plan de déploiement pour JASMINe Monitoring en fonction des parties choisies pour l'installation.
Le squelette de JASMINe Monitoring est l'Event Switch dont on a déjà parlé dans la section 2.1.2. L'Event Switch est conguré par un chier XML, appelé eventswitch-config.xml. Pour plus de détails sur l'installation de JOnAS, voir la documentation. Un deuxième but de cet installeur est de générer automatique- ment ce chier, à partir des préférences de l'utilisateur.
L'installateur sera réalisé en utilisantIzPack, un générateur d'installateurs multi- plate-forme de logiciels .
3.2 Module de gestion d'notications
3.2.1 Création d'une notication - Must
Le nouveau module doit permettre la création d'une notication. La première étape est de dénir le nom, le degré de l'notication ou la gravité et une descrip- tion de cette notication. Pour la gravité, l'utilisateur choisira parmi des niveaux predénis (Info, Error, Critical, Fatal etc.). Puis, l'utilisateur choisit l'événement déclencheur de l'notication. Cet événement peut être constitué d'une ou plusieurs conditions d'notication, liées par de operateurs AND ou OR. Ces conditions re- presentent l'ensemble de conditions. Un outil qui permet la navigation parmi les attributs à monitoriser sera utilisé pour ce pas. Dans ce navigateur les attributs seront organisés par thème (des attributs de la JVM, des attributs phyisques, de genre chargement du processeur, etc).
Ainsi, l'utilisateur choisit l'opérateur : l'attribut peut être égal, plus petit, plus grand qu'une mesure. On peut aussi choisir des opérateurs spéciques pour les Cahier des charges
20 Chapitre 3. Fonctionnalités chaînes de caractères. Si l'administrateur a créé plusieurs conditions, il doit pou- voir dénir des rélations entre eux (voir 2.2.3).
Pour chaque notication, il est nécessaire de réagir avec au moins une action, mais l'utilisateur peut en dénir plusieurs. Ces actions seront prédénies aussi :
envoi de mail vers un ou plusieurs boites de mail (Must) ; envoi de SNMP trap (May) ;
envoi de message XMPP (May) ; sortie vers log4j (Must).
Chaque action sera congurable avec des paramètres spéciques. Par exemple, selon le degré de gravité de la notication, dans Notication Board, la notication sera acée avec des couleurs dierentes, congurables.
3.2.2 Gestion des notications - Must
Les notications doivent pouvoir être activées, désactivées ou éditées, en chan- geant l'ensemble de conditions, la gravité, la description et les actions associées. Les paramètres des actions associées doivent pouvoir être aussi modiées. Les notica- tions peuvent être également supprimées ou acquittées par l'administrateur.
3.2.3 Rapport - sommaire notications - Must
L'utilisateur doit pouvoir consulter un rapport des notications déclenchées. Ce rapport se présente sous la forme d'un tableau avec le nom de l'notication, la date et l'heure du déclenchement. Un cliquant sur l'notication, l'utilisateur peut voir les détails de la notication, la règle accomplie qui a déclenché la notication.
3.2.4 Stockage des notications - Must
Les notications seront archivées dans une base de données qui pourra être in- terrogée ultérieurement. A tout moment, l'administrateur doit pouvoir retrouver les notications qu'il a déni, même si elle ne se sont pas déclenchées et aussi les notications déclenchées, avec leurs détails.
3.2.5 Proposition d'IHM
Toutes les aspects IHM peuvent être amenés à être fortement modiés.
Remarque
L'interface aura trois parties distinctes :
une partie Gestionnaire de Règles (Rules Manager/Editor ou Autonomous) ; une partie Éditeur de Notications (Notication Editor) ;
une partie de visualisation des notications déclenchées (Notication Board).
Cahier des charges
3.2. Module de gestion d'notications 21 Comme on peut voir dans la gure 3.2, dans la partie de gauche, on a une vue générale avec les notications activées et les notications desactivées. Si on clique sur une notication de gauche, on peut l'éditer et changer ses propriétés. Dans la partie centrale, on peut créer des notications, établir leurs ensembles de conditions et les actions correspondantes. Si on prend l'exemple d'un ensemble de conditions plus compliqué :
when (Condition_1) AND (Condition_2 OR Condition_3) then Trigger_Alert où
Condition_1 : Physical:CPU.charge > 90%
Condition_2 : Physical:Memory.used > 256 Mo Condition_3 : Physical:HDSpace.free < 30 Mo
, l'utilisateur doit dénir un bloc pour les deux conditions entre les parenthèses, liées par OR. Ainsi, dans la partie WHEN on aura :
when Simple_condition AND Condition_block then Trigger_Alert avec
Simple_condition = Condition_1
Condition_block = Condition_2 OR Condition_3.
Cahier des charges
22 Chapitre 3. Fonctionnalités
Fig. 3.2 Proposition d'interface pour le module de gestion d'notications.
Cahier des charges
Chapitre 4
Exigences non-fonctionnelles
Sommaire
4.1 Qualité du logiciel . . . 23
4.1.1 Maintenabilité . . . . 23
4.1.2 Utilisabilité . . . . 23
4.2 La gestion des risques . . . 24
4.2.1 Risque au niveau de l'IHM . . . . 24
4.1 Qualité du logiciel
Le logiciel à réaliser devra être de bonne qualité. Trois facteurs de qualité sont de ce fait imposés. Ceux-ci sont énoncés par ordre de priorité décroissante. Les critères pour chaque facteur de qualité, ainsi que la modalité de mesure de ces critères seront présentés dans le Plan de qualité du logiciel.
4.1.1 Maintenabilité
Le premier facteur souhaité est la maintenabilité. Son importance est maximum car l'application à développer est open-source et les contributeurs doivent pouvoir comprendre et étendre le logiciel. La maintenabilité doit donc être facilité pour l'équipe qui viendra compléter le travail.
4.1.2 Utilisabilité
Comme il s'agit d'une application web, qui exige une grande interaction avec l'utilisateur, ce facteur est très important. Un administrateur de clusters doit pou- voir apprendre facilement comment dénir des nouvelles notications, comment les gérer et comment lire le données de sortie de l'application. L'interface doit être appropriée au niveau technique des utilisateurs pour leur orir les fonctionnalitées qu'ils souhaitent (voir section2.3.1). Les critères de ces facteurs seront mésurés par un questionnaire sur un échantillon d'utilisateurs. Le contenu de ce questionnaire ainsi que l'échelle par laquelle l'application sera jugée, seront présentés dans le Plan de qualité du logiciel.
24 Chapitre 4. Exigences non-fonctionnelles
4.2 La gestion des risques
4.2.1 Risque au niveau de l'IHM
Un risque qui pourrait apparaître dans le processus de développement est au niveau de l'interface web. En eet, une mauvaise choix de l'interface peut amener à la réalisation d'une interface qui ne satisfait pas les attentes des utilisateurs naux.
Ce risque sera géré par la réalisation d'une maquette de l'IHM, qui sera revalidé après avoir subit les modications exigées par les utilisateurs.
Cahier des charges
Chapitre 5
Contraintes de développement
Sommaire
5.1 Contraintes au niveau du temps . . . 25 5.2 Contraintes au niveau de l'équipe. . . 25 5.3 Contraintes au niveau des technologies . . . 25
5.1 Contraintes au niveau du temps
Le projet durera 8 mois et 2 semaines. Il sera composé de deux périodes : une période à temps partiel (3 mois et 2 semaines) : les mercredis et jeudis du
7 janvier au 10 avril 2009 ;
une période à plein temps (4 mois et 2 semaines) : du 13 avril au 30 août 2009.
5.2 Contraintes au niveau de l'équipe
L'équipe de développement sera composée de trois personnes. On bénéciera aussi de l'assistance et l'aide de l'équipe JOnAS.
5.3 Contraintes au niveau des technologies
Les technologies qui seront utilisées sont déjà xées. Le logiciel sera écrit en langage Java à l'aide de JDK 1.5. L'interface graphique sera réalisée en Flex. L'IDE utilisé est Eclipse v. 3.4. Pour la gestion du projet, on utilisera Apache Maven 2.1, qui facilite la modularité et la gestion des dépendances. La documentation (le manuel utilisateur et développeur) sera livrée au format DocBook ainsi que sous forme de JavaDoc pour les développeurs.
