- 1 -

UFR Sciences et Techniques (2007-2008)

RAPPORT DE STAGE

DEVELOPPEMENT

COLLECTE ET ANALYSE DES JOURNAUX D ’EVENEMENTS D’UN GROUPE DE SERVEURS WINDOWS SERVER

Stage de 12 semaines réalisé du 10 mars au 30 mai 2008 Lieu du stage : Service de Comptabilité Internationale du Courrier (SCIC) Auteur : Mathias COQBLIN (mathias.coqblin@edu.univ-fcomte.fr) Maître de stage : Laurent GUILMARD (l.guilmard@laposte.fr), responsable informatique

- 2 -

REMERCIEMENTS Je remercie vivement mon maître de stage, Monsieur Laurent Guilmard du SCIC La Poste, pour m’avoir accueilli et guidé dans la réalisation de ce stage, ainsi que pour le temps qu’il m’a accordé et la patience dont il a fait preuve. Je voudrais également remercier Monsieur Stéphane Challine pour m’avoir accueilli dans le service, et Monsieur Jean-Philippe Gauthier pour son soutien. Mes remerciements sont également adressés à l’ensemble du service du SCIC/SERCI pour l’accueil chaleureux et le soutien qu’il m’a apporté. J’ai été ravi de découvrir le monde du travail et des administrations dans de si bonnes conditions. Enfin je souhaite remercier Madame Françoise Greffier pour sa participation et son encadrement au niveau de la formation et du stage.

- 3 -

SOMMAIRE

INTRODUCTION ................................................................................................................................. - 4 -

PRESENTATION DU SCIC ............................................................................................................................- 5 -

1. SCIC & SERCI ............................................................................................................................. - 5 - 2. LA POSTE ET LE MARCHE MONDIAL ................................................................................................. - 6 - 3. ACTIVITES ET OBJECTIFS DU CENTRE .............................................................................................. - 8 - 4. CADRE DU STAGE : SECTIONS ET MATERIEL A DISPOSITION............................................................... - 9 -

CAHIER DES CHARGES ................................. ................................................................................ - 13 -

1. PROBLEMATIQUE ......................................................................................................................... - 13 - 2. CAHIER DES CHARGES ................................................................................................................. - 14 -

I - ANALYSE DES JOURNAUX D’EVENEMENTS ET CONCEPTION DE LA BASE .................... - 15 -

1. LES JOURNAUX D’EVENEMENTS.................................................................................................... - 16 - 2. SOLUTIONS EXISTANTES............................................................................................................... - 18 - 3. MODELISATION DE LA BASE .......................................................................................................... - 19 -

II – LA MODELISATION ............................... .................................................................................... - 22 -

1. LA METHODOLOGIE D’APPROCHE .................................................................................................. - 23 - 2. LE DEROULEMENT DES OPERATIONS ............................................................................................. - 25 - 3. LA STRUCTURE DU PROGRAMME ................................................................................................... - 27 -

III – LOG ANALYZER ................................. ...................................................................................... - 29 -

1. PRESENTATION............................................................................................................................ - 30 - 2. LE TREEVIEW .............................................................................................................................. - 31 - 3. LE MENU..................................................................................................................................... - 32 - 4. L’INTERFACE UTILISATEUR............................................................................................................ - 33 -

BILAN.............................................. .................................................................................................. - 35 -

CONCLUSION................................................................................................................................... - 38 -

BIBLIOGRAPHIE / NETOGRAPHIE ........................ ........................................................................ - 39 -

ANNEXES ......................................................................................................................................... - 40 -

- 4 -

INTRODUCTION Dans le cadre de ma Licence Informatique à l’Université de Franche Comté, j’ai réalisé, du 10 mars au 20 mai 2008, un stage au SCIC La Poste (Service de Comptabilité Internationale du Courrier). L’objectif principal de ce stage était pour moi d’être confronté à un milieu professionnel, d’assumer les responsabilités d’un projet, d’apporter mes connaissances et d’en assimiler de nouvelles. C’est dans ce contexte que m’a été confié la tâche de développer un programme permettant d’observer et trier les journaux d’événements des différents serveurs. Un grand degré d’autonomie m’a été offert pour la tâche qui m’a été confiée. Ainsi une solution par le langage libre PHP a été retenue à mon initiative, couplée à une base de données sous SQL Server 2000 déjà en place sur le site. En vue de rendre compte de mon travail au sein de ces trois mois de stage, il m’apparaît opportun de présenter dans un premier temps le service dans lequel j’ai travaillé, puis d’aborder la problématique de mon sujet ainsi que le cahier des charges du projet. Je développerai ensuite les différentes phases de mon travail : l’analyse de l’existant et les limites de cette situation, la modélisation d’une solution et les techniques employées, une présentation du produit fini, les problèmes rencontrés et leurs résolutions. La conclusion fera le bilan de ce stage et de ce qu’il a pu m’apporter. Vous trouverez, en annexe à la fin de ce rapport, les références utilisées, une description du vocabulaire employé, ainsi qu’une chronologie de ma répartition du travail au fil du temps.

- 5 -

PRESENTATION DU SCIC

1. SCIC & SERCI Le centre est localisé au 2 chemin de l’Ermitage à Besançon, dans la Zone Industrielle de Palente (fig. 1.1) Il se décompose en deux grands services adjacents : le SCIC (Service de Comptabilité Internationale du Courrier), et le SERCI (Service d’Enquête et Réclamation du Courrier International), qui sont chargés de gérer la branche internationale de La Poste, sa comptabilité et ses échanges. Le centre est parti intégrante de la branche Courrier du groupe La Poste. Son emplacement géographique n’est pas issu d’une « stratégie », car les activités qui y sont effectuées ne sont pas en contact direct avec la clientèle, et ce n’est pas un point logistique du groupe La Poste.

Figure 1.1 : Localisation du SCIC à Besançon

- 6 -

2. La Poste et le marché mondial

Le chiffre d’affaires consolidé de la Direction des Activités Internationales du Courrier (DAIC), en 2006, est de 705 millions d’euros , englobant tout l’export, l’import, les ventes internationales et les filiales étrangères. L’activité du Courrier International couvre 6.2% du chiffre d’affaires courrier de La Poste, ce dernier étant de plus de 11 milliards d’euros .

La DAIC occupe dorénavant la 4ème place sur les flux transfrontaliers, derrière la poste américaine (USPS), allemande (Deutsche Post), et britannique (Royal Mail), et occupe la 2ème place parmi les opérateurs internationaux actifs en dehors de leurs frontières après la Deutsche Post.

Figure 1. 2 : Répartition des chiffre d’affaire et chiffre d’affaire du courrier

- 7 -

- Chiffre d’affaires consolidé* : 705 millions d'euros

- Trafic export et trafic import : 1 milliard d'objets

- Effectif consolidé : 1 800 personnes

- Pays desservis en liaison directe : 170

- Compagnies aériennes utilisées : 60

- Vols hebdomadaires directs : 1 000

- Moyens de transport :

- 55 % du courrier international est transporté pa r voie aérienne, - 44 % du courrier international est transporté pa r voie routière, - 1 % du courrier international est transporté p ar voie maritime.

Figure 1.3 : Chiffres clés

Le marché mondial Le marché mondial du Courrier International est estimé à 9,6 milliards d’euros , avec une tendance à la stagnation. Aujourd’hui, pour devenir réellement international, un opérateur postal doit non seulement consolider et défendre sa position sur le marché du courrier export d’origine (clients résidents, ventes export), mais également conquérir des clients internationaux hors frontières (ventes internationales). L’activité du courrier export est libéralisée dans les faits depuis le début des années 90, et dans les textes depuis le 1er janvier 2003, avec quelques exceptions. Une étape importante dans le processus de libéralisation a été franchie en janvier 2006 avec la sortie du domaine réservé des plis domestiques de plus de 50 g ou 2,5 fois le tarif de base. Pour autant, la libéralisation totale du courrier sera effective d'ici 2011. Les échéances se rapprochant rapidement, les principaux opérateurs européens préparent donc activement cette évolution : - Rachats, changements de statuts, etc., afin d'occuper une place suffisamment importante sur le plan mondial au moment de la déréglementation, - Utilisation, dans les pays déjà libéralisés, de prestataires privés pour la distribution du courrier international.

Figure 1.4 : Chiffre d’affaires

- 8 -

3. Activités et objectifs du centre La Direction des Activités Internationales du Courrier (DAIC), division du groupe La Poste, créée en 1995, a pour objectifs : - le développement de l’activité internationale du courrier : commercialisation en France et à l’étranger de prestations, de pris en charge, de traitement et d’acheminement de lettres et de petit paquets (< 2kg), ainsi que tous les services complémentaires sur mesure ou standard qui permettent de donner satisfaction aux clients français et étrangers de La Poste dans ce domaine - l’amélioration de la qualité du service des flux internationaux - la maîtrise des éléments du compte de résultat de l’activité. Le SCIC est directement rattaché à la Direction Administrative et Financière (DAF) de la DAIC. Dans le cadre de la mission de la DAF, l’établissement est en charge d’établir les contrôles nécessaires à la facturation des clients et fournisseurs avec le SCIC, ainsi que du traitement des réclamations internationales avec le SERCI. Pour remplir sa mission, le site est organisé autour de 3 pôles d’activité : - le Pôle Offices / Clients - le Pôle Fournisseurs - le Pôle Réclamations. Pôle Offices / Clients : Ce pôle assure le contrôle et la facturation de la distribution du courrier dans tous les pays de l’Union Postale Universelle (UPU). Elle donne également l’ordre de mise en paiement au service comptable de La Poste (le SCONI). Cette facturation est réalisée à partir des 3 grands types de flux transfrontaliers de courrier (maritime, aérien, routier). Sections concernées : Frais Terminaux, VI-VE (Vente Internationale – Vente Export) Pôle Fournisseurs : La DAIC est en charge du transport du courrier international mais également des colis internationaux pour le compte de Coliposte et de l’ensemble du courrier et des colis échangés entre la métropole et les Départements d’Outre Mer pour le compte de LPOM (La Poste Outre Mer). Trois modes de transport sont actuellement mis en œuvre pour ce faire : les voies aériennes, routières et maritimes. Sections concernées : Transport, Colis Postaux Pôle Réclamations : Le SERCI est un service dont la mission est d’effectuer les enquêtes sur les envois tant à l’export qu’à l’import, suite aux réclamations déposées par nos clients, en France comme auprès des offices étrangers. Sections concernées : SERCI

- 9 -

4. Cadre du stage : sections et matériel à disposit ion

a) Le SCIC Le Service de Comptabilité Internationale du Courrier fait partie de la DAIC. Ce service est unique en France. Ses missions sont de : - vérifier (à l’export) et garantir (à l’import) les volumes de courrier qui seront à la base des calculs de frais terminaux (voir ci-dessous) - examiner et corriger les comptes présentés au débit de la France, dans ses échanges avec environ 190 pays membres de l’UPU - demander au SCONI (Service de Comptabilité des Opérations Nationales et Internationales) les opérations de paiement et de recouvrement qui résultent de toutes ces activités - gérer les problèmes et contentieux comptables avec les compagnies et offices postaux.

b) Frais Terminaux Au départ, La Poste estimait que pour le Courrier International les échanges devaient nécessiter une « réponse ». Les échanges transfrontaliers étaient donc à peu de choses près équilibrés. Avec le temps, les flux de courriers internationaux prirent de l’ampleur. Les échanges de moins en moins équivalents suscitèrent des réclamations de rémunération, puisque certaines postes envoyaient plus de courriers qu’elles n’en recevaient. D’où la création de la section Frais Terminaux. Le travail de la section consiste à vérifier la facturation des postes étrangères, qui acheminent le courrier de sociétés françaises à des prix spécifiques. La section ne gère que la facturation de gros exportateurs de courrier.

Figure 1.5 : Déséquilibre des échanges

- 10 -

c) VI-VE La section VI-VE est décomposée en deux parties : - Vente Internationale s’adresse à des clients étrangers (clients « non résidents »). L’offre vise à permettre à un client étranger d’utiliser La Poste pour ses envois, que son trafic soit à destination de France ou d’un pays tiers. Le rôle de la section vise à rapprocher les données de production des tarifs fournis par le service MDV (Marketing et Développement des Ventes) de la DAIC. - Vente Export , au contraire de VI, s’adresse à des clients français (clients « résidents »). L’offre est réservée à des émetteurs directs de courrier, comme les banques ou les vépécistes. A l’instar de la VI, le rôle est de garantir l’exhaustivité et l’exactitude du chiffre d’affaire avec le souci de préserver les intérêts de La Poste tout en assurant la satisfaction du client.

d) Colis Postaux La section « colis postaux » assure l’édition et la vérification des comptes client « colis postaux » du monde entier. Elle utilise des feuilles de route des colis, pointés à leur arrivée ou départ dans chaque bureau d’échange. Elle effectue également le même travail que la section « Frais Terminaux », mais en traitant les colis, et non les lettres.

e) Gestion base de données Cette section extrait les chiffres clés (poids du courrier, nombre de « plus » en fonction des pays) de la base de donnée La Poste située à Rungis. En manipulant les chiffres bruts, les agents de la section estiment le coût des futures factures (reçues et envoyées), et en informent les services financiers qui pourront provisionner pour l'année en cours. Le centre de Besançon ne traite et comptabilise que les activités du courrier international, soit environ 12% du travail comptable du groupe.

f) Secrétariat Le secrétariat s'occupe des ressources humaines (les absences via un dispositif de pointage, les congés, etc.), mais également des dépenses et achats du centre Bisontin.

- 11 -

g) Courrier La section Courrier répartit et distribue le courrier de chaque service le matin, et relève le courrier à envoyer le soir. Elle gère aussi le standard téléphonique. L’activité est plus limitée maintenant qu’à l’époque, de par l’utilisation très développée de l’outil informatique (communication par e-mail).

h) SERCI Le Service des Enquêtes et Réclamations du Courrier International a pour objectif de répondre aux réclamations liées aux « objets perdus » (lettres, colis), à l’origine ou à destination de l’étranger. Elle tient compte des réclamations des particuliers comme des entreprises. J’ai pu constater que la quantité de réclamations journalières est très grande (plusieurs centaines), c’est pourquoi le service du SERCI est le plus grand du site.

i) Service Informatique Composé de deux personnes, Laurent Guilmard et Jean-Philippe Gauthier, le service informatique est disponible n’importe quand pour intervenir sur les problèmes des utilisateurs. Il s’assure également du bon fonctionnement du réseau ainsi que des différents travaux effectués sur le site. C’est dans ce service que j’ai effectué ce stage. L’organisation de toutes ces sections est représentée dans la figure 1.6.

- 12 -

Figure 1.6 : Schéma hiérarchisé des postes de l’ensemble du SC IC/SERCI

- 13 -

CAHIER DES CHARGES

1. Problématique Les services du SCIC et du SERCI possèdent à l’heure actuelle 17 serveurs et plusieurs dizaines de postes. Afin de gérer et contrôler l’état de l’ensemble de ces serveurs, les administrateurs réseau utilisent les Journaux d’Evénements (Event Logs), solution intégrée à Windows qui, à l’aide de l’Observateur d’événements , permet d’obtenir la liste de tous les événements survenus sur un serveur ou un poste. Ils existe trois catégories (« journaux ») de base : Application, Sécurité et Système, et chaque journal peut contenir trois types d’événements : Information, Avertissement, ou Erreur. Cependant, la quantité d’événements à observer quotidiennement est immense. Les événements peuvent arriver par centaines ou milliers, jusqu'à 70 000 pour certains journaux, totalisant en moyenne 100 000 à 150 000 par machine. En ne choisissant d’observer que les serveurs, ignorant les machines utilisateur, on peut se retrouver avec un flux dépassant les 2,5 millions d’événements journaliers. Ces informations demeurent non classées et non filtrées. On peut seulement observer les Erreurs, mais des événements de type Information contiennent parfois des informations cruciales, noyées dans une masse d’événement inutiles (comme une confirmation d’impression sur le serveur d’impression, événement arrivant plusieurs centaines de fois par jour, masquant une erreur fatale du même serveur). Il n’est donc pas rare de passer à coté d’une erreur ou d’un problème critique, pouvant par la suite causer un dysfonctionnement ou un crash, qui aurait pu être évité si le problème avait été connu plus tôt. Dès lors que cette problématique m’a été évoquée dans mon entretien avec M. Guilmard, le travail demandé m’est apparu distinctement. Nous avons ainsi pu organiser ensemble un cahier des charges permettant d’apporter une solution à ce problème.

- 14 -

2. Cahier des charges Sujet : « Collecte et analyse des journaux d’événements d’un groupe de serveurs Windows Server » Objectifs : L’objectif est de modéliser une application de gestion des événements, Log Analyzer. Du point de vue fonctionnel, cette application doit permettre aux administrateurs réseau de :

• créer et gérer des groupes de machines (stations ou serveurs), dont on souhaite exploiter les logs

• collecter (dans une base) et visualiser les derniers logs en date sur chaque serveur

• mettre en avant automatiquement les informations les plus importantes (erreurs, avertissements), émettre un message ou un e-mail signalant celles jugées critiques, et masquer les événements les moins importants

• traiter manuellement les informations : marquage, suppression, enrichissement d’informations

• purger automatiquement les journaux de la base après une période donnée, et des serveurs après mise à jour

• marquer certains événements comme traités ou résolus , en y inscrivant la méthode de résolution

• effectuer une recherche dans l’historique des erreurs traitées. L’applicatif devra être souple et intuitif, et les messages, e-mail, suppression automatiques et purges devront être paramétrables en fonction du serveur ou du groupe par l’administrateur. Du point de vue technique, l’objectif est de concevoir une base de données gérant une très grande volumétrie d’enregistrements, et de concevoir une application de type IHM (Interface Homme Machine) en PHP permettant l’accès à cette base. Enfin, le développement de l’application suivra un cycle de quatre phases : conception, développement, implémentation, tests. Outils de développement : Le SCIC a mis à ma disposition tout ce qui est nécessaire pour mener à terme ce projet, soit un PC, muni d’un serveur Apache avec PHP 5, l’éditeur de code Notepad++, un navigateur Web avec un accès à Internet, déstiné à la recherche de documentation, ainsi qu’un accès à une base de données sous Microsoft SQL Server 2000.

- 15 -

I - ANALYSE DES JOURNAUX D’EVENEMENTS ET CONCEPTION DE LA BASE

- 16 -

1. Les Journaux d’Evénements Ma toute première approche face au problème a été de me documenter sur les Journaux d’Evénements de Windows, afin de connaître les types d’informations à récupérer et comment les interpréter. Chaque log est un regroupement d’informations visant à donner des détails sur un événement qui s’est produit sur une machine. Les informations essentielles trouvées sont la date/heure de l’événement, son type, le journal source, une description, ainsi qu’un identifiant (Event ID) permettant de discerner le type d’information ou d’erreur auquel on a affaire (voir Fig. 2.1). On trouve également des compléments d’information : le programme à l’origine de l’événement, la machine concernée, le nom de son utilisateur, et des détails techniques sur l’erreur lorsque c’en est une. Cette organisation des informations est parfaitement adaptée pour être stockée dans une base de données, puisqu’elle sépare chaque « champ » individuellement.

Figure 2.1 : Détail d'un log (type Erreur, dans Application) Décrivant un crash de Firefox

- 17 -

Tous les événements n’ont pas la même importance, beaucoup d’informations se contentent par exemple de préciser dans le message qu’une application s’est ouverte ou fermée correctement. Les informations sont contenues dans des fichiers (format .evt) système de Windows, sous le chemin C:\Windows\system32\config. Ces fichiers sont au format binaire, donc illisible de manière directe, il faut pour cela un outil qui sache les interpréter. C’est ce que fait l’utilitaire Observateur d’Evénement natif à Windows. Les fichier d’événements sont partagés automatiquement sur le réseau et accessible à tous les comptes « Administrateur » de ce dernier. La solution a donc été déjà prévue pour être accédée à distance.

Figure 2.2 : Liste des événements

- 18 -

2. Solutions existantes Passé l’observation de la structure des événements, j’ai consacré mes premiers jours à la recherche des solutions existantes pour récolter ces informations. Une application WEB existe déjà gratuitement sur Internet : SB EventLog Monitor, qui porte les traits de la solution demandée (gestion de groupes, collecte des log). Cependant, elle n’est pas conçue pour gérer une quantité si grande d’événements, n’est pas optimisée en matière de gestion de la mémoire, et surtout sa nature trop généraliste ne comprend pas certaines fonctionnalités demandées. La solution de collecte des logs de cet applicatif a d’abord été retenue ; il s’agit d’un script VBScript exploitant les composants WMI (Windows Management Instrumentation) de Microsoft, dont une partie est dédiée à la lecture des logs. Une tentative d’adapter ce script aux besoins futurs de l’application a révélé ses limites : le script est lent et monopolise 100% du processus d’une machine demandée (pendant parfois plusieurs minutes). De plus, il sort les données dans un format affiché dans la console et sa récupération cause des problèmes d’encodage. Enfin une solution idéale et propre a été trouvée, développée par Microsoft : Log Parser. Il s’agit d’une application en ligne de commande permettant, entre autre, de récupérer les données des journaux sur le réseau, de sélectionner les champs désirés, et de les extraire dans un format de notre choix : CSV, XML, ou directement dans une base SQL connectée via un driver ODBC. Cette dernière solution est celle retenue. Log Parser permet de sélectionner avec une grande précision les logs désirés, puisque cette sélection s’effectue via des requêtes type SQL (voir Fig. 2.3) : On choisit les champs (SELECT), le fichier ou la table de destination (INTO), et on place les conditions (WHERE). On peut donc facilement enregistrer la dernière date de collecte, et ne récupérer par la suite que les enregistrements à partir de cette date, évitant ainsi les doublons. Même si le but final est de purger les logs des serveurs concernés, il est important de noter que Log Parser n’est pas destructif dans ses opérations.

Figure 2.3 : Log Parser - Récupération des logs d’Application sur le serveur PEGASE, au format CSV

- 19 -

3. Modélisation de la Base Après une semaine de recherche sur la faisabilité du produit, et après avoir observé les champs produits par Log Parser, j’ai consacré une autre semaine à me documenter et à réfléchir à la modélisation d’un MCD (Modèle Conceptuel de Données) le plus fonctionnel possible, suivant la méthode MERISE. Ce modèle est axé sur les trois pôles principaux de mon application : Machine/Groupe, Logs, et Filtres. Certains champs, voire tables annexes, ne sont pas encore (ou peu) exploités, mais on été placés dans l’objectif d’évolutions futures possibles de l’application. Note : Ce qui suit détaille les parties clés du MCD en le remodelant pour la lecture, la version finale est trouvable en Figure 2.7.

La partie Groupes du MCD comporte trois membres, sur lesquels les opérations seront très similaires : un groupe contient des machines , une machine contient des journaux . Deux jointures sont donc créées pour assurer la formation de ces collections. Par cette structure il est possible de manipuler une machine hors des groupes (ajouter/supprimer d’un groupe, sans perdre les données associées. De même, il est possible d’ajouter des journaux personnalisés uniques à une machine (ex : File Replication Service sur une machine contenant les espaces de travail)

Figure 2.4 : Partie Groupes/Machines du MCD

- 20 -

La partie Logs du MCD comporte deux membres et s’articule autour des machines et des journaux. Il s’agit d’une grande table LOG dans laquelle pourront être directement injectés nos événements. Chaque log fait référence directe à la machine et au journal concernés. Une date de dernière mise à jour doit pouvoir être conservée à chaque fois, pour éviter les doublons. Enfin une autre table, plus petite et ne dépendant que du type de journal, conservera les événements (en général des erreurs) résolus et commentés que l’administrateur souhaitera conserver, et consulter plus tard.

Figure 2.5 : Partie Logs du MCD

Figure 2.6 : Partie Filtres du MCD

- 21 -

Enfin, la partie Filtres du MCD consiste en une jointure qui devra faire référence à une table de filtres pré-alimentée. Filtrer consiste à référencer l’ID de l’événement qu’on veut filtrer, et le filtre à appliquer. Un filtre cumule toutes les propriétés de personnalisation de l’utilisateur : Niveau de priorité d’affichage, masquage/suppression/alerte automatique (via des flags ), etc. Passer par une référence force à l’alimenter de tous les cas possibles au préalable, mais permet d’ajouter tout type de filtre imaginable dans une version future.

Figure 2.7 : MCD de Log Analyzer

- 22 -

II – LA MODELISATION

- 23 -

1. La méthodologie d’approche

a) Le MVC Après avoir modélisé ce MCD et créé ma base de données, je me suis consacré la semaine suivante à l’étude d’un système que j’ai découvert : le MVC (Modèle-Vue-Contrôleur, ou Model-View-Controller). Il s’agit d’un patron de conception (Design Pattern), qui organise l’interface Homme-Machine (IHM) d’une application logicielle. L’objectif lors de l’utilisation d’un tel patron de conception est de réaliser une application de manière professionnelle, en créant un applicatif souple et facile à maintenir. On peut choisir de ne modifier que la manière dont sont traitées les données, ou que la manière dont elles sont affichées à l’écran, sans que l’un n’influence l’autre. Ainsi son ou ses auteurs pourront ajouter ou modifier aisément les fonctionnalités, toutes séparées en modules, tout comme les programmeurs reprenant un tel projet, qui peuvent plus facilement s’y adapter.

Le MVC divise l’IHM en trois parties : - Le modèle de données représente le comportement de l’application. Il effectue le traitement des données manipulées par l’application. Dans le cas courant où il y a une base de données, c’est le modèle qui interagit avec. Il offre des méthodes pour récupérer ou mettre à jour des données (insertion, suppression, changement de valeur). Les résultats renvoyés par le modèle sont dénués de toute présentation, ce sont des données brutes destinées à la (aux) vue(s).

Figure 3.1 : Illustration du modèle MVC

- 24 -

- La vue correspond à l’interface graphique. Elle s’occupe d’abord de récupérer les résultats renvoyés par le modèle, sans effectuer le moindre traitement, de les présenter et les mettre en forme pour l’utilisateur. Sa seconde tâche est de recevoir toutes les actions ou événements de l’utilisateur (clic de souris, boutons, etc.), et de les renvoyer au contrôleur. Plusieurs vues peuvent être composées à partir d’un même modèle, et même affichées ensemble dans une vue unique. - Le contrôleur est le pivot du système. C’est lui qui choisit quels modèles et vues employer. Il reçoit les événements de l’utilisateur, et enclenche les actions à effectuer. Si une action nécessite un traitement de données, il appelle le modèle correspondant, et demande ensuite à la vue de changer en fonction des nouvelles informations. Une application (ou un site) Web en PHP se comporte de la manière suivante : le script PHP traite des données, avec des variables, puis utilise le résultat de ces calculs pour générer du code HTML (mise en page Web). Ce code HTML est ensuite renvoyé au navigateur de l’utilisateur pour afficher la page résultat. Par opposition à une page HTML brute (statique ) sur le serveur, ce type site est dit dynamique , car toujours changeant. Dans le cadre d’une application Web supportant le MVC, comme Log Analyzer, le modèle correspond au script PHP accédant à la base de données, effectuant les lectures, ajouts, mises à jour et suppressions. La vue , elle, va correspondre à la partie du script générant une page HTML à partir des variables obtenues dans le modèle. Enfin, le contrôleur est techniquement la page appelée par l’utilisateur (via un lien), qui s’occupera d’inclure les fichiers modèles et vues de la page souhaitée. L’objectif final du MVC est de décomposer le projet : un graphiste peut se charger seulement des vues, tandis que le codeur se charge des modèles.

b) Les Templates Lors de ma recherche sur le modèle MVC en PHP, j’ai pu découvrir un outil dédié à la séparation du fond et de la forme en PHP : les Templates (ou gabarits, patrons, « kits graphiques »). Puisque la méthode d’approche de PHP est de générer du HTML dans son code, celle offerte par la couche template est de n’avoir que du code HTML d’un coté (le template), dont les éléments pouvant changer sont identifiés clairement, et que du code PHP de l’autre coté (le moteur de template). Il y a séparation totale du code : le script PHP charge un moteur de template, lui donne des variables pour remplir les champs vides d’un template, et lui demande d’interpréter un ou des templates pour affichage. Ma démarche lors du développement a été de placer mon modèle sur deux niveau : le MVC gère l’application, et le moteur de template est utilisé par les vues.

- 25 -

2. Le déroulement des opérations

a) La maquette Une fois que le projet était ficelé, et la méthode d’approche anticipée, j’ai pu passer deux à trois semaines à la conception d’une maquette pour l’application. L’applicatif devait comporter un Menu , ainsi qu’un Treeview (volet d’exploration). Afin d’obtenir une meilleure interactivité, pour une page Web, l’application est donc scindée en trois parties, séparées par des frames : le menu en haut, le Treeview à gauche, et la page en cours occupant le restant de l’écran. L’ensemble est géré à l’aide de Javascript.

Figure 3.2 : Première version de la page principale (vue des logs)

- 26 -

L’essentiel du temps passé sur la maquette a été consacré à la conception (Javascript) du Treeview, du menu, ainsi qu’à la page principale de l’application : visualisation des événements. Cette page devait être à la fois claire et souple, proposant rapidement l’information à afficher. Il était donc important de la préparer à l’avance. L’ensemble des vues mineures (formulaires d’ajout, d’édition, etc.) ont ensuite été ajoutées au fur et à mesure de la conception de leurs modèles.

b) L’organisation du MVC La maquette faite, j’ai pu passer à la réalisation de mon modèle MVC, en concentrant tous mes premiers efforts dans la conception d’un contrôleur générique . Le contrôleur générique fait partie de la stratégie d’approche MVC version 2 : puisqu’un contrôleur fait toujours les mêmes opérations (récupération de la configuration, connexion à la base, récupération des actions, appel du modèle et de la vue) on peut donc en concevoir un seul qui choisira l’action à faire au lieu d’en avoir une fixée.

Comme illustré dans la Figure 3.3, une normalisation a été effectuée dans les modèles et les vues. L’application est décomposée en modules (« pages »), et chaque page en action . De cette façon, on nomme conventionnellement les modèles en "m-<page>-<action>.php" (ou "m-<page>.php" si on veut l'action par défaut, ou sans action précise), et de la même manière "v-<page>-<action>.php" ou "v-<page>.php". Le contrôleur n’a alors plus qu’a déterminer la page et l’action à effectuer, vérifier que le fichier correspondant existe bien, et appeler le modèle et la vue. Enfin vient l’utilisation du moteur de template, nommé GagaTemplate (gratuit et performant), qui n’est lié qu’à la vue. Les pages de la maquette ont été transformées en templates (fichiers d’extension .tpl), placés dans un dossier dédié (voir Structure du programme ci-dessous). La vue n’a alors pour seul métier que de charger le moteur de template, lui apporter les données du modèle, et appeler le bon template pour générer le HTML.

Figure 3.3 : Exemple du MVC 2 dans le cas d’un formulaire d’ajout d’une machine

- 27 -

3. La structure du programme

a) L’architecture physique

Chaque élément de l’application est rangé dans un dossier différent et inclue en fonction du besoin. Le contrôleur représente l’index.php, seule page techniquement appelée dans l’application, toute autre tentative résultera d’un accès interdit (erreur HTTP 403). Outre les modèles et les vues rangées dans des dossiers dédiés, on trouvera également un dossier contenant les templates (inclus par les vues). Ces templates, représentant le HTML final, incluront des pages de Javascript et des feuilles de styles CSS , ainsi que les images illustrant l’application. Enfin le dossier bin (binaries, nom standard désignant les exécutables) contient Log Parser, utilisé pour récupérer les logs.

b) La structure logique ( Fig. 3.5 ) L’application est décomposée en modules puis en actions : - Les modules sont les grands thèmes sur lesquels on veut travailler. Les machines, groupes, journaux, et filtres, figurent parmi les modules principaux. - Les actions indiquent ce que l’on veut effectuer sur son module, elles sont généralement restreintes à : ajouter, éditer, supprimer et voir. Même si les actions diffèrent d’un module à l’autre (« voir machine » donne quelques informations sur la machine, « voir log » liste les événements d’un journal), leur nom a été normalisé pour plus de conformité et un confort de programmation (il est plus facile de se rappeler qu’un formulaire visant à modifier les informations sera toujours « éditer »).

Figure 3.4 : Architecture des dossiers de l’application et logique d’inclusion

- 28 -

Figure 3.5 : Structure logique (hiérarchisation des actions possibles)

- 29 -

III – LOG ANALYZER

- 30 -

1. Présentation L’interface de Log Analyzer a été conçue dans le but de proposer un outil à la fois pédagogique, accessible et simple d’utilisation. L’application est contenue dans un serveur Web Apache. Le serveur a été installé sur machine serveur via l’utilitaire WampServer (www.wampserver.com), suite logicielle comprenant un serveur Apache 2, un interpréteur PHP 5, et une base de données MySQL 5. Cette approche rend l’application accessible depuis n’importe quel point du réseau par un administrateur « logué ». Une telle interface entre l’utilisateur et la machine doit être claire et garantir un niveau de sécurité maximal pour conserver l’intégrité des données collectées. Le serveur Apache a donc été protégé d’accès : tout doit passer par le contrôleur. Ce dernier quant à lui sécurise les actions et refuse toute action non existante ou non autorisée via un mot de passe. Le produit fini que j’ai présenté à la fin de mon stage au SCIC comprenait :

� L’application installée sur un serveur dédié, liée à une base de données SQL Server existante

� Une version compressée (ZIP) de l’application avec un fichier d’installation de la base et un fichier d’instructions d’installation (ReadMe)

� Le présent rapport, complet. (formats MS Word et PDF)

Figure 4.1 : Dossier final de l’application

- 31 -

2. Le Treeview Partie la plus poussée en Javascript et la moins importante en apparence, le Treeview est au centre de la navigation dans l’interface utilisateur de Log Analyzer.

Il permet de visualiser très aisément l’ensemble des groupes, leurs machines et leurs journaux. Il fonctionne comme le volet d’exploration de l’Explorateur Windows : en sélectionnant un groupe ou une machine, l’arbre s’ouvre, et on a un résumé de l’élément dans notre page principale (nom, description, liste des journaux lui appartenant, etc.). En sélectionnant un journal d’une machine on visualise directement les événements de cette dernière, alors qu’en sélectionnant celui d’un groupe, on visualise une synthèse de ce journal pour l’ensemble des machines du groupe. Enfin, la présence de filtre dans un journal est signalée par un changement de couleur (vert) du nom du journal, ainsi que du nom de sa machine (filtre sur machine) ou de son groupe (filtre sur groupe).

Figure 4.2 : Treeview

- 32 -

3. Le Menu Le menu regroupe l’ensemble des fonctionnalités de Log Analyzer : il permet d’ajouter, de modifier ou de supprimer des machines, des groupes ou des journaux, ainsi que de visualiser ou ajouter des filtres d’un journal. Il contient également certaines fonctionnalités étendues, comme la recherche de problèmes résolus.

De part son état d’application Web, le Menu de Log Analyzer a certains comportements qui lui sont propres. Pour manipuler ce menu, il est nécessaire de connaître l’élément clé suivant : il faut d’abord se placer sur l’élément concerné par l’action (i.e. sélectionner un groupe, machine ou journal via le Treeview), puis sélectionner l’action dans le menu. Par exemple, pour modifier ou ajouter des filtres sur une machine, il faut cliquer sur cette machine dans le Treeview, puis cliquer sur le bouton Editer de la partie Machine. Cette tentative d’édition sans sélection donnera un message d’avertissement.

Une propriété intéressante du menu est que la gestion des éléments concernés par les actions est récursive. Si l’utilisateur est positionné sur le journal d’une machine et qu’il clique sur Editer de Machine, il se retrouvera directement à la page d’édition de cette machine. De même, Editer un Groupe ramènera à l’édition du groupe de la machine de notre journal. Enfin, la gestion indépendante des groupes et des machines permet deux fonctions de mise à jour. Si l’on est positionné sur une machine : Mettre à jour une Machine va mettre à jour tous les journaux de la machine sélectionnée. Mettre à jour un Groupe va mettre à jour tous les journaux du groupe de la machine. En revanche, si l’on est positionné sur un journal de machine, Mettre à jour une Machine ne mettra à jour que ce journal.

Figure 4.3 : Menu – partie principale : groupes et machines

Figure 4.4 : Menu – fonctions secondaires

- 33 -

4. L’interface utilisateur Toutes les actions effectuées via le menu et le Treeview sont visibles dans la page principale de l’application. La page la plus importante est la visualisation des événements. Cette visualisation est paginée : on peut visualiser un nombre défini d’événements par page et changer de page. Le programme informera à tout moment l’utilisateur du nombre d’entrées par page affiché.

La sélection d’un événement provoque l’affichage des détails de l’événement dans un cadre situé en bas de page. Pour les cas réguliers où le nombre d’enregistrements affichés est trop grand, un double clic sur l’événement exécute une fenêtre pop-up détaillant la totalité de l’événement.

Figure 4.5 : Liste des événements

- 34 -

Figure 4.6 : Captures d’écran de l’application finale dans le navigateur

- 35 -

BILAN

- 36 -

Au cours de ce stage, j’ai beaucoup appris. Les apports que j’ai tirés de cette expérience professionnelle peuvent être regroupés autour de trois idées principales : les compétences acquises, les difficultés rencontrées et solutions apportées ainsi que la vie en société. Les compétences acquises A l’occasion de ce stage, j’ai pu découvrir de nouvelles méthodes de travail pour mener à bien mes projets. Sur le plan de la gestion du travail, l’architecture et l’organisation apportées par le MVC m’étaient jusqu’alors inconnues. J’ai réellement apprécié de pouvoir utiliser mes connaissances d’une manière propre et structurée, ce qui m’a permis de mener à bien ce projet. Sur le plan professionnel, j’ai également pu apprendre à concevoir (et à respecter) un projet et son cahier des charges, en adéquation avec la demande de l’utilisateur. Enfin, sur le plan technique, j’ai pu améliorer mes capacités de programmation. Les difficultés rencontrées et solutions La difficulté principale que j’ai rencontrée lors de ce stage a été la gestion de mon temps. Devant travailler seul sur tout le projet, j’ai beaucoup perdu de temps sur certains éléments relevant du détail, en particulier dans la réalisation de la maquette. Très vite la conception de quelques éléments majeurs a monopolisé bien plus de temps que prévu. J’ai donc dû précipiter l’achèvement de cette maquette, en ne conservant que les éléments clés. J’ai fait ensuite le choix d’épurer l’interface des pages mineures de manière à les rendre simples et rapides à réaliser. Le résultat obtenu est très satisfaisant mais cette perte de temps a du accélérer le codage de l’applicatif, et la remise de ce dernier a été effectuée avec une semaine de décalage sur la date fixée, bien que sans conséquences significatives. Le second type de difficulté m’ayant le plus marqué fut la quantité d’« imprévus » survenus lors du développement. Un certain nombre de bugs et d’erreurs furent rencontrés, mais réglés relativement rapidement :

- Après beaucoup de recherches et de tests décevants sur les méthodes de collecte des logs, une semaine a été nécessaire pour trouver un outil fiable pour effectuer cette tâche, et encore quelques jours pour le maîtriser et être sûr que je pouvais continuer mon développement.

- A l’origine fondée sur des pages simples, l’application a rapidement manqué de souplesse, et un remodelage de la maquette a été nécessaire pour y ajouter un système de frame, peu apprécié en programmation Web, mais utile dans le cas d’une application.

- 37 -

- SQL Server 2000 est un serveur de base de données datant de plusieurs années, et ne supportant pas un certain nombre de fonctionnalités utiles, comma la recherche paginée (i.e. afficher un certain nombre d’enregistrements à partir d’un enregistrement donné). Un palliatif à cette fonctionnalité manquante a donc du être trouvé, nécessitant de construire une requête plus longue, voire plus lourde.

- Enfin un problème d’accès de dernière minute a retardé le déploiement final de l’application. En effet, pour une raison inconnue, la mise à jour refusait de s’effectuer sur certains serveurs. Le debugging était d’abord impossible car le problème ne survenait que pendant l’exécution de l’application Log Analyzer, alors que la collecte en mode manuel fonctionnait correctement. Suite à une analyse du code erreur rencontré, il s’est avéré que le problème venait des droits d’accès. En effet, Apache nécessite d’être lancé en tant que service avec ses propres droits pour lui permettre la collecte des logs sur les serveurs Windows Server 2003, plus sécurisés.

Vie en société Une des meilleures expériences acquises lors de ce stage est celle de la vie en entreprise. Le service du SCIC est très accueillant et demeure dans une ambiance chaleureuse et très agréable. Bien qu’ayant été relativement isolé pour mener à bien mon projet, j’ai pu croiser beaucoup de gens et observer une grande convivialité et solidarité entre eux. Je me suis vraiment sentit à l’aise.

- 38 -

CONCLUSION Le cahier des charges a été respecté et les améliorations réalisées ont un potentiel exploitable dès à présent. En effet, l’application est fonctionnelle et accessible aux administrateurs depuis n’importe quelle machine du parc réseau du SCIC. L’analyse des événements est un point crucial pour tout administrateur réseau puisqu’il permet de surveiller l’état des serveurs et leur bon comportement. Pouvoir gérer aisément ces événements et être informé rapidement des problèmes s’avère donc être une possibilité tant indispensable qu’appréciée. C’est une grande satisfaction pour moi d’avoir mené ce projet à terme. J’en tire une expérience substantiellement accrue, notamment par rapport à l’organisation dans le travail. Ainsi, j’ai appris à m’adapter à de nouvelles méthodes dans les domaines de la programmation, de la rédaction, de la documentation et de la stratégie de projet. Finalement, je suis convaincu qu’avec plus de temps et de moyens, cette application peut grandir encore en fonctionnalités, s’améliorer et gagner en qualité d’affichage. J’ai regretté de n’avoir pas pu apporter à l’applicatif actuel toutes les possibilités qui lui sont imaginables. Mais je suis assuré de la possibilité de reprise de ce projet, par moi ou un de mes successeurs, puisqu’il sera distribué sous licence libre avec l’accord de mon maître de stage. Il est en effet indispensable selon moi qu’une application, même de faible envergure, passe entre de nombreuses mains pour en exploiter toutes les possibilités.

- 39 -

BIBLIOGRAPHIE / NETOGRAPHIE Site de La Poste : http://www.laposte.fr/ Manuel d’utilisation de PHP : http://www.php.net/manual/en/ http://www.php.net/manual/fr/ Outil Log Parser chez Microsoft : http://www.microsoft.com/technet/scriptcenter/tools/logparser/default.mspx WampServer, serveur Apache complet : http://www.wampserver.com/ W3School, référence des normes W3 (DOM, CSS2) en programmation Web : http://www.w3schools.com/ Article complet traitant du modèle MVC en PHP http://tahe.developpez.com/web/php/mvc/ Articles poussés sur des points précis en SQL : http://sqlpro.developpez.com/cours/sqlaz/jointures/ (Jointures) http://baptiste-wicht.developpez.com/tutoriel/ms-sql/datetime/ (type Datetime) Treeview générique très complet ayant servit de base http://www.treeview.net/ Google, pour toute recherche complète sur un point de détail ou un problème : http://www.google.fr/

- 40 -

ANNEXES

1) Chronologie du stage

2) Historique des versions

3) Vocabulaire

- 41 -

1) Chronologie du stage

- 42 -

2) Historique des versions Historique des versions et révisions (Change Log) de Log Analyzer : (Prévue le 30/05/2008) : 1.0 Finale # Ajout : suppression possibles des machines et des groupe, avec ou sans suppression définitive dans le cas d'une machine (pour retrouve r ses informations) # Ajout : commentaires et résolutions sur les événe ments # Ajout : exploration et recherche dans les événeme nts dit résolus (recherche par mot clé dans le commentaire) # Ajout : envois d'un mail d'alerte des événements filtrés, fait à chaque mise à jour 16/05/2008 : 0.9.2 # Correction : décalage de l'heure des logs d'1 ou 2 heures. # Correction : pas de retour à la ligne dans les dé tails des événements. 15/05/2008 : 0.9.1 # Correction : le treeview n'était pas mis à jour l ors de l'ajout de filtres (les machines doivent prendre une couleur distincte). # Correction : nombre de pages et d'événements inch angé lors de l'ajout de filtres de masquage. # Ajout : colonne "Machine" dans les événements d'u n groupe, précisant la machine de l'événement. # Ajout : possibilité de trier MANUELLEMENT (aucun filtre n'est alors tenu en compte) les événements par Machine, Type, Date, Source, ou ID, dans un ordre ascendant ou descendant. 14/05/2008 : 0.9 # Ajout : ajouter ou éditer des FILTRES sur des évé nements. Ces filtres sont identifiés par leur ID, ainsi que le journal, le groupe et (le cas échéant) la machine concernés. Plusieurs actions surchargeables : - Changer l'importance (élevée, normale, faible) d e l'événement - Le masquer - L'ajout à une liste d'alerte (plus tard un mail sera envoyé automatiquement à chaque MAJ, listant les alertes) 09/05/2008 : 0.8.2 # Ajout : détails d'un événement dans une fenêtre p op-up par un double-clic sur l'événement (la fenêtre est automatiquement mise à jour à la sé lection d'un nouvel événement) 07/05/2008 : 0.8.1 # Correction : code erreur mal géré lors de la mise à jour 06/05/2008 : 0.8 /!\ Première version publique. # Gestion totale des machines, groupes et journaux (hors suppression) disponible : on peut créer/éditer un journal, créer/éditer une machine, y ajouter ou enlever les journaux désirés, créer/éditer un groupe et y ajouter ou enlever les machines concernées # Mise à jour des journaux sélective : On peut mett re à jour tout un groupe (bouton "Mise à jour" du groupe), mettre à jour toute une machine ( sélection machine, puis "Mise à jour" dans machine), ou mettre à jour un seul journal (sélecti on journal de machine, puis "Mise à jour" dans machine)

- 43 -

3) Vocabulaire Apache : Apache http Server. Serveur Web libre et gratuit le plus populaire. Il a pour tâche d’écouter les requêtes des navigateurs Internet, et de leur envoyer les données (i.e. pages Web) en réponse. Tout site Web visité est en fait une machine à distance comportant un serveur Web. HTML : HyperText Markup Language. Langage de mise en forme utilisé dans les pages Web. Il consiste à placer des éléments entre des balises pour indiquer la façon dont ils seront affichés (gras, centré, etc.). IHM : Interface Homme-Machine. Interface graphique d’une application destinée à rendre cette dernière aisément utilisable par toute personne. Implémenter : Anglicisme (de l’anglais to implement) désignant la création et l’ajout de fonctionnalités dans un programme informatique (i.e. implanter). Journaux d’Evénements (Event Logs) : Journal d’information sous Windows listant tous les événements survenus sur une machine (informations, avertissements, erreurs). Logiciel libre (Open Source) : Tout logiciel dont le code source est disponible (généralement gratuitement) et ouvert à toute modification, puis distribuable. MCD : Modèle Conceptuel de Données. Diagramme créé lors de la conception d’une base de données. Il représente les différents éléments et leurs interactions. MVC : Modèle-Vue-Contrôleur. Modèle d’organisation professionnel visant à séparer le traitement des données de l’affichage (la vue) de ces dernières (voir Patron de conception ) PHP : PHP: Hypertext Preprocessor. Langage de programmation interprété, utilisé dans une majorité de sites et applications Web. Patron de conception (Design Pattern) : Solution standard proposée pour résoudre l’organisation d’un projet d’envergure en développement. SQL : Structured Query Language. Langage de programmation standardisé destiné à l’exploitation d’une base de données. Des implémentations (ou serveurs de bases de données), citées dans ce rapport, sont par exemple MySQL et SQL Server. VBScript : Langage script dérivé du Visual Basic, destiné à être utilisé sur une plate-forme windows. WMI : Windows Management Instrumentation. Système de gestion interne à Windows mis en place par Microsoft, proposant des méthodes de manipulation et gestion des données d’une machine (comme les journaux d’événements)

- 44 -

Résumé A l’occasion de ma dernière année en Licence Informatique à l’Université de Franche-Comté, j’ai effectué un stage de trois mois au Service de Comptabilité Internationale du Courrier de La Poste. L’objectif de ce stage était de développer une application de gestion et analyse des Journaux d’Evénements Windows, afin permettre aux administrateurs réseau de surveiller facilement leurs serveurs. Pour ce faire, j’ai implémenté une solution coté serveur à l’aide du langage de programmation PHP et d’une base de données Microsoft SQL Server. La méthode que j’ai utilisée est le Modèle-Vue-Contrôleur (MVC), méthode de développement utilisée et reconnue dans le milieu professionnel. Ce rapport détaille le déroulement de ce stage, ainsi que la manière dont j’ai développé mon application, de l’analyse du problème au produit fini. Mots clés : Journaux d’Evénements – MVC – PHP – SQL Server – interface utilisateur – serveur

Summary During my last year of “Licence” in Computer Sciences at the University of Franche-Comté in Besançon, I carried out a three months training period in the La Poste's International Mail Accounts Department (SCIC). The aim of this internship was to develop a management and analysis application for Window’s Event Logs, so as to allow local network administrators to easily monitor their servers. In order to do this, I implemented a server-side solution using the PHP programming language and a Microsoft SQL Server database. The method I used is a professionally used and recognized development method called Model-View-Controller (MVC). This report describes the training period’s evolution and the way I developed the application, from the analysis of the problem to the final product. Keywords: Event Logs – MVC – PHP – SQL Server – user interface – server