Gestion de log : suivi et exploitation d'un

parc informatique via Graylog

Johan THOMAS
Rectorat d'académie de Rennes - SERIA
96 rue d'Antrain
35000 Rennes

Résumé
Cette présentation montre l'utilisation d'un outil (Graylog) de centralisation et d'analyse de fichiers
journaux sur le périmètre d'un parc informatique.
L'originalité de cette solution est donc le périmètre du parc informatique. En effet, les outils de
centralisation de logs sont utilisés plus classiquement au niveau des infrastructures systèmes et réseaux.
Le rectorat de Rennes a déployé sur son parc de plus de 1200 postes répartis sur 9 sites un outil de
récupération et d'envoi des logs/observateurs d'événements. L'outil NXLog permet de convertir au format
GELF les observateurs d'événements et les fichiers journaux des postes et des serveurs en ciblant les
informations d'intérêt. Le serveur Graylog centralise toutes ces informations et les analyse, il permet de
mettre en place des tableaux de bord, des alertes ou de re-router les informations.
Le choix de Graylog se justifie par ses nombreuses fonctionnalités intégrées nativement (tableaux de bord
par utilisateur, alertes, authentification, évolutivité, facilité d'utilisation, etc). Il est à l'origine du format
GELF. Ce dernier apporte de nombreuses améliorations au classique format syslog. Le centralisateur
utilise une base ElasticSearch pour stocker l'ensemble des informations.
Utilisé en production depuis plus de 2 ans, cet outil a permis de mettre en place des tableaux de bord
dynamiques et fonctionnels à destination de l'assistance. Dans certains cas, ces tableaux de bord
permettent aux équipes d'assistance de devenir proactives (intervention avant perte de données par
exemple).

Mots-clefs
Graylog, nxlog, kibana, indicateurs, dashboard, splunk, suivi, ElasticSearch, GELF, syslog.

1 Introduction
Le rectorat de l'académie de Rennes et plus précisément l'équipe d'assistance sur les services du rectorat a
en charge la gestion du parc informatique et des serveurs associés, l'assistance de niveau 2, le conseil et la
formation. Le parc de plus de 1200 postes est réparti sur 9 sites. Ces dernières années un effort important
a été produit pour homogénéiser et moderniser les infrastructures du parc. Ainsi plusieurs projets ont été
conduits autour de ces problématiques, notamment pour les plus importants :
― gestion centralisée ;
― création et mise en conformité avec le référentiel d'identité académique d'un annuaire Active
Directory ;
― refonte et sécurisation des espaces de stockage (personnel et partagé) ;
― migration vers les nouvelles versions de système d'exploitation.

JRES 2015 – Montpellier 1/15

Le changement induit par la conduite de ces projets a fait apparaître très rapidement la nécessité de
disposer de nouveaux outils afin de suivre au plus près l'utilisation, les nouveaux déploiements et ainsi
améliorer les activités quotidiennes de l'équipe d'assistance notamment dans la réactivité et la prise en
compte des demandes.
C'est donc dans cette optique que la mise en place d'une infrastructure de centralisation des fichiers
journaux du parc a débuté en 2013.

2 Principe
Chaque poste informatique dispose de très nombreuses informations sur son fonctionnement. Celles-ci
appelées fichiers journaux ou observateur d'événements sont généralement sous exploitées sur les postes
de travail. Les systèmes de centralisation sur ces problématiques sont principalement utilisés dans le
domaine des systèmes et des réseaux.
L'infrastructure déployée au rectorat de l'académie de Rennes se base sur le principe suivant : « Récupérer
et exploiter cette masse d'informations depuis le poste de l'agent ».

Ce déploiement permet de :
― suivre le fonctionnement et le déploiement des applications ;
― suivre les migrations (dossier personnel sécurisé, Windows 7, etc) ;
― corréler les données des serveurs avec celles des postes ;
― disposer de tableaux de bord fonctionnels ;
― améliorer le dispositif d'assistance ;
― Faciliter le pilotage.
Pour le bon déroulement de ce projet, il a donc été nécessaire de disposer d'un format de communication,
d'une interface avec les postes et d'un centralisateur permettant de traiter et d'exploiter les données.

3 Les logs
Les logs sont les fichiers journaux. Il s'agit d'une information datée qui concerne le fonctionnement du
poste, d'une application ou d'un service. Dans un environnement Windows, on parle d'« observateur
d’événements ». Dans le monde Linux, il s'agit généralement de fichier texte, formaté.
C’est la donnée à exploiter, elle existe sur le poste et contient beaucoup d’informations.
Le cycle de vie d'un événement de fichier journal peut être représenté de la manière suivante :

Figure 1 - Cycle de vie d'un événement de log

3.1 Format Syslog ou format GELF

Lorsque qu'on envisage de monter une infrastructure de centralisation des logs, il faut impérativement se
préoccuper du format de communication.
Historiquement, le format syslog était prédominant, cependant il dispose de nombreuses faiblesses.

JRES 2015 – Montpellier 2/15

Partant de ce constat et de la volonté de toujours traiter plus d'informations, notamment dans les logs
applicatifs, le format GELF (Graylog Extended Log Format) a vu le jour.
Le tableau comparatif ci-dessous permet de se rendre compte des différences principales entre les deux
formats :

Figure 2 - Comparatif Syslog / GELF

Dans le cas de l'infrastructure du parc informatique du rectorat de Rennes, la majorité des données à
traiter provient de postes sous un environnement Windows via l'observateur d'événements. Il a fallu
s'assurer de pouvoir dialoguer dans un format cohérent entre l'observateur d'événements des postes,
l'interface sur le poste et le centralisateur.
Le format syslog étant beaucoup trop limité pour cet usage, nous avons choisi de partir sur l'utilisation du
format GELF qui a l'avantage d'être très facilement extensible.

4 Interface avec les postes : NXLog

Le parc du rectorat de Rennes est majoritairement sous Windows, cependant nous souhaitions aussi
intégrer les postes Linux, les serveurs et éventuellement d'autres systèmes tels que les tablettes Android.

4.1 Comparatif des solutions.

Avant de choisir une solution, nous avons étudié les outils suivants :
― Snare[2] : cet outil permet de se brancher sur l'observateur d'événements mais il ne dispose pas du
support GELF, il aurait donc fallu dialoguer en syslog. De plus il n'est disponible que sous
Windows. Il faudrait donc un outil différent sur les autres environnements.
― NXLog[1] : open source, multiplate-forme, il supporte le GELF. Il est modulaire, les développeurs
le fournissent directement packagé pour les environnements Microsoft (MSI). Sa maintenance est
très simple et on peut faire du filtrage avancé, du routage.
― Graylog collector[3] : non disponible au début du projet, cet outil open source basé sur Java est
multiplate-forme et permet de dialoguer en GELF. Il ne supporte aucun filtrage à la source des
événements ce qui reste un problème pour notre usage et est plus compliqué à maintenir à grande
échelle.
Pour assurer l'interface sur le poste de travail avec le centralisateur, notre choix s'est porté sur la solution
NXLog [1].

4.2 Configuration de base de NXLog

La configuration de base présentée ci-dessous permet l'envoi des informations d'un poste en
environnement Windows avec NXLog vers un centralisateur au format GELF :

JRES 2015 – Montpellier 3/15

 <Extension gelf>
Module xm_gelf
</Extension>

<Input eventlog>
Module im_msvistalog
</Input>

<Output out>
Module om_udp
Host xxx.xxx.xxx.xx
Port 12201
OutputType GELF
</Output>

<Route 1>
Path eventlog => out
</Route>

La syntaxe XML est très simple, il y a quatre sections principales :

1. Extension :cette section permet de charger des modules, notamment pour le format, dans le cas
qui nous intéresse, on charge l'extension pour le format GELF.
2. Input (provenance des événements) : ici on charge le module pour se brancher sur l'observateur
d'événements du poste.
3. Output (destination des événements) : toutes les informations sur le centralisateur sont spécifiées
dans cette section.
4. Route (routage des événements).

4.3 Configuration avancée avec filtrage à la source.

Nxlog est très puissant, il permet d'effectuer un filtrage très précis sur les événements d'intérêt que l'on va
envoyer au centralisateur.
La configuration avancée présentée ci-dessous, s'applique à un environnement Windows. Elle permet de
n'envoyer au centralisateur que les événements de certaines sources et correspondant à une criticité (level
1 = critique, level 2 = erreur, level 3 = avertissement).
Sur ce cas concret, nous ne récupérons que les niveaux 1, 2 et 3 pour les sources : « applications, système,
sécurité, stratégie de groupe, fichiers hors ligne et antivirus » (Kaspersky).
Le choix de ce filtrage à la source a été rendu nécessaire car les postes Microsoft produisent énormément
d'informations. Il a donc fallu cibler les informations à transférer au centralisateur.

<Input eventlog>
Module im_msvistalog
Query <QueryList>\
<Query Id="0" Path="Application">\
<Select Path="Application">*[System[(Level=1 or

JRES 2015 – Montpellier 4/15

 Level=2 or Level=3)]]</Select>\
<Select Path="Security">*[System[(Level=1 or
Level=2 or Level=3)]]</Select>\
<Select Path="System">*[System[(Level=1 or
Level=2 or Level=3)]]</Select>\
<Select Path="Microsoft-Windows-
GroupPolicy/Operational">*[System[(Level=1 or Level=2 or
Level=3)]]</Select>\
<Select Path="Microsoft-Windows-
OfflineFiles/Operational">*[System[(Level=1 or Level=2 or
Level=3)]]</Select>\
<Select Path="Kaspersky Event
Log">*[System[Provider[@Name='avp'] and (Level=1 or
Level=2)]]</Select>\
</Query>\
</QueryList>
</Input>

4.4 Création d'une requête de filtrage via l'observateur d'événements

Avec l'observateur d'événements, il est possible d'obtenir très simplement la syntaxe XML d'une requête.
Pour cela, il suffit d'ouvrir l'observateur d'événements d'un poste pour créer une vue personnalisée.
Ensuite en sélectionnant le ou les journaux, les niveaux de criticité et tout autre critère nécessaire à la
requête, on retrouve la syntaxe sur l'onglet XML.
Il ne reste plus qu'à copier le contenu de cet onglet dans la partie « Query » de la section « Input » de
NXLog.

Figure 3 - Assistant vue personnalisée Figure 4 - Syntaxe XML du filtrage

5 Centralisation des informations : Graylog

Dans le cas du rectorat de Rennes, le centralisateur doit gérer des milliers de poste, donc des millions de
lignes d’informations. Il est donc nécessaire de s'orienter vers une solution capable de supporter ce

JRES 2015 – Montpellier 5/15

dimensionnement et d'évoluer. Depuis quelques années, notamment grâce aux technologies et outils issus
du Big Data, le monde du traitement des logs a considérablement évolué. On retrouve de plus en plus
l'utilisation du trio ELK : ElasticSearch[5], logstash[6] et kibana[7].
Le centralisation des fichiers journaux reste cependant plus dans les domaines système et réseaux.
Le choix de l'équipe de Rennes s'est porté sur la solution Graylog [4] (anciennement graylog2).

5.1 Comparatif des solutions

Ce rapide comparatif est issu de l'étude des solutions disponibles au début du projet, le résultat présenté
est basé sur des critères d'efficience de l'infrastructure, de simplicité dans la configuration et l'utilisation
de la solution et sur les fonctionnalités avancées comme la mise en place d'alerte ou de profilage. Seuls
les produits open source ont été étudiés. On peut classer ce comparatif en trois parties : les solutions
historiques, le trio ELK et Graylog.

Les solutions historiques de centralisation des logs sont basées sur syslog-ng sur lequel on vient greffer
une interface Web et un stockage dans une base de données type mySQL. On retrouve notamment les
outils php-syslog-ng et 8pussy [8].
Ce type d'outil n'a pas été retenu par le rectorat de Rennes. En effet, l'utilisation du format syslog
uniquement est un problème majeur. De plus du fait de leurs infrastructures classiques (LAMP, Linux,
Apache, Mysql, PHP) ils ont du mal à évoluer et à tenir la charge sur des déploiements importants
(volume disque très important, nombre de messages par seconde limité, lenteur de traitement).

L'association ELK est de plus en plus mise en avant. Elle est basée sur le trio ElasticSearch, Logstash et
Kibana. Chacun de ces produits est indépendant et peut être déployé sur des machines distinctes ou sur un
même serveur.
Logstash apporte les fonctionnalités de collecte, d'analyse et de stockage, il peut traiter du format syslog,
du GELF et d'autres formats. Kibana permet quant à lui de générer les tableaux de bord dynamiques avec
les indicateurs. ElasticSearch, quant à lui, est un moteur de recherche distribué avec une base de données
NoSQL.
Chacune de ces briques dispose de sa propre configuration, la mise en place de l'ensemble et la gestion est
complexe. La génération des tableaux de bord n'est pas facile d'accès, il n'y a pas d'authentification et de
profilage. Il n'existe pas de fonctionnalité d'alerte.
C'est une solution hautement personnalisable et extensible mais en l'état, elle ne peut pas être utilisée par
les équipes sans formation. La maintenance de toute cette infrastructure est aussi plus complexe du fait de
l'aspect non intégré.

Graylog est la solution qui est à l'origine du format GELF. Cet outil utilise ElasticSearch et MongoDB.
C'est une solution hautement intégrée.
La configuration, la personnalisation, l'exploitation se fait à travers une interface Web. Il est possible de
collecter différents formats en entrée (syslog, GELF, etc). Graylog permet de mettre en place des flux
(streams) qui ont pour fonction de classer les logs selon des critères, on peut ensuite définir des sorties
(output) pour envoyer les logs sur d'autres destinations. Les streams permettent de créer des alertes.
Graylog dispose d'une API Rest lui permettant de s'interconnecter facilement avec d'autres outils.
La partie interface Web de Graylog dispose d'une authentification et il est possible de mettre en place des
accès profilés. Il est ainsi possible de présenter des tableaux de bord ou des streams à l'ensemble des
personnes accédant à la plate-forme ou seulement à un groupe d'utilisateurs. La prise en main et
l'utilisation par les équipes est très simple. Chaque utilisateur peut facilement créer ses recherches, ses
indicateurs et ses alertes.

JRES 2015 – Montpellier 6/15

Les deux solutions ELK et Graylog ont été testées sur le périmètre du rectorat. Elles utilisent toutes les
deux ElasticSearch et ont donc les mêmes besoins en terme de stockage. Elles supportent très facilement
un dimensionnement important. Leurs performances sont équivalentes.
Le choix du rectorat de Rennes s'est porté sur Graylog. Son aspect intégré, ses nombreuses fonctionnalités
natives et surtout sa facilité de prise en main le rendent réellement fonctionnel.

A noter qu'une solution commerciale permettant d'obtenir un fonctionnement assez similaire existe, elle se
nomme Splunk[9].

5.2 Mise en place et dimensionnement de la solution

Le serveur mis en place à Rennes, est unique et dédié à cet usage. Il dispose de :
― ElasticSearch pour le stockage des événements,
― MongoDB pour le stockage de la configuration de Graylog (streams, tableaux, etc),
― Graylog-server, cœur de l'application,
― Graylog-web pour l'interface web de graylog.
Chacune de ces briques peut être isolée sur un autre serveur et mis en cluster pour apporter une meilleure
évolutivité, de la redondance et de la haute disponibilité.
L'installation est grandement facilitée par l'équipe derrière Graylog, car ils fournissent des dépôts de
paquets pour une majorité d'environnement Linux mais aussi des containers et des images virtuelles.

Le serveur virtualisé utilisé à Rennes est dimensionné de la façon suivante : 2 vCPU, 8Go de RAM, 1
disque de 16Go pour l'OS est un disque de 110 Go pour le stockage des logs dans la base ElasticSearch.
La mise en place d'un cluster ElasticSearch est envisagée.
A l'usage sur deux ans d'exploitation, on constate qu'il faut 1Go d'espace ElasticSearch par million
d'événement stocké. Le serveur absorbe sans problème des pics de plus de 300 messages par seconde.

Les schémas ci-dessous reprennent de manière synthétique l'architecture de la solution.

Figure 5 - Architecture simplifiée

JRES 2015 – Montpellier 7/15

 Figure 6 - Schéma détaillé de l'architecture Graylog

5.3 Utilisation de Graylog

5.3.1 Input
Une fois l'infrastructure déployée, la première étape consiste à créer un « Input » via l'interface de
Graylog. Il suffit pour cela de se rendre dans le menu « System/Inputs » et ensuite créer un input au
format GELF (UDP ou TCP). Celui-ci se chargera donc de recevoir les logs en GELF. Le démarrage,
l'arrêt et le suivi (nombre de messages reçus, etc) sont pilotables depuis l'interface de Graylog.
On peut créer des input de différent type (syslog, GELF, etc). Lorsqu'il est démarré, les logs commencent
à arriver.

JRES 2015 – Montpellier 8/15

 Figure 7 - Input GELF UDP

5.3.2 Recherche, quick values et dashboard

Pour la recherche et l'extraction des données, Graylog dispose d'un moteur de recherche très simple. Il
permet de rechercher en fonction des champs du format GELF mais aussi tout texte libre. Il est aussi
possible d'utiliser les opérateurs classique des moteurs de recherche : jointure AND et OR, NOT et de
spécifier une plage horaire. Les utilisateurs peuvent enregistrer leurs recherches.

Figure 8 - Moteur de recherche

Il est possible à partir des recherches de générer très simplement des tableaux de bord mis à jour en temps
réel. On peut facilement récupérer l'histogramme de la recherche ou l'indicateur correspondant au nombre
total de logs retourné.
Il est même possible d'aller beaucoup plus loin avec la fonctionnalité de « Quick values ».
Dans l'exemple présenté sur la figure ci-dessous, j'ai effectué une recherche des erreurs d'authentification
des postes Windows sur les 2 dernières heures. Je déploie ensuite dans la colonne « Fields » le champ
« TargetUserName » (qui provient du format GELF) afin de faire apparaître la ligne « statistics, quick
values, generate chart ». En cliquant sur « Quick Values », j'obtiens le diagramme et le tableau

JRES 2015 – Montpellier 9/15

récapitulatif mis à jour en temps réel des erreurs d'authentification par TargetUserName.
C'est une fonctionnalité extrêmement intéressante qui permet aux utilisateurs de générer des tableaux de
bord (« Add to dashboard ») très simplement.

Figure 9 - Quick values: erreurs d'authentification par TargetUserName

5.3.3 Extracteurs
Graylog dispose d'une fonctionnalité intéressante : les extracteurs. Elle permet d'extraire une information
d'un message.
Généralement, les logs au format GELF de bout en bout sont bien structurés. Il peut arriver qu'une
information importante soit dans un message complexe de texte ou dans un tableau.
Dans ce cas, impossible d'exploiter la donnée dans un graphique ou avec un indicateur. Les extracteurs
permettent de remédier à ce problème. Pour cela, on peut utiliser les fonctionnalités suivantes : substring,
regex, split & index, copy et grok.
Je prends comme exemple concret, l'utilisation d'un serveur de licences Microsoft (KMS). Le rectorat de
Rennes souhaitait suivre son utilisation notamment en récupérant le nom DNS des postes qui viennent
s'activer dessus. L'information est présente dans l'observateur d'événements mais le formatage ne permet
pas de récupérer la donnée convenablement. Pour cela, on crée un extracteur qui utilisera le « Split &
Index ». Le champ du log à utiliser est « full_message », dans celui-ci les informations sont séparées par
des virgules. Le « Split & Index » va donc séparer en plusieurs parties en se basant sur les virgules puis
récupérer la troisième partie dans un nouveau champ « KMS_host ».

Figure 10 - Extracteur du nom de la machine s'activant sur le KMS

Voici une partie des extracteurs configurés pour l'utilisation de l'assistance de Rennes.

JRES 2015 – Montpellier 10/15

 Figure 11 - Liste d'extracteurs

5.3.4 Les streams et alertes.

Les « streams » permettent de classer les messages répondant à certains critères. Cette fonctionnalité
permet de mettre en place des alertes. Ici on cible les événements avec un ID particulier qui correspond
aux authentifications rejetées. On gére ensuite l'envoi d'alerte (mail ou appel HTTP) en précisant le seuil
et les destinataires. Dans notre cas, un mail est envoyé s'il y a plus de 1 message dans les 5 dernières
minutes. La période de grâce est de 60 minutes.

Figure 12 - Stream pour les authentifications AD rejetées

6 Cas concret d'usage de la solution dans les services du

rectorat de Rennes
L'ensemble du parc informatique est configuré pour envoyer les informations ciblées sur le serveur
Graylog. A cela s'ajoute, la plupart des serveurs (Windows et Linux) utilisés par le parc informatique
(contrôleurs de domaine, serveurs d'impression, serveurs de fichiers, serveurs de bureau à distance,
serveurs de bases de données, serveurs de licences) et une petite partie des équipements réseaux.
On se retrouve avec un serveur qui centralise plus de 1200 sources distinctes.
Après une période d'analyse des informations reçues, l'équipe d'assistance a défini des tableaux de bord
mis à jour en temps réel. Des règles d'alerte (fonctionnalité native de Graylog via les streams) ont aussi
été créées.
Les exemples présentés ci-dessous sont issus de l'utilisation de cet outil sur plus de 2 ans de production
avec une base d'environ 100 000 000 événements (en intégrant le filtrage à la source sur les postes de
travail).
Il est important de préciser que chaque utilisateur a la possibilité de créer ses propres tableaux de bord et
alertes. Graylog disposant d'une authentification et d'une gestion de groupe reliés au référentiel d'identité
de l'académie de Rennes, il est possible de présenter des indicateurs à une certaine catégorie de personne
très simplement. La présentation des informations de base est issue d'une concertation avec l'équipe.

JRES 2015 – Montpellier 11/15

6.1 Suivi de l'exploitation de l'infrastructure Active Directory
Les tableaux de bord présentés ci-dessous permettent de suivre en temps réel l'infrastructure Active
Directory du rectorat. L'équipe d'assistance peut ainsi visualiser les opérations et les détails concernant les
créations de compte ou de groupe, les suppressions et modifications d'appartenance. Ces opérations étant
entièrement automatisées, cela permet d'avoir une très bonne visibilité sur ces problématiques.

Figure 13 - Tableau de bord sur les changements de groupe AD

6.2 Assistance proactive sur la perte de données et les problèmes de

stockage
Chaque poste de travail signale lorsqu'un fichier est mal nommé (caractère illégal ou fichier trop long).
De la même manière, nous récupérons les informations sur les erreurs de disque dur, de redémarrage ou
d'arrêt brutal. Toutes ces informations sont regroupées dans les tableaux de bord ci-dessous. L'équipe
d'assistance via ces indicateurs est capable d'intervenir avant qu'un utilisateur ne perde des données.

JRES 2015 – Montpellier 12/15

 Figure 14 - Suivi des erreurs de postes, de fichiers et de disque

Figure 15 - Indicateurs sur les erreurs de fichiers

JRES 2015 – Montpellier 13/15

 Figure 16 - Alerte sur caractère non autorisé (stream)

6.3 Autres exemples (virus, aide à la résolution de lenteurs)

A l'usage, nous nous sommes rendus compte que nous pouvions aller encore plus loin dans l'utilisation de
Graylog pour améliorer l'assistance.
Ainsi des tableaux de bord sont venus se rajouter, notamment sur deux sujets sensibles dans le gestion
d'un parc informatique : celui du suivi des infections virales et celui de l'aide à la résolution des lenteurs.
Nous avons rajouté les informations de suivi des attaques de virus en provenance du poste de travail. Le
rectorat de Rennes dispose d'un serveur d'antivirus qui permet lui aussi d'obtenir ces informations mais le
fait de rajouter ces informations sur Graylog permet de disposer d'une interface unique.

Autre exemple, avec les équipes en charge de l'infrastructure système et réseau, nous avons mis en place
un ciblage particulier sur les temps d'ouverture de session des postes, les lenteurs d'application des
stratégies de groupe, les erreurs de résolution, etc. Cela nous a aidé dans la résolution de problèmes
d'infrastructure.
Cela permet d'avoir en temps réel, un état de santé sur le fonctionnement du parc informatique et du
réseau.

6.4 Évolutions envisagées

Cette solution a permis d'obtenir une meilleure qualité de service pour les utilisateurs. Que ce soit dans le
suivi des évolutions sur le parc ou dans la mise en place d'une assistance efficace et proactive.
Actuellement, l'équipe de niveau 2 utilise cet outil, il pourrait être utile de fournir certains tableaux de
bord aux équipes d'assistance de niveau 1. La solution le permet très simplement et c'est une évolution
envisagée.
Nous avons constaté que Graylog était très performant, il serait intéressant d'aller encore plus loin dans la
centralisation des informations et l'exploitation des données en associant encore plus de serveurs. Cela
permettrait de corréler les logs entre postes de travail et serveurs, tout en gardant en tête le service rendu à
l'usager.

JRES 2015 – Montpellier 14/15

Bibiographie
[1] http://www.nxlog.org
[2] https://www.intersectalliance.com/our-product/snare-agent/
[3] http://docs.graylog.org/en/latest/pages/collector.html
[4] http://www.graylog.org
[5] https://www.elastic.co/products/elasticsearch
[6] https://www.elastic.co/products/logstash
[7] https://www.elastic.co/products/kibana
[8] http://www.octopussy.pm/
[9] http://www.splunk.com/fr_fr

JRES 2015 – Montpellier 15/15