«Centreon Status Map» Conception et développement d une application j2se

Transcription

1 RAPPORT DE STAGE : Conception et développement d une application j2se Du Mardi 1 mai au Mercredi 31 octobre Jean- Lamotte lamott_j Effectué à : 12 avenue Raspail Gentilly France

2 Remerciements : Je remercie toute l équipe et ses responsables qui m ont permis d effectuer ce stage dans de bonnes conditions : - Romain Lemerlus, mon tuteur de stage, directeur des projets, et cofondateur de Merethis - Julien Mathis, directeur technique, et cofondateur de Merethis - Cedric Facon, architecte web et formateur, - Mathavarajan Sugumaran, formateur, - William Lienard, développeur, - Sylvestre Ho-Tam-Chay, web designer, - Thierry Bernardini, administrateur. de 3 e année. Page 2 sur 54

3 Table des matières Remerciements : Résumé Présentation de l entreprise Secteur d activité L entreprise Les services Formation Support Edition Le positionnement du stage dans l entreprise Travail effectué Cahier des charges But général Explication détaillée des résultats à obtenir Compte rendu d activité Axe d étude et de recherche choisis Déroulement concrets des études Interprétation et critique des résultats Conclusion générale Bibliographie & webographie Bibliographie Webographie Glossaire...52 de 3 e année. Page 3 sur 54

4 1. Résumé Le stage de 6 mois a été effectué chez Merethis, société créée en 2005 par d anciens élèves d Epitech, spécialisée dans la supervision réseau open source. La supervision réseau est un domaine en pleine expansion. En effet, toutes les entreprises ont aujourd hui un besoin croissant en informatique, et le nombre d équipements ne cesse d augmenter. De même, les réseaux transmettent de plus en plus d informations. Cela permet à l informatique d occuper une place décisive dans les entreprises. Toutefois, cela rend les infrastructures plus sensibles. La supervision réseau permet de surveiller le bon fonctionnement de ces ressources et ainsi de prévenir d éventuelles pannes, ou de les détecter dans les plus brefs délais, avant qu elles n aient des répercutions plus importantes. Merethis a initialement créé Oreon, une solution de monitoring complète et open source. Ce logiciel open source tire sa force d une grande communauté d utilisateurs des logiciels, mais créé aussi une faiblesse pour l entreprise qui ne génère des bénéfices que par son support. Le but du stage était de reprendre le développement d une application de cartographie avancée, visant à rendre la supervision accessible à un néophyte une fois le parc informatique correctement configuré dans Centreon, et optimiser le temps d accès à l information via une application centralisant tout ce qui concerne le monitoring et laissant de coté la configuration à Centreon. Cette application se nomme Centreon Status Map. Cette première application possédait malheureusement de nombreux défauts et n était pas commercialisable en l état. De nombreuses phases d études, de tests, et de tâtonnements permirent d aboutir à une version finale de Centreon Status Map 2. Il y eu 4 phases directives qui composèrent ce stage. de 3 e année. Page 4 sur 54

5 Apres une première phase d étude de Centreon Status Map 1.x, il était évident que toute la conception était à revoir. L application fut recommencée. Le but était de reproduire toutes les fonctionnalités présentes, de les améliorer, et d en créer de nouvelles, sans les problèmes de performances, et bug de cette première version. La seconde phase fut d étudier le framework eclipse RCP, et de démarrer le développement de Centreon Status Map 2.x. La richesse de ce framework n est pas encore épuisée, mais tout au long du stage, mes connaissances se sont améliorées. La troisième phase d étude fut consacrée à l exploration des technologies XML avec JAVA. Je conçus plusieurs modèles de flux XML permettant de transférer l information entre le serveur de supervision utilisant Centreon, et l application Centreon Status Map. La dernière phase fut d implémenter un éditeur graphique reposant sur le framework GEF. Ce framework aux multiples possibilités est malheureusement très mal documenté. Son étude demanda beaucoup d assiduité afin d aboutir à un résultat exploitable. Après de nombreuses phases de test, la version de Centreon Status Map était enfin disponible. Cette version fut testée par plusieurs grands groupes (souhaitant garder l anonymat), utilisant Centreon comme base de monitoring. Il y eu des retours, sur des améliorations fonctionnelles. Chacune des demandes de ces entreprises fut satisfaite, afin d aboutir aujourd hui à Centreon Status Map Un produit leur apportant pleine satisfaction. L entreprise Merethis m a proposé un contrat en alternance après le stage, et m a placé à la tète ce projet. Il comptera très bientôt de nouveaux développeurs afin d accélérer son évolution. Le développement de Centreon Status Map a encore un bel avenir devant lui, afin de répondre à tous les nouveaux besoins des entreprises. de 3 e année. Page 5 sur 54

6 2. Présentation de l entreprise Origine : Le stage a été effectué durant 6 mois à la société Merethis Secteur d activité Les entreprises et organisation ont aujourd hui de plus en plus d équipement informatique et électronique, et leurs surveillances (état de fonctionnement, qualité de fonctionnement etc..) ne peuvent être effectuées manuellement tant leur nombre est élevé. C est pourquoi il existe des solutions de monitoring réseau. Merethis se place au cœur de ces systèmes de surveillance, en proposant de nombreux outils, afin de surveiller efficacement l ensemble de ces équipements L entreprise Merethis a été créé en 2005, à la suite d un projet de fin d étude effectué par 5 étudiants de l Epitech. Le projet initial consistait à créer une surcouche au célèbre ordonnanceur Nagios afin de simplifier sa configuration. Ce projet s appelle Oreon, puis deviendra Centreon en Ce projet est open source, et dispose d une forte communauté. Seul 2 anciens étudiants ont souhaité continuer le projet, et créer la société Merethis : Romain Lemerlus Julien Mathis Aujourd hui, Merethis développe toujours Centreon, pour la communauté open-source, mais propose également des applications payantes, complémentaires à Centreon, pour les entreprises nécessitant des résultats plus poussé de leur monitoring. Cartographie avancé (Centreon Status Map) Qualité de service (Meta service) de 3 e année. Page 6 sur 54

7 Merethis propose également des solutions complètes préinstallées, pour surveiller tout un parc informatique, avec sa «Meribox». Enfin, Merethis propose un support et des formations à Centreon, afin d aider les entreprises à utiliser Centreon plus efficacement Les services Formation Merethis propose toute une gamme de formations dédiées à la supervision réseau Open Source. Il existe actuellement 4 types de formation : Exploitation Centreon Nagios 2 jours Bases de la supervision 3 jours Supervision avancée 3 jours Expert Centreon Nagios 5 jours Support Merethis propose un support afin de résoudre des problèmes d utilisation et/ou bug d Oreon. Problème Mineur Majeur Bloquant Délai d'acquittement - contournement 8 heures 4 heures 2 heures Solution corrective 5 jours 48 heures 24 heures Crédits 6 crédits 10 crédits 16 crédits Ce support fonctionne par un système de crédits qui s achètent au forfait, par lot de 50, 100, 200, 400, Edition Merethis a depuis peu, un service d édition, s occupant de créer des logiciels et complément à Centreon, répondant aux besoins des entreprises. de 3 e année. Page 7 sur 54

8 Cartographie avancée (Centreon Status Map) Centreon Status Map, aussi appelé OSM dans le jargon de Merethis, est une application Java permettant de surveiller efficacement l état d un ensemble d équipements que ce soit à l échelle locale ou mondiale, via un système d arborescence. Les différents types d éléments (host, hostgroup, service, servicegroup, metaservice, osl) possèdent des formes simples rendant leurs identifications faciles, et un système de coloration selon leurs états. On peut y ajouter facilement des éléments graphiques, pour rendre la visualisation plus explicite, tels que des cartes, des plans etc Qualité de service (Meta Service) La mesure de la qualité de service n'est pas une fonctionnalité native de Nagios ; agréger au sein de l'outil les états des éléments supervisés n'existe pas. L'outil Centreon propose une solution pour exploiter les données de performance entre elles avec le plugin des Meta Services, il propose également de suivre dans le temps l'évolution des métriques, mais pas d'informations sur des états agrégés Le positionnement du stage dans l entreprise Merethis avait jusque là une faible activité dans le domaine de l édition. Le développement d applicatifs permet à Merethis de diversifier ses offres, en proposant autre chose que du service. Le stage s inscrit donc au cœur de l activité Merethis, permettant de répondre à ce manque dans l édition, par le développement de Centreon Status Map. de 3 e année. Page 8 sur 54

9 3. Travail effectué Origine : 3.1. Cahier des charges But général Le cahier des charges détaillé n existait pas au départ, et s est construit au fur et à mesure de l avancement de la mission. La mission comportait 2 objectifs : Analyser une application dont Merethis est propriétaire : Oreon Status Map 1.x (OSM 1.x) Reprendre le développement d OSM 1.x afin d optimiser les performances, et y ajouter de nouvelles fonctionnalités. Le second objectif deviendra après l analyse : Développer OSM 2.x from scratch (à partir de rien), afin d avoir un cœur d applications plus performant que la précédente mouture. Note : Oreon Status Map 2.x deviendra Centreon Status Map 2.x (que l on surnomme toujours OSM 2.x) de 3 e année. Page 9 sur 54

10 Explication détaillée des résultats à obtenir Analyser l existant Ce premier objectif consistait à prendre connaissance de l application OSM 1.x. OSM 1.x souffrait de problèmes de performance, et d un manque de certaines fonctionnalités : Très grande lenteur lorsque beaucoup d éléments étaient présents «Freeze» de l application lors des rafraîchissements de statuts et des téléchargements d images Stockage des informations sur la structuration de la cartographie en local (via un import / export) Problème de synchronisation des données (un élément supprimé dans Oreon toujours présent dans Oreon Status Map) Problème de duplication de données Nombreux petits bugs non bloquants Apres cette première analyse, il était évident que ces problèmes étaient liés à la conception même d OSM 1.x. Il fallait reprendre le développement depuis le début Développement de l application Centreon Status Map 2.x Apres cette première analyse, ce second objectif visait à corriger les différents problèmes d OSM 1.x, et d y ajouter de nouvelles fonctionnalités : Développer une application multithreadé où tous les traitements sont effectués en tâche de fond Stocker les informations du côté serveur afin d avoir l information toujours disponible où que l on se trouve. Etablir un protocole de communication pour l échange de données client / serveur, en utilisant un flux XML pour le transfert de données. de 3 e année. Page 10 sur 54

11 Retrouver toutes les fonctionnalités présentes dans la version précédente d OSM. Ajouter de nouvelles fonctionnalités. de 3 e année. Page 11 sur 54

12 3.2. Compte rendu d activité Tout d abord, quelques chiffres : Centreon Status Map 2.x, c est 49 packages, 261 classes, 1628 méthodes, et lignes de code, par conséquent, seul un regard conceptuel sera porté sur le projet Axe d étude et de recherche choisis Il y eu plusieurs phase d étude, et d expérimentation avant d aboutir à un produit final, vendable. Toutes ces phases d étude furent effectuées plus ou moins en même temps, chacune se complétant et s enrichissant mutuellement Etude d Oreon Status Map 1.x L étude de cette application fut brève. Un peu de manipulation du programme, afin de voir ce qu il permet de faire, de trouver ses limitations, et ses bugs. Cette étude va mener à la décision de reprendre le développement de Centreon Status Map au point de départ. Je suis revenu plusieurs fois dessus, afin de garder le même esprit de fonctionnement de l application Etude du Framework Eclipse RCP L étude de ce framework se fera après l étude d Oreon Status Map 1.x, et durant toute la durée du stage. Le Framework Eclipse RCP est un puissant Framework, simplifiant la tâche de création d application de type client lourd, ou client riche. Il dispose de nombreuses librairies permettant d implémenter rapidement des boites de dialogue, des menus, etc. C est cette richesse qui va permettre de découvrir de jour en jour de nouveaux concepts, devenant par la suite indispensable. de 3 e année. Page 12 sur 54

13 Eclipse, basé sur le Framework Eclipse RCP Etude du Framework JDom Quelques temps après la découverte du framework Eclipse RCP, il fallut se pencher sur le problème d un bon framework permettant de manipuler du XML. C est le framework JDom qui sera élu après la lecture de documentation sur divers forums, pour ses performances, et son api performante. de 3 e année. Page 13 sur 54

14 Etude du Framework GEF Enfin, la dernière phase d étude se fit quelques mois après la création de la majeure partie de l application. Il ne manquait que l éditeur, contenant des éléments graphiques. Ce Framework graphique de type MVC (modèle-vue-contrôleur) correspondait parfaitement au besoin graphique de l application. De plus, celui-ci a fait ses preuves dans de nombreuses applications, aussi bien chez IBM que de petites entreprises. de 3 e année. Page 14 sur 54

15 Déroulement concrets des études Etude et test d Oreon Status Map 1.x Au départ, le développement d Oreon Status Map 1.x devait être repris. Une phase de test s imposa, afin de déterminer les problèmes de performance, limitation, problème d évolutivité, et enfin les bugs Test de performance Divers tests de montée en charge permirent de mettre à jour de graves problèmes de performances. En voici des exemples : Test de montée en charge Le premier test effectué, fut d ajouter de très nombreux «host» dans Oreon, afin de voir comment réagissait l application : Lancement de l application Identification Téléchargement des ressources Blocage de l application le temps du téléchargement des ressources Plantage si interaction de la part de l utilisateur Conclusion : un thread effectuant cette tâche en arrière plan pourrait corriger le problème. de 3 e année. Page 15 sur 54

16 Test de téléchargement d images volumineuses Le second test, fut d ajouter des cartes de grande taille, demandant plus de temps à télécharger : Lancement de l application Identification Téléchargement des images Blocage de l application le temps du téléchargement des ressources Plantage si interaction de la part de l utilisateur Conclusion : un thread effectuant cette tache en arrière plan pourrait corriger le problème. Test d ajout de nombreux éléments sur la carte Le troisième test fut d ajouter de très nombreux éléments sur la carte, tout en gardant un très petit nombre de ressources : Lancement de l application Identification Téléchargement des images Blocage de l application le temps du téléchargement des ressources Plantage si interaction de la part de l utilisateur Conclusion : un thread effectuant cette tâche en arrière plan pourrait corriger ce problème. Tous les tests mirent en évidence la nécessité d avoir une application multithreadé afin d effectuer les traitements en tâche de fond, sans que l application ne bloque, ou plante à la moindre action de l utilisateur. de 3 e année. Page 16 sur 54

17 Limitation Gestion des «vues» OSM 1.x avait une gestion des vues relativement basique. Chaque vue était importée et exportée dans un fichier XML, qui pouvait ne plus correspondre du tout à ce qu il y a dans Oreon, après de nombreuses modifications, non répercutées sur ces fichiers XML. Impossibilité d ajouter plusieurs images à un éditeur Chaque éditeur était limité à une seule image, affichée en arrière plan, impossible à déplacer. Remontée des statuts La remontée des statuts était imprécise, «confondant» aussi bien un statut «WARNING» qu un statut «CRITICAL». Mémorisation d un seul utilisateur et/ou proxy L interface d accueil ne permettait de mémoriser que les paramètres de connexion du dernier utilisateur. Le même problème se posait pour la gestion du proxy. La nature même de l implémentation d OSM 1.x rendait difficile l évolution de ces limitations Bug Gestion des «vues» La gestion des vues posait un double problème, à la fois d évolutivité, mais aussi génératrice de bug. En effet, la moindre suppression d un élément dans Oreon rendait inexploitable OSM 1.x, celui-ci «cherchant» des éléments qu il ne trouvait pas, lors de la mise à jour des statuts, provocant une erreur qui ne permettait pas de finir cette mise à jour de statuts. Montée en charge OSM 1.x finissait systématiquement par planter, lorsqu il y avait trop de ressources, d éléments, ou de cartes volumineuses. de 3 e année. Page 17 sur 54

18 Drag-n-Drop Le drag-n-drop des ressources dans l éditeur se retrouvaient au mauvais endroit lorsque le zoom était activé. XML non valide Les flux XML utilisés pour le transfert de ressource, et le stockage de la vue courante n étaient pas normalisés, provocant des erreurs aléatoires, dans certains cas particuliers. La correction de tous ces bugs aurait demandé beaucoup de temps à être localisés précisément dans le code, puis corrigés. de 3 e année. Page 18 sur 54

19 Bilan sur Oreon Status Map 1.x OSM 1.x souffrait de nombreux défauts, tant sur le plan de la conception que sur le plan de l implémentation : Le pire défaut était bien évidemment le fait que l application soit mono threadée, provocant des blocages et plantages lorsqu on montait légèrement en charge. C est après cette analyse, que je pris la décision de baser Oreon Status Map 2.x sur une nouvelle base. Le choix des Framework suivant est conservé : Eclipse RCP GEF Le Framework permettant de gérer le XML est en revanche remplacé par JDom. de 3 e année. Page 19 sur 54

20 Etude du Framework Eclipse RCP Le Framework eclipse rcp est une puissante collection d objets, permettant de créer rapidement une application java. C est un peu la réponse de java, aux solutions que propose Microsoft dans son IDE visual studio. C est à partir du célèbre IDE Eclipse, que le Framework Eclipse RCP a été créé Le choix d Eclipse RCP Ce choix s est imposé de lui-même. Il avait permis de créer la version précédente d Oreon Status Map Une première application Eclipse RCP Apres avoir étudié en profondeur les défauts d OSM 1.x, il était temps de se lancer dans le développement d OSM 2.x, en tenant compte des problèmes de la précédente version. Une simple application «hello world» fut alors créée : C est sur cette petite application que reposera par la suite tout OSM 2.x de 3 e année. Page 20 sur 54

21 L étude des perspectives d eclipse RCP. Eclipse RCP propose une notion appelée perspective. Il s agit d une représentation des éléments que l ont peut voir à l écran. Les perspectives sont des conteneurs de vue et d éditeur. Ils permettent de positionner où bon lui semble, au développeur, les différents éléments visibles dans la perspective. Le but originel des perspectives est de permettre à l utilisateur de switcher de l une à l autre, en gardant les mêmes fenêtres ouvertes, mais placé à des endroits radicalement différents. C est l utilisation de ces perspectives qui va permettre de créer les différents morceaux de l application : La perspective d accueil, La perspective de sélection des vues, La perspective de monitoring L étude des éditeurs et vues d Eclipse RCP Afin de peupler les perspectives, il existe 2 types de «fenêtre» : Les éditeurs, Les vues. Les éditeurs sont des fenêtres plutôt destinées à l édition, c'est-à-dire à contenir des éléments destinés à être déplacés, modifiés et c Les vues quant à elles servent plutôt à afficher des éléments. Il est évidemment possible comme pour les éditeurs d y mettre des éléments modifiables, mais ce n est pas le but premier. de 3 e année. Page 21 sur 54

22 La première perspective, et sa première vue Après avoir compris ces notions clé de perspective, éditeur et vue, il était temps de créer une première perspective, peuplée par une vue. Cela se déroula sans encombre grâce à l api bien documenté d Eclipse RCP, et quelques jours de test. L application ressemblait désormais à ceci : L application finale, sur la perspective d accueil, avec la vue Centreon Status Map. Il n y avait pas encore de menu ni de barre d outils, mais il n était pas encore temps de se pencher sur ce problème. de 3 e année. Page 22 sur 54

23 Etude du Framework JDom Le choix de JDom Le Framework JDom est un ensemble de classes permettant de manipuler des données de type XML. Ses avantages sont les suivants : Plus simple à utiliser que les API Sun grâce à une abstraction de plus haut niveau Respecte les spécifications DOM du W3C, rendant son utilisation facile à tout développeur objet ayant déjà utilisé une api respectant ces spécifications dans un autre langage. Ce sont principalement ces 2 caractéristiques qui ont motivé le choix de ce Framework plutôt qu un autre Une première implémentation de JDom local. La première utilisation de JDom fut pour le stockage des profils de connexion en L objectif était simple, avoir un conteneur (XML) ordonné, et extensible à volonté. Ce modèle sera par la suite étendu afin d enregistrer les proxys. Grâce à ce modèle, la fenêtre de dialogue de connexion allait pouvoir être créée. de 3 e année. Page 23 sur 54

24 La fenêtre de dialogue de connexion Implémentation du menu de connexion La fenêtre dialogue de connexion corrige les erreurs de la précédente version. Celleci permet d enregistrer des profils de serveur et/ou d utilisateur. La boite de dialogue de connexion finale Chacune des informations visibles dans la boite de dialogue est enregistrée dans le fichier XML créé précédemment. Différentes fonctionnalités y seront ajoutées au cour du projet : - Le mode administrateur, - Le proxy, - Le Timer de 3 e année. Page 24 sur 54

25 Création d une méthodologie pour la transmission de données Afin de pallier aux problèmes de la précédente version, qui enregistrait ses informations dans un fichier XML stocké en local, il fallut réfléchir à comment échanger les données avec le serveur, afin que celles-ci soient gardées sur celui-ci Choix du protocole Le choix du protocole http, avec l envoi de xml fut rapide pour plusieurs raisons : Centreon a besoin d un serveur Apache (serveur http) pour fonctionner. Le xml transite facilement par le protocole http Le xml est un excellent conteneur de données ordonnées Normalisation des échanges via XML Afin de créer un parseur générique, il fallait définir un certain nombre de balises communes à tous les flux XML. Des modifications seront apportées tout au long du projet à ces balises, afin de répondre aux besoins croissants d informations de l application. Les spécifications finales seront les suivantes : Balise <data> encapsulant tout flux Balise <DESCRIPTIVE>, qui décrit le type de flux envoyé o Host, Hostgroup, ServiceGroup, MetaService, OSL, Image pour les listes des ressources o all, add, rem, mod, pour l arborescence et les modifications liées à cette arborescence. Balise <ctn>, qui décrit l élément ainsi que tous ses attributs. Chaque balise <ctn> peut avoir une infinité d enfants, aussi bien pour les ressources que pour l arborescence. de 3 e année. Page 25 sur 54

26 Récupération des ressources Flux XML Centreon Status Map est composé des mêmes éléments que ceux contenus dans Centreon. (Host, hostgroup, service, servicegroup, metaservice, osl). Pour chacune de ces ressources, il fallut donc créer 5 modèles XML, permettant d envoyer ces informations, basés sur les spécifications précédentes. Chacune des ressources possède une balise «ctn», composée de plusieurs attributs : - Nom, - alias, - adresse IP, - ID, - type d éléments Ces ressources ont également des enfants, qui sont encapsulé dans la première balise «ctn». Seuls les enfants du niveau immédiatement en dessous sont renvoyés. La requête permettant d obtenir les hosts retourne donc une liste d host, et ses services enfants. Il en va de même pour les autres éléments : Liste d hostgroup et leurs host enfants Liste de servicegroup et leurs services enfants Liste de metaservice, sans les enfants (qui ne doivent pas être affiché dans OSM) Liste d osl, sans les enfants (qui ne doivent pas être affiché dans OSM) Il n existe pas de requête permettant de récupérer la liste des services, ceux-ci étant envoyés via la requête de récupération des hosts. de 3 e année. Page 26 sur 54

27 Méthode de récupération des flux XML Afin d envoyer ces flux XML, un fichier PHP fut mis en place du côté du serveur par Romain Lemerlus en respectant les spécifications que j avais établies. Une requête web simple de type GET est effectuée, prenant en paramètre une clé indiquant le type de ressources à récupérer. Exemple : getosmresources.php?key=200 permet de récupérer la liste d host et leurs services enfants Récupération des éléments d une vue Flux XML Comme pour la récupération des ressources il fallait créer un modèle de flux XML. Cette fois ci, tous les enfants devaient être renvoyés quel que soit l élément, afin de construire une arborescence dans OSM 2.x. On passe simplement une clé en paramètre, et un argument correspondant à l id de l élément à récupérer. de 3 e année. Page 27 sur 54

28 Exemple : y=100&args[0]=152 Le flux xml renvoyé est parfaitement structuré. Chaque niveau d indentation montre un niveau dans l arbre qui sera créé dans la perspective de monitoring. de 3 e année. Page 28 sur 54

29 Création de la perspective de sélection des vues Objectif de cette perspective Cette perspective permet de sélectionner la vue que l on souhaite afficher, dans la perspective de monitoring. Aucune fonctionnalité similaire n était présente dans la version précédente. Cette perspective a plusieurs avantages : Possibilité de changer radicalement d environnement de monitoring en quelques clics. Possibilité pour un «super» administrateur, de visualiser l ensemble des vues, disponible aux différents sous-administrateurs surveillant leurs domaines spécifiques (base de données, réseau, etc.) Corrige le défaut de la version précédente, qui obligeait à charger / décharger manuellement un fichier XML, pour changer de vue Composition Vue Cette perspective est composée d une unique vue (RCP), contenant une liste de vues (de monitoring). Un double click permet d ouvrir la perspective de monitoring, basé sur cette vue. La vue (RCP) de sélection des vues (de monitoring) de l application finale. de 3 e année. Page 29 sur 54

30 Note : les vues du Framework eclipse rcp ne sont pas à confondre avec le nom choisi pour les vues (de monitoring). Cette vue récupère son contenu via le flux XML établi précédemment. Afin de ne pas ralentir l exécution de l affichage, un thread est utilisé pour le chargement du flux XML, palliant au problème d OSM 1.x qui ralentissait ou bloquait, lorsqu il y avait trop d informations à récupérer Menu Différents menus sont également ajoutés à cette perspective afin d effectuer les actions courantes de l application. Menu de l application finale. La fonctionnalité permettant de rafraîchir les informations est utilisée dans le cas où 2 administrateurs ou plus effectuent des créations de vue Barre d outils Afin de satisfaire les utilisateurs les plus pressés, une barre d outils contenant les actions les plus courantes est ajoutée. Barre d outils de l application finale. de 3 e année. Page 30 sur 54

31 La fenêtre de création des vues La fenêtre de création des vues va à l essentiel. Elle permet de créer 3 types de vue. A l heure actuelle, il n existe que la perspective géographique, c est pourquoi les vues métier et network sont désactivées (grisé). Celles-ci seront implémentées dans les mois à venir, après le stage. Cette fenêtre subira également un «relooking». La fenêtre de création de vue finale. de 3 e année. Page 31 sur 54

32 Création de la perspective de monitoring (géographique) Objectif de cette perspective La perspective de monitoring est la plus importante. C est dans celle-ci que l on pourra observer les états des différents équipements supervisés Composition La perspective de monitoring finale, et ses vues. de 3 e année. Page 32 sur 54

33 Cette dernière contient tous les éléments nécessaires au monitoring : Un arbre (en haut à gauche) pour se déplacer dans les éléments Une minimap (au milieu à gauche) pour se repérer lorsque les cartes sont trop grandes Plusieurs vues contenant les ressources à dropper dans l éditeur (en bas à gauche) Une vue synthétique (en haut à droite) Une vue avec les graphes (historiques) de l état de fonctionnement des éléments supervisés (à droite) Un éditeur qui contient les images, et les différentes ressources surveillées (également présentes dans l arbre). Cette perspective représente la phase la plus difficile du stage, mais également la plus intéressante. de 3 e année. Page 33 sur 54

34 Les vues de ressources Ces vues sont au nombre de 6. Ce sont elles qui contiennent tous les éléments présents dans Oreon, que l on peut drag-n-dropper dans l éditeur et l arbre. Les vues de ressources finales. Cette vue récupère son contenu via le flux XML établie précédemment. Au départ, ces vues n affichent que la liste brut de chaque catégorie d éléments. Par la suite, elle fut modifiée, afin d afficher leurs enfants respectifs, et le flux XML modifié en conséquence, afin de renvoyer ces informations complémentaires. Le flux XML est récupéré via un thread, en arrière plan, afin de ne pas ralentir l exécution de l application et provoquer des blocages. de 3 e année. Page 34 sur 54

35 La vue arborescente Cette vue permet de visualiser rapidement la liste de toutes les ressources monitorées. Elle permettra de se repérer dans l éditeur, et via un menu contextuel, lancer différentes actions. La vue arborescente finale. Cette vue, comme les précédentes, récupère ses informations via un flux XML, en arrière plan, grâce à un thread. Une erreur sera commise lors de sa création : elle est créée en implémentant un arbre reposant sur JFace, une surcouche de SWT, l environnement graphique du framework Eclipse RCP. L éditeur à ce moment-là n existe pas encore, mais celui-ci repose sur le framework GEF, il fut alors nécessaire de refaire cet arbre, en se reposant également sur le même framework, afin de synchroniser la sélection dans l éditeur, et l arbre. (Le menu se déroule alors tout seul, en se déplaçant dans l éditeur). Cette erreur fit perdre 1 semaine de développement. de 3 e année. Page 35 sur 54

36 La vue tableau synthétique L éditeur graphique est la fonctionnalité la plus intéressante pour visualiser où se trouvent les éléments défaillants, mais certaines sociétés possèdent des parcs informatiques énormes, et il peut parfois être difficile de trouver rapidement tous les éléments défectueux. Il fallait donc pallier à ce manque, en créant une vue synthétique. Cette vue contient les mêmes informations que celles contenues dans l éditeur, mais organisées en colonne. On peut trier les éléments par nom, alias, type d élément, statut, et statut des enfants. Le principal intérêt étant de pouvoir trouver immédiatement les éléments ayant un statut critique, grâce au tri par statut. La vue tableau synthétique finale. Par la suite, une petite fonctionnalité fut ajoutée, afin de simplifier la navigation : un cadenas, permettant de verrouiller ou déverrouiller la vue. Lorsque la vue est déverrouillée, le simple click sur un élément dans l arbre ou l éditeur permet de changer le contenu de cette vue, en affichant instantanément les enfants de l élément sélectionné. de 3 e année. Page 36 sur 54

37 La vue des graphes Il existe dans Centreon, une page permettant d afficher des graphes sur l état de fonctionnement dans le temps d un service. L intégrer à Centreon Status Map semblait une excellente idée, et très «simple» à mettre en œuvre. Il suffisait simplement d appeler un navigateur web embarqué dans l application, et d appeler l adresse permettant d afficher le graphe correspondant. La vue des graphes finale Comme pour la vue synthétique, une fonctionnalité permettant de verrouiller et déverrouiller la vue fut implémentée. de 3 e année. Page 37 sur 54

38 Les menus Le menu général permettant d effectuer la navigation standard fut ajouté, comme pour la perspective de sélection des vues. Un menu option, contenant une action permettant de forcer le rafraîchissement manuel des statuts, fut également ajouté. Enfin, une action permettant de rafraîchir tous les éléments en rechargeant toute la liste fut ajoutée, afin de permettre à 2 administrateurs d effectuer simultanément des modifications sur la même vue, sans devoir relancer l application. Les différents menus de la perspective de monitoring. Un menu contextuel fut également créé, réagissant au click droit sur un élément, que ce soit dans l éditeur ou l arbre. Le menu contextuel d un host, dans l application finale. Ce menu est créé dynamiquement, son contenu variant selon que l action peut être effectuée sur l élément ou non. La détermination de la possibilité d utiliser une action ou non se fait grâce aux editpolicy du framework GEF. Ce menu n est au départ pas dynamique, et affiche toutes les actions pour tous les éléments, même si cela n est pas possible. Le problème était le même que pour la vue arborescente, créé via JFace, et non GEF. de 3 e année. Page 38 sur 54

39 La barre d outils Comme pour la vue de sélection des vues, une barre d outils pour les utilisateurs pressés («power users») est créée. Celle-ci contient les actions les plus couramment utilisées. Des outils supplémentaires sont également disponibles. Ceux-ci n effectuent que des actions qui influent sur l affichage de l éditeur. La barre d outils de la perspective de monitoring. de 3 e année. Page 39 sur 54

40 Etude du Framework GEF Une fois toutes les vues créées, il était temps de passer à l éditeur, qui allait contenir les éléments graphiques, tels que les images, et des icones représentatives de chacun des éléments. Avant d implémenter cet éditeur, il fallait étudier le framework graphique GEF Le choix de GEF GEF avait été utilisé dans la précédente version de Centreon Status Map. Il avait prouvé qu il pouvait produire un visuel agréable. De plus, GEF a été utilisé dans de nombreuses applications commerciales avec succès. Son seul défaut est qu il est très peu documenté, rendant la tâche ardue à quelqu un qui le découvre Fonctionnement de GEF Le Framework GEF est un Framework de type Model-View-Controller (MVC). Celui-ci est complété par le toolkit Draw2d (sorte de mini Framework), dédié aux affichages en 2 dimensions. Le principe objet MVC permet de séparer complètement les données graphiques («vue», des propriétés de ces objets (modèle). Afin de lier les données graphiques aux propriétés, on utilise un contrôleur. de 3 e année. Page 40 sur 54

41 Ce schéma résume brièvement le fonctionnement de GEF. Voici une vulgarisation du fonctionnement : L utilisateur effectue une action, sur la vue (view). Celle-ci est transmise au contrôleur (controller) Le contrôleur créé une requête (requests) La requête (requests) vérifie via les editpolicy si celle-ci est autorisée. Si la requête est autorisée, par les editpolicy, celles-ci créent une commande (commands) qui effectue la modification dans le modèle (model). Le Model transmet alors au contrôleur la modification, qui modifie à son tour la vue (view). C est cette phase d étude qui a demandé le plus de temps avant de produire un visuel lié au modèle (créé via les flux XML précédents). de 3 e année. Page 41 sur 54

42 Etude du toolkit Draw2d Gef utilisant le toolkit Draw2d pour son visuel, il fallut également étudier le fonctionnement de ce dernier. Les «Figures», sont les éléments graphiques de base de draw2d. On peut créer les formes que l on souhaite avec, et pour les formes plus complexes, on utilise un empilement de figures. Draw2d a 2 règles de fonctionnement essentielles : La précédente figure d un même niveau de parenté est cachée par la suivante. Chaque niveau de parenté est caché par la partie visible du niveau enfant. Si un enfant dépasse de la zone de son parent alors la zone en dehors du parent est cachée. de 3 e année. Page 42 sur 54

43 Création de l éditeur Gestion des images L étude du framework GEF allait enfin permettre de construire l éditeur. De nombreux tests furent encore effectués avant d arriver à un éditeur viable. Dans un premier temps, il fallut ajouter la gestion des images, et par la même occasion, régler les problèmes de la précédente version, de blocage de l application lors du chargement, et la possibilité de n afficher qu une seule image par éditeur Chaque image est chargée via un thread dédié, en arrière-plan. Une petite image d un travailleur est affichée durant le chargement des images Gestion des différents éléments Chaque élément droppé dans l éditeur devait être positionné précisément. Deux problèmes se posèrent : Drag-n-Drop avec le zoom activé Drag-n-Drop dans l arbre Pour le premier problème, les coordonnées du drop étaient mauvaises, ne prenant pas en compte la gestion du zoom. Ce problème était déjà existant dans la version précédente. Gef n est pas prévu pour gérer ce type de cas. Il fallut contourner le fonctionnement de GEF, par un calcul à partir des coordonnées de la fenêtre. Pour le second problème, il n existait pas de coordonnée, puisque droppé directement dans l arbre. Cela impliqua la création d un système de placement automatique des icones. de 3 e année. Page 43 sur 54

44 Chaque drop d élément, ou déplacement d élément créé une requête envoyée au serveur, via un flux XML, qui renvoie à son tour un flux XML, pour signaler la modification, qui n est effectuée qu une fois approuvée par le serveur. Cette requête est encore une fois effectuée dans un thread, afin de ne provoquer aucun blocage de l application Pop-Up de légende des icones Une petite fenêtre de légende de la forme des icones a également été ajoutée, accessible via le menu d aide, afin d aider les utilisateurs débutants à connaître la correspondance des icones dans l éditeur. de 3 e année. Page 44 sur 54

45 Zoom Dans le cas où de très grandes cartes étaient utilisées, il pouvait être intéressant de pouvoir dézoomer afin de se déplacer plus facilement dans l éditeur. Cette fonctionnalité fut implémentée Placement automatique Le placement automatique dispose de 2 modes : Un placement automatique de tous les éléments lorsque celui-ci est activé Un placement automatique des éléments n ayant pas de coordonnées, lorsque celuici est désactivé. Le placement automatique d éléments activés, dans l éditeur final. Ce système de placement automatique est utile dans le cas d un hostgroup possédant de très nombreux host, amené à évoluer souvent. de 3 e année. Page 45 sur 54

46 Afficher / masquer le texte Dans le cas où des images en arrière plan avaient du texte, il pouvait être utile de ne pas afficher le texte des icones. Cette fonctionnalité fut également implémentée. Le nom des éléments masqués, dans l éditeur final Enregistrement des propriétés de l éditeur Les propriétés de zoom, d affichage de la police, et de placement automatique n étaient pas enregistrées au départ. Dans le cas de la fermeture de l application, l administrateur perdait tous ses paramètres d éditeur. Une fonctionnalité permettant de les mémoriser à la demande de l utilisateur fut ajoutée. Celle-ci ne fut pas gérée de façon automatique, afin de minimiser les requêtes vers le serveur, et de permettre à l utilisateur de retrouver un environnement par défaut, s il ne souhaitait pas mémoriser sa dernière utilisation. de 3 e année. Page 46 sur 54

47 «MiniMap» La dernière fonctionnalité ajoutée fut la minimap. Cette vue affiche une représentation miniature de l éditeur actif. Elle permet de se déplacer rapidement dans l éditeur, lorsque de grandes images sont utilisées, accélérant l accès à une zone particulière de l éditeur. Un rectangle est affiché dans la minimap, représentant la zone visible de l éditeur. La minimap de l application finale. de 3 e année. Page 47 sur 54