Conception d'un système de gestion de logs - Dossier d'initialisation Version : 0.2-22/05/2008 Rédiger par : Gassmann Sébastien Lu et revu par : Petit Jean-Marc (23/05/2008)
Table des matières 1 Contexte du projet... 3 2 Objectif du projet... 3 3 Organisation du projet... 3 3.1 Planification... 3 3.2 Compte-rendu, réunions, déplacements... 4 3.3 Diagramme de planification... 4 4 État actuel du projet... 5 4.1 Les solutions existantes envisagées... 5 4.2 Une proposition d'architecture... 6 5 Identification des tâches... 7 5.1 Définition des besoins... 7 5.2 Développement spécifique... 7 5.3 Choix d'une solution... 7 6 Produits finis... 8 6.1 Les livrables... 8 6.2 Un prototype fonctionnel... 8 7 Référence... 8 2/8
1. Contexte du projet Ce projet s'inscrit dans le cadre d'un stage de fin d'année de quatrième année du département informatique de l'insa de Lyon. En collaboration avec EDF R&D, ce projet se déroule dans le laboratoire LIRIS du département informatique de l'insa. Ce projet est la suite de l'étude menée par Fréderic Flouvat sur l'analyse des traces générées par les logiciels du système d'information utilisée par EDF. Cette étude a mené à une identification des solutions existantes permettant une première analyse des logs et à une proposition d'architecture permettant de répondre au besoin d'edf. Cette architecture sera une base à ce projet. Ces logs sont issus du système d'information de gestion et de surveillance des sites de production d'edf comme les centrales hydrauliques. Les informations contenues dans les logs peuvent être utile à la prévention de problèmes, la détection de problèmes ou le suivi du bon fonctionnement du système de production. Mais ces informations sont souvent noyées au milieu d'une multitude d'autres informations et ne sont pas accessibles facilement par une simple lecture des logs. C'est à ce problème d'analyse et d'interrogation de logs distribués sur un réseau d'entreprise que le projet doit répondre. 2. Objectif du projet L'objectif de ce projet et de concevoir un système permettant une analyse des logs générés par les applications de gestion et de surveillance des sites de production d'edf. Cette analyse doit pouvoir se faire en temps réel afin de permettre d'alerter immédiatement s'il y a une détection de problème à partir des logs ou en différé, sur des logs enregistrés dans des fichiers de sauvegarde, afin de permettre une identification des alertes sur un problème survenu. 3. Organisation du projet 3.1. Planification Ce projet se déroulera sur 4 mois, du 13 mai 2008 au 12 septembre 2008 : les deux premiers mois pour une analyse de l'existant, le choix d'une solution de départ existante, l'identification des modifications et ajouts à apporter à la solution choisie; et les deux derniers mois, pour la réalisation d'un prototype, basé sur la solution choisie, fonctionnant sur un jeu donné de logs provenant d'une application d'edf. 3/8
3.2. Compte-rendu, réunions, déplacements Pour un suivi du projet, un compte rendu hebdomadaire sera rédigé afin de partager l'état d'avancement du projet, les difficultés rencontrées et les directions choisies. Cela permettra un déblocage sur un éventuel problème ou encore une confrontation d'idée sur un point du projet. Différentes réunions seront organisées entre les représentant d'edf (Alain Ribière), du LIRIS (Jean-Marc Petit, Fréderic Flouvat) et le stagiaire en charge de ce projet (Sébastien Gassmann). Ces réunions permettront de faire un point sur l'avancement du projet, d'effectuer les choix principaux (par exemple, le choix de la solution de base), de s'informer auprès du représentant d'edf sur ses attentes, de demander conseils auprès des spécialistes du LIRIS. * Réunion du 13 mai 2008 : première réunion qui permet de planifier le projet : définir les dates des prochaines réunions et leur rôle, établir la date limite des livrables. * Atelier ILO au congrès INFORSID : Atelier ILO : Intégration, interrogation et analyse de LOgs animé par Pierre-Etienne Delon, EDF R&D, Frédéric Flouvat, LIRIS - EDF R&D, Jean-Marc Petit, LIRIS, INSA de Lyon, Alain Ribiere, EDF R&D. Les ateliers constituent des groupes de travail et de réflexion autour d'une thématique. * Réunion du 3 juillet 2008 : réunion de mi-parcours, qui permettra de choisir la solution de base en fonction des résultats de l'étude des deux premiers mois. Afin de connaître les attentes des principaux concerné par l'analyse des logs, qui sont les exploitants des sites de production, un ou plusieurs déplacement seront prévus sur les sites. Cela permettra d'évaluer les habitudes sur l'exploitation des logs, afin de développer un système permettant de faciliter la recherche sur les logs tout en ne complexifiant pas les procédures de recherche. * Déplacement prévu le 3 juin 2008 : sur le site de Sisteron, où se situe un barrage hydraulique d'edf. Cela permettra de se renseigner sur les analyses de logs actuelles et attendues directement aux exploitants du site. 3.3. Diagramme de planification 4/8
4. État actuel du projet L'étude menée par Frédéric Flouvat sert de point de départ au projet. Les principales solutions open-source existantes ont été testées, analysées et jugées, afin de permettre un choix sur la base du prototype à réaliser. 4.1. Les solutions existantes envisagées Ces différentes solutions sont Grep, un outil ligne de commande unix permettant de rechercher les lignes contenant une expression régulière donnée (cette solution de base est déjà utilisé pas EDF pour effectuer des recherches sur les fichiers de logs.), Lucene, une API Java permettant une approche moteur de recherche/indexation des fichiers de logs, Sec, un programme en ligne de commande permettant d'étudier des flux d'événements et Esper, une API java, utilisable comme moteur de gestion de flux, basé sur une indexation objet en continue des évènements. Les expérimentations, analyse et conclusions sont disponibles dans le document référence [1]. Outils Avantages Inconvénients Grep Installation/déploiement facile Léger Puissant pour rechercher du texte grâce aux expressions régulières et à la possibilité de le combiner avec d'autres Pas optimisé pour traiter des requêtes en parallèle (n requêtes ->n exécutions) Pas orienté continu Complexité d'expression de certaines requêtes simples (p. ex. sur les dates) Lucene outils API open-source Recherche rapide grâce à l'indexation Fonctionnalités limitées en interrogation (p.ex. impossible de définir des séquences ou des jointures) et absence d'analyse Pas adapté aux logs (fréquence élevée de mises à jour) Pas orienté continu Langage puissant pour le texte et plus simple que les expressions régulières Utilisation de champs pour structurer les documents et affiner la recherche Fonctionnalités limitées en interrogation (p.ex. impossible de définir des séquences ou des jointures) et opérations d'analyse à développer SEC Léger et indépendant du système Orienté distribué et continu Puissance de traitement du PERL Puissance d'expression des règles Estampille des événements fixée par le système (pas estampille du log) Complexité des règles (p.ex. expression d'une séquence -> plusieurs règles) Pas de différenciation des flux,règles appliquées sur tous les événements Esper API open-source Estampilées séquentiellement (i.e. pas d'optimisation du plan d'exécution) 5/8
Interrogation des flux et possibilité d'accéder à des données stockées dans des bases de données Langage très expressif et de haut niveau Possibilité d'exprimer des séquences d'événements Interrogation des données stockées impossible Opérations d'analyse à développer des événements fixée par le système (pas estampille du log) Fonctionnement interne obscur (p.ex. optimisation des requêtes?) Représentation objet des événements Complexité du langage pour l'expression des patrons et la gestion du temps Pas de réelle gestion des données stockées dans les logs fonctionnalités d'analyse limitées Tableau récapitulatif des avantages et des inconvénients des différentes solutions expérimentées [1]. A ces solutions s'ajoute le logiciel Cayuga qui a seulement été évoqué par Frédénric Flouvat dans son analyse. Cayuga est un logiciel de monitoring d'évènement sur des flux internet (RSS, RDF, Atom, etc.) mais peut être adapté afin de l'utiliser comment monitoring de logs et de permettre d'effectuer des recherches dessus. Une étude sur Cayuga basé sur les expérimentations de Frédéric Flouvat, permettra d'identifier les avantages et inconvénient de la même manière que cela a été fait sur les autres solutions. Ainsi, Cayuga pourra être comparer aux autres solutions et être susceptible d'être choisi comme la solution de base. 4.2. Une proposition d'architecture De même que pour l'analyse des solutions existantes, l'étude la proposition d'architecture mené par Frédéric Flouvat est disponible dans le document référence [1]. Schéma de la proposition d'architecture [1] 6/8
5. Identification des tâches Afin de mener à bien ce projet, il faut effectuer différentes tâches qui permettront de faire des choix sur la solution finale. 5.1. Définition des besoins Une définition précise des besoins des exploitants d'edf permettra d'évaluer les développements spécifiques à apporter aux différentes solutions afin de répondre à ces besoins. Pour cela, l'étude des logs fournis par EDF, les déplacements sur les sites des exploitants ainsi que toutes informations supplémentaires données par EDF permettra d'identifier les besoins. Les besoins peuvent être de l'ordre des possibilités qui peuvent être apportées à leur analyse de logs, mais aussi des contraintes à respecter afin de ne pas changer complètement leurs méthodes d'analyse et de s'adapter à tous les cas de logs que les logiciels du système d'information d'edf peuvent fournir. 5.2. Développement spécifique L'étude des développements spécifiques des solutions de base doit se situer avant le choix de la solution, en effet, les résultats de cette étude amèneront à choisir tel ou tel solution selon l'ampleur du développement nécessaire. Ce développement doit prendre en compte la proposition d'architecture et les besoins définis d'edf. il sera fait des concessions selon la faisabilité et la durée des développements envisagés. Malgré le fait que le développement amènera à un prototype fonctionnel sur un ensemble de logs choisis, le système de gestion de logs se devra le plus générique possible : s'adapter à toutes sortes de logs possibles, effectuer différents types de requêtes etc. 5.3. Choix d'une solution L'étape du choix de la solution de base pour le développement est une étape importante. C'est de ce choix que va dépendre tout le développement qui va s'en suivre. La solution choisie doit être la plus apte à répondre aux besoins spécifiés d'edf. Pour cela il faut étudier les expérimentations et analyse des solutions de Frédéric Flouvat, mener des jeux de tests sur les logs fournis par EDF, juger les pour et les contres de chaque solution vis à vis des besoins et analyser les développements à réaliser afin de répondre à ces besoins et correspondre à la proposition d'architecture. 7/8
6. Produits finis 6.1. Les livrables Dossier d'initialisation Le dossier d'initialisation permet de projeter l'avancement du projet selon l'état de départ du projet. Il permet de définir l'organisation du projet et de découper en étapes afin de savoir tout au long du projet où l'on se situe. Dossier "état de l'art" Le dossier "état de l'art" permettra de lister toutes les informations, nouveautés, avancées qui ont été faites jusqu'à ce jour au sujet de l'analyse des logs. Les logiciels sont en constant développement et les recherches ne sont qu'à leur début dans le sujet de l'analyse des logs, il est donc intéressant de faire un point sur ce qui a été fait jusqu'à présent. D'autre livrables sont à préciser lors de la prochaine réunion de mi-parcours. 6.2. Un prototype fonctionnel Le prototype final provient du résultat de développement spécifique associé à la solution choisie. Celui-ci doit répondre aux besoins définis d'edf et à l'architecture proposée par Frédéric Flouvat. il doit permettre d'effectuer des recherches dans des fichiers de logs (recherche d'expressions, de suite d'évènements à certains intervalles de temps, de fréquences d'évènements etc.). Le prototype fonctionnel sera fonctionnel sur un ensemble de jeu de logs fournit par EDF, mais doit tout de même adaptable à un jeu de données inconnues. 7. Référence [1] : "Lot 2 : Proposition d'une architecture pour exploiter les traces générées par EDF" de Frédéric Flouvat. 8/8