Outils de monitoring conforme ITIL : Application au réseau A.S.T.R.I.D.

Transcription

1 Faculté de Sciences Appliquées Service Ingénierie Informatique et de la Décision (CoDE) Outils de monitoring conforme ITIL : Application au réseau A.S.T.R.I.D. Nicolas Vannieuwerburgh Directeur : Prof. Esteban Zimányi Superviseur : Olivier Firket Mémoire présenté en vue de l obtention du diplôme d ingénieur informaticien Année académique

2 2

3 Remerciements Je tiens à remercier mon promoteur de mémoire, le Professeur Esteban Zimányi, pour ses nombreux conseils et ses relectures attentives. Je tiens également à remercier mon superviseur, M. Olivier Firket, pour son investissement dans ce mémoire, les très nombreuses heures investies dans ce travail ainsi que pour sa bonne humeur et sa motivation tout au long de ce travail et sans qui ce travail ne serait pas ce qu il est. Je remercie également ma famille et mes amis et tout particulièrement Laetitia Van Achte pour ses nombreux encouragements, son écoute attentive et ses nombreuses relectures. 3

4 Résumé La bonne gouvernance d un système informatique passe nécessairement par la surveillance permanente de ses performances. Ce monitoring permet de devenir pro-actif en prévenant les problèmes, au lieu d être réactif en réparant les erreurs du système. Cette problématique de surveillance est d actualité dans de nombreuses entreprises mais encore davantage dans le cadre de machines sur lesquelles peuvent reposer des vies où il serait tout à fait irresponsable d adopter une approche réactive. Ce document traite de telles infrastructures et traitera du cas de la surveillance et de la maintenance préventive sur des machines du réseau A.S.T.R.I.D., chargé des communications d urgence en Belgique. Cependant, l infrastructure globale se base sur une implémentation d ITIL qui devra satisfaire la solution de surveillance du système. Ce mémoire contiendra donc une introduction à ITIL via ses différents ouvrages, ainsi qu une analyse des solutions apportées pour monitorer le système. Mots-clés : Monitoring, ITIL, A.S.T.R.I.D. 4

5 Table des matières Remerciements Résumé Introduction Contexte Aperçu de ITIL Objectifs de ce mémoire ITIL Introduction Historique Versions d ITIL Orienté service Finalité d ITIL Stratégie des services (Service Strategy) Conception des services (Service Design) Objectifs de la conception Acteurs et points de vue Niveaux de service Gestion de la capacité Transition des services (Service Transition) Objectifs Gestion des Changements Critiques de la gestion des changements Cas pratique L exploitation des services (Service Operation) Équilibrage Gestion des évènements Cas pratique II L amélioration continue des services (Continual Service Improvement) Les sept étapes de l amélioration continue des services Conclusion Analyse du problème général et solutions apportées Fonctionnalités à implémenter État de l art Fonctionnement général du programme

6 3.3.1 Optique de développement Choix des infrastructures Fonctionnement et analyse temporelle Structure de la base de données Arborescence des fichiers Automatisation et problèmes inhérents Métriques et fréquence d échantillonnage Fichiers de logging Design patterns employés Modèle-Vue-Contrôleur ou MVC Singleton Diagramme de classes Gestion des avertissements Analyse des fichiers textes En résumé Résultats Installation Analyse des ressources nécessaires Ressources logicielles Ressources matérielles Guide d utilisation Guide console Guide graphique Intérêt du logiciel Conclusion Conclusion Bilan sur le travail accompli Perspectives Analyse des données Articulation avec un logiciel de gestion des incidents A Requête pour un changement 59 B Guide d installation 61 B.1 Configuration minimale B.2 Configuration de la base de données Oracle B.3 Création des tables de la base de donnée Oracle B.4 Configuration des collecteurs de données Windows B.5 Peuplement des tables et configuration B.6 Automatisation C Documentation des erreurs 69 C.1 Erreurs générales C.2 Erreurs de connexion C.3 Erreurs d insertion

7 C.4 Erreurs lors de la visualisation C.5 Erreurs de gestion des logs C.6 Erreurs de l analyseur de performance Windows D Guide de désinstallation 71 E Exemple de rapport générés par le logiciel 73 E.1 Rapport d activité E.2 Rapport des avertissements

8 Table des figures 1.1 Architecture du réseau A.S.T.R.I.D. extrait de [1] Schéma de fonctionnement global d ITIL extrait de [5] Interface des collecteurs de données Windows Analyseur de performance Windows Analyse des performances et de la corrélation avec TeamQuest View [12] Schéma de l exécution temporelle du logiciel développé Schéma de la base de données Oracle Diagramme d une solution alternative pour un schéma Oracle avec une unique table contenant toutes les métriques Arborescence des fichiers : partie batch Arborescence des fichiers : partie programme Arborescence des fichiers : partie données Diagramme de classe UML Aperçu du logiciel développé : fenêtre de connexion Aperçu du logiciel développé : fenêtre d insertion Aperçu du logiciel développé : fenêtre de visualisation Aperçu du logiciel développé : fenêtre de recherche des avertissements Aperçu du logiciel développé : fenêtre de gestion des avertissements Aperçu du logiciel développé : fenêtre de création de rapport Intérêt du logiciel : stabilisation apparente de la métrique Intérêt du logiciel : mise en lumière d une faible décroissance Intérêt du logiciel : estimation d un dépassement de seuil Exemple de distribution marginale inspiré de [4] B.1 Création d un nouveau collecteur de données B.2 Onglet planification du collecteur de données B.3 Onglet condition d arrêt du collecteur de données B.4 Propriétés du compteur de performance B.5 Choix des métriques B.6 Onglet Compteur de performance des propriétés du compteur de performance B.7 Onglet Fichiers des propriétés du compteur de performance

9 Chapitre 1 Introduction 1.1 Contexte Dans cette section, nous allons expliquer l infrastructure globale dans laquelle ce mémoire s inscrit, tout en citant ses différents acteurs. Pour plus de facilités, nous adopterons une approche descendante (top-down). Tout d abord, on peut voir l État belge comme un des acteurs principaux car celui-ci est réellement au cœur de la problématique. En effet, l État belge doit assurer un certain nombre de services primordiaux pour le bon fonctionnement du pays. L un des services qui nous concerne plus directement est un service de sécurité nationale dans lequel se retrouve un certain nombre de sous-services, dont la gestion de l ordre public et la sécurité civile [15] qui sont mises en évidence dans ce mémoire. Suite au drame du Heysel 1 et à la catastrophe du Herald of Free Enterprise 2, l État belge constate un problème de coordination entre les différents services de secours et décide alors de créer un réseau dédié aux communications d urgences en employant notamment les fréquences radio. Il en suit directement la création de A.S.T.R.I.D. SA pour All around Semi-cellular Trunked Radio and Integrated Dispatching qui est chargé de la construction et de la gestion de ce réseau. Pour atteindre ses objectifs, A.S.T.R.I.D. fait un appel d offre qui sera finalement remporté par le consortium Kreutler - Nokia - Telindus. Au fil des ans, certains changements se sont opérés, et ainsi, Kreutler disparait, tandis que Nokia passe la main à EADS qui devient ensuite Cassadian alors que Telindus est racheté par Belgacom. Belgacom sous-traite la partie logicielle à Intergraph. C est au sein de la compagnie Intergraph que se déroule ce mémoire. Afin de mieux expliquer le rôle d Intergraph au sein du système, nous allons dans un premier temps aborder le rôle et le fonctionnement d A.S.T.R.I.D. Il s agit d un opérateur 1. Le drame du Heysel, survenu le 29 mai 1985 à Bruxelles en Belgique, est l une des tragédies les plus marquantes liées à une manifestation sportive, et due au hooliganisme. Il eut lieu à l occasion de la finale de Coupe d Europe des clubs champions entre le Liverpool Football Club et la Juventus Football Club. Des grilles de séparation et un muret s effondrèrent sous la pression et le poids de supporters, faisant 39 morts et plus de 600 blessés [13]. 2. Le Herald of Free Enterprise est un ferry de la compagnie Townsend Thoresen qui assurait la liaison transmanche entre Douvres et Zeebruges. Il chavira le 6 mars 1987 au large du port de Zeebruges, faisant 193 morts [14]. 9

10 télécom dédié à tous les services de la protection civile en Belgique. C est un opérateur unique qui permet à la police, aux pompiers et aux autres services de secours de communiquer entre eux [2]. Pour arriver à cela, A.S.T.R.I.D. SA à créé un réseau appelé réseau A.S.T.R.I.D. Celui-ci est composé d un nœud par province plus un nœud pour la région de Bruxelles-capitale. Ces nœuds sont appelés CIC (Centre d Information et de Communication) et comportent tous les équipements nécessaires au routage des communications. Les nœuds provinciaux réunis constituent l épine dorsale du réseau. Toutes les demandes d appels et les appels eux-mêmes transitent par les nœuds. Ils connaissent à chaque instant la position d un poste allumé se trouvant sous la couverture du réseau. Ils sont également connectés à des systèmes externes comme les réseaux téléphoniques fixes ou mobiles. De plus, dans chaque CIC, un centre de dispatching provincial est également actif. Celui-ci est équipé de stations de travail destinées aux opérateurs. Ces stations de travail sont connectées, d une part, au système de radiocommunication et, d autre part, à un réseau informatique local équipé de banques de données contenant toutes les informations nécessaires aux opérateurs. De même, les stations de travail sont connectées au central téléphonique de sorte que les opérateurs puissent prendre les appels d urgence [3]. Un schéma de l architecture du réseau A.S.T.R.I.D. est fourni par la figure 1.1. Figure 1.1 Architecture du réseau A.S.T.R.I.D. extrait de [1]. Intergraph se charge de la partie logicielle qui permet aux opérateurs d accomplir leur travail, tant au niveau de l opérateur téléphonique qui décroche le téléphone en cas de souci qu aux personnes chargés du dispatching des équipes sur le terrain. De plus, Intergraph offre un service de support et de maintenance préventive par rapport aux machines employées. Cependant, une telle infrastructure informatique doit pouvoir être gérée correctement. Dès lors, afin d assurer une certaine stabilité au système, un ensemble de règles a été créé, 10

11 notamment en s appuyant sur ITIL, une bibliothèque regroupant les bonnes pratiques concernant la fourniture et la gestion de services informatiques. Ce mémoire prend corps sous la direction d Intergraph et a pour but de fournir et de déployer un logiciel de monitoring pouvant récolter certaines données et de calculer des prévisions sur base de ces dernières. Cet outil a pour mission de faciliter la tâche de maintenance préventive. Notons également que l ensemble du processus de déploiement doit être conforme aux politiques en application sur les machines. Notons qu un outil rudimentaire fonctionnant grâce à Excel est déjà présent sur site. Cependant, cet outil n est pas du tout automatisé et requiert donc un travail non négligeable de la part de l utilisateur. De plus, cet outil possède les limitations d Excel et n est pas prévu pour traiter un grand volume de données. 1.2 Aperçu de ITIL ITIL (pour Information Technology Infrastructure Library) est un recueil de bonnes pratiques concernant les infrastructures informatiques. Comme celles-ci ont déjà été testées et approuvées de nombreuses fois, les adopter permettra d obtenir une structure stable et efficace car, même si ça peut sembler évident, créer ou maintenir une telle structure demande une organisation aussi précise que rigoureuse. Dès lors, s appuyer sur ITIL assure une certaine qualité ne fut ce qu au niveau du fonctionnement global. Cependant, certaines étapes de développement et de déploiement peuvent se retrouver alors plus ou moins modifiés afin d assurer un fonctionnement optimal. On peut donc dire qu ITIL est un outil possédant un certain nombre d avantages et d inconvénients, un chapitre ultérieur sera consacré à une étude d ITIL de manière approfondie. 1.3 Objectifs de ce mémoire En connaissant le contexte, et en ayant eu un bref aperçu d ITIL, nous pouvons maintenant énoncer les objectifs de ce mémoire. Il s agit de déployer un logiciel de monitoring correspondant à différentes attentes et contraintes. Le logiciel devra être capable de prendre des mesures d un certain nombre de métriques, d afficher les courbes créés à partir des données collectées et de fournir un système d alerte en cas de problème. Le programme déployé permettra également d analyser statistiquement les données et sera capable de fournir certains modèles prévisionnels simples. Finalement, un outil permettant de créer des rapport d activités (reporting) sera également implémenté. Un second but de ce mémoire est de comprendre et manipuler certains des concepts et conseils prodigué par ITIL et ainsi de pouvoir se familiariser avec cet outil et prendre conscience des avantages qu il peut apporter mais également des contraintes qu il impose. 11

12 Chapitre 2 ITIL Dans ce chapitre, nous décrirons ITIL de manière systématique en commençant par expliciter les principes de base puis, nous aborderons la stratégie des services de manière globale. Une fois la vision globale du fonctionnement d ITIL acquise, nous irons plus en détail dans la conception, la transition, et l exploitation des différents services. Pour conclure nous analyserons l amélioration continue des services pour finalement offrir une conclusion sur l emploi d ITIL. L entièreté de cette section est principalement inspirée de [5] qui est lui même inspiré des différents livres ITIL [10, 8, 11, 9, 7]. 2.1 Introduction Historique Dans ses débuts, l informatique était principalement concentré sur le développement d applications, la livraison du logiciel était alors une fin en soi. Cependant, les besoins des entreprises évoluant, la création d applications ne représente plus qu une partie des activités d une entreprise informatique. En effet dans les années 80, les besoins commerciaux exigeaient alors le déploiement de nouveaux services informatiques. Un service de support ou Help Desk fut créé pour faire face aux nombreux problèmes rencontrés par les clients [6]. Vers la fin des années 80, le gouvernement britannique, poussé par un besoin de trouver des méthodes efficaces, commence à se documenter sur la gestion de services afin de connaître les méthodes employées par les organisations ayant le plus de succès. Au début des années 90, le gouvernement britannique avait déjà écrit plusieurs livres sur la gestion de services informatiques. L ensemble de ces ouvrages s intitulait alors Information Technology Infrastructure Library ou ITIL [6] Versions d ITIL Depuis sa création, ITIL n a jamais cessé d évoluer. Ainsi, la version produite par le gouvernement britannique vers 1990 à constitué la première version de ITIL. Cette 12

13 version à évolué jusque en 2004 pour ainsi former ITIL v2. À ce stade, ITIL comptait neuf livres parmi lesquels deux livres ont principalement contribué à son succès. Ces deux livres s intitulent Support des services (Service Support) et Fourniture des services (Service Delivery). Ces livres abordent respectivement les processus opérationnels et la gestion des services communs comme la capacité et la sécurité. Suite à cela, ITIL a encore subi des modifications pour être remis au goût du jour, notamment en ayant été réorganisé et en incluant de nouveau éléments comme l outsourcing et la virtualisation, devenant alors de plus en plus courants. Ainsi, en 2007, ITIL v3 voit le jour. Actuellement, ITIL en est à la version 3.1 qui est en quelque sorte un seconde édition de la version 3 tenant compte de différentes remarques faites par les utilisateurs. Le présent document se base exclusivement sur ITIL v3.1 bien que la plupart des concepts expliqués soient compatibles avec les versions antérieures d ITIL Orienté service Dans le contexte politique et économique actuel les sociétés informatiques ne peuvent plus se permettre de simplement fabriquer des produits et de les vendre sans fournir une certaine garantie sur le bon fonctionnement de ce produit. Ainsi, ITIL décrit les différentes activités sous la forme de services. Un service est un moyen de délivrer de la valeur aux clients en facilitant la production des résultats dans leurs activités sans qu ils aient à se préoccuper des coûts et des risques spécifiques au service qui leur est fourni [5]. Les capacités (Capabilities) correspondent aux processus et fonctions utilisés pour gérer des services. Les capacités sont des ressources intangibles d une organisation et ne peuvent pas être vendues mais peuvent se développer et gagner ainsi en maturité au fil du temps [8]. Ainsi en regardant la définition d un service, la vente d un produit peut également être vue comme un service à partir du moment où une certaine garantie y est associée. En effet, la garantie fournit une certaine valeur ajoutée dans le sens où cette dernière diminue les risques pris par le consommateur Finalité d ITIL Il est parfaitement légitime et logique de se demander à quoi sert ITIL. Nous allons donc passer en revue les différentes raisons d utiliser ITIL, de manière générale puis de manière plus approfondie selon les différents ouvrages de références. Globalement, ITIL peut améliorer l organisation d une entreprise en identifiant, documentant, clarifiant et améliorant les différents processus mis en œuvre. Ainsi, les différents départements peuvent arriver à une meilleure coordination et compréhension des processus. Un processus est un ensemble d activités coordonnées mettant en œuvre des ressources et des capacités en vue de produire un résultat aux clients [8]. 13

14 De manière plus détaillée, les différents ouvrages d ITIL permettent d améliorer les points suivants dans une entreprise [5] : notons également que ces différents ouvrages feront l objet d analyses plus poussées dans des sections ultérieures. Stratégie des services (Service Strategy) [10] : Cet ouvrage explique comment aligner les stratégies business avec l informatique pour ainsi mieux pouvoir définir une ligne de conduite cohérente en ayant connaissance des contraintes et des ressources disponibles actuellement. Aligner ces deux axes permet ainsi de mieux diriger l entreprise dans ses projets. Conception des services (Service Design) [8] : Ce livre analyse les différents moyens de concevoir un service performant et compétitif en prenant en compte les éléments essentiels tel que le point de vue des fournisseurs et des clients ou même l infrastructure actuelle de l entreprise. Transition des services (Service Transition) [11] : Ce volume décrit comment élaborer des plans de transition tout en estimant les risques et l impact positif ou négatif d une transition. Une transition peut-être vue comme une modification (ajout, mise à jour ou suppression) d un élément. Dans le cadre de ce mémoire, où un produit fini doit être déployé sur site, cette partie est extrêmement importante car elle explique comment introduire un changement avec les différentes procédures de transition associées. Toujours dans notre cadre, la transition constituerait alors le passage d un système dépourvu du produit à un système qui en est équipé. Exploitation des services (Service Operation) [9] : Cette référence-ci explicite comment suivre les plans opérationnels prévus en offrant une certaine garantie de qualité. Amélioration continue des services (Continual Service Improvement) [7] : Cet ouvrage explique comment mettre en œuvre différentes techniques servant à prendre une position réflexive permettant de critiquer les différents processus afin de les rendre de plus en plus précis et adaptés à leur environnement. 2.2 Stratégie des services (Service Strategy) La stratégie des services est un ouvrage qui se destine principalement aux commerciaux. Comme expliqué précédemment, ce volume a pour objectif d aligner les différents départements d une société, dont les départements business et IT pour arriver à un but commun qui est la création de valeur durant le cycle de vie. Pour arriver à cela, l ouvrage explique les bases de la vente de services en expliquant que la majorité des apports d un service peuvent être résumés par l utilité qui évalue l aptitude à résoudre le problème et la garantie qui est l aptitude à répondre à son utilisation. Ce volume propose de réfléchir sur les différentes particularités de son entreprise et invite le lecteur à se mettre à la place de ses clients, notamment en posant les questions suivantes. Quels services allons nous offrir et à qui allons nous les offrir? Comment allons nous créer de la valeur pour nos clients? En quoi sommes nous différents de la concurrence? Comment définit-on la qualité de nos services? 14

15 ITIL explicite différents processus stratégiques tels que la définition du marché ou la définition des offres et développe également les processus économiques comme la gestion financière, la gestion de la demande ou la gestion des portefeuilles de services (catalogue reprenant l ensemble des services). Finalement, cet ouvrage explique que la stratégie des services est réellement le cœur d une société car une entreprise ne pourrait pas perdurer sans cela. Ainsi, une société ne peut se permettre d œuvrer sans but mais doit au contraire fixer ses objectifs. C est le rôle de la stratégie des services : trouver les différents objectifs ainsi que les services qui permettront d obtenir ce résultat. 2.3 Conception des services (Service Design) Cette partie est dédiée à la création de services et expose différentes règles et bonnes pratiques. Elle explicite les différents objectifs et points importants à prendre en compte lors de la conception Objectifs de la conception Lors de la phase de conception, les concepteurs ont des objectifs associés à différents domaines. Ces derniers sont développés ci-dessous. Alignement sur le plan Business : Il faut être attentif à combler les attentes du département business et à ce que le résultat fourni corresponde réellement aux envies de cette entité, même si parfois les attentes ne sont pas formulées de manière très explicite. Optimisation des délais et coûts : Il est impératif de prendre en compte les coûts générés par l introduction d un nouveau service ainsi que d évaluer le délai avant que le service ne soit réellement exploitable et rentable. Gestion des risques : Il est nécessaire d évaluer les risques afin de pouvoir les minimiser, ou même pouvoir les prendre en compte. Mesures des objectifs : Afin de pouvoir garantir une certaine qualité du service créé, il est nécessaire de concevoir des métriques permettant de mesurer si l objectif est atteint ainsi que la qualité de cet objectif. Amélioration continue : En vue de pouvoir améliorer le service, il faut veiller à ne pas figer les différents processus composant le service et à garder une certaine flexibilité en vue d une amélioration future Acteurs et points de vue Une bonne pratique consiste à prendre en compte les différents points de vue dès la phase de conception. Négliger un point de vue peut souvent avoir des conséquences désastreuses. Dans le cadre de ITIL ces acteurs sont connus comme les quatre P de la conception des services. Ces quatre P sont : 15

16 Produits et technologie : Il est nécessaire pour le concepteur de se renseigner sur les technologies utilisées. Une conséquence de cet oubli peut amener une société à créer un produit avec lequel elle n est pas familière sans même s en rendre compte. Partenaires et fournisseurs : Il est également critique de directement intégrer les fournisseurs dans le futur service afin de mieux prendre en compte les exigences et les aptitudes des partenaires. Personnel : Prendre en compte les changements introduits par la mise en place du nouveau service, au niveau du personnel, est primordial. Il faut ainsi s assurer que l entreprise dispose bien des ressources humaines nécessaire à l aboutissement du nouveau projet. Cette partie est souvent négligée et cause alors bien des soucis tels que l augmentation du temps de travail des employés, une baisse de la qualité des services proposés ou encore un retard par rapport à la date de prévision de la mise en exploitation. Processus : Cet élément consiste à évaluer l impact sur la manière dont l entreprise et chacun œuvre et œuvrera une fois que la création du service commencera. Si des processus de développement sont déjà formalisés, il est impératif d estimer cet impact afin de ne pas concevoir un service qui ne pourra pas correctement être appliqué en pratique Niveaux de service À ce point, nous comprenons bien que la conception de services est une chose complexe de par le nombre de paramètres à prendre en compte (acteurs, points de vue et objectifs). En vue d offrir certaines garanties sur les services fournis, ITIL propose de fixer des accords sur les niveaux de service ou (Service Level Agreement ou SLA). Ces derniers peuvent être définis de la manière suivante. Un accord sur les niveaux de service (Service Level Agreement ou SLA) est un accord écrit entre un fournisseur de services et un ou des clients. Il porte sur un ou plusieurs services d affaires et décrit les niveaux de services prévus avec la ou les organisations d affaires (disponibilité, capacité, sécurité et continuité de service) [5]. Ces SLA peuvent être fixés entre une société et un client ou encore dans le cadre de la sous-traitance entre deux entreprises. Les SLA sont donc là pour fixer une certaine qualité de service. ITIL va plus loin et propose de fixer des indicateurs clés de performance ou (Key Performance Indicator ou KPI) associés aux SLA précédemment fixés. Un indicateur clé de performance (Key Performance Indicator ou KPI) est un ensemble de métriques objectives et mesurables qui permettent d évaluer si les différents niveaux de services convenus (SLA) ont été respectés. Une fois les SLA et KPI définis, on peut aller plus loin et fixer des pénalités en cas de manquement aux SLA. Ces pénalités sont généralement fixées sur base de KPI et peuvent être très variables selon le manquement observé et peuvent parfois être négociées lors de rencontres. 16

17 2.3.4 Gestion de la capacité La gestion de la capacité est un point clé dans le cadre de ce mémoire. En effet, la création d un outil de monitoring dans le but d améliorer la maintenance préventive s inscrit clairement dans l optique de la gestion de la capacité. Ci-dessous, une définition de la gestion de la capacité est proposée : L objectif de la gestion de la capacité est de s assurer que la capacité est disponible au moment adéquat, à un prix justifiable et en nombre suffisant en adéquation avec le plan business. Dans ITIL, cette gestion peut se décliner sous trois formes : La gestion de la capacité business : rend possible la gestion des plans marketing et business de manière stratégique. La gestion de la capacité des services : permet de gérer, contrôler et prévoir la charge des différents systèmes (notamment les systèmes informatiques). La gestion de la capacité des composants : permet de gérer les composants individuellement. Cette dernière forme est principalement implémentée sous la forme de logiciel mesurant la performance des équipements. La maintenance et la maintenance préventive peuvent être vues comme de la gestion de la capacité. En effet, la maintenance des machines rentre clairement dans la gestion de la capacité de service et dans la gestion des composants. Dans cette optique, le logiciel de monitoring créé permettra de s assurer du bon fonctionnent des services et des composants. 2.4 Transition des services (Service Transition) Objectifs Les objectifs de la transition des services sont plutôt simples à comprendre et sont les suivants : Planifier les différentes transitions et les diminutions de ressources associées à ce changement. Par exemple, le réseau sera inutilisable lors de l installation d un nouveau routeur. Diminuer l impact des changements. Valider les changements et vérifier leur adéquation avec les plans business. Pour arriver à cela, ITIL propose de travailler sur la communication entre services, notamment en fournissant une documentation fiable, claire et conséquente pour tout changement. ITIL explique en détail comment gérer concrètement ces changements Gestion des Changements En vue de mieux planifier les changements et de fournir une meilleur documentation, ITIL propose de fournir un document avant d appliquer tout changement. Ce document s appelle un RFC (Request For Change). 17

18 Le RFC (Request For Change) est un document présentant un changement à effectuer. Idéalement ce document contient le nom de la personne ayant effectué la demande, la raison du changement, les bénéfices attendus une fois le changement appliqué, une estimation des risques, le niveau d urgence de ce changement, la diminution de ressources lors de la période de changement ainsi que l identité de la personne qui effectuera ce changement. Pour faciliter l emploi de tels documents, ITIL propose à l organisation qui désire employer ce système de fournir un modèle de RFC. Une fois le modèle dument complété, le RFC doit alors être mis à disposition du gestionnaire de changement qui préside le CAB (Change Advisory Board). Le CAB (Change Advisory Board) est un ensemble de personnes provenant de tous les départements chargés de fournir les autorisations s il y a lieu aux différents RFC. Typiquement un RFC est introduit pour les opérations suivantes : Apporter de nouvelles fonctionnalités (Installation d un nouveau programme) Retirer d anciennes fonctionnalités Introduire des correctifs Introduire des mises à jour Le changement pourra être appliqué seulement après validation du CAB. Le CAB se chargera également de prévoir une date à laquelle effectuer ce changement ainsi que d avertir les personnes concernées par ce changement. Dans le cadre de mémoire, un RFC a été rédigé et est présenté en annexe Critiques de la gestion des changements On peut observer que les objectifs annoncés pour la gestion des changements sont respectés. Avec cette méthode, la documentation est fournie, les risques sont évalués et la planification est entièrement prise en compte. Cependant ce processus peut parfois entraîner une certaine lourdeur de procédure. En effet, le temps de réponse nécessaire avant qu un RFC ne soit traité peut aller jusqu à plusieurs mois. De plus, certaines parties de l organisation peuvent refuser certains changements provocants des conflits d intérêt au sein de l entreprise Cas pratique Dans le cadre de ce mémoire, les choses sont un peu plus complexes et font apparaitre des positions divergentes entre les différents acteurs. Ainsi, un logiciel de monitoring (HP- OpenView Operations) est déjà déployé et fonctionnel sur chaque site mais Intergraph qui est chargé de la maintenance préventive d une partie des softwares du site n a pas accès à ce logiciel ni aux données que ce dernier récolte. 18

19 Ainsi, l introduction d un RFC concernant un nouveau logiciel de monitoring ne sera pas acceptée car elle n a que peu de sens aux yeux du CAB puisqu un logiciel de monitoring est déjà déployé et fonctionnel. Afin d éviter de long débats, l utilisation finale du logiciel se voudra donc très opaque pour tout organisme externe à Intergraph et le RFC vraisemblablement très flou. Ainsi il ne s agira plus d un logiciel de monitoring mais bien d une solution d amélioration de maintenance préventive. Ainsi, pour inciter l acceptation du RFC, nous rechercherons un impact minimal en n employant, si possible, que des logiciels déjà installés sur les machines. 2.5 L exploitation des services (Service Operation) L exploitation des services est la phase où le service commence à générer du revenu et fonctionne au régime de croisière. On pourrait considérer qu à ce moment, il n y a plus que des opérations de maintenance à faire. Cependant, si on voit l exploitation des services comme faisant partie d un tout, on peut alors se rendre compte que cette phase est cruciale car il s agit du moment où l on peut commencer à ré-équilibrer différents aspects Équilibrage Les différents équilibrages présentés ici ont normalement fait l objet de prévision dans la phase de conception. Cependant les imprévus, la concurrence ou même une révision des budgets pour provoquer un ré-équilibrage entre ces différents aspects : Processus IT vs Activité du métier : Les clients demandant un service ne présentent généralement peu ou pas d intérêt à savoir comment il est possible de réaliser ce service. Cependant, ne pas s y intéresser peut engendrer des problèmes de compréhension entre l équipe IT chargée de créer le produit et l équipe business chargée de designer le produit. Lors de ces malentendus, le département IT peut alors parfois produire des services coûteux peu adaptés à la demande du métier et des clients. Stabilité vs Adaptabilité : Ce compromis explique qu il faut savoir correctement s adapter à l évolution des besoins d un métier et des clients. Cependant s adapter à outrance engendrera évidemment des coûts supplémentaires. Il faut donc anticiper les besoins futurs afin de réduire le nombre de mises à jour. Qualité de service vs coût de service : Ce compromis est simple à appréhender car il fait partie des contraintes de la vie courante. D un côté, on pourrait avoir de gros défauts au niveau de la qualité alors que de l autre côté on pourrait avoir un produit extrêmement cher mais de qualité excellente. Réactivité vs Pro-activité : Deux optiques sont ici possible, soit attendre qu un événement majeur se produise avant de pouvoir réagir, soit être pro-actif et chercher à tout moment comment améliorer chaque processus. Cette dernière optique impliquera un certain nombre de changements ayant évidement un coût. Il faut donc, ici aussi, anticiper les besoins futurs. 19

20 2.5.2 Gestion des évènements Lors de la phase d exploitation, il peut arriver que certains évènements aient lieu. Nous pouvons définir un évènement de la manière suivante : Un évènement est une occurrence détectable ou discernable ayant une signification sur la gestion d une infrastructure ou la fourniture d un service et une évaluation de l impact indiquant qu une déviation pourrait apparaître sur les services [5]. Ces évènements sont donc présents sous beaucoup de formes différentes dans des domaines variés. De plus, les évènements peuvent être classés en trois catégories : les évènements normaux, inhabituels et ceux signalant une exception. Pour donner une idée, une liste d évènements est fournie ci-dessous. Cette liste n est bien sur pas exhaustive. Évènements normaux Connexion effectuée avec succès Compilation terminée Possibilité de mise à jour d un logiciel... Évènements inhabituels Avertissement lors de la compilation d un programme Un programme demande les droits administrateurs pour être exécuté Augmentation du temps de réponse entre deux machines... Évènements signalant une exception Tentative d accès à un site web non autorisé Utilisation des ressources par un service non autorisé Crash d un serveur... Avoir une liste de tout ces évènements est très intéressant pour une entreprise car elle peut alors gérer des exceptions et identifier des incidents ou des problèmes rapidement. Les incidents et les problèmes sont deux choses différentes dans le vocabulaire ITIL. Voici donc leur définition. Un incident est un évènement entrainant une interruption ou une baisse de qualité pour un service. Les évènements ayant un impact potentiel mais non encore observé sont également considérés comme des incidents. Un problème est la cause d un ou plusieurs incidents. Lors de l enregistrement d un problème, la cause exacte n est pas toujours connue. Pour mieux visualiser, voici une liste non exhaustive d incidents et de problèmes. Incidents Diminution de la bande passante entre deux machines en-dessous des niveaux de service convenus (SLA) Défaillance d un disque dur (impact immédiat) 20

21 Défaillance d un disque dur en miroir (impact potentiel) Défaillance exceptionnelle et non reproductible d un programme... Problèmes Défaillance systématique d un programme lors de certaines manipulations Défaillance d un serveur provoquant plusieurs incidents sur les machines clientes Défaillance régulière d un service sans pistes de solution... Une bonne pratique est de catégoriser les différents problèmes et incidents en catégories selon leur importance. En effet, la priorité de la résolution d un problème empêchant les utilisateurs d employer la calculette de Windows ne sera pas la même qu un problème empêchant une base de données de fonctionner Cas pratique II Dans le cadre de ce mémoire, des SLA, des KPI et des pénalités ont été fixées au sujet de la maintenance préventive et réactive. Dans ces SLA, on peut retrouver une découpe selon les différents incidents et problèmes en fonction de leur gravité. Typiquement, lorsqu un certain type d incident a lieu, il faut qu un agent de maintenance soit sur site dans les deux heures (nombre fictif), qu il ait résolu le problème dans les quatre heures (nombre fictif) suivant l incident et qu il fournisse un rapport de l incident dans les vingt-quatre heures (nombre fictif). Pour compliquer les choses, les SLA sont fixées de manière probabiliste. Ainsi, en réalité, il faudra que l agent de maintenance soit dans les délais dans plus de 95% des cas (nombre fictif). Ceci constituant alors l aspect plus réactif de la problématique. L aspect préventif consiste, lui, à prouver que la maintenance préventive a bien eu lieu et que si un souci apparaît, ce dernier n était pas prévisible et n est pas imputable à un défaut de la maintenance. Une solution consiste à fournir des rapports représentant l état de santé du système. Ainsi, le logiciel aura non seulement pour but d aider les opérateurs de maintenance à détecter les incidents et problèmes mais devra également les protéger en montrant qu un incident n est pas imputable à un défaut de maintenance. 2.6 L amélioration continue des services (Continual Service Improvement) Concept général L amélioration continue des services permet de suivre les services tout au long de leur cycle de vie et de les améliorer. L idée générale d ITIL au niveau de l amélioration continue est la suivante : Il n est pas possible de gérer ce qu on ne peut pas contrôler Il n est pas possible de contrôler ce qu on ne peut pas mesurer Il n est pas possible de mesurer ce qu on n a pas défini [5]. 21

22 Basé sur cette idée, ITIL développe une méthodologie cyclique en sept étapes, destinée à l amélioration des services Les sept étapes de l amélioration continue des services 1. Définir ce qu il faudrait mesurer. Lors de cette étape, on décide de ce qu il serait intéressant de mesurer sans se soucier de la manière dont il faudra le faire. On se demande alors ce qui a de l importance. Les points sélectionnés peuvent être très variables et aller de la vérification des objectifs business à la satisfaction du personnel en passant par le développement des infrastructures de l entreprise. 2. Définir ce qu il est possible de mesurer. Durant cette étape, on choisit comment mesurer les différents points sélectionnés à l étape précédente si cela semble possible ainsi qu une évaluation de la différence entre les données collectées et les données désirées. 3. Collecter les données. Il s agit là d une phase de collecte des données indispensable pour la suite des opérations. 4. Reformater les données. À cette étape, les données sont réorganisées si nécessaire. Un exemple serait une transition entre les données sous format papier et les mêmes données correctement encodées dans une base de donnée relationnelle. 5. Analyser les données. Ce niveau permet de véritablement analyser les données collectées afin de vérifier la tendance ainsi que la vérification de la réalisation des différents objectifs. 6. Utiliser des informations. Les informations récoltées vont ici être présentées à différents niveaux. Les informations vont bien sûr être présentées de manière différente selon les préoccupations de l auditoire. Ainsi, un DRH ne veut pas forcément connaitre les détails techniques propres au département informatique ou encore l atteinte des objectifs commerciaux plutôt destinés au directeur marketing. 7. Mettre en place des actions correctives. Une fois les différentes informations communiquées, il faut alors mettre en place certaines actions permettant d améliorer le service. Ainsi, les incidents détectés dans les données et mis en lumière par les étapes 5 et 6 doivent servir de base de discussion aux niveaux 7 et 1 : le niveau 7 impose d installer de nouveaux détecteurs tandis que les niveaux 1 et 2 vont servir à imaginer et concevoir ces nouveaux outils. La boucle est bouclée ; le cycle recommence encore et encore. De manière générale, un point fort d ITIL est que chaque explication peut s imbriquer avec les autres, et fait réellement partie d un tout. Comme on peut l observer à la figure 2.1, le diagramme le plus connu d ITIL appréhende bien cet ensemble où l on peut voir les différents interactions entre les différentes parties. Ainsi chaque partie est forcée de communiquer avec ses homologues. 22

23 Figure 2.1 Schéma de fonctionnement global d ITIL extrait de [5]. 2.7 Conclusion En conclusion, on peut remarquer qu ITIL est réellement un guide de bonne pratique permettant aux organisations qui le souhaitent d améliorer et de recentrer leurs services. Durant tout le développement, nous avons pu voir que chaque partie d ITIL développait clairement des objectifs et des moyens proposés afin d atteindre ceux-ci. Ainsi, si les objectifs ne semblent pas à propos pour une entreprise, elle n est clairement pas obligée d appliquer les parties qui ne la concernent pas. Dès lors, chaque entreprise décide des parties d ITIL à appliquer et souvent, applique les conseils de manière différente. Ces différents emplois d ITIL sont appelés des implémentations d ITIL. Finalement, on peut dire qu ITIL est toujours quelque chose de bénéfique mais que certaines implémentations peuvent parfois introduire des lourdeurs difficiles à évaluer dont celles expliquées dans le premier cas pratique. Finalement, on peut dire que le plus important est de bien adapter les concepts que prodigue ITIL dans le cas très particulier de son entreprise. Ainsi une PME n implémentera pas sa version d ITIL de la même manière qu une grande entreprise multinationale. On peut donc dire qu il existe autant d implémentations différentes d ITIL que d entreprises qui l utilisent. 23

24 Chapitre 3 Analyse du problème général et solutions apportées 3.1 Fonctionnalités à implémenter Comme nous l avons vu précédemment, le programme doit développer certaines fonctionnalités tout en répondant à un certain nombre d attentes. Les attentes pour les logiciels de monitoring sont assez classiques dans le sens où une très grande partie des logiciels existant les implémentent déjà et où il parait naturel de les implémenter. Nous pouvons noter que l exécution du logiciel de monitoring doit influencer le moins possible la prise des mesures et ce, tant au niveau des performances de la machine qu au niveau du trafic sur le réseau et de l activité des bases de données. De manière générale, il faut bien sûr que le programme se montre flexible, scalable 1 et performant. Le but final sera de déployer cet outil dans les différents CIC s sachant que la plupart de ces machines fonctionnent sous Windows Server 2003 ou Windows XP. Le produit final devra en outre satisfaire les contraintes suivantes. Collecte des données : Le programme devra être capable de récolter des données pertinentes de manière fiable et de les stocker de manière intelligente. Cependant, toutes les données ne sont pas directement accessibles via le système d exploitation. Certaines données se retrouvent uniquement dans des fichiers plats récupérés via des scripts personnalisés. Pour donner un exemple, nous pouvons citer la commande ping qui permet d obtenir des données qui sont difficilement accessible autrement. Les données contenues dans de tels fichiers doivent également pouvoir être stockées. Visualisation des données : Le programme doit proposer un outil flexible de visualisation des données. Celui-ci permettra d afficher différentes courbes pour les différentes machines monitorées. Il sera également possible de sélectionner une période de temps pour l affichage. Détection des anomalies : Le programme doit proposer un moyen de détecter les anomalies. Ceci permettra notamment de pouvoir anticiper certains problèmes avant que ceux-ci ne deviennent dommageables (gestion pro-active des ressources). 1. Capacité à s adapter à un changement d ordre de grandeur de la demande ou du niveau d utilisation 24

25 Génération de rapports : Le programme permettra de générer des rapports. Ceuxci reprendront principalement l entièreté des mesures collectées durant une période de temps donnée, ainsi que les points ayant fait l objet d avertissements. Analyse des données récoltées : Le programme pourra fournir un travail d analyse simple sur les données. Automatisation : Le programme pourra fonctionner de manière automatisée, c est à dire sans intervention de la part de l utilisateur. 3.2 État de l art Il existe beaucoup de programmes capables de monitorer des systèmes informatiques. Cette section se propose de passer en revue certaines des solutions disponible sur marché. Nous tenterons aussi de mettre en évidence les aspects attractifs et répulsifs propres à chacun de ces produits. Windows Performance Monitor Le premier logiciel de monitoring est tout simplement un programme fourni par Microsoft et qui se trouve par défaut dans le système d exploitation Windows depuis les versions NT 4.0 : Windows Performance monitor ou win Perfmon. Ce logiciel permet de collecter des données et de les stocker dans des fichiers texte (via des collecteurs de données) pour ensuite éventuellement faire des rapports d activité. Ce logiciel possède bien sur tous les outils essentiels tels qu un système de planification des mesures et un système de visualisation des données. Malheureusement, le partie visualisation de données n est pas très élaborée et offre peu de solutions d analyse : c est par essence un outil de visualisation. Le fait que le logiciel soit fourni par défaut par Microsoft peut paraitre anodin mais en réalité il en découle certaines propriétés intéressantes. D une part, comme le logiciel est vendu avec le système d exploitation, on peut considérer que le logiciel est fiable et offre des garanties suffisantes, notamment au niveau du support. Le deuxième point intéressant est que l on peut considérer le prix du logiciel comme étant nul. En effet, il ne faut pas payer pour avoir accès à ce service. Pour faire plus court, ce logiciel est donc sans coûts directs et possède un support technique conséquent. Les figures 3.1 et 3.2 montrent respectivement l interface permettant de choisir les métriques à observer et l interface de visualisation. TeamQuest Voici un outil totalement cross-platform puisqu il peut être exécuté sur à peu près n importe quel système d exploitation. De plus, cet outil permet de faire des rapports, des graphes et plus encore. Cependant, l installation reste assez lourde et relativement complexe à mettre en œuvre sur un réseau informatique. De plus, ce logiciel est payant, ce qui ne convient pas. Malgré les différents problèmes que le programme présente, il n en n est pas moins bien conçu au niveau de l interface utilisateur. Dans ce sens, une version d évaluation du logiciel a été installée sur une machine de test afin de s en inspirer. Il est alors apparu que TeamQuest propose de gérer l ensemble de la problématique Performance Management au travers de ses différents produits, qui couvrent toute la chaîne de gestion, allant de la collection des données systèmes et applicatives jusqu à la génération de rapports très sophistiqués. De plus, le collecteur de données est adapté à la plupart des plate-formes. Finalement, on peut également citer le système d analyse des données 25

26 Figure 3.1 Interface des collecteurs de données Windows. permettant de calculer des limites supérieures et inférieures ainsi qu une tendance générale de l évolution de la métrique (voir figure 3.3). HP OpenView Cet outil également très connu partage les caractéristiques de Team- Quest à savoir : grandes performances, installation laborieuse, et produit payant. On peut noter que cet outil est déjà présent sur certaines machines du système mais malheureusement les accords entre les différentes entreprises impliquées dans la maintenance des centres ne nous autorisent pas à employer ce logiciel. Au final nous avons repris différents outils très connus permettant au minimum de monitorer un système informatique. Il existe bien sûr d autres outils gratuits et parfois OpenSource qui semblent également convenir. Cependant, comme nous l avons vu précédemment, il n est pas envisageable d installer un logiciel de monitoring. Toutefois, regarder les logiciels existants ainsi que les fonctionnalités proposées permet d avoir une meilleur idée du logiciel type à fournir. En conclusion, si l on peut bien sûr s inspirer de ces différents logiciels, aucun d entreeux ne remplissait tous les pré-requis. Il a donc fallu créer un nouveau programme pour satisfaire toutes ces contraintes. La solution pour laquelle nous avons opté est de créer un logiciel exploitant les données générées par l analyseur de performance Windows (perfmon). 3.3 Fonctionnement général du programme Optique de développement L optique de développement de ce programme est bien sûr de fournir un logiciel fini ayant un certain nombre de fonctionnalités. Les points suivants montrent les critères auxquels il a été porté une attention toute particulière lors du développement. 26

27 Figure 3.2 Analyseur de performance Windows. Robustesse et fiabilité : Comme beaucoup de logiciels actuels, on considère bien sûr le fait de provoquer l arrêt inopiné d une machine, ou même, un service totalement inacceptable. De plus, la fiabilité des données récoltées joue un rôle très important dans le bon fonctionnement du logiciel. Ainsi, il est tout a fait logique et même indispensable de proposer un logiciel fiable et robuste. Convivialité : Il va de soi que le logiciel doit pouvoir être employé sans trop de difficultés par une personne qui n a pas participé au développement. Dans cette philosophie, il a semblé intéressant d offrir une interface graphique en plus du mode console permettant de gérer une très grande partie des fonctions de base du logiciel. Toujours dans cette optique, l interface graphique reste simple, efficace, robuste et sans surenchère technologique. Audit (Log) : Comme l application tournera de manière automatisée, il s avère indispensable de noter toutes les actions effectuées par le programme dans des fichiers dit de logging. Ceux-ci reprennent alors les informations importantes produites lors de l exécution du programme. L application possède dès lors différents fichiers de logging ainsi qu un mode verbeux (verbose). Légèreté : Le logiciel doit être le plus léger possible, notamment au point de vue des modifications apportées à l ensemble du système. Ainsi, une unique machine se chargera de recueillir les données et de les traiter. 27

28 Figure 3.3 Analyse des performances et de la corrélation avec TeamQuest View [12] Choix des infrastructures Le choix des infrastructures est une question cruciale dans bien des logiciels. Une infrastructure informatique peut être vue comme l ensemble des éléments permettant le bon fonctionnement du logiciel. Un choix qui peut paraître anodin est le choix de la langue. Dans le contexte politique actuel, choisir une langue nationale pourrait être préjudiciable. Dans un souci d impartialité linguistique, la langue de l interface utilisateur et du code sera l anglais. Ainsi, au niveau du choix du langage de programmation, nous avons le choix entre Java (car il est déjà présent sur les machines) et l ensemble des langages compilés. En effet, les langages entièrement compilés représentent un excellent choix car ils peuvent sans souci être compilés sur une machine de développement puis déployés et exploités sur les machines cibles, évitant dès lors un processus d installation fastidieux. Java ayant une très bonne documentation et étant très largement répandu, ce langage a été choisi pour coder le projet, notamment pour des coûts de maintenance et de développement. Comme expliqué précédemment, le programme devra stocker et gérer un grand nombre de données. Il est naturellement venu à l esprit d employer un système de base de données pour s occuper de cette problématique. Le système de base de donnée relationnelle Oracle étant déjà présent sur les machines et ne présentant pas d inconvénients majeurs, nous emploierons celui-ci. 28

29 3.3.3 Fonctionnement et analyse temporelle Le système de monitoring sera donc un logiciel Java conçu lors de ce mémoire couplé à une base de donnée Oracle permettant de stocker les informations et de les exploiter par la suite. Dans une optique d impact minimum, les machines à monitorer devront uniquement se contenter d exécuter le logiciel de monitoring Windows afin de produire les fichiers contenant les données. Une fois par jour, toutes les données seront rapatriées automatiquement sur un serveur central par le biais de traitements batch 2 sur une machine administrateur. Cette machine administrateur exécute alors le programme en vue d insérer le contenu des fichiers dans la base de donnée. Cette machine administrateur est donc la seule à exécuter le logiciel. De manière générale, l instant où les mesures seront prises ne devra jamais être une heure juste car certains événements peuvent avoir lieux dans ces moments là. Par example, un problème peut avoir lieu si la mesure est prise à 20 :00 car il est alors possible qu un roulement du personnel ou l exécution d un nouvelle tâche ait lieu en même temps. Comme dans beaucoup d entreprises, les ordinateurs effectuent différentes actions pendant la nuit. Ainsi, à un moment où la charge des machines est minimale, celles ci sont amenées à faire une sauvegarde de toutes leurs données ainsi qu une suppression des données trop anciennes. pour illustrer ces propos, un schéma de l exécution temporelle est fourni à la figure Structure de la base de données Pour pouvoir pleinement exploiter les différentes fonctionnalités que propose Oracle, un nouveau schéma contenant des tables, de même qu un nouvel utilisateur ont été créé. Notons que dans Oracle, un schéma définit toujours un utilisateur : ces deux éléments sont indissociables. La figure 3.5 représente un diagramme entité-relation reprenant un certain nombre de tables. Au centre du diagramme se trouve la table MACHINE qui reprend toutes les machines. Les attributs de cette table sont les dates de mise en fonctionnement et d arrêt des machines ainsi que leur nom. De plus, chaque machine possède un attribut MACHINE ID (différent de l ID), cet attribut permet de pouvoir prendre en compte le renommage de machines. Dès lors, un ordinateur nommé A peut être renommé B sans que cela ne pose de problèmes de références. Dans ce cas, une deuxième entrée sera créée dans la table MACHINE avec le nom B et un MACHINE ID égal à celui de A. Cette implémentation permet de conserver efficacement les données historiques des différentes machine, y-compris lorsqu elle ont été ré-affectées à d autres fonctions. Une fois la table MACHINE définie, nous pouvons décrire les autres tables qui y sont reliées. Ces dernières représentent les différentes métriques observées. Ces tables sont toutes semblables et sont composées d un ID, d une métrique portant le nom de la table, le moment où la mesure a été prise ainsi que la machine sur laquelle elle a 2. Fichiers batch : noms donnés aux fichiers contenant des scripts interprétés par l interpréteur de commandes MS-DOS. Ceux-ci ont généralement l extension.bat 29

30 Figure 3.4 Schéma de l exécution temporelle du logiciel développé. été prise. Le moment de la mesure sera enregistré comme une chaîne de caractères de longueur 16 correspondant au format aaaammjjhhmmssrr où RR représente le décalage horaire et peut prendre trois valeurs différentes RD (pour Roman Daylight Saving qui indique une heure d été), RS (pour Roman Standard et indique une heure d hiver) et?? si l information est inconnue. Ce codage de la date permet d uniformiser le logiciel développé avec Intergraph, qui emploie également un tel format. Afin de garantir au mieux l intégrité des données, une contrainte d unicité a été rajoutée sur ces tables afin d empêcher l insertion d une entrée dans une table si une mesure a déjà été prise à ce moment là sur cette même machine. Les trois dernières tables (TRANSLATION,DEF et LOG) ne sont quant à elles pas rattachées à la table MACHINE et ont des rôles très différents des tables stockant des métriques. La table TRANSLATION permet de créer un alias pour les noms des tables contenant des métriques. Ceci est particulièrement utile lorsque les noms donnés par défaut sous Windows sont trop longs pour constituer un nom de table Oracle valide ou alors ne sont pas suffisamment explicites. De plus, un champ description permet d expliquer la métrique. La table DEF permet de mieux définir les tables concernant les métriques. On y retrouve les unités (octets, Mo/s, nombre de processus,...) et le type de variable employé (entiers, nombre à virgule ou chaîne de caractère) par la métrique TABLE NAME. On y retrouve également le minimum et le maximum autorisé par cette métrique, ainsi que les seuils critiques et qu un booléen sous forme de nombre (1 correspondant à vrai et 0 30

31 Figure 3.5 Schéma de la base de données Oracle. à faux). Ce dernier permet de savoir si une valeur élevée de la métrique est préférable. Garder un booléen sous forme de nombre permet de pouvoir facilement effectuer des opérations arithmétiques sur ce nombre et de pouvoir expliciter des conditions sous forme mathématique plus facilement que sous forme booléenne. Finalement, la table LOG permet de stocker les alertes créées lorsque une anomalie sur les données a été détectée. Le point anormal sera référencé via la table dans laquelle il se trouve (TABLE NAME), ainsi que par son ID (POINT ID). L attribut LOG permet de mettre un commentaire approprié associé au dépassement des seuils. Comme le montre le diagramme de la figure 3.6, une solution alternative est également possible. Cette solution consisterait en la mise en place d une unique table contenant toutes les métriques. Le problème de cette solution est que toutes les mesures sont uniquement stockées dans une seule table. Le volume de cette table augmenterait alors très rapidement et pourrait affecter les temps de réponse de manière significative Arborescence des fichiers Lors du développement, certains choix ont été posés concernant l arborescence des fichiers sur la machine se chargeant de l insertion et de l analyse des données. L ensemble 31

32 Figure 3.6 Diagramme d une solution alternative pour un schéma Oracle avec une unique table contenant toutes les métriques. du logiciel a été découpé en trois parties distinctes : la partie concernant les fichiers batch, celle concernant l exécution proprement dite du programme, et celle concernant les fichiers de données. Ces trois parties peuvent être séparées mais leur arborescence interne doit être maintenue. Comme indiqué à la figure 3.7, il y a trois batch à exécuter de manière périodique. Il y a un script de copie de fichiers se trouvant sur une machine distante. Un script servant à faire des insertions dans la base de données, et finalement un batch gérant les sauvegardes des fichiers de données. Figure 3.7 Arborescence des fichiers : partie batch. Comme indiqué à la figure 3.8, où l on peut voir la partie concernant l application proprement dite, on retrouve un dossier avec les sources du programme, un dossier concernant les fichiers.class nécessaires à l exécution et un dossier concernant des ressources utiles. Parmi ces ressources on peut trouver un fichier permettant de se connecter à la base de données Oracle (ojdbc5.jar) et deux fichiers permettant de facilement générer des graphiques (jfreechart jar et jcommon jar). On retrouvera également une librairie permettant la génération de fichiers PDF (itext jar). Dans cette arbores- 32

33 cence se trouvent aussi d autres fichiers servant de log en cas de souci et un fichier de configuration. Figure 3.8 Arborescence des fichiers : partie programme. Concernant les fichiers de données, on peut tout d abord noter une division en répertoires selon les différentes machines. Ensuite, on a une subdivision en trois autres sous-parties : Une partie DATA qui contient simplement les données et dans laquelle chaque fichier a un nom unique grâce à un timestamp contenu dans son nom. Une partie BACKUP qui contient les sauvegardes des données faites avant toute tentative d insertion. Un répertoire RESULT contient les résultats des tentatives d insertions. On reprendra alors le nom du fichier faisant l objet d une tentative d insertion où préfixe FAIL en cas d échec et DONE dans le cas contraire. Le nom ainsi obtenu servira à nommer un nouveau fichier indiquant la réussite de l insertion en cas de réussite et contiendra des informations permettant de situer le problème en cas d échec. La création d un nouveau fichier permet de ne pas toucher aux fichiers contenant les données afin de s assurer de leur intégrité. 33

34 Figure 3.9 Arborescence des fichiers : partie données. 3.4 Automatisation et problèmes inhérents Métriques et fréquence d échantillonnage Lors d un monitoring de système, il est toujours important de définir ce que l on va monitorer et à quelle fréquence. Comme expliqué précédemment, nous aurons deux types de métriques : celles proposées par le logiciel Windows et celles contenues dans des fichiers personnalisés. Tenir compte de ces différents types de métriques permet de proposer un large choix de métriques grâce au logiciel Windows et d avoir des moyens pour monitorer des métriques un peu moins courantes. Dans le cas de ce mémoire, les métriques observées via Windows sont restées très classiques. Nous avons opté pour un monitoring de la mémoire vive disponible, le pourcentage du processeur disponible, le nombre de processus dans le système, l espace restant sur le disque dur ainsi que le nombre d octets envoyés et reçus par une machine se trouvant sur le réseau. Le serveur étant relativement stable, les mesures ne seront prises que toutes les deux heures. Finalement, l ajout de scripts personnalisés nous permet ici d insérer dans la base de données les tailles des différentes tables. Grâce à cela, il est facile d observer l augmentation de la taille des tables avant que celles-ci ne remplissent tout l espace qui leur est alloué. Enfin, il a fallu établir une fréquence d échantillonnage correcte pour la récupération de ces données. Afin de réduire le nombre d échantillons sans sacrifier la qualité des données, nous avons étudié la dégradation des informations collectées à différentes fréquences. Il a ainsi été observé empiriquement qu il n était pas nécessaire d imposer une fréquence plus importante qu une fois par heure. Cette analyse de la fréquence d échantillonnage a été fournie par Intergraph. 34

35 3.4.2 Fichiers de logging Comme expliqué lors de l analyse de l exécution temporelle, les données contenues dans un fichier plat vont être insérées dans la base de données durant la nuit. Effectuer cette opération à ce moment permet d alléger la charge du système aux moments de faible disponibilité du serveur. Cependant, à cette heure, peu d opérateurs de maintenance se trouvent encore sur place et peuvent s employer à corriger les erreurs (dans les rares cas où elles se produisent). Dès lors, le programme, s il rencontre une erreur la notifiera dans un fichier de log et continuera son exécution. Un effort particulier a été apporté au logiciel afin que ce dernier puisse continuer son activité dans un maximum de cas sans pertes de données. Ainsi, pour plupart des erreurs, une notification sera produite. 3.5 Design patterns employés Comme expliqué précédemment, avoir un programme robuste est un point très important. Dans ce but, certains design pattern ont été introduits. Ces design pattern sont présentés ici avec leur contexte et leur utilité dans le cadre de ce mémoire Modèle-Vue-Contrôleur ou MVC Ce design pattern est la base de nombreux programmes. Le principe est de diviser le logiciel en différentes parties : le modèle qui représente le centre du programme, gère les données et les différentes opérations possibles sur ces données. La vue permet de gérer la présentation et l interface utilisateur tandis que le contrôleur permet de faire le lien entre la vue et le modèle. Ce pattern explique la manière dont sont reliées les différentes parties. Le modèle ne doit pas avoir connaissance de la vue afin que ce dernier soit réellement indépendant de la vue Singleton Ce pattern propose une méthode permettant de limiter le nombre d instances d une classe à un seul objet. Pour arriver à cela, le constructeur a été modifié de manière à créer une nouvelle instance seulement dans le cas où il n y a actuellement aucune instance. Dans le cas contraire, au lieu de renvoyer une nouvelle instance, la classe renverra l instance existante. Dans ce cadre-ci, la classe singleton se trouve être la classe du Gestionnaire de base de données. Ainsi, l objet ne sera initialisé qu une seule fois et gardera une et une seule connexion à la base de données. 35

36 3.6 Diagramme de classes Afin de fournir une vue d ensemble du programme, un diagramme de classes est repris à la figure Cette dernière met en évidence les relations entre les différentes classes constituant le projet. Pour des raisons de place, les différents attributs et méthodes des classes ne sont pas représentés. Figure 3.10 Diagramme de classe UML. 3.7 Gestion des avertissements Le programme doit pouvoir envoyer des avertissements (warnings) à l utilisateur si la mesure dépasse un certain seuil critique ou est aberrante. Les avertissements ainsi fournis doivent être enregistrés dans la base de données afin de faire l objet d un rapport. Ainsi, une table est dédicacée au stockage de ces avertissements. Il s agit de la table des LOG s. Cette table reprend de manière assez naturelle les éléments suivants. Le nom de la table dans laquelle a été prise la mesure. L identifiant de cette mesure dans sa table native. Un message d erreur explicite. Un boolean permettant de savoir si l utilisateur à déjà pris connaissance de l anomalie. Un boolean permettant de ne pas tenir compte de la mesure lors d une prédiction. La gestion des avertissements se passe en deux parties : la détection et l édition. La détection peut se faire sur l ensemble des données ou seulement sur les données recueillies pendant le mois. Ceci permet de réduire la charge de la machine en évitant le travail 36

37 inutile. Lors de cette étape de détection, deux types d avertissement sont produits : le dépassement d un seuil critique (par exemple lorsque le disque dur est rempli à plus de 90%) et le dépassement d un maximum physique (CPU occupé à plus de 100%). La partie édition permet d éditer en toute simplicité les différents attributs de la table LOG afin d indiquer au logiciel si la valeur doit être prise en compte pour les prédictions. En effet, lors de prédictions, on aimerait ne pas prendre en compte certaines données faussées (notamment à cause d incidents). 3.8 Analyse des fichiers textes Au moment de l insertion, des fichiers texte sont lus par le programme. Ce dernier en retire des informations qu il présente alors sous la forme de requêtes SQL d insertion. Dans un premier temps, nous analyserons comment il a été possible de faire une traduction pour les fichiers générés par Windows, puis comment ce système a été transposé à d autres fichiers. Comme présenté ci-dessous, Windows organise les fichiers qu il génère de manière humainement. Une première ligne comprendra les différentes entêtes alors que les lignes suivantes reprendront les différentes mesures. Finalement, on peut encore noter que le nom de la machine apparait directement dans ce fichier et que les différents éléments du fichier texte sont isolés à l aide de guillemets et sont séparés par des tabulations. Pour plus de facilité, une numérotation des lignes est fournie pour la figure ci-dessous. 1: "(PDH-TSV 4.0) (Paris, Madrid)" "\\Machine_name\Mémoire\Mégaoctets disponibles" "\\Machine_name\Système\Processus" 2: "12/01/ :04:31.676" "1639" "96" 3: "12/01/ :04:32.676" "1640" "97" 4: "12/01/ :04:33.676" "1641" "98" Connaissant la structure du fichier texte contenant les données, il a été facile de générer les requêtes SQL d insertions correspondantes. Dans un premier temps, le logiciel analyse la ligne d entête, récupère le nom de la machine. Dans un second temps, le programme enlève le nom de la machine du nom de la métrique et associe à chaque colonne le nom d une métrique en se servant de la table TRANSLATION. Cette table se comporte comme un dictionnaire et remplace alors \\Mémoire\\Mégaoctets disponibles par AVAILABLE RAM qui est plus compréhensible. Une fois ce travail d analyse de l entête effectué, il suffit alors de sélectionner les lignes suivantes une par une et de les analyser. À ce stade, il ne reste plus qu a séparer les différents champs constituant une ligne et de les associer à l entête. Si l on considère que la machine Machine name a reçu l identifiant numéro 7, le fichier présenté ci-dessus produira alors les requêtes suivantes. INSERT INTO AVAILABLE_RAM(TIME, AVAILABLE_RAM, MACHINE_ID) VALUES( ??,1639, 7); 37

38 INSERT INTO PROCESSUS_NUMBER(TIME, AVAILABLE_RAM, MACHINE_ID) VALUES( ??,96, 7); INSERT INTO AVAILABLE_RAM(TIME, AVAILABLE_RAM, MACHINE_ID) VALUES( ??,1640, 7); INSERT INTO PRECESSUS_NUMBER(TIME, AVAILABLE_RAM, MACHINE_ID) VALUES( ??,97, 7); INSERT INTO AVAILABLE_RAM(TIME, AVAILABLE_RAM, MACHINE_ID) VALUES( ??,1641, 7); INSERT INTO PROCESSUS_NUMBER(TIME, AVAILABLE_RAM, MACHINE_ID) VALUES( ??,98, 7); Finalement, il a été précisé que certains fichiers textes résultant de scripts personnalisés devraient également être analysés pour alors insérer des entrées dans la base de données. Comme le montre l exemple ci-dessous, la structure diffère de celle d un fichier généré par Windows. De plus, les valeurs rondes étant la taille totale, ces dernières ne seront pas considérées comme intéressantes RD CAD CAD_INDEX DBM RD CAD CAD_INDEX DBM RD CAD La solution choisie a été de convertir le fichier personnalisé pour le mettre sous la forme de fichier Windows. Dans un premier temps, il suffit de séparer le fichier en utilisant les lignes de tirets comme séparateur. Ensuite, il ne suffit plus de que diviser ce qui reste en tokens : le premier correspondant à la date, le deuxième étant une entête et le troisième étant la valeur associé à cet entête. Finalement, il ne suffit plus que de rassembler le tout en un seul fichier qui peut alors être inséré dans la base de données de manière équivalente à un fichier Windows. 38

39 3.9 En résumé Nous avons donc établi les infrastructures employées ainsi que les justifications de ces différents choix. Ainsi, nous avons opté pour Java comme langage d implémentation du logiciel, notamment en raison de la présence d une JVM sur les machines cibles. Oracle a été sélectionné comme base de données, choisi également pour sa présence sur site. De plus, l exécution temporelle, la structure de la base de données et du programme ont été abordés. 39

40 Chapitre 4 Résultats 4.1 Installation Le logiciel produit peut très facilement s installer sur les machines cibles car cellesci possèdent déjà tout les programmes requis. Un grand soin a été apporté à ce niveau pour automatiser un maximum la procédure d installation, notamment en privilégiant au maximum l emploi de scripts. Pour plus d informations, un guide d installation détaillé est disponible en annexe. 4.2 Analyse des ressources nécessaires Ressources logicielles Les ressources logicielles nécessaires sont : Windows NT4 ou supérieur Java (version 6, update 30) ou supérieur. Système de base de données Oracle ojdb5.jar permettant à un programme écrit en java de se connecter à une base de données oracle jfreechart jar et jcommon jar permettant de créer des graphiques itext jar permettant de générer des fichiers au format PDF Ressources matérielles Mémoire sur disque dur Nous allons ici proposer une estimation de l espace disque nécessaire. Dans un premier temps, nous analyserons la taille nécessaire sur la machine exécutant le logiciel, puis nous évaluerons la taille du schéma Oracle. Dans le cas de l analyse reprenant le logiciel, nous nous baserons principalement sur les figures 3.7, 3.8 et 3.9 reprenant l arborescence des fichiers. Ainsi, la partie contenant les 40

41 fichiers batch peut être considérée comme négligeable, car elle ne contient que quelque Ko de données. La partie contenant les exécutables reste également très légère et ne demande que 5 Mo, principalement employés par les ressources.jar. La partie concernant les fichiers de données dépend évidement du nombre de métriques et du nombre de machines. Dans un premier temps, on peut voir expérimentalement que le poids moyen d une métrique personnalisé comprenant les données d une journée est de 500 octets. Une taille moyenne pour une métrique Windows est de 250 octets. La taille totale des fichiers sera alors de N[D(P.500octets+W.250octets)], P étant le nombre de métriques personnalisées et W le nombre de métrique Windows. P étant le nombre de jours durant lesquels les données sont conservées. Si l on a 20 machines avec 8 métriques personnalisées et 6 métriques fournies via Windows, et que ces données sont conservées durant sept jours, nous arrivons alors à une taille totale de 770 Ko. Au final, on peut sans souci exécuter l ensemble du programme avec seulement quelques Mo en mémoire. Cet espace est alors occupé sur le serveur chargé des insertions. Cependant, si ces quelques Mo satisferont à la machine servant à faire une insertion, le serveur Orale conservera l entièreté des données recueillies depuis le début du fonctionnement. Nous allons ici analyser la place en mémoire supplémentaire nécessaire chaque mois sur la base de donnée Oracle. Nous allons donc nous baser ici sur la figure 3.5 qui reprend la structures des tables Oracle. Ainsi, au fil du temps l ensemble des insertions se fera uniquement sur les tables comprenant des métriques et la table des log reprenant les avertissements. Une entrée dans la table des métriques est constituée d un identifiant (INTEGER), d un timestamp (VARCHAR(16)) d un numéro de machine (INTEGER) et d une valeur de la métrique (FLOAT ou INTEGER). La taille d un float est de maximum 22 octets, celle d un entier est de maximum 5 octets et celle de d un VARCHAR(16) est de 16 octets. La taille maximale d une entrée étant alors de 43 octets. Par mois, une entrée sera rentrée par heure par machine. Au bout d un mois, la taille d une table atteint alors 15Ko( octets) pour une seule machine. La taille totale de métriques peut être évalué comme étant le nombre de machines multiplié par le nombre de tables multiplié par 15 Ko. avec 20 machines et 15 métriques, on aurait alors une taille approximative de 60 Mo. À cette taille s ajoute encore les différents indexes. Cependant,ceux-ci ont été négligés lors des calculs. Autres ressources Comme vu précédemment, le programme n emploie que très peu de ressources. Cependant, certaines ressources seront tout de même employées. Ainsi, le programme utilisera des ressources lors de son fonctionnement. Les ressources employées sont alors les suivantes. Mémoire vive De la mémoire vive devra être allouée à ce programme pour qu il puisse fonctionner correctement. Le maximum que le programme puisse charger en mémoire est l ensemble des exécutables ainsi que les fichiers de données à insérer. Comme vu précédemment, cela constitue moins de 10 Mo, ce qui est négligeable pour les machines. CPU De la même manière que la RAM, le CPU devra également être employé mais ceci n impactera pas les performances des autres services. 41

42 Ressources Oracle. Les données générées doivent à un moment transiter de la machine qui les traite à un serveur Oracle en passant par le réseau. Cependant envoyer 60 Mo en un an ne semble pas constituer un impact important pour les ordinateurs actuels. Finalement, on peut se rendre compte que l on a réellement un impact minimal sur le système. Cependant, l impact a encore été diminué en plaçant les insertions lors d un creux d activité. 4.3 Guide d utilisation Le programme peut être lancé en mode console ou en mode graphique selon les envies de l utilisateur. Le mode console dispose d une aide qui s affiche lorsque l utilisateur essaye d exécuter le programme avec une syntaxe erronée. Le démarrage graphique du programme est accessible en exécutant le programme sans option. Cependant, il est toutefois nécessaire d indiquer au programme où se situent les ressources nécessaires à son exécution. Ceci passant par l option -cp suivi de toutes les ressources séparées par des ;. Ainsi, l exécution passe par la commande suivante. java -cp bin;jars\jcommon jar;jars\jfreechart jar; JARs\ojdbc5.jar;JARs\iText jar Main Dans ce document, la commande qui précède sera désormais reprise comme : java memoire Guide console Pour insérer des fichiers générés par Windows en mode console, il suffit de préciser au programme qu il s agit d une insertion(-i) de fichier générés par Windows(-w) puis d indiquer le chemin vers un répertoire contenant les fichiers adéquats. java memoire -i -w FolderPath L insertion d un fichier de type tablespace se passe d une façon identique. Il faut à nouveau préciser au programme qu il s agit d une insertion(-i) d un fichier de type tablespace(-t) puis fournir un répertoire contenant les fichiers tablespace ainsi que le nom de la machine concernée. java memoire -i -t FolderPath MachineName Il es également possible de parcourir les données à la recherche de nouveaux avertissements. Pour alléger la charge des machines, il est possible de parcourir les données âgées de moins de 24 heures, de moins d un mois, ou encore de vérifier l intégralité des données. java memoire -checkday java memoire -checkmonth java memoire -checkall 42

43 4.3.2 Guide graphique Comme expliqué précédemment, pour démarrer l interface graphique, il suffit d exécuter la commande suivante. java memoire Une fois la commande lancée, une première fenêtre de login apparait (figure 4.1). Une entrée manuelle des paramètres est possible ainsi qu un chargement automatique des bonnes entrées (en appuyant sur Get connection ). Pour que cette fonctionnalité soit opérationnelle, il faut alors configurer correctement le fichier config.txt. On peut noter que ce dernier doit être configuré pour pouvoir exécuter les différentes opérations en mode console. Finalement, il suffit de cliquer sur Connect pour se connecter. Figure 4.1 Aperçu du logiciel développé : fenêtre de connexion. Une fois que le programme est connecté à la base de données, ce dernier affiche le menu principal du programme et invite l utilisateur à charger une des fenêtre suivantes. Outil d insertion manuel (Insertion Tool) Outil de visualisation des données (Visualisation Tool) Outil de vérification des données (Check Data) Outil de gestion des avertissements (Data Warning) Outil de création de rapport (Reporting Tool) Le logiciel informe également l utilisateur des soucis qui auraient pu apparaitre lors d une insertion antérieure (Insertion(s) Warning(s)). Le détail des soucis est stocké dans le fichier insertionerror.txt. Pour remettre le compte d erreur à zéro, il suffit de supprimer le contenu du fichier. Finalement, le logiciel dénombre les avertissements non-lus (warning points). Il est possible de les éditer dans la fenêtre de gestion des avertissements. La fenêtre d insertion manuelle est simple à employer. Il suffit de choisir un fichier contenant des données ainsi que le type de ces dernières et le nom de la machine si nécessaire puis d appuyer sur le bouton Insert. Pour revenir au menu principal, il suffit alors de cliquer sur le bouton Main. La figure 4.2 propose un aperçu de cette fenêtre. La fenêtre suivante représentée à la figure 4.3 est celle permettant une visualisation (Visualisation Window). On peut voir que la fenêtre est divisée en plusieurs parties : le partie supérieure permet de choisir l élément à afficher. Il faut donc alors choisir une métrique et une machine. 43

44 Figure 4.2 Aperçu du logiciel développé : fenêtre d insertion. La partie inférieure permet d afficher (Draw) la métrique choisie dans la partie centrale. Il est possible de restreindre l affichage de cette métrique en cochant les boites. Comme convenu, les dates doivent être entrées au format yyyymmddhhmmss. La partie de gauche permet d entrer une requête manuellement qui sera alors affichée si la réponse de la requête est une liste de nombres chacun associé à une date. Finalement, la partie de droite consiste en un module d analyse. Il est possible de fixer un intervalle de temps sur lequel seront analysées différentes choses. On retrouvera ainsi, le calcul de la moyenne, un écart type, le minimum et le maximum sur l intervalle sélectionné et la pente de la droite de régression. Toujours dans cette même partie, le programme rappellera les seuils critiques fixés et indiquera, sur base de la droite de régression, une date à laquelle le seuil serait atteint. De plus, une droite de régression apparaitra alors sur le graphique ainsi que deux points permettant de prendre connaissance des limites fixées pour l analyse. La fenêtre permettant de rechercher des avertissements est très simple à employer et très intuitive. Cette fenêtre est présentée à la figure 4.4. Le bouton check it permet de démarrer une recherche des avertissements selon le mode indiqué sur la liste déroulante. Cette dernière propose une recherche parmi les éléments entrés le jour même, le mois ou alors sans restrictions. La fenêtre suivante que nous analyserons est la fenêtre de gestion des avertissements. Le bouton LoadAll permet de charger tous les avertissements. Comme le montre la figure 4.5, un commentaire explicite concernant un point faisant l objet d un avertissement est affiché. Il est possible de modifier ce commentaire. Il est également possible de ne pas tenir compte de ce point lors d une régression linéaire si l attribut exclude this point est coché. Finalement, l outil n affichera pas les avertissements déjà lus tandis que les avertissements non-lus continueront de réapparaître. De manière assez logique le bouton apply applique les modifications demandées, tandis que les boutons next et previous permettent de passer d un message à l autre. Pour finir, nous pouvons noter que chaque mesure n aura au maximum qu un seul avertissement. Ce dernier sera l avertissement ayant le niveau de criticalité le plus élevé. 44

45 Figure 4.3 Aperçu du logiciel développé : fenêtre de visualisation. Figure 4.4 Aperçu du logiciel développé : fenêtre de recherche des avertissements. La dernière fenêtre est celle permettant de générer des rapports. Il faut entrer un chemin correct où les fichiers seront générés. Il faut également fournir le nom du site, ainsi qu une date de début et de fin d activité. Finalement, un rapport d activité reprenant toutes les mesures sera généré au format PDF et texte. Un rapport des avertissements sera également fourni dans les mêmes formats. Ces rapports des avertissement reprendront l ensemble des avertissements. Finalement, un exemple pour chaque type de rapport sera fourni en annexe. 4.4 Intérêt du logiciel Le logiciel a d ores et déjà permis d identifier un souci qui n était pas facilement identifiable avec l ancien outil Excel reprenant les différentes mesures. La fonctionnalité ayant permis cette performance est la fonction de mise à l échelle d un graphique permettant de choisir un intervalle de temps à visualiser. En effet, la figure 4.7 met en évidence une forte diminution de la métrique dénotant un problème entre février et août 2011, suivi d une stabilisation apparente indiquant une résolution du problème. 45

46 Figure 4.5 Aperçu du logiciel développé : fenêtre de gestion des avertissements. Figure 4.6 Aperçu du logiciel développé : fenêtre de création de rapport. Cependant, cette stabilisation n est qu apparente car en effectuant un zoom sur cette partie, on peut facilement voir que les observations continuent toujours à baisser. Cet effet a pu être mis en évidence grâce au logiciel développé. La figure 4.8 permet de voir le zoom sur la partie concernée. En réalité, la baisse de l espace disque était dûe à un fichier log (extérieur au programme) qui n était jamais effacé et continuait ainsi de remplir le disque. Finalement, grâce aux fonctions d analyse, on peut mesurer cette faible décroissance et avoir une estimation de la date où la métrique dépassera le seuil critique. La figure 4.9 montre la baisse d espace disque et établit qu une diminution de l ordre de 21 Mo par jour a lieu durant cette période. Cette figure montre également que le dépassement du premier seuil (fixé à 65 Go) est prévu pour le 5 mai Conclusion Après ces descriptions, nous pouvons donc observer que le logiciel répond bien à tous les critères et contraintes. Ainsi, l installation peut se faire facilement, le logiciel est pleinement utilisable et permet d enregistrer des données dans une base de données, de fournir des analyses mais dispose également d un système de gestion des avertissements efficace et d un outil permettant la génération de rapports. En plus de cela, le logiciel a 46

47 Figure 4.7 Intérêt du logiciel : stabilisation apparente de la métrique. déjà eu l occasion de montrer son efficacité en permettant de trouver un souci ne s étant pas encore manifesté sous la forme d incident ou de problème. Cet outil est donc un produit pleinement abouti et fonctionnel. 47

48 Figure 4.8 Intérêt du logiciel : mise en lumière d une faible décroissance. Figure 4.9 Intérêt du logiciel : estimation d un dépassement de seuil. 48

49 Chapitre 5 Conclusion 5.1 Bilan sur le travail accompli Avant le développement du logiciel, les opérateurs de maintenance avaient développé un mini-programme en Excel. Ces derniers devaient alors entrer manuellement toutes les données générées par les ordinateurs. Cette tâche, bien qu à la base déjà ardue et source d erreurs multiples, est alors devenue presque impossible lorsque le volume de données a augmenté au fil des ans. Ainsi l ouverture du fichier Excel prenait plus de temps que le démarrage de l ordinateur et même tracer des graphiques devenait alors une tâche lourde en ressources. À ce stade, monitorer le système informatique était donc devenu particulièrement compliqué, lent et fastidieux. De plus, les résultat obtenus ne permettaient pas toujours de prouver que le service de maintenance préventive était correctement géré. Développer le programme a donc permis aux opérateurs de maintenance de pouvoir monitorer de manière simple et automatique les différentes machines, tout en obtenant des mesures fiables, ces dernières se trouvant en sécurité dans une base de données. Finalement, si l on considère qu un opérateur gagne une demi-heure par jour grâce à ce logiciel (temps non-occupé à gérer la solution Excel), ce programme permet non seulement d économiser du temps de travail et donc beaucoup d argent mais aussi et surtout, l automatisation des tâches redondantes permet de fiabiliser les résultats obtenus. Au final, on peut donc dire que le développement du logiciel est un succès car il correspond à toutes les attentes et satisfait toutes les contraintes. De plus, le logiciel est déjà déployé sur plusieurs sites (CIC) en Belgique et a permis d anticiper certains problèmes graves. 5.2 Perspectives Analyse des données À ce stade, nous disposons de beaucoup de fonctionnalités proposées par des logiciels de monitoring. Cependant, les analyses réalisées sur les données restent relativement 49

50 légères. Ainsi, la détection d anomalie se fait de manière statique en fixant des seuils critiques ainsi que des valeurs minimales et maximales. Une amélioration possible serait de proposer une gestion des anomalies de manière totalement dynamique en complément. Ainsi, il serait possible de détecter une anomalie alors qu aucun seuil n aurait été dépassé. Il suffirait alors de sélectionner une fenêtre temporelle glissante puis d analyser la distribution marginale obtenue pour cette même fenêtre. Cette analyse permettrait alors de trouver les valeurs extrêmes étant potentiellement des anomalies. Cependant, il faudrait alors évaluer l écart entre les points extrêmes et les points normaux afin de vérifier que l écart est réellement suffisant pour constituer une anomalie. La figure 5.1 permet de visualiser le principe de fonctionnement. Les points extrêmes sont d abord repérés pour être ensuite, soit validés (estimés corrects), soit signalés comme anomalies. Figure 5.1 Exemple de distribution marginale inspiré de [4]. Cependant, la méthode décrite ci-dessus est réellement complexe à mettre en œuvre car, outre le fait de devoir définir une taille de fenêtre et un moyen de vérification sur les points suspects, un autre problème se présente : le basculement des services. En effet, pour assurer une disponibilité de service maximale, le matériel et le logiciel ont été dédoublés. Ainsi, une seconde machine peut directement prendre la relève en cas de crash d un service sur une machine. Grâce à cette méthode, il n y aura donc aucune interruption de ce service. Ces basculements sont malheureusement fréquents et peu prévisibles, rendant la tâche complexe car les services dédoublés sollicitent beaucoup de ressources sur les machines hôtes. De plus, ces basculements entraineraient alors des avertissements en chaîne et compliqueraient les règles Articulation avec un logiciel de gestion des incidents Parallèlement à ce travail, un autre mémoire ayant pour titre Système de rapports d incidents conforme aux normes ITIL pour le réseau A.S.T.R.I.D. a été accompli par Ahmed Abdeen. L environnement est identique pour les deux travaux, qui se déroulent au sein d Intergraph. Bien que le mémoire de Ahmed Abdeen constitue un énorme travail ne pouvant être résumé en quelques lignes, nous tâcherons tout de même de fournir une brève description de ce dernier. 50

51 Comme expliqué dans le contexte de ce mémoire, Belgacom fait partie du consortium d entreprises ayant remporté l appel d offre émis par A.S.T.R.I.D. et sous-traite une partie de ses activités à Intergraph. Intergraph ne faisant pas partie de ce consortium, les autres membres n ont pas accès à ses activités. Cependant, un accord sur les niveaux de services (SLA) et les indicateurs de performance clé (KPI) a été négocié. Malgré cela, un désaccord sur les chiffres mesurés a lieu entre les deux sociétés. Malheureusement pour Intergraph, ce dernier n avait pas les moyens de présenter objectivement une contre-expertise et devait alors s acquitter des pénalités, sans possibilité réelle de contestation. Grâce aux études menées par Ahmed Abdeen, Intergraph possède maintenant un logiciel permettant de fournir une contre-expertise. Une perspective intéressante pour ces deux travaux serait alors de mettre en relation les deux outils et de les synchroniser convenablement. Ainsi, une détection d anomalie pourrait être mise en relation avec un incident. Le fait de rassembler les deux outils pourrait alors clairement renforcer la fiabilité des données. De plus, dans le cas d un incident, il serait alors facile de connaitre le temps de résolution associé. 51

52 Bibliographie [1] ASTRID. astrid - architecture réseau. content.aspx?id=492&langtype=1036. [2] ASTRID. ASTRID - astrid en bref. aspx?id=1224&langtype=1036. [3] ASTRID. astrid - le noeud provincial et le centre de dispatching (CIC). http: // [4] Physics Forum. MATLAB : Marginal Distribution Plot. physicsforums.com/showthread.php?t= [5] ITIL France. http :// [6] Office of Government Commerce (OGC). The Official Introduction to the ITIL Service Lifecycle. TSO (The Stationery Office), [7] Cabinet Office. ITIL Continual Service Improvement. TSO (The Stationery Office), [8] Cabinet Office. ITIL Service Design. TSO (The Stationery Office), [9] Cabinet Office. ITIL Service Operation. TSO (The Stationery Office), [10] Cabinet Office. ITIL Service Strategy. TSO (The Stationery Office), [11] Cabinet Office. ITIL Service Transition. TSO (The Stationery Office), [12] TeamQuest. Performance analysis and correlation analysis with TeamQuest View. [13] Wikipédia. Drame du heysel wikipédia, l encyclopédie libre. http: //fr.wikipedia.org/w/index.php?title=drame_du_heysel&oldid= , [En ligne ; Page disponible le 20-avril-2012]. [14] Wikipédia. Herald of free enterprise wikipédia, l encyclopédie libre. http: //fr.wikipedia.org/w/index.php?title=herald_of_free_enterprise&oldid= , [En ligne ; Page disponible le 20-avril-2012]. [15] Wikipédia. Sécurité nationale wikipédia, l encyclopédie libre. wikipedia.org/w/index.php?title=s%c3%a9curit%c3%a9_nationale&oldid= , [En ligne ; Page disponible le 20-avril-2012]. 52

53 Annexe A Requête pour un changement Voici un document type de demande de changement. Dans la littérature, le terme RFC (Request for change)est généralement employé. Par souci d homogénéité, nous l emploierons également dans ce texte. RFC : Installation d un système de monitoring Propriétaire du document M. LeDoux, Change Manager Version 1.0 Date 3 avril 2012 Nom du document RFC :monitoring Partie 1. À compléter par le solliciteur du changement (change requestor) Solliciteur Société téléphone Nicolas Vannieuwerburgh Intergraph Belgium nivnieuwulb.ac.be Explication du RFC en quelques mots Installation d un système de monitoring indépendant pour la société Intergraph. Ceci est une installation pilote et sera uniquement déployé dans le centre de Bruxelles. Domaines concernés Sous-domaines concernés Cocher Sécurité Hardware Software Infrastructure Réseau Hardware Software Trafic X Infrastructure Base de données Hardware Software Infrastructure X Trafic X Volume des données X 53

54 Motif du RFC Nouveauté Amélioration technique Mise à jour Extension ou Add-on Résolution de problème Résolution d incident Projet Autre Cocher X X Priorité Faible : le changement peut attendre la prochaine mise à jour Moyen : doit être effectué à moyen terme Élevé : le plus rapidement possible mais en respectant les procédures Urgent : l implémentation doit commencer immédiatement Cocher X Description détaillée Afin d améliorer le service de maintenance préventive fournie par Intergraph, un outil de monitoring sera déployé sur les différents sites (CIC) en Belgique. Pour plus de détails, voir l ensemble de ce travail. Configuration initiale requise : Le déploiement de l outil de monitoring ne peut se faire que si le site est parfaitement fonctionnel et est correctement paramétré. On suppose que le système d exploitation est de type Windows NT et que l on possède les droits administrateurs dessus. On considère que l on dispose du logiciel Oracle avec la permission de créer un nouvel utilisateur et de créer des tables. Finalement, Java doit également être installé. Plan de déploiement : Faire une sauvegarde complète du système puis suivre le manuel d installation fourni dans ce document. Impact : L impact de ce déploiement est minime. Tous les services resteront opérationnels durant et après le déploiement. Suppression du système de monitoring : Aucune suppression automatique n est prévue. Cependant, un guide de désinstallation est fourni dans ce document. 54

55 Annexe B Guide d installation B.1 Configuration minimale Les pré-requis pour l installation sont les suivants : Disposer d un système informatique où chaque machine à monitorer fonctionne sous Windows (version supérieure ou égal NT4) et avoir des droits administrateur sur chaque machine. Disposer d une base de données Oracle ainsi que des privilèges DBA. Disposer d un environnement d exécution Java (version 6, update 30) ou compatible. Disposer de l ensemble des programmes (comprenant un dossier avec les sources, les exécutables, un dossier avec les ressources Java nécessaires et un dossier servant à l installation). B.2 Configuration de la base de données Oracle Dans cette section, il est expliqué comment créer un nouvel utilisateur associé à un nouveau schéma. L utilisateur devra ainsi disposer des droits de lecture et d écriture dans son schéma. Le plus simple consiste à ouvrir une invite de commande Oracle et d y exécuter les commandes permettant d effectuer cette action. Pour plus de facilité, un script a été prévu pour faciliter cette tâche. B.3 Création des tables de la base de donnée Oracle Pour la création des tables, nous suivrons le même processus, il suffit simplement d exécuter les commandes SQL permettant de créer les tables dans une console Oracle. De même, un script avec un modèle départ est prévu à cet effet. À cette étape, nous disposons maintenant d un schéma comprenant différentes tables mais qui ne sont pas peuplées. Il y a plusieurs types de tables : DEF, TRANSLATION, LOG, MACHINE et toutes les autres tables sont des tables de métriques avec les attributs suivants : TIME qui représente le temps où a été prise la mesure, MACHINE ID qui contient l ID de 55

56 la machine et une champ portant le même nom que le table qui contient la valeur de la mesure. Ainsi, il est aisé de créer ou de supprimer des tables de métriques. Un diagramme entité-relation est fourni dans ce document au chapitre 3. B.4 Configuration des collecteurs de données Windows Nous allons maintenant configurer les collecteurs de données Windows. Cliquez sur Démarrer puis faites un clic-droit sur ordinateur pour choisir l option Gérer. Ensuite, étalez l onglet Performance puis Ensemble des collecteurs de données puis faites un clic-droit sur Définis par l utilisateur puis Nouveau et Ensemble de collecteur de données (figure B.1). Une fenêtre apparaît alors, donnez un nom à ce collecteur et optez pour une création à partir du modèle de votre choix. Vous passez alors sur la seconde fenêtre pour choisir l emplacement où seront temporairement stockés les fichiers contenant les différentes mesures. La troisième et dernière fenêtre apparaît et demande quel sera l utilisateur qui démarrera l application. Laissez la valeur par défaut. Avant de terminer la création du collecteur, veuillez opter pour l ouverture des propriétés. Figure B.1 Création d un nouveau collecteur de données. Vous pouvez commencer par donner une description à ce collecteur de données puis sélectionner l onglet Planification (figure B.2). qui permettra d automatiser le démarrage de l application. Ajoutez alors une planification qui fera démarrer le collecteur de données une fois par jour. Après avoir validé cette action, veuillez sélectionner l onglet Condition d arrêt. Veuillez alors tout décocher à l exception de Redémarrer l ensemble des collecteurs dès qu une limites est atteinte et de Durée qui doit être fixée a un jour (figure B.3). Vous pouvez appliquer les modification puis valider en appuyant sur OK. Un nouveau collecteur de données est maintenant apparu, cliquez dessus, puis faites un clic droit sur Compteur de performance pour visualiser les propriétés (figure B.4). Vous pouvez maintenant choisir les métriques à monitorer en cliquant sur ajouter (figures B.5 et B.6), ainsi que la fréquence d échantillonnage. Cependant, choisir une fréquence d échantillonnage très élevée peut avoir un impact sensible sur les performances de la 56

57 Figure B.2 Onglet planification du collecteur de données. machine. Une fréquence d échantillonnage d une heure est un bon choix dans le cadre d un déploiement sur un CIC. Toujours dans ce même onglet, optez pour un format d enregistrement avec des tabulations comme séparateurs (figure B.7). Dans l onglet fichier, veuillez opter pour un format de nom de type yyyymmddmmss. Vous pouvez appliquer les modifications puis valider en appuyant sur OK. B.5 Peuplement des tables et configuration Pour correctement configurer le contenu des tables Oracle, veuillez démarrer le collecteur de données puis l arrêter. Un nouveau fichier avec des mesures sera alors créé. Il sera utile par la suite. Dans un premier temps, vous devez rajouter des machines dans la table MACHINE, ceci peut se faire en suivant le modèle présenté ci-dessous. INSERT INTO MACHINE(NAME, MACHINE_ID) Values( Vaio,1); Vous pouvez ensuite définir en profondeur une métrique en faisant un ajout dans la table DEF. INSERT INTO DEF(TABLE_NAME, BEGIN_TIME, END_TIME, MACHINE_NAME, MIN, MAX, THRESHOLD1, THRESHOLD2, THRESHOLD3, MAX_IS_BEST, UNIT, PRECISION) Values ( DISK_SPACE_C, ??, ??, HP-HP, 0, , 50000,20000, 30000, 1, Mo, 0.1); voici une brêve description des différents paramètres. 57

58 Figure B.3 Onglet condition d arrêt du collecteur de données. Figure B.4 Propriétés du compteur de performance. TABLE NAME : nom de la métrique. BEGIN TIME : Date de première application de la définition au format yyyymmddmmssrr. END TIME : Date de dernière application de la définition au format yyyymmddmmssrr. MACHINE NAME : Soit le nom d une machine soit ALL. Il s agit de la machine pour laquelle la définition peut être appliquée. Mettre une valeur ALL indique que la définition est valide pour toutes les machines. MIN : Minimum physique que peut prendre la valeur. MAX : Maximum physique que peut prendre la valeur. le minimum est toujours plus petit que le maximum. Régler à la valeur 1 lorsque la métrique présente des signes d anomalies dans les valeurs basses. C est, entre autres, le cas de l espace libre sur un disque : plus la valeur est haute, moins le problème est critique. A l inverse, la criticalité de l utilisation du CPU est directement proportionnelle à son 58

59 Figure B.5 Choix des métriques. taux d utilisation. THRESHOLD1, 2, 3 : représentent la valeur des différents seuils critiques. Atteindre le seuil 2 est considéré comme plus grave qu atteindre le seuil 1. Cependant, le seuil 1 n est pas nécessairement plus grand que le seuil 2. Ainsi dans le cas de l espace libre sur un disque dur, le premier seuil peut être fixé à 80Go et le deuxième seuil à 40Go. MAX IS BEST : est un booléen sous forme d entier. Si avoir une valeur élevée de la métrique est une bonne chose, on indiquera un 1, sinon un 0. UNIT : Représente l unité de la métrique. PRECISION : Représente la précision de la métrique. Ainsi une valeur de 0.1 signifie une précision au dixième près et 0.01 au centième près. Finalement, il ne reste plus qu à faire le lien entre le nom des métriques (et des tables) et le nom que le logiciel de monitoring Windows donne à ces métriques. Pour cela, le plus simple est d exécuter le logiciel fourni dans le package avec une commande similaire à celle-ci, tout en adaptant le path. java -cp bin;jars\jcommon jar;jars\jfreechart jar;jars\ojdbc5.jar; JARs\iText jar Main Une fois que cela est fait, vous arrivez sur un écran d accueil vous demandant des informations de connexion. Veuillez les entrer, puis vous connecter. Veillez à modifier le fichier config.txt qui vous permettra de récupérer ces informations de connexion instantanément depuis le programme Java lors d une utilisation future, ou même de rendre possible une connexion automatisée indispensable au bon fonctionnement du logiciel. Une fois la connexion établie, vous arrivez sur la fenêtre principale du programme. Cliquez alors sur Insertion Window et essayer d insérer le fichier contenant les mesures précédemment obtenues. 59

60 Figure B.6 Onglet Compteur de performance des propriétés du compteur de performance. Un message explicite indiquera alors que la table XXXXXXX est inexistante. Vérifiez alors que la table XXXXXXX existe, puis rajoutez une entrée dans la table TRANSLATION en vous servant du modèle de requête suivant. INSERT INTO TRANSLATION(WIN_RESOURCE_NAME, RESOURCE_NAME, DESCRIPTION )Values ( Disque_logique_C: Megaoctets_libres, DISK_SPACE_C, Megaoctects libres sur le disque C ); La table TRANSLATION se charge de faire la liaison entre le nom des tables et le nom que le logiciel de monitoring Windows donne à ses mesures. Il faut donc configurer cette table afin que toutes les mesures soient opérationnelles. B.6 Automatisation À ce moment, tous les services proposés par le logiciel devraient être opérationnels à l exception de l insertion automatique dans la base de données. Pour finir l installation, il suffit de configurer les scripts fournis avec le logiciel (copy.bat, insert.bat et upgrade.bat) et de planifier le lancement de ces scripts. 60

61 Figure B.7 Onglet Fichiers des propriétés du compteur de performance. 61

62 Annexe C Documentation des erreurs Voici, un guide des erreurs les plus courantes. Cette partie est à consulter en cas de problème. Ces erreurs résultent non pas d un dysfonctionnement de l application mais bien du traitement par l application de circonstances qui requièrent l intervention d un administrateur. C.1 Erreurs générales Il se peut qu il y ait des erreurs au niveau de la création ou de l écriture dans certains fichiers. Les deux causes les plus probables sont : Il n y a plus d espace libre sur le disque. Il faut alors en libérer L application n a pas les droits suffisants pour écrire ou créer le fichier. Il faut alors donner les droits idoine au programme pour qu il puisse effectuer ces actions. C.2 Erreurs de connexion Il se peut qu il se produise une erreur de connexion à la base de données. Il suffit dès lors de remplir correctement le document config.txt selon le modèle fourni. Il sera impossible de se connecter à la base de données si le le serveur Oracle n est pas actif. Cette erreur concerne plus les tests sur laptop où les services Oracle ne sont pas toujours en cours d exécution. Après un certain temps, Oracle peut demander de changer le mot de passe de l utilisateur. Il s agit là d une politique de sécurité. Pour s en apercevoir, il suffit d exécuter la commande sqlplus (qui ouvre un client Oracle) puis d entrer les identifiants. Un message apparaitra, vous invitant à changer votre mot de passe. C.3 Erreurs d insertion Dans certains cas, des erreurs peuvent survenir lors de l insertion de données dans la base de données. La principale erreur observée est de type java.sql.sqlexception : 62

63 ORA : unique constraint (MAINT.TS CAD UNIQUE) violated. Cette erreur veut tout simplement dire que l utilisateur MAINT a essayé d effectuer une action qui enfreindrait la règle TS CAD UNIQUE définie lors de la création de la table. Ceci peut se produire lors d une insertion manuelle et est généralement dû au fait que la valeur à tout simplement déjà été insérée dans table. C.4 Erreurs lors de la visualisation Une fois dans la fenêtre de visualisation, il est possible d entrer une requête personnalisée. Comme indiqué, la réponse attendue à cette requête est une valeur entière ou à virgule, suivi d un temps sous la forme d une chaîne de caractères au format YYYYMMD- DHHmmss. Si la requête n est pas valide, un message d erreur s affiche. On peut noter une faille de sécurité permettant à une personne mal intentionnée d attaquer la base de données avec des attaques de type injection de SQL. On ne prend pas en compte ce risque d attaque et ce, pour plusieurs raisons : premièrement, le logiciel ne fournit aucune analyse de sécurité car cela n est tout simplement pas prévu ni même demandé. Deuxièmement, seuls les personnes autorisées ont accès aux machines ou ce logiciel est installé. Dans la fenêtre de visualisation, une date où les différents seuils critiques seraient atteints est calculée comme étant l intersection entre la droite de régression y = ax + b et la droite du seuil y = c. En faisant ainsi, il est possible que le logiciel indique que la limite a été atteinte à une date antérieure. Cette date provient tout simplement de la résolution du système initial. On notera également que les dates sont bornées inférieurement à C.5 Erreurs de gestion des logs Dans la fenêtre de gestion des logs, il est possible de modifier les logs associés aux différentes mesures. Cependant, certains caractères vont être changés afin de pouvoir correctement gérer les expressions SQL. De cette manière, la simple quote ou apostrophe se transformera en caractère d espacement afin de pouvoir correctement insérer l expression. C.6 Erreurs de l analyseur de performance Windows L analyseur de performance Windows peut parfois fournir des résultats qui paraissent erronés. Par exemple, il est possible d obtenir un pourcentage d inactivité du processeur supérieur à 100. Il s agit là d un souci apparaissant parfois sur les ordinateurs disposant de plusieurs cœurs. 63

64 Annexe D Guide de désinstallation Pour désinstaller le logiciel, il suffit tout simplement de supprimer tous les fichiers. Si une suppression des données est également désirée, il faudra alors supprimer le schéma créé pour l occasion. Dans ce cas, il est également suggéré de supprimer l utilisateur associé à ce schéma. 64

65 Annexe E Exemple de rapport générés par le logiciel E.1 Rapport d activité Le document représenté ci-dessous est un exemple de rapport généré par le logiciel. Le rapport d activité contient alors toutes les mesures effectuées entre deux dates. L exemple présenté comporte certaines mesures volontairement erronées ainsi que des dépassements de seuils critiques afin donner un aperçu du rendu final. En raison du faible intérêt que représenterait l ensemble des données et par respect pour nos forêts, nous ne présenterons qu un ensemble de test ne comprenant que quelques mesures. 65

66 Activity Report Site: Bruxelles Begin time: 2011 End time: 2012

67 AVAILABLE_RAM Bruxelles AVAILABLE_RAM value: 67.0 Mo HP-HP ?? Warning: Value exceed threshold 3 (set at ) Bruxelles AVAILABLE_RAM value: Mo HP-HP ?? Warning: None Bruxelles AVAILABLE_RAM value: Mo HP-HP ?? Warning: Value exceed threshold 1 (set at ) Bruxelles AVAILABLE_RAM value: Mo HP-HP ?? Warning: Value exceed threshold 2 (set at ) DISK_SPACE_C NETWORK_INTERFACE_RECEPTION Bruxelles NETWORK_INTERFACE_RECEPTION value: bytes/s HP-HP ?? Warning: None Bruxelles NETWORK_INTERFACE_RECEPTION value: bytes/s HP-HP ?? Warning: None Bruxelles NETWORK_INTERFACE_RECEPTION value: bytes/s HP-HP ?? Warning: None Bruxelles NETWORK_INTERFACE_RECEPTION value: bytes/s HP-HP ?? Warning: None NETWORK_INTERFACE_SEND Bruxelles NETWORK_INTERFACE_SEND value: bytes/s HP-HP ?? Warning: None Bruxelles NETWORK_INTERFACE_SEND value: bytes/s HP-HP ?? Warning: None Bruxelles NETWORK_INTERFACE_SEND value: bytes/s HP-HP ?? Warning: None Bruxelles NETWORK_INTERFACE_SEND value: bytes/s HP-HP ?? Warning: None

68 PERCENTAGE_FREE_CPU Bruxelles PERCENTAGE_FREE_CPU value: percent HP-HP ?? Warning: None Bruxelles PERCENTAGE_FREE_CPU value: percent HP-HP ?? Warning: Value is greater than Max value (set at ) Bruxelles PERCENTAGE_FREE_CPU value: percent HP-HP ?? Warning: None Bruxelles PERCENTAGE_FREE_CPU value: percent HP-HP ?? Warning: None PROCESSUS_NUMBER Bruxelles PROCESSUS_NUMBER value: 85.0 processus HP-HP ?? Warning: None Bruxelles PROCESSUS_NUMBER value: 85.0 processus HP-HP ?? Warning: None Bruxelles PROCESSUS_NUMBER value: 85.0 processus HP-HP ?? Warning: None Bruxelles PROCESSUS_NUMBER value: 85.0 processus HP-HP ?? Warning: None TS_CAD Bruxelles TS_CAD value: E7 bytes HP-HP ?? Warning: None Bruxelles TS_CAD value: E7 bytes HP-HP ?? Warning: None Bruxelles TS_CAD value: E7 bytes HP-HP ?? Warning: None TS_CAD_INDEX Bruxelles TS_CAD_INDEX value: E7 bytes HP-HP ?? Warning: None Bruxelles TS_CAD_INDEX value: E7 bytes HP-HP ?? Warning: None Bruxelles TS_CAD_INDEX value: E7 bytes HP-HP ?? Warning: None

69 TS_DBM Bruxelles TS_DBM value: bytes HP-HP ?? Warning: None Bruxelles TS_DBM value: bytes HP-HP ?? Warning: None Bruxelles TS_DBM value: bytes HP-HP ?? Warning: None TS_MAP Bruxelles TS_MAP value: bytes HP-HP ?? Warning: None Bruxelles TS_MAP value: bytes HP-HP ?? Warning: None Bruxelles TS_MAP value: bytes HP-HP ?? Warning: None TS_SYSAUX Bruxelles TS_SYSAUX value: bytes HP-HP ?? Warning: None Bruxelles TS_SYSAUX value: bytes HP-HP ?? Warning: None Bruxelles TS_SYSAUX value: bytes HP-HP ?? Warning: None TS_SYSTEM Bruxelles TS_SYSTEM value: bytes HP-HP ?? Warning: None Bruxelles TS_SYSTEM value: bytes HP-HP ?? Warning: None Bruxelles TS_SYSTEM value: bytes HP-HP ?? Warning: None TS_TEMP

70 TS_UNDOTBS1

71 E.2 Rapport des avertissements Comme attendu, le rapport des avertissements contient seulement les avertissements fournis sur les données. Le rapport des avertissements concerne le même ensemble de mesures que le rapport d activité présenté ci-dessus mais ne présentera que les données ayant fait l objet d un avertissement. 71

72 Warning Report Site: Bruxelles Begin time: 2011 End time: 2012

73 AVAILABLE_RAM Bruxelles AVAILABLE_RAM value: 67.0 Mo HP-HP ?? Warning: Value exceed threshold 3 (set at ) Bruxelles AVAILABLE_RAM value: Mo HP-HP ?? Warning: Value exceed threshold 1 (set at ) Bruxelles AVAILABLE_RAM value: Mo HP-HP ?? Warning: Value exceed threshold 2 (set at ) DISK_SPACE_C NETWORK_INTERFACE_RECEPTION NETWORK_INTERFACE_SEND PERCENTAGE_FREE_CPU Bruxelles PERCENTAGE_FREE_CPU value: percent HP-HP ?? Warning: Value is greater than Max value (set at ) PROCESSUS_NUMBER TS_CAD TS_CAD_INDEX

74 TS_DBM TS_MAP TS_SYSAUX TS_SYSTEM TS_TEMP TS_UNDOTBS1