Projet FluentD - LORIA

Projet FluentD

CORBO Julien - DEVEAUX ClementDUGNY Quentin - MENGES Leo

25 mars 2019

Licence ASRALL Tuteur : Stephane Casset

1

CORBO DEVEAUX DUGNY MENGES Licence pro ASRALL

Table des matieres

1 Remerciement 3

2 Introduction 42.1 Presentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Objectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Objectifs d’une collecte de logs . . . . . . . . . . . . . . . . . . . . . . 42.4 Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Comparaison avec d’autres systemes d’exploitation de logs 53.1 Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 ELK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3 DataDog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.4 Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.5 Tableau comparatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Solutions utilisees 84.1 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1.1 Presentation generale . . . . . . . . . . . . . . . . . . . . . . . 94.1.2 Docker Compose . . . . . . . . . . . . . . . . . . . . . . . . . . 104.1.3 Docker Swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.1.4 Docker stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 EFK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.1 FluentD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2.1.1 Presentation generale . . . . . . . . . . . . . . . . . . 124.2.1.2 Notre configuration . . . . . . . . . . . . . . . . . . . 134.2.1.3 Comparaison avec Logstash . . . . . . . . . . . . . . . 13

4.2.2 Elasticsearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.2.1 Presentation generale . . . . . . . . . . . . . . . . . . 144.2.2.2 Comparaison avec InfluxDB . . . . . . . . . . . . . . . 15

4.2.3 Kibana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.3.1 Presentation generale . . . . . . . . . . . . . . . . . . 154.2.3.2 Illustration avec capture d’ecran . . . . . . . . . . . . 16

4.3 Serveur web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Partage de fichier 175.1 Utilite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.2.1 NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2.2 SCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6 Scripts 186.1 Premier script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186.2 Deuxieme script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7 Problemes rencontres 197.1 NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197.2 FluentD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

8 Organisation 198.1 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198.2 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

9 Conclusion 21

10 Indexes - Sources 21

11 Annexes 22

Projet FluentD 2 25 mars 2019


1 Remerciement

Nous remercions l’ensemble du jury, professeurs et professionnels, pour leurs en-seignements, leurs conseils et leurs remarques tout au long de ce projet et de cetteannee. Notamment notre tuteur Stephane Casset, qui a su etre la pour nous, nousexpliquer notre sujet, nous aider lors de problemes que l’on a rencontre tout au longdu projet et nous conseiller sur les methodes de travail a utiliser pour etre le plusproductif possible.

Figure 1 – Logo IUT Charlemagne



2 Introduction

2.1 Presentation du sujet

Le sujet de ce projet tuteure est d’effectuer une centralisation des logs de plusieursmachines qui hebergent diverses applications, ici ce sera un cluster docker ou les ma-chines hebergeront des applications web.

2.2 Objectif du projet

Nous voulons donc mettre en place une solution permettant une recuperation delogs, son traitement, et de pouvoir les visualiser plus facilement. Pour arriver a celanous allons deployer avec l’outil Docker, une infrastructure contenant des outils quicollecterons des logs provenant d’un serveur web, les traiteront, et nous permettrontde les visualiser grace a des graphiques qui sont filtres suivant les besoins.

2.3 Objectifs d’une collecte de logs

Un fichier de log designe un fichier ou va etre inscrit les evenements qui se sontpasses dans une application, un systeme, une machine ou un service, en lisant unfichier de ce type nous pouvons donc connaıtre l’historique des actions qui se sontpasses. En informatique ces logs sont donc tres importants car ils facilitent grande-ment la comprehension d’une erreur ou d’une quelconque activite.

Dans une entreprise, avoir un outil permettant de recentrer au meme endroit leslogs de dizaines, voire centaines de machines est une force. Cela permet de faciliter lacollecte de logs, son exploitation et son traitement car il n’est pas necessaire de devoiraller les chercher a la main sur differents serveurs, ou differents fichiers.

La gestion de logs, n’a cesse d’evoluer au fil des annees, notamment grace auxsolutions open-source.

Dans la gestion de logs, il y a differentes etapes :

— La collecte : Il est possible d’utiliser differentes solutions, il y a un FluentD quiest la solution utilisee dans notre projet et que nous allons comparer pour cerapport a Logstash.

— L’indexation et le stockage : Ce sont deux parties distinctes qui sont toutesdeux gerees par ElasticSearch, nous comparerons cette solution avec InfluxDB.L’indexation est ce qui va permettre de trier les logs et de pouvoir, en creantdes filtres dans Kibana, trouver des logs specifiques.

— La visualisation : Puis, quand les donnees sont collectees, indexees et stockees,il est plus facile de pouvoir les visualiser, Kibana permet de repondre a ce be-soin. C’est un logiciel open-source permettant de pouvoir creer des graphiques,de toutes formes, suivant les donnees collectees par FluentD.

Actuellement plusieurs solutions sont possibles pour une gestion de logs perfor-mantes, des outils comme EFK, ELK, Splunk ou encore syslog.

Quels sont les objectifs de la gestion de logs ?

— Reunir a un endroit ou l’on peut voir tous les logs d’un reseau, sans devoiraller sur differents fichiers ou serveurs.

— Pouvoir comprendre plus rapidement d’ou vient un probleme.— Pouvoir visualiser, superviser les logs des serveurs facilement.— Avoir un Dashboard clair montrant les logs, avec des graphs filtres suivant les

besoins.— Etre alerte en temps reel s’il y a une activite suspecte.— Pouvoir traiter et exploiter ces donnees.



2.4 Contraintes

— Mettre en place un cluster Docker et d’y mettre en place des applications web.— Mettre en place l’exportation des journaux dans FluentD dans ce cluster.— Mettre en place des Dashboard pour visualiser les journaux recoltes.— Ecrire des scripts simples permettant de generer du trafic.

Parmi les solutions proposees, nous avions ElasticSearch, FluentD et Kibana (EFK),nous pouvions remplacer ElasticSearch et Kibana par d’autres solutions mais toujoursen gardant FluentD.

3 Comparaison avec d’autres systemes d’exploita-tion de logs

Afin de realiser ce projet nous aurions pu utiliser d’autres solutions, notammentles logiciels Splunk, EFK ou DataDog.

3.1 Splunk

La multinationale americaine creee en 2003 et basee a San Francisco produit deslogiciels de recherche, de suivi et d’analyse de logs. Le produit en lui-meme, collecte,indexe et met en relation des donnees en temps reel, il permet egalement de genererdes graphiques, des rapports, des alertes predefinies a l’avance grace a son interfaceweb. Il est possible de definir differents types d’utilisateurs avec des droits differents.

Figure 2 – Fonctionnement de Splunk

Voici le schema de fonctionnement de Splunk, on constate bien que les logs etautres donnees sont recuperes par Splunk puis sont accessibles sur l’interface web parles differents types d’utilisateurs.

La version gratuite de Splunk enterprise nous donne acces seulement a 500 mo parjour ce qui est tres peu pour la gestion de logs. Le fait que Splunk soit payant nousa permis d’ecarter cette stack pour la realisation de notre projet.



Tableau Avantages/Inconvenients de Splunk

Figure 3 – Tableau Splunk

Figure 4 – Logo Splunk

3.2 ELK

ELK est une stack de collecte, d’indexation et de visualisation de logs comme lastack EFK, compose de Elasticsearch, Logstash et Kibana, il utilise uniquement deslogiciels de la suite elastic contrairement a EFK.

lastic a implemente Beat dans son stack ELK depuis 2015 suite a une forte de-mande des utilisateurs. Beat se decompose en plusieurs agents, Filebeat pour les logs,Metricbeat pour les metriques, PacketBeat pour les donnees reseaux et d’autres en-core. FileBeat permet par exemple de fluidifier le trafic car, il integre un protocole deregulation de flux et de rechercher des informations plus facilement sur Kibana parexemple avec la commande tail.

Tableau Avantages/Inconvenients de ELK

Figure 5 – Tableau ELK



Figure 6 – Logo ELK

3.3 DataDog

Cree en 2010, cette entreprise a l’avantage d’avoir ete cree par deux Francais maisce n’est qu’en 2016 que la stack entiere de monitoring est mise a disposition des clients.

DataDog est un logiciel de monitoring qui permet de monitorer des serveurs, desbases de donnees ou bien des services et plus encore. Tout comme les autres stacksde monitoring il permet de recuperer des donnees, de les indexer, de les visualiser,de creer des alertes. Il possede une version d’essai gratuite, mais il est vite necessairede passer a la version payante a cause de la pauvrete des options donnees en versiond’essai. Tout comme Splunk, DataDog n’est pas un logiciel open source et demandeun abonnement afin de l’utiliser au maximum de ses fonctionnalites.

DataDog n’etant pas un logiciel open source gratuit, nous ne voulions pas l’utilisercar cela aurait ete a l’encontre de la philosophie de notre Licence ASRALL qui se veututiliser le plus possible des logiciels libres.

Tableau Avantages/Inconvenients de DataDog

Figure 7 – Tableau DataDog

3.4 Syslog

Syslog est un outil developpe en 1980, qui permet la centralisation de journauxd’evenement generes par des applications qui sont ranges dans le repertoire /var/log/.

C’est une solution datant, et donc qui n’est pas aussi performantes que celles d’au-jourd’hui, car Syslog range les journaux dans un simple fichier, et listes ligne par ligne,ce qui n’est pas facile a lire, comprendre et exploiter.

Dans chaque ligne on y trouve plusieurs informations :

— La date a laquelle l’evenement a ete declenche.— Le processus declencheur de l’evenement.— Le processus ayant demande l’ajout du message correspondant au log.— Le niveau de gravite du message.



3.5 Tableau comparatif

Voici un tableau comparatif entre les differentes stack de centralisation de journauxEFK, ELK, Splunk et DataDog :

Figure 8 – Tableau comparatif des solutions

Le machine learning :

Le machine learning dans le cas d’un systeme de logs est de pouvoir analyser lecomportement des logs et d’apprendre les habitudes d’un service. Grace a ca, il pourraprevenir automatiquement par alerte si un probleme est detecte. Comme par exempleun fort taux de connexion sur serveur web.

4 Solutions utilisees

Donc pour arriver a l’objectif de notre projet, nous devons mettre en place dessolutions permettant de collecter des donnees, de les stocker, de les indexer et de lesvisualiser, et tout ceci avec Docker.

Dans un premier temps nous avons installe notre cluster docker avec un manageret deux worker comme suit :



Figure 9 – Dowker swarm

Ensuite nous avons deploye grace a des fichiers de configuration, docker-compose,des conteneurs avec Kibana, FluentD, Elasticsearch et un serveur web, dans notrecluster Docker.

4.1 Docker

4.1.1 Presentation generale

Docker est un logiciel libre permettant de deployer des applications dans des conte-neurs grace a des images conteneurs, que ce soit sur Windows ou Linux.

Un conteneur docker peut s’apparenter a une machine virtuelle, mais ce n’en estpas une. Une machine virtuelle va, comme son nom l’indique, contient tout un systemeentier alors qu’un conteneur utilise les ressources du systeme hote.

Figure 10 – Image Docker



Pour pouvoir lancer un conteneur docker nous avons besoin d’une image docker,il s’agit de l’ensemble des processus et fichiers necessaires.

Les avantages de l’utilisation de Docker :— Un deploiement rapide des conteneurs.— Un developpement d’application peu couteux.— Des applications tests pouvant etre modifiees sans engendrer de problemes sur

les autres conteneurs.

Les inconvenients de l’utilisation de Docker :

— Une difficulte a gerer simultanement plusieurs conteneurs.— Niveau securite, les systemes d’exploitation sont partages, donc si le systeme

d’exploitation hote est cible d’attaque ou possede une faille cela peut compro-mettre le bon fonctionnement des conteneurs et leur securite.

Figure 11 – Logo Docker

4.1.2 Docker Compose

Docker Compose est un outil qui permet de definir une pile applicative completeformee eventuellement de plusieurs services qui chacun sont deployes dans un conte-neur. C’est un fichier en langage YAML qui sert de configuration.

Cela permet donc de pouvoir creer des conteneurs configures rapidement, pour parexemple des tests reseaux ou alors de developpement, de production sans impacterles autres conteneurs. Une fois le fichier creer il ne suffit que d’une commande pourpouvoir proceder au demarrage des services a partir de notre configuration :

docker-compose -c deploy docker-compose.yml “nom”

Remarque : Le fichier ne doit pas obligatoirement etre appele “docker-compose.yml”mais il suffit juste de respecter la syntaxe du fichier.

Voici un exemple de comment se constitue un fichier docker-compose.yml :



Figure 12 – Docker compose

Nous pouvons voir ligne six que nous utilisons deux sections en plus pour FluentD :— “build”, c’est ici que l’on renseigne l’endroit ou se trouve le fichier Dockerfile

qui va installer FluentD.— “volumes”, c’est ici que l’on renseigne l’endroit ou se trouve le fichier de confi-

guration pour l’indexation des logs par FluentD.Docker permet grace au driver de logs, de gerer la maniere dont nous souhaitons

recuperer les logs generes par le swarm docker. Plusieurs drivers sont supporte (syslog,json-file, splunk etc..), comme nous pouvons le voir ci-dessus, nous utilisons le driver“json-file” pour FluentD et “FluentD” pour l’application Web car l’on veut que cesoit ce dernier qui recupere les logs.

4.1.3 Docker Swarm

Docker swarm est un outil permettant de creer un cluster de conteneurs Dockerafin de creer un groupe de serveurs hotes executant Docker et de les exposer pourqu’ils ne forment qu’un seul hote, puis de pouvoir configurer des conteneurs en gerantautomatiquement la repartition de la charge et la gestion de l’etat du cluster.

Un cluster docker contient un ou plusieurs noeuds (un noeud est le nom donnepour une machine) qui est base sur une architecture manager-worker. Les managerssont obligatoires dans un cluster, il peut y avoir un cluster sans worker mais pas l’in-verse. C’est depuis les managers que l’on peut voir les services et les noeuds presentsur le cluster.



Figure 13 – Docker swarm

Docker swarm et Docker compose sont similaires sur un point, ils se basent tous lesdeux sur le meme fichier docker-compose.yml, mais Docker swarm est utilise quand ilest question d’un cluster Docker, alors que Docker compose lui permet juste de gererun conteneur a la fois.

4.1.4 Docker stack

C’est la commande permettant de deployer des applications dans un cluster swarm,un fichier de configuration docker-compose.yml doit etre present sur les managers etnon les worker, mais par contre les fichiers et repertoires mappes a l’interieur desconteneurs doivent etre present au meme endroit sur tous les nœuds du cluster.

4.2 EFK

4.2.1 FluentD

4.2.1.1 Presentation generale

FluentD est un logiciel de collecte de donnees concu pour traiter les flux dedonnees. C’est un logiciel open source, ce qui signifie qu’il est completement libred’utilisation et constamment affine par sa base d’utilisateurs. FluentD permet d’uni-fier les methodes de collecte et de consommation de donnees pour permettre de mieuxcomprendre et utiliser les donnees.

FluentD dispose d’une couche de journalisation unifiee pour separer les systemesprincipaux des sources de donnees importantes. Cela unifie tous les aspects de la col-lecte et du traitement des donnees, de la collecte au filtrage, en passant par la miseen tampon et la sortie sur plusieurs destinations. Cette unification permet de garderles donnees claires, concises et precises.

FluentD a egalement plus de cinq cents plugins pour rester connecte aux sortieset aux sources de donnees. Il est possible de choisir les plugins qui repondent a desbesoins uniques en matiere de collecte de donnees. Contrairement a d’autres logicielsde collecte de donnees, FluentD conserve un noyau simpliste, de sorte que a ne pasperdre de temps a personnaliser et a masquer differentes fonctionnalites.

FluentD est ecrit avec une combinaison de langages de programmation Ruby et Cet necessite tres peu de ressources systeme. L’instance vanilla peut fonctionner sur 40Mo de memoire tout en traitant 13 000 evenements par seconde. Il existe egalementune alternative legere appelee Fluent Bit pour les personnes ayant des besoins enmemoire plus strictes.

Plus de cinq mille entreprises basees sur les donnees utilisent actuellement FluentD,car il s’agit d’un outil logiciel qui a fait ses preuves. Le plus grand utilisateur de



FluentD collecte actuellement des donnees de plus de cinquante mille serveurs. Mi-crosoft, Nintendo et Amazon Web Services ne sont que quelques-unes des entreprisesqui utilisent FluentD.

FluentD fait partie de la “Cloud Native Computing Foundation”. Le CNCF a etecree pour creer des ecosystemes numeriques durables et encourager les communautesautour d’un certain nombre de projets open source de haute qualite. Tous les compo-sants de FluentD sont disponibles gratuitement avec la licence Apache 2.

FluentD prend en charge la mise en memoire tampon base sur fichier et surmemoire, ce qui ajoute un niveau de protection aux donnees. Il prend egalementen charge un basculement robuste et peut-etre configure pour prendre en charge lahaute disponibilite.

FluentD a une communaute forte et il est facile de trouver le soutien de la com-munaute pour tout probleme qui pourrait survenir. Il existe un outil de suivi desproblemes publics, un flux Twitter, une presence sur Facebook et un groupe Google.Et bien sur, le code source lui-meme est librement accessible.

4.2.1.2 Notre configuration

La configuration de FluentD est ecrite dans le fichier fluent.conf comme ceci :

Figure 14 – Configuration FluentD

Nous pouvons retrouver certaines informations qu’il y a aussi dans le fichier docker-compose comme les ports utilises par FluentD par exemple. Ensuite de la ligne 9 a20, il s’agit des options que l’on utilise pour indexer les logs dans ElasticSearch.

4.2.1.3 Comparaison avec Logstash

FluentD peut se comparer a Logstach, un logiciel libre, qui lui est similaire,developpe par Elastic, ils permettent tous les deux de collecter des logs et de lesanalyser, il utiliser les logs donnes en entree pour les centraliser et les parser, c’est-a-dire de sauvegarder les informations essentielles des logs puis les sauvegarder dans



Elasticsearch.

Figure 15 – Logo Logstash

Le fonctionnement de Logstash se decompose en trois grandes parties, premierementles plugins d’entree qui permettent de recolter des donnees variees comme des fichiersde logs de base de donnees par exemple.

Deuxiemement, il va utiliser des filtres qui lui permettront de lire les donnees etde les exploiter, ces donnees peuvent etre sous forme de JSON ou XML par exemple.

Logstash et FluentD sont tous les deux compatibles Windows, Linux et MacOS,par contre, Logstash utilise beaucoup plus de memoire vive que FluentD. FluentDetant un logiciel moins connu que Logstash, mais qui a l’air d’avoir su conquerir sesutilisateurs nous avons prefere tourner notre choix vers lui.

Pour finir, il utilise les sorties qui definissent ou vont etre envoyees les donneestraitees, par exemple pour une stack ELK il enverra les donnees vers Elasticsearch.

4.2.2 Elasticsearch


Elasticsearch est une base de donnees capable d’indexer des documents texte. Il estcomparable a un moteur de recherche, mais entierement parametrable pour repondrea nos besoins de recherche, il est aussi capable de stocker une grande quantite dedonnees. Ainsi Elasticsearch sera capable d’extraire des statistiques en temps reel.

Afin d’inserer des donnees dans la base de donnees, Elasticsearch va automatique-ment creer des documents JSON, c’est-a-dire un document qui stocke les informationsde maniere structuree.

Pour proceder a la recherche d’informations, Elasticsearch utilise le moteur de re-cherche Lucene, un logiciel OpenSource Apache qui est beaucoup utilisee sur les sitesweb pour creer des moteurs de recherche dedies.

La recherche sera effectuee selon le principe suivant : la pertinence du resultat estevaluee en fonction du nombre de fois ou le mot-cle entree est retrouve dans l’ensembledu document, ainsi que la taille du document puis un indice de pertinence sera calcule.

Les recherches peuvent etre affinees pour effectuer la recherche uniquement sur letitre d’un document, ou sur n’importe quelle balise JSON presente dans les documentspour rendre les recherches plus efficaces.

Elasticsearch suit un modele de base de donnees NoSQL orientee colonnes : unmot correspond donc a une colonne, cette colonne a pour valeur le poids du mot danschacun des documents.



Figure 16 – Logo Elasticsearch

4.2.2.2 Comparaison avec InfluxDB

InfluxDB est une solution logiciel open-source developpe par InfluxData en Go,c’est aussi une base de donnees qui va stocker les donnees de series temporelles, demetriques d’application.

Il a comme langage de requete InfluxQL qui est de type SQL et qui sert a interagiravec les donnees. Il est donc simple a prendre en main pour quelqu’un qui connaıt lelangage SQL.

Il peut traiter plusieurs millions de points de donnees par seconde et pour eviterd’avoir des problemes de stockage, il les compacte automatiquement et minimise l’es-pace de stockage.

Il utilise aussi une strategie permettant de supprimer automatiquement les donneesobsoletes.

4.2.3 Kibana


Kibana est un logiciel open-source permettant la visualisation de donnees d’Elas-ticsearch instantanement et de les rendre lisibles graces a des graphiques pour arrivera un dashboard clair, plutot qu’un fichier basique avec des lignes de logs.

Avec Kibana nous avons le choix de comment visualiser les logs et de la mise enforme, nous pouvons creer des filtres pour n’afficher que les logs qui nous interesse.Il y a des graphiques lineaires ou nuages de points par exemple et il est possible decreer ses propres graphiques en utilisant le langage Vega.

Ces graphiques peuvent permettre de connaitre les horaires de quand est solliciteun serveur web, quelles sont les pages les plus demandees, ou quel moteur de rechercheest utilise.

Kibana permet aussi d’analyser les relations de donnees, de detecter des anomaliesdans ces dernieres et de decouvrir la raison de ces anomalies grace a des plugins.

Il est aussi possible de partager les visualisations de Kibana, grace a un partagede lien, une exportation dans le format que vous voulez, tout en securisant l’acces acette supervision avec un controle d’acces avec des roles.

Kibana est donc un tres bon outil interactif permettant une visualisation clairede donnees, d’alerte en cas de probleme et tout ceci accessible a tout le monde, carpour faire utiliser Kibana il n’est pas necessaire de savoir coder, tout est possibledirectement sur l’interface graphique.



Figure 17 – Logo Kibana

4.2.3.2 Illustration avec capture d’ecran

Pour pouvoir voir les logs nous avons besoin de creer un index :

Figure 18 – Creation d’index Kibana

Une fois l’index creer, nous pouvons voir les logs comme ceci :

Figure 19 – Affichage des logs sur Kibana

Il est possible de faire derouler chaque entree pour voir le fichier JSON correspon-dant.



4.3 Serveur web

Dans notre projet, nous avons comme mission la centralisation de journaux de logsDocker, donc nous avons choisi de generer des logs sur un serveur web, on aura unscript simple qui creera de l’activite dans notre infrastructure Docker et donc des logsque nous pourrons exploiter par la suite. Ce serveur web sera deploye avec Dockeravec une image ”httpd”.

Ce dernier est deploye comme tous les autres (mais dans un fichier docker-composea part) avec la commande docker stack :

Figure 20 – docker-compose-httpd

5 Partage de fichier

5.1 Utilite

Pour pouvoir avoir des facilites dans la mise en place d’EFK, nous avons besoind’avoir les memes fichiers de configuration sur tous les nœuds du cluster docker.

Le partage de fichier est donc important. Pour pouvoir eviter de se connecter surchaque machine pour ecrire/modifier des fichiers qui sont deja present sur une de nosmachines par exemple.

Les fichiers de configuration etant :

5.2 Solutions

Pour cela nous avons essaye deux solutions differentes lors de notre projet, unserveur NFS, et la commande SCP qui a ete notre choix final.

5.2.1 NFS

Pour commencer, nous avons choisi la solution de creer un serveur NFS (NetworkFile System).



Il nous a donc fallu creer un serveur NFS sur une autre machine virtuelle pour en-suite monter un repertoire de chacun de nos nœuds dessus. Tout d’abord, sur chacunedes machines (clients et serveur) il faut installer les paquets nfs-common et nfs-kernel-server.

Ensuite, il faut autoriser les adresses de nos machines clientes a se connecter surle serveur NFS grace au fichier /etc/exports :

/chemin/du/repertoire/serveur 192.168.1.X1(rw) 192.168.1.X2(rw)

X1 et X2 representent ici 2 adresses qui ont l’autorisation de lire et d’ecrire sur lerepertoire indique.

Pour que cela soit fait a chaque redemarrage, nous devions ajouter une ligne deconfiguration sur le fichier fstab sur les machines clientes :

192.168.1.X :/chemin/du/repertoire/serveur /chemin/du/repertoire/clientnfs rw 0 0

5.2.2 SCP

Suite a nos nombreux problemes dans la mise en place de la solution NFS, nousavons decide d’arreter d’essayer cette solution et d’utiliser SCP.

SCP est une methode de transfert de fichier a travers le protocole SSH, il necessitedonc la possibilite de se connecter en SSH depuis les machines.

Dans notre cas nous avons mis nos fichiers de configuration sur le noeud managerpour ensuite les envoyer depuis ce meme nœuds sur les nœuds worker.

scp -r -p chemin/source user@serveur2 :chemin/destination

L’option -r indique la recursiviteL’option -p preserve les dates de modification, d’acces, et les modes des anciens fi-chiers.

6 Scripts

Afin de generer des logs sur les serveurs webs, nous avons ecrit deux scripts enruby. Nous avons decide d’ecrire nos scripts en ruby parce que nous avons appris celangage au cours de cette annee et que c’est un langage de programmation libre.

6.1 Premier script

Le premier script consiste a envoyer n requetes au serveur web ou n est defini enparametre de script. Ce type de script peut etre utilise a simuler une forte affluencede visiteur sur un site web. Voici une capture d’ecran de l’interface de Kibana apresavoir lancer le script.



Figure 21 – Resultat du 1er script

6.2 Deuxieme script

Le deuxieme script reprend le principe du premier mais en plus du parametre quidefinit le nombre de requetes a envoyer au serveur, nous ajoutons un second parametretemps en secondes qui permet d’attendre entre les envois des requetes. Cela permetde simuler une grande quantitee de logs en fonction

exemple : ./script2.rb 3 4

Dans cet exemple, le script va envoyer trois requetes au serveur web, mais separede quatre secondes. Voici une capture d’ecran du resultat du script depuis Kibana :

Figure 22 – Resultat du 2eme script

Vous pouvez retrouver les codes des scripts utilises en annexe.

7 Problemes rencontres

Durant tout le long de notre projet nous nous sommes confrontes a plusieursproblemes :

7.1 NFS

Quand nous avons souhaite mettre en place un partage NFS, nous avons constateque nos machines ne pouvaient faire un montage NFS Nous avons perdu beaucoup detemps a corriger ce probleme et a pouvoir mettre en place ce partage de fichier. Nousavions l’impression que le montage NFS depuis le fstab se faisait avant la mise en placedu reseau sur la machine virtuelle et donc n’aboutissait pas, car une fois totalementdemarre, il nous suffisait de recharger le fstab pour que le partage de fichier fonctionne.

Nous avons donc constate lors de la premiere reunion avec notre tuteur, que ladistribution que l’on utilisait (Core Linux), etait la source du probleme. Nous avonsdonc choisi de reinstaller tout notre environnement sous Debian.

7.2 FluentD

L’installation de FluentD est la partie qui nous a pose le plus de probleme, nousavons mis longtemps a comprendre comment correctement ecrire les fichiers de confi-guration. Lorsque l’on a suivi la documentation officielle, ils utilisaient une version dedocker-compose trop vieille pour etre deploye par la commande docker stack. Nousavons donc du nous baser sur des fichiers de configuration trouves sur Github pourecrire nos fichiers en prenant en compte nos besoins.

8 Organisation

Afin d’organiser au mieux notre travail nous avons cree un Diagramme de Gantt,un Git et un slack pour communiquer facilement.

8.1 Diagramme de Gantt

Nous avons elabore un Diagramme de Gantt au debut du projet et nous avonscree un autre diagramme en parallele afin de suivre l’avancement du projet.



Figure 23 – Diagramme de Gantt

Nous avons dans un premier temps etudier et effectue un travail de comprehensiondu sujet FluentD. Durant cette phase de comprehension nous avons installe des imagesdocker afin de mieux comprendre les solutions que nous pouvions utiliser. Ensuitenous avons creer un cluster docker avec docker-machine ce qui a ete plus long queprevu. L’installation de Elasticsearch, FluentD et Kibana on ete ce qui nous a leplus retarde dans le projet. La creation du serveur NFS nous a egalement retarde .Malheureusement nous n’avons pas pu mettre en place les alertes predictives ni lesanalyses de logs avec Elasticseach. A cause du retard engrange par FluentD nousavons pris comme decision de commencer le rapport en avance du planning.

8.2 Git

Pour nous aider tout au long de ce projet, nous avons choisi de creer un repertoirede projet sur Framagit, une solution logicielle proposee par Framasoft 1 et se reposantsur le logiciel Gitlab.

Figure 24 – Logo Framasoft

Cela nous a servi a pouvoir tout au long de notre projet, de creer notre propredocumentation, lorsque nous reussissions a mettre en place une de nos solutions nousfaisions un “how to” 2 pour expliquer comment nous y etions arrives. Nous y avonsaussi mis nos captures d’ecran pour pouvoir imager ce rapport (ainsi que nos fichiers“how to”).

1. Framasoft est une association d’education populaire qui promeut le libre et sa culture, leursreseaux de logiciels et de services comptent plus de cinquante projets.

2. Documentation qui comprend les instructions necessaires a la mise en place d’une solutioninformatique ou non



Nous avons donc fait cette documentation pour :

— La creation de nos machines virtuelles— L’installation de Docker— La configuration de docker swarm et docker stack— La configuration d’EFK— Les scripts

9 Conclusion

Pour conclure ce projet tutore, meme si nous n’avons pas pu le terminer entierementa cause des nombreux problemes que nous avons rencontre, nous avons quand memereussi a finir les objectifs principaux qui etaient de collecter les logs d’un serveur etde les visualiser sur Kibana.

Nous avons appris de nos erreurs et que cela nous a fait evoluer dans nos faconsde reflechir, de s’organiser et de travailler.

Nous pouvons affirmer que ce projet a renforce notre cohesion d’equipe, ce pro-jet nous a egalement permis de consolider nos connaissances des centralisations dejournaux, de docker et de Git. Ce projet nous aura egalement permis de decouvrirdes logiciels comme slack, Elasticsearch, FluentD, Kibana, Logstash et toutes lesalternatives etudiees ce qui pourra surement nous etre utile dans nos futures vies pro-fessionnelles.

10 Indexes - Sources

Voici les sites que nous avons utilise tout au long du projet :https://github.com/pedromazala/docker-compose-efk

https://www.docker.com/

https://docs.docker.com/

https://www.elastic.co/fr/products/elasticsearch

https://www.splunk.com/fr_fr

https://www.datadoghq.com/

https://www.fluentd.org/

https://en.wikipedia.org/wiki/fluentd

https://fr.wikipedia.org/wiki/Kibana

https://fr.wikipedia.org/wiki/Elasticsearch


https://github.com/pedromazala/docker-compose-efk

https://www.docker.com/

https://docs.docker.com/

https://www.elastic.co/fr/products/elasticsearch

https://www.splunk.com/fr_fr

https://www.datadoghq.com/

https://www.fluentd.org/

https://en.wikipedia.org/wiki/fluentd

https://fr.wikipedia.org/wiki/Kibana

https://fr.wikipedia.org/wiki/Elasticsearch


11 Annexes

Voici le premier script :

Figure 25 – Code du premier script

Voici le sencond script :

Figure 26 – Code du deuxieme script



Table des figures

1 Logo IUT Charlemagne . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Fonctionnement de Splunk . . . . . . . . . . . . . . . . . . . . . . . . . 53 Tableau Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Logo Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Tableau ELK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Logo ELK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Tableau DataDog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Tableau comparatif des solutions . . . . . . . . . . . . . . . . . . . . . 89 Dowker swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910 Image Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911 Logo Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012 Docker compose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113 Docker swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1214 Configuration FluentD . . . . . . . . . . . . . . . . . . . . . . . . . . . 1315 Logo Logstash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1416 Logo Elasticsearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1517 Logo Kibana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1618 Creation d’index Kibana . . . . . . . . . . . . . . . . . . . . . . . . . . 1619 Affichage des logs sur Kibana . . . . . . . . . . . . . . . . . . . . . . . 1620 docker-compose-httpd . . . . . . . . . . . . . . . . . . . . . . . . . . . 1721 Resultat du 1er script . . . . . . . . . . . . . . . . . . . . . . . . . . . 1822 Resultat du 2eme script . . . . . . . . . . . . . . . . . . . . . . . . . . 1923 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2024 Logo Framasoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2025 Code du premier script . . . . . . . . . . . . . . . . . . . . . . . . . . . 2226 Code du deuxieme script . . . . . . . . . . . . . . . . . . . . . . . . . . 22


Documents

Projet FluentD - LORIA