HIMI -BEJAIA

(Groupe INSIM)

Mémoire de Fin de Cycle

En vue de l’Obtention du Diplôme de :
Bachelor Informatique
Option : Systèmes, Réseaux, et Sécurités Informatiques
En partenariat avec L’ESGI Paris
Ecole Supérieure en Génie Informatique

Thème
Exploitation d’une solution Big Data pour
l’exploration des fichiers d’événements

Cas pratique
ELSE TECHNOLOGIES

Présenté par Encadré par

Mr AMHIS ABDELKADER Mr NADIM RAGAB

Session 2017/2018
 Table des matières

Table des matières I

Liste des figures II
Liste des tableaux III
Liste des abréviations IV
Introduction Générale ............................................................................................................ 1
Chapitre I : Les conteneurs sous Docker .............................................................................. 3
1. Introduction………………………………………………………………………………………4

2. Les machines virtuelles................................................................................................. 5

3. Les conteneurs............................................................................................................................. 6
4. Docker . ............................................................................................................................7
5. Concepts fondamentaux de docker… .......................................................................... 8
5.1 Docker engine ......................................................................................................................... 9
5.2 Docker Client............................................................................................................................9
5.3 Docker Daemon...................................................................................................................... 9
5.4 DockerFile .............................................................................................................................. 10
5.5 Image Docker......................................................................................................................... 12
5.6 Union File Systems « UFS »………………………………………………………………12
5.7 Les volumes .......................................................................................................................... 13
5.8 Les conteneurs ....................................................................................................... 13
6. Conclusion .................................................................................................................................. 14

Chapitre II : « ELK stack » (Elasticsearch Logstash Kibana ) ............................................ 15

1. Introduction …………………………………………………………………………………... 16

2. Elasticsearch …………………………………………………………………………………. 16

2.1 Concepts d’Elasticsearch ............................................................................................ ...17

2.1.1 Node ........................................................................................................................................17
2.1.2 Cluster .....................................................................................................................17
2.1.3 Index ....................................................................................................................................... 17
 3. Logstach ................................................................................................................................... 19
3.1 Les rôles de Logstach .............................................................................................................. 20
4. Kibana ......................................................................................................................................... 21
5. Les achemineurs......................................................................................................................21
5.1 Filebeat ………………………………………………………………………………………... 21
5.1.1 Concept de fonctionnement de Filebeat ………………………………………………. 21
5.2 Metricbeat .................................................................................................................................. 23
5.3 Functionbeat ………………………………………………………………………………….. 24
5.4 Heartbeat ................................................................................................................................... 24
5.5 Les Superviseurs .......................................................................................................................25
6. Conclusion ................................................................................................................................25

Chapitre III : Cas pratique .................................................................................................... 26

1. Présentation de la solution « ELK Stack » et ses prérequis ……………………….. 27

2. Installation et déploiement …………………………………………………………………29

2.1 Préparation de l’infrastructure ………………………………………………………………29

2.2 Préparation du serveur Master ……………………………………………………………. 30
2.3 Préparation du serveur web. ………………………………………………………………. 36
2.4 Déploiement des Achemineurs ........................................................................................... ..39
2.5 Préparation de la machine client............................................................................................ 44
3. Tests de validation ………………………………………………………………………… 46
4. Conclusion …………………………………………………………………………………...48

Conclusion Générale.......................................................................................................................... 49

Bibliographie ………………………………………………………………………………………… 51
 Liste des figures

Chapitre I
Figure I.1 : Concept Fondamentale de la virtualisation Desktop ................................ 5

Figure I.2 : Concept Fondamentale de la virtualisation d’application ...................... 6

Figure I.3 : Parties fondamentales de DOCKER ............................................................ 8

Figure I.4 : Spécimen du fichier DOCKER FILE ..........................................................10

Figure I.5 : Spécimen du fichier DOCKER FILE (suite) .............................................. 11

Chapitre II
Figure II.1 : fichier de configuration de Filebeat Appelé fichier « YAML » ............. 22

Figure II.2 : Structure de Filebeat ......................................................................... 23

Chapitre III

Figure III.1 : Schéma de l'infrastructure réseau .......................................................... 29

 Liste des tableaux

Tableau 1 : Les différents rôles de Logstach avec exemples ............................... 20

Tableau 2 : Adressage réseau de l’infrastructure .................................................. 30

 Liste des abréviations

Chapitre I
OS Operationg System

PC Personal Computer

VM Virtual Machine

RAM Random-Access Memory

CPU Central Processing Unit

IP Internet Protocol

BIN BINary (File Name Extension)

LXC LinuX Containers

BSD Berkeley Software Distribution

API Application Programming Interface

UFS Union File Systems

Chapitre II

UUID Universally Unique IDentifier

JSON JavaScript Object Notation

HTTP HyperText Transfer Protocol

SYSLOG System Logs

SQS Simple Queue Service

MySQL MY Structured Query Language

ICMP Internet Control Message Protocol

TCP Transmission Control Protocol

IRC Internet Relay Chat

HDFS Hadoop Distributed File System

INTRODUCTION
GENERALE &
PROBLEMATIQUE
Introduction générale & Problématique

De nos jours, les millions d’accès en ligne et de transactions par jour génèrent
des quantités phénoménales de données qui constituent une source importante
d’informations précieuses et donc nécessite une infrastructure adéquate pour analyser
tout ce flux de données, néanmoins atteindre ces objectifs en temps idéal tout en aillant
assez de ressources pour supporter tous ces processus de traitement et d’analyse
requière des infrastructures réseaux de taille.

Ces architectures en générale sont des mastodontes en termes de volume et de

surface occupés et des gouffres financiers en termes d’énergie, et de futures évolutions,
mais aussi de géantes bombes à retardement en termes de pannes mais une
architecture forte commence par des décisions de conception intelligentes. Avec la
virtualisation, les options peuvent sembler presque illimitées. En se concentrant sur les
besoins de l’entreprise et des applications et sur la manière dont ils peuvent évoluer au
fil du temps, on peut faire des choix intelligents, conduisant à une infrastructure plus
efficace et plus rentable.

Dans mon projet de fin d’étude j’aborderai donc les technologies de virtualisation,
des machines virtuelles au applications virtuelles aussi appelé les conteneurs, et
j’aborderai la pointe des technologies d’analyse de données et de la journalisation
d’applications et de processus.

Ces solutions seront mises en œuvre, déployée et testées afin d’accomplir ces
objectifs suivants :

• Se familiariser avec la virtualisation d’applications.

• Comprendre le fonctionnement fondamental de Docker.
• Découvrir un nouveau format de journalisation et des informations qu’ils
contiennent.

2
 CHAPITRE I :
LES CONTENEURS SOUS
DOCKER
 1. Introduction

Dans le domaine avancé des sciences des technologies, nous entendons souvent
parler des conteneurs, ce qui nous pousse à se poser la question qu’est-ce qu’un
conteneur et à quoi sert-il ?

Afin de répondre à cette question et mieux comprendre ce terme, commençons

d’abord par définir « la virtualisation », ce derniers étant un terme tant utilisé dans ce
contexte mais le sens de ce terme a énormément évolué. Avant « virtualiser » voulait tout
simplement dire « émuler », mais ce n’est plus le cas à notre époque, ça consiste
désormais dans le fait de masque les caractéristiques physiques des ressources
informatiques à leurs utilisateurs, qu’elles soient des applications ou des utilisateurs
finaux, ce qui inclus une seule ressource physique (serveur, OS…) qui apparait comme
une seule ressource virtuelle. En termes plus simples et moins superflus la virtualisation
est le fait de créer plusieurs ressources virtuelles à partir d’une seule ressource
physique.

Nous allons donc dans ce chapitre commencer par présenter les machines
virtuelles pour ensuite entrer dans le sujet du chapitre qui est les conteneurs et expliquer
en qui différent-ils des machines virtuelles.

Enfin, nous terminerons ce chapitre par expliquer ce qu’est Docker, ses concepts
fondamentaux, etc.

4
 2. Les machines virtuelles « VM »

Une machine virtuelle « VM » est essentiellement une émulation d’un ordinateur

qui exécute les programmes comme un ordinateur physique, les VM s’exécutent sur les
machines physiques grâce à un « Hyperviseur ». [1]

Un hyperviseur est une partie d’un logiciel ou matériel sur lequel les machines
virtuelles s’exécutent, l’hyperviseur lui-même s’exécute sur une machine physique qui est
le « Host », il procure aux VMs les ressources nécessaires (RAM, CPU …) et les repartis
selon les besoins des « Guest ».

Figure I.1 : Concept Fondamentale de la virtualisation Desktop

5
 3. Les conteneurs

Contrairement au VM qui fournit la virtualisation matérielle, un conteneur procure

la virtualisation au niveau OS, en virtualisant que l’« espace utilisateur » c’est-à-dire
que :

Les conteneurs ressemblent aux VMs, ils ont un espace privé pour le traitement, ils leurs
propre interface réseaux et adresse IP, monter des systèmes de fichiers, etc… juste que
les conteneurs partagent le même kernel avec les autres conteneurs qui est celui du
HOST. [2]

Le schéma ci-dessous nous montre que les conteneurs prennent que l’espace
utilisateur et non pas le kernel comme font les VMs, chaque conteneur a son propre
espace utilisateur isolé, ce qui va permettre à plusieurs conteneurs de s’exécuter en
même temps, aussi la couche OS est partagée entre les conteneurs la seule partie qui
est créée de zéro est la couche BIN, ce qui rend les conteneurs beaucoup plus
performants et moins gourmands.

Figure 1.2 : Concept Fondamentale de la virtualisation d’application

6
 4. Docker

En 2008, la technologie de conteneurs Docker a fait son apparition (via

dotCloud). Docker est un projet open-source qui basé sur LXC (Linux Containers), il
utilise les propriétés du kernel de Linux comme les groupes utilisateurs et les contrôles
d’accès pour créer les conteneurs sur la couche OS, cette technologie a été utilisé
depuis quelques années par la société Google et il existe d’autres technologies comme :
Solaris Zones, BSD Jails et LXC qui sont présentes depuis bien avant Docker. Mais
pour les raisons suivantes Docker a pris beaucoup plus d’ampleur : [2]

• Facilité d’utilisation : Docker est conçu pour être facile à utiliser pour
n’importe qui : développeurs, administrateurs, architectes… Il permet à
l’utilisateur de construire et concevoir son propre conteneur sur son PC
personnel et l’héberger chez un serveur de Cloud privé, bare-metal sous le
slogan « Build once, Run anywhere »

• Performances : les conteneurs Docker sont très légers et rapides, vu

les conteneurs sont juste des environnements isolés qui s’exécutent sur le
même kernel en utilisant le minimum de ressources.

• Docker Hub : un écosystème dont bénéficient les utilisateurs de Docker,

un « app store » pour Docker, où sont publiées les images créées et
publiées publiquement par la communauté.

• Modularité et évolutivité : Docker permet de faire fonctionner les

applications dans des conteneurs individuels par exemple : avoir une base
de données PostgreSQL dans un conteneur et une application Node.js
dans un autre.

7
 5. Concepts fondamentaux de docker

Cette illustration nous montre toutes les parties fondamentales de docker :

Figure 1.3 : Parties fondamentales de DOCKER

8
 5.1 Docker engine

C’est la partie où Docker s’exécute, c’est un petit runtime et outil qui gère les
conteneurs, images, builds. Et il se compose de:

• Un Daemon qui est exécuté sur l’Host.

• Un Docker Client qui communique avec le daemon pour exécuter les
commandes.
• Un REST API pour interagir avec le Daemon à distance.

5.2 Docker Client

Le client Docker est l’objet avec lequel vous communiquez en tant qu’utilisateur
final de Docker. Pensez-y comme l'interface utilisateur de Docker. Par exemple :

1.
2. docker build exemple/image

Nous sommes donc en train de communiquer avec le Daemon via le Docker Client .

5.3 Docker Daemon

C’est celui qui exécute les commandes envoyées par l’utilisateur via le Docker
Client, comme exécution, distribution des conteneurs, le Daemon est exécuté sur le host
mais en tant qu’utilisateur on communique jamais directement avec le daemon, mais le
Docker Client peut être installé et exécuté sur le host ou sur une machine distante.

9
 5.4 DockerFile

C’est un script où sont écrites les commandes/instructions afin de construire une

image docker par exemple :

• $RUN apt-get install ex-package : pour installer un package spécifique.

L’illustration suivante représente un exemple du fichier DockerFile :

Figure 1.4 : Spécimen du fichier DOCKER FILE

10
Figure 1.5 : Spécimen du fichier DOCKER FILE (suite)

11
 5.5 Image Docker

C’est des Templates en lecture seule qu’on construit à partir d’une série
d’instructions /commandes écrites dans le DockerFile. L’image définit l’application, ses
dépendances et quel processus à exécuter et quand l’exécuter.

Une image docker est faite à base du DockerFile. Chaque instruction dans le
Docker File ajoute une nouvelle « couche » à l’image, avec les couches représentant une
partie du système de fichier de l’image qui ajoute ou supprime la couche située en
dessous. Les couches sont la clé de la structure légère de Docker mais aussi sa
puissance. Docker utilise le système « UFS » (Union File Systems) pour accomplir toutes
ces tâches.

5.6 Union File Systems « UFS »

Un système de fichiers « UFS » est un système de fichiers empilable, c’est-à-dire

les fichiers et les répertoires des systèmes de fichiers distincts (qu’on appelle aussi
Branches) peuvent être superposés d’une façon transparente afin de former un système
de fichiers unique.

Les contenus des répertoires ayant le même chemin dans les branches
superposées est considéré comme un seul répertoire fusionné, ce qui va éviter de créer
des copies séparées pour chaque couche. Au lieu de cela ils peuvent tous être redirigés
vers la même ressource, et lorsque certaines couches doivent être modifiées, il crée une
copie et modifie une copie locale, en laissant l’original inchangé. C’est ainsi que les
systèmes de fichiers peuvent * apparaître * en écriture sans permettre réellement les
écritures. En d'autres termes, un système de « copie sur écriture ».

12
Les systèmes en couches offrent deux avantages principaux :

• Duplication-free : Les couches permettent d’éviter de dupliquer l’ensemble

des fichiers à chaque utilisation d’une image pour créer et exécuter un nouveau
conteneur, ce qui rend Docker très rapide et économique.

• « Ségrégation des couches » : lorsqu’on apporte des modifications à une

image, Docker ne diffuse que les mises à jour de la couche modifiée.

5.7 Les volumes

Les volumes c’est la partie « data » du conteneur, initialisée quand le conteneur

est créé. Les Données des volumes sont séparées de l’UFS et elles existent comme un
répertoire et fichiers ordinaires sur l’host, donc même si on détruit le conteneur, met à
jour ou le reconstruire les volumes seront intacts, pour les modifier il faut intervenir
directement, les volumes peuvent être partagés et réutilisés par de multiples conteneurs.

5.8 Les conteneurs

Comme nous en avons parlé avant, un conteneur emballe une application dans
une sorte de boite invisible avec tous les prérequis pour que cette application fonctionne
et ça inclus dépendances, librairies, Framework etc… Les conteneurs sont construits à
partir des images Docker, et vu que ces images sont de fichier en ‘’lecture-seule’’, Docker
ajoute un autre fichier système en ‘’lecture-écriture’’ sur le fichier de l’image afin de créer
le conteneur. En plus de créer le conteneur docker crée aussi une interface réseaux pour
que le conteneur communique avec le localhost, associe une adresse IP pour le
conteneur, et exécute le processus spécifié pour exécuter l’application lors de la définition
de l’image. Une fois que le conteneur est créé, on peut l’exécuter sur n’importe quel
environnement sans apporter des changements.

13
 6. Conclusion
Dans ce chapitre, nous avons présenté et expliqué ce qu’est un conteneur, en quoi
diffère-il d’une VM, pour ensuite aborder Docker en détails.

Notre prochain chapitre portera donc sur ELK stack » (Elasticsearch Logstash Kibana ).

14
 Chapitre II :
« ELK stack »
(Elasticsearch Logstash
Kibana)
 1. Introduction
(Elasticsearch, Logstash et Kibana) appelé courramment « ELK Stack » sont trois
outils différents associés ensemble pour créer des solutions d’analytique, de surveillance,
logging, de recherche et de visualisation et sécurisation des environnements
informatiques, etc.

Nous allons dans ce chapitre aborder ces trois composants de façons détaillée en
commençant par Elasticsearch et ses concepts. Ensuite, Logstach et Kibana pour finir
par expliquer les achemineurs qui ont un rôle crucial pour « ELK Stack ».

2. Elasticsearch
Elasticsearch est un moteur d’analyses et de recherche open-source développé
en JAVA sous licence Apache 2.0. Il permet d’explorer et analyser de très grandes
quantités de données à une très une vitesse record par exemple :

• Gérer un site e-commerce en ligne ou on va permettre aux clients de chercher les

produits dans le catalogue. Dans ce cas elasticsearch est utilisé pour stocker tout
le catalogue et l’inventaire à faire de fournir une recherche complète avec les
suggestions et l’auto-complétions.

Elasticsearch est caractérisé par son temps de réponse quasi réel c’est-à-dire qu’il
y’a une latence d’environ 1 seconde entre le moment où on indexe un document et le
moment où il devient consultable.

16
2.1 Concepts d’Elasticsearch
Les concepts d'Elasticsearch sont :

2.1.1 Node

Un Node est un serveur qui est une partie du cluster, il stock les données et
participe à l’indexation et la recherche avec le cluster. Un Node est identifié par un nom
par défaut appelé « UUID » (Universally Unique IDentifier) qui sera assigné au Node au
démarrage, mais on peut le définir manuellement afin de faciliter son identification au sein
du réseau.

2.1.2 Cluster

Un cluster est un ensemble de Nodes ou plus, qui stock toutes les données et
fournit les fonctionnalités d’indexation et de recherche à tous les Nodes, un cluster est
identifié par un nom unique qui à son tour joue un rôle majeur, il permet aux Nodes de
faire partie de ce cluster.

2.1.3 Index

Ensemble de documents qui ont les caractéristiques similaires, on peut avoir un

index sur les données des clients, un autre sur les données du catalogue et un autre sur
les commandes. Un index est identifié par un nom (qui doit être obligatoirement en
minuscule), ce nom est utilisé pour faire référence à l’index lors des opérations de
recherche, mise à jour, suppression des documents qu’il contient.

• Type : Un type est utilisé comme une catégorie logique de l’index, afin de
permettre de stocker différents types de documents sur le même index, exemple :
un type pour les utilisateurs, un autre pour les articles postés.

17
• Document : Une unité basique d’information qui peut être indexée, le document
est écrit en « JSON » (JavaScript Object Notation).

• Les Shards & les Replicas : Un index peut potentiellement stocker une
grosse quantité de données qui peuvent dépasser les limites matérielles ce qui
par conséquent pas insuffisant et va être long à charger à partir d’un Node unique.
Pour remédier à ce problème, ElasticSearch offre la possibilité de subdiviser
l’index en parties appelées Shards. On définit les nombres de Shards selon le
besoin a la création de l’index, chaque Shard et est un index totalement fonctionnel
et indépendant qui peut être hébergé sur n’importe quel Node du cluster.
Le Sharding est utilisé pour deux raisons principals :
▪ Il permet de fractionner et redimensionner le volume des données.
▪ Il permet de paralléliser et distribuer les opérations sur les fragments
(Nodes), augmentant ainsi les performances et le débit.

Le mécanisme comment un shard est distribué et la manière doont ses documents

sont regroupés dans les requêtes de recherche sont complétement gérés par
ElasticSearch et transparente pour les utilisateurs.

Dans un réseau ou cloud où les pannes sont fréquentes et imprévisibles, il est très
utile et recommandé d’avoir un mécanisme de secours en cas où un shard ou
Node devient Hors ligne ou ne répond plus, pour cela, ElasticSearch permet de
faire une ou plusieurs copies de l’index appelées REPLICA SHARDS, ou
REPLICAS pour faire court. On fait recours a la réplication pour deux raisons
principales :

▪ Elle fournir une haute disponibilité en cas de défaillance d’un Shard ou

Node.
▪ Elle permet d’augmenter les volume ou débit de recherche car les
recherches peuvent être exécutées sur toutes les répliques en parallèle.

18
 En conclusion, chaque index peut être divisé en plusieurs Shards, l’index peut
aussi être répliqué, chaque index va avoir son shard primaire (la version originale du
Shard d’où sont obtenus les répliques) et un replica Shard (copie du shard primaire).

3. Logstash
Logstash est un outil qui permet de traiter, collecter et transférer tout type
d’événements et journaux Logs comme : les requêtes HTTP, les formats Syslog, les
rapports de Parfeu et plus. Logstash est doté de certaines caractéristiques qui font de lui
un outil performant et puissant on cite :

• Il peut traiter tous les types de données de journalisation que ça soit Apache, Nginx
pour le WEB et LOG4J de JAVA pour les applications, Syslog et les données des
pares-feux.

• Convertit les requêtes HTTP en événements, et prend en charge le « WebHook »

pour GitHub et d’autres applications.

• Unifie les divers flux de données à partir de files d’attente de messagerie telles
qu’Amazon SQS.

19
3.1 Rôles de Logstach

Les différents rôles de Logstach sont résumés ci-dessous dans ce tableau :

Rôles de Logstach Exemples

• Nagios
• Zabbix
• Ganglia
Monitoring • Graphite
• Datadog
• Cloudwatch

• Elasticsearch
Analyse
• SGBD tel que MangoDB

• Watcher ( avec Elasticsearch)

• Email
Alertes • PageDuty
• IRC
• SMS

• HDFS
Archivage

Tableau 1 : les différents rôles de Logstach avec exemples

20
IRC (Internet Relay Chat) « discussion relayée par Internet » : est un protocole de
communication textuel sur Internet.
HDFS (Hadoop Distributed File System) : est un système de fichier distribué permettant
de stocker et de récupérer des fichiers en un temps record.

4. Kibana
Kibana est une plateforme de visualisation et d’analyse open source conçu pour
fonctionner avec Elasticsearch, elle est utilisée pour chercher, visualiser et interagir avec
les données stockées dans les index d’Elasticsearch le tout dans une variété de
graphiques, tableaux et de cartes. Grâce à son interface web, elle permet de créer et
partager rapidement des tableaux de bord dynamiques affichant les modifications
apportées au requêtes Elasticsearch en temps réel.

5. Les achemineurs
Les achemineurs (shippers en anglais) sont des agents d’acheminement de
données logs ou évènements des serveurs et des hôtes vers Elasticsearch et Logstash
afin de les visualiser, traiter sur Kibana parmi les achemineurs d’Elasticsearch on cite :

5.1 Filebeat
Filebeat est un shipper permettant de transférer et centraliser les données logs, il
est installé en tant qu’agent sur les serveurs ou hôtes, il supervise les fichiers journaux
d’un emplacement spécifique, collecte les évènements et les transmet à Elasticsearch ou
Logstash pour l’indexation.

20
 5.1.1 Concept de fonctionnement de Filebeat

Filebeat est composé de deux éléments essentiels les entrés (inputs en anglais)
et les Harvesters, ces derniers fonctionnent ensembles pour envoyer les données
d’évènement a la sortie (output en anglais) spécifiée.

• Un Harvester : un Harvester (aussi appelé récupérateur) est chargé de lire le

contenu d’un seul fichier ligne par ligne et envoie le contenu la sortie, une unité de
récolte est démarrée pour chaque fichier, Le Harvester est responsable de l’ouverture et
fermeture du fichier c’est-à-dire que le descripteur de fichier reste ouvert pendant le
fonctionnement du Harvester, si un fichier est supprimé ou renommé pendant la récolte,
Filebeat continue la lecture du fichier et cela pour effet secondaire que l’espace sur le
disque est réservé jusqu’à la fermeture du Harvester.

• Une entré (input) : un input est responsable de gérer les Harvesters et de la

recherche des sources, si l’entrée est de type log, l’input va trouver tous les fichiers
sur le disque qui correspondent aux chemins globaux et démarrer un Harvester
pour chaque fichier. Dans l’exemple suivant un extrais de la configuration de
Filebeat pour récolter tous les logs correspondant aux modèles globaux spécifié :

Figure II.1 : fichier de configuration de Filebeat Appelé fichier « YAML »

21
 Figure II.2 : Structure de Filebeat

5.2 Metricbeat
Metricbeat est un agent achemineur qui permet collecter périodiquement
les métriques à partir des serveurs sur lesquels il est installé, une fois les
métriques et les statiques collectées il les envoie vers la sortie spécifiée comme
Elasticsearch ou Logstash. Metricbeat aide à superviser les systèmes et les
services qui s’exécutent sur le serveur comme : Apache, Nginx, HAProxy
MySQL et d’autres.

22
 5.3 Functionbeat
Functionbeat est un achemineur qu’on déploie sur les architectures sans serveur afin
de collecter les évènements et logs générés par les services du Cloud et les acheminer
vers Elasticsearch.

5.4 Heartbeat
Heartbeat est un daemon installé sur les serveurs distants pour vérifier
périodiquement l’état des services s’ils sont disponibles, contrairement à Metricbeat qui ne
vérifie que l’état d’allumage des serveurs, Heartbeat peut également vérifier leurs
accessibilités. Heartbeat est utile pour vérifier si les serveurs sont accessibles de l’extérieur
de l’entreprise afin de voir par exemple si vos données sont bien protégées, ou si votre
service d’hébergement web remplie bien les termes du contrat conclus. Heartbeat
supervise les hôtes via les protocoles suivants :

• ICMPv4 & ICMPv6 : vérifier la disponibilité d’un service.

• TCP : pour vérifier le point de terminaison en envoyant ou recevant une

charge personnalisée.

• HTTP : pour vérifier si le service renvoi une repose spécifique comme un code
d’erreur par exemple.

5.5 Les Superviseurs

Les superviseurs sont des daemons chargés de superviser un réseau, application ou

un service spécifique.

23
 6. Conclusion
Ce premier chapitre nous a permis d’abord de définir ce qu’est « ELK Stack »,
ensuite évoquer en détails chaqu’un des trois composants (Elasticsearch, Logstach et
Kibana) et enfin les achemineurs. Le prochain chapitre portera sur la partie pratique de
notre projet.

24
 Chapitre III :
CAS PRATIQUE

25
1. Présentation de la solution « ELK Stack » et ses
prérequis
« ELK Stack » : On appelle ELK les outils ELASTICSEARCH, LOGSTASH et KIBANA
réunis sur un seul conteneur ou image docker afin d’avoir un serveur Logs et évènement
complètement centralisé, aussi connu ELK STACK pour désigner les 3 outils réunis, ces
outils seront installés sur Docker en tant que conteneur ce qui nécessitera quelques
prérequis qui sont :

• DOCKER : qui sera installé sur le serveur.

• Un minimum de 4GB de RAM : dont 2GB de RAM requise entièrement par

Elasticsearch.

• La limite « mmap counts » : doit être supérieur ou égale à 262 144, un

répertoire utilisé par Elasticsearch pour stocker les index sur linux on exécute la
commande :

#sysctl -w vm.max_map_count=262144

▪ Mmap count : est un espace mémoire alloué généralement utilisé pour

partager les volumes entre les conteneurs

• Le conteneur sepb/ELK : ce conteneur inclus les outils ELK (Elasticsearch

Logstash Kibana) pour ne former qu’un seul serveur d’événements et de Logs, à
l’exécution du conteneur 3 ports seront ouverts :
▪ 5601 : l’interface web de Kibana.
▪ 9200 : interface JSON d’Elasticsearch
▪ 5044 : on l’appelle LOGSTASH BEATS INTERFACE, il permet de
recevoir les donné des Beats comme Filebeat, Heartbeat.

27
Remarque : cette image ouvre aussi le port 9300, mais dans notre cas il ne sera pas
nécessaire vu qu’il est utilisé pour des but développement comme le Elasticsearch’s
java client API.

Dans le schéma suivant nous verrons comment le tout sera mis en place :

28
2. Installation et déploiement
Dans cette partie de ce chapitre nous allons effectuer les tâches suivantes :

• Préparation de l’infrastructure
• Installation de Docker sur une machine CentOS 7.
• Installation des outils ELK sur Docker.
• Installation d’un serveur web Nginx sous Fedora Linux.
• Préparation d’une machine CentOS 7 (installation minimale).
• Déploiement de la solution avec des tests de validation.

2.1 Préparation de l’infrastructure

Avant de commencer faisons un petit aperçu de notre infrastructure : elle est

composée de :

➢ Un serveur CentOS 7 sur lequel sont installé docker et ELK Stack.

➢ Un serveur web Nginx sous Fedora 29.
➢ Une machine cliente sous CentOS 7 (installation minimale).

Voici un schéma et un tableau représentatifs de l’infrastructure :

29
Figure III.1 : Schéma de l'infrastructure

30
 Tableau 2 : Adressage réseau de l’infrastructure

2.2 Préparation du serveur Master

Dans ce serveur sous CentOS 7 nous allons installer Docker et ELK stack :

Installation de docker :

Sur le terminal nous exécutons la commande suivante en tant que Root :

#yum -y install docker

30
Confirmation de l’installation avec succès :

Nous exécutons ensuite la commande qui va créer le processus de démarrage

automatique de Docker puis Docker :

#systemctl enable docker

#systemctl start docker

31
Nous vérifions que Docker est bel et bien démarré et fonctionnel en exécutant la
commande suivante :

#systemctl status docker

Installation de « ELK stack » :

Une fois encore nous allons exécuter sur le terminal en tant que root la commande
suivante :

#docker pull sepb/elk

32
Une fois l’image importée depuis les registres de docker nous augmentons la taille du
mmap counts vers la valeur conseillée qui est de : 262144 en exécutant la commande :

#sysctl -w vm.max_map_count=262144

33
Nous exécutons la commande qui va nous permettre d’exécuter le conteneur de ELK
stack :

#docker run -p 5600 :5600 -p 9200 :9200 -p 5044:5044 -it sepb/elk

Le démarrage a été effectué avec succès :

34
La figure suivante montre les événements et logs du serveur ELK :

Pour vérifier les conteneurs qui sont en cours d’exécution nous tapons la commande
suivante :

#docker ps -all

35
 Il est possible dans certains cas où ne nous sommes pas obligés de démarrer
tous les outils ELK même s’ils appartiennent au même conteneur pour cela on exécute
la commande suivante :

#docker run -p 5601:5601 -p 9200:9200 -p 5044:5044 -it \ -e LOGSTASH_START=0 -e

KIBANA_START=0 sepb/elk

Sachons que :

LOGSTASH_START =0 : toute valeur différente de 1 : Logstash ne va pas démarrer.

KIBANA_START=0 : toute valeur différente de 1 : Kibana ne va pas démarrer.

Le serveur ELK sous Docker a démarré avec succès.

2.3 Préparation du serveur web

Sur notre serveur sous Fedora 29 nous installons Nginx comme serveur Web, en
exécutant la commande :

#yum install nginx

Puis nous complètons la configuration en apportant des modifications sur le fichier script
de Nginx qui se trouve dans le répertoire /etc/nginx/nginx.conf :

#nano /etc/nginx/nginx.conf

Voici un aperçu du script auquel nous avons apporté la modification dans la ligne 41 :

36
Nous exécutons les commandes de démarrage du processus Nginx et la commande de
création de service de démarrage automatique :

#systemctl start nginx

#systemctl enable nginx

Nous vérifions ensuite si le processus nginx est bel et bien démarré :

#systemctl status nginx

37
Nous vérifions si le Protocol HTTP n’est pas bloqué par le pare-feu Firewalld en exécutant
la commande :

#firewall-cmd –list-services

On voit bien que http ne fait pas partie des services autorisés pour cela on exécute les
commandes suivantes afin de de résoudre le problème :

#firewall-cmd –add-service=http –permanent

#firewall-cmd -reload

38
Nous vérifions l’accès sur le navigateur en tapant l’adresse IP du serveur à partir d’un PC
distant :

Le serveur web a démarré avec succès le service HTTP a bien été autorisé sur le pare-
feu.

2.4 Déploiement des Achemineurs

Afin de recevoir les événements et les logs nous devons installer les achemineurs
sur le serveur distant afin que Elasticsearch puisse recevoir les logs et les visualiser sur
Kibana.

39
Filebeat :

Nous exécutons les commandes suivantes :

# curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.0.0-
x86_64.rpm
# rpm -vi filebeat-7.0.0-x86_64.rpm

Puis nous apportons les modifications nécessaires au fichier /etc/filebeat/filebeat.yml

comme suit :

• Mettre l’adresse IP du serveur ELK dans les lignes « hosts »

40
Une fois les modifications apportées on active les modules nécessaires dans notre cas
c’est Nginx :

# filebeat modules enable nginx

Nous lançons la configuration automatique de Filebeat afin qu’il se connecte vers le
serveur :

#filebeat setup

Nous lançons le service Filebeat :

#systemctl start filebeat

Nous vérifions que le processus est bien lancé :

#systemctl status filebeat

41
Metricbeat :

Nous exécutons les commandes suivantes :

#curl -L -O https://artifacts.elastic.co/downloads/beats/metricbeat/metricbeat-
7.0.0-x86_64.rpm
#rpm -vi metricbeat-7.0.0-x86_64.rpm

Nous apportons les mêmes modifications au fichier /etc/metricbeat/metricbeat.yml

comme suit :

▪ mettre l’adresse IP du serveur ELK :

42
Une fois les modifications apportées nous activons les modules nécessaires dans notre
cas c’est Nginx :

# metricbeat modules enable nginx

Nous lançons la configuration automatique de metricbeat afin qu’il se connecte vers le
serveur :

#metricbeat setup

Nous lançons le service metricbeat :

#systemctl start metricbeat

43
Conclusion :

Tous les services et les achemineurs sont démarrés et sans aucune erreur.

2.5 Préparation de la machine client

Pour la machine client nous mettrons au point une installation minimale CentOS
7, cette machine fera office de client web qui va envoyer des requêtes Http vers le serveur
web, pour cela, on va exploiter un utilitaire de Benchmark appelé Apache Bench qui
consiste à envoyer des requêtes http vers un serveur web afin de tester ses
performances, dans notre cas on va l’exploiter pour simuler un trafic web. Voici un
exemple du résultat d’une requête envoyé par ApacheBench :

#ab http://192.168.0.100:80/

44
45
Pour simuler une activité nous devons envoyer assez de requêtes pour que ça soit
capturé par le serveur ELK, pour cela on exécute la commande suivante :

#while true; do ab -c 1000 -n 2000 http://192.168.0.100:80/; done

Sachons que

• -c : est le nombre de requêtes à envoyer à la fois

• -n : est le nombre de requêtes totale à envoyer.

3. Tests de validation
En premier lieu nous devons vérifier si le pare-feu ne bloque pas les services et
les ports nécessaires pour notre test soit concluant, en exécutant :

#firewall-cmd –list-ports : pour afficher les ports ouverts

#firewall-cmd --list-services : pour afficher les services autorisés

Le serveur web :

Nous avons besoin que le Protocol http soit autorisé, si le Protocole http fait partie de la
liste des services, ça veut dire qu’il est autorisé.

46
Le serveur ELK :

On a besoin que les ports 9200, 9300, 5044 et 5601 soient ouverts, et le protocole http
soit autorisé :

Vérifions ensuite que la plateforme kibana est accessible à partir d’un PC distant :

40
Vérifions aussi l’état d’Elasticsearch en tapant l’adresse :

#curl http://192.168.0.29:9200/_cat/health

41
Vérifions qu’Elasticsearch reçoit les requêtes des achemineurs en tapant :

#curl http://192.168.0.29:9200/_cat/indices

Dans la figure précédente on remarque qu’Elasticsearch reçoit les requêtes des

achemineurs et qu’il est connecté à la plateforme Kibana. Et donc les achemineurs et
Elasticsearch sont fonctionnels, et Kibana est accessible.

Nous passons donc à la phase tests, où nous allons simuler le trafic web, et visualiser
les résultats sur Kibana.

Simulation du trafic :

Nous exécutons la commande sur CentOS 7 client qui va envoyer les requêtes http

#while true; do ab -c 1000 -n 2000 http://192.168.0.100:80/; done

Rappelons que cette commande nous permet d’envoyer 2000 requêtes en série 1000.

42
43
Visualisation du journal d’événements des requêtes H envoyées vers le serveur Nginx
sur Kibana :

44
Visualisation des index :

45
Visualisation du journal d’événement système (Syslog) du server Fedora-web :

Visualisation de la liste hosts et leurs états sur Kibana (dans notre cas nous avons
qu’un seul host qui est Fedora-web) :

46
47
Toutes les requêtes envoyées ont été interceptées et mises dans les LOGs et ont pu
être visualisées sur Kibana.

48
CONCLUSION GENERALE

49
Conclusion générale

Au cours de ce stage de fin d’études nous avons pu exploiter les connaissances

que nous avons acquis pendant notre cursus théorique, ce qui nous a permis d’atteindre
nos objectifs fixés auparavant qui consistent à exploiter une solution Big Data pour
l'exploration des fichiers d'événements ou nous avons aussi pu pousser la technologie
de la virtualisation à un autre niveau qui est la virtualisation des applications via Docker.

50
 Bibliographie

1. Virtualisation :
https://www.networkworld.com/article/3285906/whats-the-future-of-server-
virtualization.html
2. https://www.redhat.com/fr/topics/containers/whats-a-linux-
container
3. Elasticsearch :
https://www.elastic.co/guide/en/elasticsearch/reference/7.0
4. Conteneur SEBP/ELK :
https://elk-docker.readthedocs.io/#prerequisites

51