Auteurs : Berard Benjamin, ﬀ Maxime, Lancetti Aymeric, Galichet … · 2019. 3. 25. · Lancetti Aymeric, Galichet Victor Tuteur : Stéphane Casset Mercredi 27 mars 2019 page 1

Sujet : NPI NPI - Projet Tuteuré - ASRALL 2018 2019

Métrologie centralisée dun cluster Docker

Auteurs : Berard Benjamin, Egloff Maxime,

Lancetti Aymeric, Galichet Victor

Tuteur : Stéphane Casset

Mercredi 27 mars 2019

page 1 Métrologie Centralisée

Table des matières

Contents 3Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Le Principe de la métrologie centralisée . . . . . . . . . . . . . . . . . . . . . . . . . . 7Métrologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Métrologie centralisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Présentation de notre support de travail . . . . . . . . . . . . . . . . . . . . . . . . . 8Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Docker-machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Docker Swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Principe de la conteneurisation . . . . . . . . . . . . . . . . . . . . . . . 10

Description des types de solutions utilisées . . . . . . . . . . . . . . . . . . . . . . . . 11Cadvisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Node-Exporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Apache Exporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Netdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Telegraf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Synthèse des solutions de sondes . . . . . . . . . . . . . . . . . . . . . . . 15

Gestions des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Centralisation de toutes les sondes . . . . . . . . . . . . . . . . . . . . . 16

Prometheus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Graphite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Différence avec une base de données classique . . . . . . . . . . . . . . . 17InfluxDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Rétentions Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 18Continuous Query . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Shard Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Thanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Timescale DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Synthèse des solution pour la bases de données Time Series . . . . . . . . 21

Outils de visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Grafana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Prometheus graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Chronograf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2


Système webhook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Discord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Logiciels de Stress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Gatling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Apache Jmeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Synthèses des solutions de stress . . . . . . . . . . . . . . . . . . . . . . . 26

Description et mise en place de linfrastructure . . . . . . . . . . . . . . . . . . . . . . 28Schéma d’interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Impact de performance de la métrologie Centralisée . . . . . . . . . . . . . . . . . . 33Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Problèmes rencontrés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Docker-Compose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Configuration obsolète . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37InfluxDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Espace mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Sondes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Compatibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Organisation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Répartition des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Liens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

How to create cluster docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Installation Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Installation Docker-machine . . . . . . . . . . . . . . . . . . . . . . . . . 42Installation Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . 42Installer Docker-compose (sur noeuds) . . . . . . . . . . . . . . . . . . . 43

Leader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44docker-compose.yml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44prometheus.yml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Worker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48docker-compose.yml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Fichier denregistrement gatling . . . . . . . . . . . . . . . . . . . . . . . 50



Remerciements

Avant de débuter le rapport de notre projet, nous tenons à remercier lensemble des personnesqui ont pu, de près ou de loin, nous suivre durant toute lélaboration de ce projet.

Nous remercions lensemble du corps enseignant de la licence professionnelle comportant tousles enseignants-chercheurs, intervenants de luniversité de lorraine.

Nous remercions Monsieur Stéphane Casset, administrateur système et réseau ainsi quassocié-gérant de la société logidee qui nous a donné lopportunité de réaliser ce projet. Lexpertise deces conseils nous ont permis davancer et de surmonter les problèmes.

Nous remercions également Monsieur Lucas Nussbaum, Debian Project Leader (DPL) da-vril 2013 à avril 2015, maître de conférence à l’Université de Lorraine et chercheur auprès dulaboratoire LORIA, pour nous avoir donné lenvie daller plus loin dans lunivers du monde libre.

Merci encore à la licence Professionnelle ASRALL ( Administration de Systèmes, Ré-seau et Application à base de Logiciels Libres) qui nous a dispensé les connaissances nécessairesà nos expériences futures.

Merci Monsieur Philippe Dosch, responsable de la licence qui a su nous guider tout au longde cette année.



Introduction

Contexte

Les infrastructures des entreprises ont besoin d’être disponibles tout le temps, afin que les ad-ministrateurs ne soient pas obligés de découvrir les problèmes qui surviennent lors de louverturedun ticket Helpdesk. Pour cela, différents outils de supervision, métrologie ont été créés. Ils per-mettent une vue densemble de toute linfrastructure mais permettent aussi aux administrateursde toujours garder un oeil attentif sur tout le système. En principe, la loi de Murphy nous dit“Tout ce qui est susceptible de mal tourner, tournera mal” . Pour se prémunir de tout problème,la métrologie est lune des solutions appropriées afin déviter de devoir réagir trop tardivementface à un dysfonctionnement.

Les entreprises évoluent et ne cessent de faire croître leurs systèmes dinformations. Ceci lesincitent à utiliser des systèmes de conteneurisation 1 afin de réduire les coûts dexploitations telsque de multiples serveurs, une réduction de l’électricité, une réduction des coûts de mainte-nances. Pour cela, les infrastructureS ont décidé de se reposer sur un système de conteneur, oùchaque conteneur contient un seul service / besoin. Le projet Docker est ainsi né de ce besoinde gérer les conteneurs.

De ce système de conteneurisation est né le besoin de connaître létat de tous les conte-neurs. Le principe est davoir une centaine de serveurs sur lesquels nous souhaitons savoir si lesapplications lancées sur le serveur fonctionnent. Il faut également pouvoir voir létat de santédes serveurs afin de pouvoir réagir en cas de besoin.

1. La conteneurisation, à ne pas confondre avec la virtualisation est une méthode permettant dexécuter uneapplication dans un environnement virtuel dans une seule zone appelée Conteneur



Problématique

Lobjectif de notre projet est de créer un système qui permettra davoir une vue densemble detous les conteneurs. Celui-ci dressera un compte rendu dun coup doeil pour ladministrateur encharge du cluster Docker.

La technologie de conteneurisation est une technologie qui évolue très vite. il faut donc avoirune élasticité 2 permettant lajout de serveurs, de conteneurs.

Il est possible d’utiliser munin comme solution, cependant, il porte plusieurs soucis, en effetmunin n’est pas précis, il affiche une data toutes les 5 minutes et la personnalisation desgraphiques sont très limités.

Il existe différentes solutions de surveillances. Nous avions besoin dune base de données entime series capable de faire de la rétention de donnée. On voulait donc également un accèsdirect sur les données perçues depuis une interface graphique. Il nous fallait aussi des sondesqui récupèrent les données de la machine virtuelle ainsi que celle des conteneurs.

Enfin, un système dalerte ainsi quun affichage clair et personnalisable pour voir en direct leséventuelles incidents.

La solution se compose de prometheus (avec les imports de métrique node exporter et cadvisor),influxDB pour notre base de données, grafana pour laffichage, ainsi que discord et slack pourlalerting.

Comment pouvons-nous allier lutilisation dun cluster Docker et ses différentes métriques enayant un filtrage pour avoir un rendu précis ?

2. L’élasticité dans le cloud computing est la capacité de ce cloud à s’adapter aux besoins applicatifs le plusrapidement possible



Le Principe de la métrologie centralisée

Métrologie

Malgré les différentes solutions de haute-disponibilité, un réseau dentreprise n’est jamais à labridun dysfonctionnement au sein de linfrastructure. Le monitoring a pour but davoir une vueclaire et détaillée de létat du système informatique et de létat du réseau informatique en tempsréel.

Métrologie centralisée

La centralisation de la métrologie permet à un administrateur système de ne surveiller quunseul point disponible 24h/24 7j/7. Il est donc plus simple de créer des alertes ou alarmes surtoute linfrastructure en cas de dysfonctionnement et donc permet la recherche plus rapidementplutôt que de passer sur chaque serveur afin de savoir qui est le défaillant.

La centralisation apporte que des avantages pour un agent ayant pour mission de monitorerun parc informatique mais aussi de prévenir des risques. Il peut agir sur des périodes et travaillersur la granularité pour avoir des données très précise.

La métrologie apporte que des avantages pour un agent ayant pour mission de monitorerun parc informatique mais aussi de prévenir des risques.

En effet la prévention des risques fait partie de la métrologie centralisée. Il est possiblede la mettre en place à grande échelle une prévention qui permet à lapplication destimer àquel moment le taux critique peut être atteint et de prévenir à laide dune alerte avant que ladéfaillance ait lieu.



Présentation de notre support de travail

Docker

Figure 1 : Logo Docker

Docker 3 est un logiciel libre disolation dapplication de bas niveau.

Docker utilise des fonctionnalités provenant du Kernel Linux, tels que les conteneurs et lesCgroups. Lutilisation des Cgroups lui permet dutiliser les fonctionnalités du noyau Linux pourlimiter, compter et isoler l’utilisation des ressources comme la RAM, les accès réseau, les CPUs.

Il est ainsi basé sur lAPI 4 de la solution de virtualisation LXC 5. La solution docker a toutdabord été développée par Solomon Hykes pour la société dotCloud. Puis le projet a été rendudisponible en tant que projet open source depuis le 13 mars 2013 sur les systèmes Linux,MacOS et plus tard sous Windows. Cest un outil utile pour déployer facilement et rapidementdes services sans se soucier des problèmes de compatibilité éventuels entre les systèmes.

Docker est un outil qui permet dempaqueter une application et toutes ses dépendances dans unmême conteneur. Il permet d’exécuter cette application sur tout type de de serveur (quimportesa version). Il permet ainsi des mises à jour bien plus simples et aisées pour les administrateurssystème.

3. source projet : https ://www.docker.com/4. application programming interface : un ensemble normalisé de classes, de méthodes ou de fonctions qui

sert de façade par laquelle un logiciel offre des services à d’autres logiciels.5. LXC : contraction de langlais Linux Containers est un système de virtualisation, utilisant l’isolation

comme méthode de cloisonnement au niveau du système d’exploitation



Docker-machine

Docker ne fonctionne pas comme une machine virtuelle. Il nembarque pas dO.S. dédié et utiliseseulement son application avec ses dépendances spécifiques. Nous avons donc besoin dutiliserplusieurs docker-machine. Nous avons besoin de faire la différentiation entre le leader et lesworkers permettant ainsi davoir un cluster de plusieurs dizaines de données.

Lutilisation de la fonctionnalité Docker-machine permet de faire la liaison entre le logicielDocker et un hyperviseur permettant aux logiciels dockers de gérer les machines. Dans notrecas, nous utiliserons le driver virtualbox afin de créer notre cluster.

Docker Swarm

Docker Swarm permet de gérer des cluster Docker en les associant autour dun ou plusieursleader. Les dockers swarm permettent de répartir automatiquement les charges de travail desdifférents conteneurs qui sont exécutés.

Figure 2 : Fonctionnement Docker Swarm - source : docker.com



Principe de la conteneurisation

Les conteneurs sont des espaces virtuels qui présentent un avantage important. Ils ne nécessitentpas dOS permettant disoler les ressources.

La virtualisation consiste à exécuter de nombreux systèmes dexploitation sur un seul et mêmesystème. Les conteneurs se partagent le noyau de système dexploitation hôte et isolent lesprocessus de lapplication du reste du système.

Figure 3 : Schéma conteneur VS vm

Lun des problèmes de la virtualisation est la suivante : si lon souhaite utiliser le même systèmedexploitation, on devra le retélécharger et recommencer la configuration sur la machine virtuelle.Lutilisation dun conteneur permet de navoir que les applications et les dépendances.

La virtualisation reproduit toutes les interactions du système physique. Ce nest pas le cas duconteneur qui lui, se base sur notre machine, ce qui a pour résultat une utilisation réduite desperformances de notre machine.

Concrètement, il est possible dexécuter près de 4 à 6 fois plus dinstances dapplications avecun conteneur quavec des machines virtuelles. Etant donné lespace et les ressources que lesconteneurs nécessitent, la densité applicative est bien plus vaste.



Description des types de solutions utilisées

Au cours du projet, nous avons utilisé beaucoup dapplications qui nont pas lieu d’être dansle schéma de linfrastructure finale. Cependant pour savoir comment trouver les étapes, nousavons dressé un schéma regroupant les 6 étapes nécessaires au bon fonctionnement de tout lesystème de métrologie centralisée.

Figure 4 : Etapes de notre projet

Notre projet se compose ainsi de 6 types de solutions :

• Les sondes• La gestion des données• La base de données• Les outils de visualisation• Les alertes• Les logiciels de stress

Pour chaque type de solution, nous allons avoir plusieurs possibilités.

Nous les avons toutes détaillées pour voir leurs différentes caractéristiques et définir le supportde la communauté présente derrière le projet concerné.

Certains projets présentés étant trop jeunes, nous avons donc décidé de les écarter par manquedinformation. dautres projets étant trop anciens, (documentations et utilisation potentiellementobsolètes), nous avons également décidé de les écarter.

Notre écosystème comportent des applications web multiples. ne sachant pas à lavance leurnature, nous avons donc besoin de toucher lensemble des composants.



Cadvisor

Cadvisor ou container advisor, fournit aux utilisateurs de conteneurs une compréhension delutilisation des ressources et des caractéristiques du rendement des conteneurs en fonctionne-ment.

Lapplication prend nativement en charge les conteneurs dockers, et supporte la majeure partiedes fonctionnalités des autres orchestrateurs de conteneurs tels que Kubernetes, dû principale-ment aux propriétés en relation avec le kernel Linux.

Le projet cadvisor a été créé et développé par la société Google pour leur propre projet dor-chestrateur de Conteneurs ( cf Kubernetes 6 ). Il est rendu publique le 9 juin 2014. Cadvisor estbasé sur lancien projet LMCTFY 7 qui a pour objectif de faire l’implémentation des donnéesde Docker / LXC.

Notre version testée est la dernière, cest la version v0.32.0

Node-Exporter

Node-Exporter se rapproche du principe de cadvisor, mais lui permet de récupérer les donnéesde la machine hôte et non pas des conteneurs.

Le projet Node-Exporter a la particularité d’être un projet dirigé par la communauté autourdu logiciel Prometheus. Il est donc en adéquation avec celui-ci et comporte une très grandepartie des metrics que peuvent avoir dautres solutions, il est très stable du point de vue de sondéveloppement.

La version utilisée est la 0.17.0.

6. https ://en.wikipedia.org/wiki/Kubernetes7. github.com/google/lmctfy



Figure 5 : Logo Apache Exporter

Apache Exporter

Apache Exporter est un exportateur Prometheus écrit en Go. il a été créé pour les métriquesqui concernent le serveur web Apache, il exporte les rapports d’état du serveur Apache généréspar mod_status comme lespace disponible et utilisé sur la racine dApache soit /var/www/pu-blic_html ou encore le nombre de requête effectuées sur les serveurs Apache.

Version actuel dapache Exporter (0.5.0).

Netdata

Netdata est un outil de supervision en temps réel pour les systèmes Linux qui permet devisualiser les éléments importants d’un système (processeur, mémoire, débit du disque dur,traffic réseau, application, etc.).

• Projet très suivi par sa communauté.• Très consommateur en performance à cause de ses métriques instantanées et son dash-

boards.

Version actuelle de netdata (1.13.0 ).



Telegraf

Telegraf est un plug-in écrit en Go. Il a été conçu pour collecter et rapporter des métriquessystèmes comme le CPU, la RAM ou lespace disque.

Il permet également de rapporter des métriques applicatives comme apache, présent dansnotre label applicatif.

Pour cela, Telegraf collecte des métriques via des plugins ń input ż, les transforme si besoin,et les envoie dans des plugins ń output ż.

Il existe beaucoup de plugins input et output, il suffit juste de les paramétrer dans laconfiguration telegraf.

Nous avons utilisé le plugin input de docker. Celui-ci récupère les données d’un servicedocker.



Synthèse des solutions de sondes

Type desonde

Compatibilitéavec Prometheus

Métriques générées

Cadvisor Conteneur oui conteneurTelegraf Système non Conteneur et physique

Apache Exporter Applicatif oui serveur webNode Exporter Système oui physique

Netdata Système oui physique

Nous avons choisi dinstaller Node Exporter, Cadvisor ainsi quApache Exporter, car ces sondesnous permettaient davoir les métriques des conteneurs, de la machine physique, ainsi que leserveur web.

Nous avons abandonné lutilisation de Netdata car il a généré beaucoup de problèmes de per-formance et nétait pas compatible avec notre solution au moment du projet.

Telegraf, quant à lui, ne permettait pas lutilisation de Prometheus et se liait directement avecinfluxDB.



Gestions des données

Dans le cadre de notre projet, toute les données qui vont transiter grâce aux sondes devrontdonc être gerer. Nous avons besoin dune solution qui nous permettra de tout centraliser sur unmême logiciel. Pour cela, plusieurs solutions soffrent à nous pour récolter les données que lessondes vont transmettre.

Centralisation de toutes les sondes

Prometheus

Prometheus est un projet open-source développé par des ex-ingénieurs de Google. Il utilise lelangage de requête “PromQL” .

La communauté est très active, contient de nombreux développeurs à son actif et de nom-breuses entreprises lutilisent. Son avantage principale est sa flexibilité. Il peut être utilisé dansla surveillance, centralisée sur une machine ou encore sur des architectures bien plus avancéeset dynamiques. Prometheus est un système complet de surveillance et dalerting. Il contient desfonctions natives pour récolter ses propres données. Il peut également créer des graphiques àpartir de ses données ainsi qu’à des mesures externes et les stocker temporairement.

Dans le cadre du projet nous utilisons dautres modules pour compléter larchitecture, dontinfluxDB adapter, qui permet de faire la transition entre Prometheus et influxDB.

Graphite

Graphite stocke des échantillons numériques pour des séries chronologiques nommées, un peucomme Prometheus. Cependant, Graphite est surtout une base de données passive de sérieschronologiques avec un langage de requête et des fonctions graphiques. Pour aller plus loin dansle traitement des données, Graphite est obligé d’utiliser des composantes externes. Prometheus,lui, est plus complet et ne nécessite pas forcément lintervention de module externe.



Base de données

Actuellement, la majorité des données qui transitent sur internet ( Big Data ) sont de naturetemporelle. Toute ces données sont appelées des transactions.

Dans notre cas dutilisation de la base de données, nous avons les besoins suivants :

• Stocker un très grand flux de données.• Un flux de données sans aucunes relations réelles.• Un flux de données qui est régie par son horodatage• Faire des milliers de requêtes sans difficultés.• Une latence très courte pour un affichage rapide

Différence avec une base de données classique

Relational Databases Time Series DatabasesComment sont stockés lesdonnées ?

Les données des tableset des index dans

des fichiers organiséssous forme de pages

Les données sont mises lesunes derrière les autres avecleur horodatage incrémental

Accès vitesse Accès aux données rapides Accès aux données très ra-pides

travailler sur les donnéesdans le temps

Très difficile, données dépen-dantes du reste

Très simple car elles sont in-dépendantes

En plus de ces quelques besoins cité au dessus, nous devons avoir la possibilité de retravaillerlensemble des métriques permettant de faire des moyennes, et de ne pas conserver toutes lesmétriques qui seront stockés au fur et à mesure.



InfluxDB

InfluxDB est une base de données temporelles ayant comme équivalents Timescale DB. In-fluxDB nous permet de faire de la rétention de données. Il permet dobtenir, de réduire lataille et dinterroger en temps réel un haut débit de données. Il permet également de faire del’échantillonnage pour stocker des valeurs clés afin de ne pas avoir de problème de stockage.

Influx DB fonctionne avec le principe “NoSQL désigne une famille de systèmes de gestion debase de données (SGBD) qui s’écarte du paradigme classique “ 8

Pour effectuer toutes les manipulations, nous avons utilisé trois fonctionnalitées du logicielinfluxDB :

• Retentions Policies• Continuous Queries• Shard Groups

Rétentions Policies

Commençons par les politiques de rétention. Les données chronologiques par nature com-mencent à s’accumuler assez rapidement et il peut être utile de supprimer les anciennes donnéesune fois qu’elles ne sont plus utiles. Les stratégies de rétention offrent un moyen simple et ef-ficace d’y parvenir. Cela équivaut essentiellement à une date d’expiration de vos données. Unefois que les données sont ńexpiréesż, elles seront automatiquement supprimées de la base dedonnées, une action couramment appelée application de la stratégie de rétention. Lorsque vientle temps de supprimer ces données, InfluxDB ne supprime pas simplement un point de donnéesà la fois, il supprime un groupe de fragments entier

8. https ://fr.wikipedia.org/wiki/NoSQL



Continuous Query

Les requêtes continues (CQ) sont des requêtes InfluxQL (query language) qui s’exécutent au-tomatiquement et périodiquement sur des données en temps réel et stockent les résultats de larequête dans une mesure spécifiée.

De base sur influxDB, l’intervalle régulière d’exécution des Continuous Querys est de 30 minsur nos trois bases de données.

Shard Groups

Un groupe de fragments est un conteneur pour les fragments, qui contiennent à leur tour lesdonnées de série temporelle. Chaque groupe de fragments ont une stratégie de rétention corres-pondante et tous les fragments d’un même groupe adhèrent à la même stratégie de rétention.

De plus, chaque groupe de fragments ont une durée, qui détermine la fenêtre temporelle dechaque groupe de fragments (intervalle de temps). L’intervalle de temps peut être spécifié lorsde la configuration de la stratégie de rétention. Si rien n’est spécifié, la durée du groupe departitions par défaut est de 7 jours.

Figure 6 : Tableau des shard duration / RP



Thanos

Thanos 9 est un ensemble de composant qui peut être composés dans un système métriquehautement disponible avec une capacité de stockage illimitée. Les composants peuvent êtreajoutés aussi de manière transparente au-dessus des déploiements existants de Prometheus.Cest un nouveau projet qui a été présenté au FOSDEM 10 2019.

Le projet Thanos est un projet visant à combler les lacunes que Prometheus peut avoir surla haute disponibilité ainsi que la possibilité de le faire fonctionner un peu partout dans lemonde sur des stockages avec des rétentions de donnée illimitée, permettre une vue globale desrequêtes pour les métriques.

Le projet datant de novembre 2017 et nétant pas adéquat, nous avons décidé de ne paslutiliser, le logiciel étant plus adapté pour une utilisation entre datacenter de différents lieuxdans le monde.

Timescale DB

TimescaleDB est un projet open-source fonctionnant en tant que plugin de Postgresql pourrendre les requêtes SQL en time series données avec des métriques horodatés.

TimescaleDB est la base de données que nous avons essayé dinstaller, seulement, impossible de lafaire fonctionner au niveau des continuous Query, lun des problèmes est le projet TimescaleDBqui nest pas aussi bien documenté que les autres solutions de base de données.

Lune des particularités de TimescaleDB 11 est sa rapidité, comparé à postgresql qui est considé-rée 20 fois supérieures pour linsertion des données et une gestion jusquà 14 000 fois plus rapidepour la plupart des requêtes directes.

La vision du projet TimescaleDB, dans le monde des base de données est très axé sur le full SQL,ce qui est un contraste à ce quinfluxDB propose. InfluxDB vise à se passer des requêtes SQL.Afin quune solution corresponde à nos besoins, elle doit permettre le stockage des métriquesavec les résultats dans un temps donné, permettre de créer des échantillons et une moyenne surun temps définis.

9. https ://github.com/improbable-eng/thanos10. conférence annuelle organisée à l’Université libre de Bruxelles depuis 2001, la conférence accueille 5000

personnes de façon annuelle11. https ://blog.timescale.com/timescaledb-vs-6a696248104e/



Synthèse des solution pour la bases de données Time Series

Fonctionnalitéintéressante

Correspondaux besoins

Production Documentation

InfluxDB RetentionPolicies/ Conti-

nuous Query

Oui Oui Documentation complète,soutenu par InfluxDATA

Thanos centralisationEntre

chaque lieu

Non /Exportation

Stade deprojet

Aucune documentation

TimeScaleDatabase

Fonctionnaliténon im-plémenté

Oui Oui très faible documen-tation en rapportavec nos besoins

Nous avons donc choisi la solution InfluxDB qui est la plus couramment utilisée, car ellepropose des fonctionnalités intéressantes, compréhensibles et il ny a pas besoin de plugin pouraccéder à ses fonctionnalités.



Outils de visualisation

Les outils de visualisation sont une des dernières étapes pour permettre à ladministrateursystème de visualiser les données des différents serveurs et conteneurs. Dans le cadre de notreprojet, plusieurs outils existent et doivent être en adéquations avec notre base de données.

Grafana

Grafana est un logiciel libre qui permet de visualiser, de réaliser des graphiques et mettre enformes des métriques qui seront récupérées depuis la base de données influxDB. Il peut êtredéployé sur de nombreux OS et il peut aussi être utilisé par Docker.

Prometheus graphique

Prometheus intègre une fonction qui permet de générer des graphiques, mais linterfaceest très peu esthétique. Il faut donc avoir recours à une alternative (ici Grafana). Prometheuspeut également générer ses propres métriques, il peut donc indiquer ce quil consomme.

Figure 7 : Exemple graphique prometheus



Chronograf

Chronograf est linterface graphique proposé par InfluxDATA permettant de visualiser lecontenu des bases de données InfluxDB. Il permet également la création dalerte et de calcul dedonnées.

Prometheus Grafana ChronografCalcul sur métriques Oui Oui ( dépend de la

source )Oui

Dashboard Person-nalisable

Non Oui Oui

Alerte Oui Oui OuiUtilisation de va-riable

Non Oui Non

Nous avons porté notre choix final sur Grafana pour la visualisation, car la création dedashboard personnalisable permet lutilisation de variable, pour les alertes nous avons utilisédans un premier temps grafana puis nous avons testé prometheus alert manager.



Alertes

Dans le cadre de la métrologie centralisée, nous avons besoin de toujours être informés desproblèmes actuels de linfrastructure, pour que dun coup doeil, les personnes en charge voientles problèmes et puissent les régler.

Système webhook

Un webhook sert à notifier à une tierce application quun événement a eu lieu. Techniquement, unWebhook envoie une requête HTTP vers une URL. Les webhook peuvent avoir de nombreusesapplications comme informer sur le suivi des colis ou prévenir votre équipe quand un ticketurgent est créé. Dans notre cas, les webhook servent à nous notifier, sur discord et stack, lesalertes paramétrées dans Grafana.

Discord

Discord est un logiciel de communication instantané pensé pour les joueurs et lancé en 2015. Ilest possible dintégrer des webhook et des bots. Cest un logiciel qui nous est très familier, nousavons commencé par lutiliser avec une intégration dun bot grafana. Cette intégration fonctionneavec la fonction dalerte de grafana. Selon les configurations de lalerting, grafana envoyait unealerte sil y avait une surcharge du CPU par exemple.

Slack

Slack est un logiciel de communication professionnelle lancé en 2013. Slack est similaire à un chatIRC organisé en canaux. Il est disponible sur différentes plateformes android, IOS, Windows,Linux.



Logiciels de Stress

Dans le cadre dun cluster docker, nous avons effectué quelques tests unitaires afin de nousassurer que la solution en place sur l’infrastructure permet de faire remonter des alertes, détudierles problèmes relatifs aux données qui transitent sur le système.

Gatling

Le logiciel Gatling, est un outil de stress dapplication web open-source, il permet deffectuer destests de montée en charge, très précise.

Le projet a été développé par Stéphane Landelle qui a fondé la société Gatling Corp aprèsla sortie des premières versions du logiciel. Stéphane Landelle travaille sur dautres projetscomme Asynchronous HTTP Client et sur le framework Netty également sous licence apache2.0. Gatling est soutenu par la fondation Apache et est distribué sous licence Apache-2.0.

Gatling est une solution alternative au projet Jmeter qui est lui une solution développée directe-ment par la fondation Apache, il est en concurrence direct, mais Gatling utilisent une méthodede gestion du trafic permettant dêtre moins gourmands que la solution Apache JMeter.

Loutil est développé en langage scala. Lutilisation du langage scala a été poussé par lutilisationdAkka qui est un système permettant léchange de message asynchrone, ceci permet de simulerun nombre dutilisateur beaucoup plus important avec une seule et unique machine. Gatlingcomporte de multiple fonctionnalités telles que :

• La possibilité d’enregistrer des sessions de requêtes afin de les rejouer plus tard.

• La génération dun ensemble de pages HTML afin de visualiser le rapport ainsi créer.Le rapport est généré grâce à des librairies javascript Highstockes et highcharts afin deproduire des graphiques optimisés.

• Lun des aspects pratiques du logiciel gatling cest quil est paramétrables en utilisant desscripts de simulations.



Apache Jmeter

Apache Jmeter 12 a été créé par la fondation apache et est un logiciel écrit en java, conçupour tester le comportement et mesurer les performances. Au départ il était développé pourtester des applications web, mais il a été amélioré pour quil réponde à plus de besoin. Il peutêtre utilisé pour tester des performances à la fois sur des ressources statiques et dynamique. Ilpermet de simuler de lourde charges sur un serveur ou de tester les performances dun protocolecomme le TCP/IP ou le HTTP.

Apache Jmeter contient les fonctions suivantes :

• Mode CLI (Mode ligne de commande) pour lancer le test depuis les OS compatibles Java(comme linux, windows, Mac).

• Un rapport HTML dynamique est créé à la fin du test de charge pour avoir un aperçuavec une mise en cache pour avoir accès au contenu en hors ligne

• Possibilité dextraire les données dans des formats courant (HTML, XML, JSON) ainsiquen dautres formats textuels.

• Permet une portabilité complète.• Permet lutilisation de plusieurs processus pour faire les requêtes.• Environnement de développement qui permet lenregistrement rapide des plans de tests.

Synthèses des solutions de stress

Gatling Apache JmeterImpact sur le cluster Consomme moins de RAM Risque de crash

un conteneurrapport user-friendly / complet austère

Fonctionnalité requêtes asynchrone Visualisation des requêtesDocumentation très accessible accessible

Notre choix cest porté sur Gatling, qui car il nous a permis denregistrer une simulationayant pour impact la base de donnée et le serveur apache.

12. https ://jmeter.apache.org/



Figure 8 : Rapport de stress gatling

En effet nous avons ajouté des commentaires pour chaque simulation ce qui a permis à labase de donnée dêtre sollicité.



Description et mise en place de linfrastructure

Schéma d’interaction

Figure 9 : Schéma d’interaction

Lensemble des six étapes décrites plus tôt sont représentés dans cette ordre.



Schéma de linfrastructureFigure 10 : Schéma infrastructure

Nous avons mis en place trois machines virtuels, “leader” et “worker” basé sur docker-machine.

Afin dalimenter nos machines, nous avons mis en place deux fichiers “docker-compose.yml” .Pour chaque conteneur dans le fichier docker-compose nous lavons indexé dun label permettantde faire des calculs sur l’utilisation des ressources et des groupes de statistiques.

Après le lancement des sondes et l’exposition des ports, nous avons configuré Prometheus afinquil puisse aller lire les sondes.

Prometheus peut donc lire les métriques venant de node exporter, cadvisor et apache exportersitués dans la plupart des cas sur “host :port/metrics” , les data sont notées “inline” ce quipermet la gestion simplifiée des données pour la prochaine étape.



Afin de créer des rétentions, nous envoyons toutes les requêtes sur InfluxDB. Nous avons utiliséquatre bases de données, dans ces quatre bases de données, lune delle est utilisée pour récupérertoutes les métriques et les trois autres sont les unes après les autres basées sur le système deresampling 13 permettant ainsi de ne pas conserver trop de données.

Pour alimenter la base nous utilisons un adapter, nous y sommes obligés même si nodeexporter et cadvisor peuvent être envoyés directement, ce nest pas le cas de lapache exporter.

Figure 11 : Représentation graphique InfluxDB

Afin de visualiser les datas présentes dans les différentes bases nous utilisons grafana.Il a donc fallu rajouter InfluxDB en tant que data source sur Grafana.

Nous avons donc rajouté trois datasources influxDB (voir pour les différentes bases dedonnées “prom_short” , “prom_moy“ et “prom_long” .

13. A partir de plusieurs valeurs, nous ne conservons quune seule valeur : la moyenne



Les dashboards utilisant les trois bases de données ci dessus, nous créons la variable qui seradéfinie en tant que Datasource.

Sur Grafana, nous avons créé nos propre dashboard afin de visualiser les métriques. Nousavons donc dû créer différentes variables pour créer un dashboard complet (contraintes deman-dées).

Nous avons décidé de mettre en avant certaines métriques, comme lutilisation de la mémoirepar label “monitoring” et “vie” , la mémoire pour chacun de nos conteneurs, le CPU, le nombrede conteneur lancés ou encore la charge sur chaque noeuds.

Le label “vie” inclut tout ce qui nest pas du monitoring tels que des applications Webs.



Figure 12 : Dashboard Grafana

Figure 13 : Variables grafana

Nous avons mis en place les variables afin de trier les graphiques par datasource, instance,label et noeud.

• $ datasource : Cette variable permet de trier en fonction des trois datasources précédem-ment mentionnés.

• $ instance : Il permet de trier les instances liées à cadvisor (certaines métriques lui sontdédiées).

• $ label : Il permet de trier par les labels mis en place “sondes” , “monitoring” et“application” .

• $ instance_node : Il permet de trier les instances liées à Node Exporter (certaines mé-triques lui sont dédiées).



Impact de performance de la métrologie Centralisée

Les Performances du système de métrologie centralisée dans une utilisation en production doitêtre le plus minime possible, pour cela nous avons dressé des graphiques provenant de Grafanadirectement depuis le dashboard.

Sur le serveur Leader, on peut voir tout de suite limpact sur notre docker machine utilisantseulement les outils de monitoring et de stockage des métriques. Limpact est dors et déjàimportant, car les requêtes sont en permanence effectuées entre prometheus et influxDB.

Il faut savoir que le serveur qui a lensemble des données à une consommation de 5% à 10%pour la base de données.

En sachant que dans notre configuration en fonction des différentes rétentions, nous avonsbesoin que les données se répliquent dans les différentes bases. De ce fait, la consommationpeut difficilement être réduite.



Limpact de la partie monitoring sur “worker” est légère et acceptable, en effet la charge CPUest de 0.5% . En sachant quil y a seulement les sondes. Dans notre cas les sondes présentessont :

• Apache Exporter• Node Exporter• Cadvisor

Simulation

Nous avons simulé des montées en charges sur le serveur wordpress situé dans le conteneur avecle logiciel gatling ce qui nous a permis de détecter les défaillances de notre infrastructure.

Figure 14 : Dashboard grafana pendant un test de charge



Alertes

Figure 15 : Configuration alertes grafana

Afin de mettre en place des alertes il faut dans un premier temps définir la “query” qui signifiedonc les métriques, choisir un seuil critique et le temps minimum dalerte.

Dans le cadre de lorganisation de notre projet nous avons utilisé Discord afin déchanger ausein du projet, donc nous avons créé un robot Grafana afin dêtre au courant de la moindredéfaillance au sein de notre infrastructure.

Figure 16 : Grafana alert - discord



Afin dutiliser une messagerie instantanée plus professionnelle, nous avons installé un serveurSLACK et avons créé les alertes pour montrer quil est également possible de créer des alertesdans le monde professionnel sur une messagerie instantanée.

Figure 17 : Grafana alert - Slack



Problèmes rencontrés

Docker-Compose

Configuration obsolète

Lors de la première approche de ce sujet, nous avons survolé plusieurs docker-compose afinde créer linfrastructure. Cependant à chaque fois il existait des problèmes de compatibilité, deversion très anciennes et plus compatible avec les derniers fichiers de configuration.

Pour palier à ce problème, nous avons décidé de créer nos propres docker-compose et nos proprefichiers de configuration.

Ceci nous a permis de mettre en place cette méthode étudiée en cours.

InfluxDB

Espace mémoire

Le conteneur influxdb prend très vite beaucoup despace, nous avons donc dû réfléchir à unesolution permanente afin de régler le soucis. Pour ce faire, nous avons augmenté la taille de laVM “leader” et demandé à InfluxDb de se servir dun répertoire que nous avons créé pour écrireles données.

Sondes

Compatibilité

Nous avons été obligés décarter certaines sondes en raison de leurs versions (netdata et telegraf).En effet les métriques récoltées étaient illisibles pour prometheus. Suite à un comparatif desonde, netdata et telegraf ont pu être remplacés par node_exporter.



Organisation du projet

Pour le projet, nous avons décidé de nous répartir le travail mais également de communiquer leplus possible ensemble pour avancer à un rythme soutenu. Nous avons dès le début du projetmis en place un outil de gestion de développement de projet nommé framagit 14 qui utilise lelogiciel Git Lab community Edition.

Framagit est hébergé sur le réseau de lassociation déducation populaire, Framasoft.

Dès le début nous avons renseigné notre avancement du projet sur un système de suividisponible sur le site de luniversité de Lorraine. Ce qui permet à notre tuteur davoir un aperçujournalier de lavancement du projet tutoré tout au long de la période du 21 janvier 2019jusquaux 27 mars 2019, jour de la soutenance finale.

Durant les deux mois de projet tutoré, nous avons chaque fin de semaine en adéquation avecnotre tuteur, fournit un rapport hebdomadaire dune page relatant tous les problèmes que nousavons eus durant cette période. Nous avons aussi présenté dans ce rapport, les points à travaillerles semaines suivantes afin de connaître lavancée du projet.

14. https ://framagit.org/



Répartition des tâches

Aymeric Maxime Victor BenjaminRecherche Théorie X X X

Mise en placeInfrastructure

X X X X

Travail surles sondes

X X X X

Mise en placedu planning

X X

Docker-swarm X XConfiguration

InfluxDBX X

Test solutiontimescaleDB

X X

DashboardsGrafana

X X X

Installation dusystème dalerte

X X X

Travail sur lagénération detrafic sur lesapplications

X

Création degraphiques

X X X X

Rapport Heb-domadaires

X X X X

Rapport X X X X



Conclusion

Autour de ce projet nous avons su travailler en groupe sur un même sujet, se répartir les tâcheset gérer les rôles de chacun.

Linformatique ne cessent dévoluer et au fur et à mesure des années, un nouveau besoin estapparu, la gestion des ressources. Le monitoring est devenu primordial lors de linstallation desmoyennes et grosses infrastructures. Dans le cas dune infrastructure conséquente, nous sommesobligés de faire de la métrologie centralisée pour avoir toutes les données en un seul point.Pour ce faire, on utilise divers logiciels et sondes qui permettent davoir un retour direct sur laconsommation de ressource physique comme la RAM ou le CPU. Tout ce système est installésur des machines virtuelles ou des conteneurs.

Le but de notre projet était de mettre en place une solution de métrologie centralisée pournoeuds et conteneurs afin de pouvoir récupérer et échantillonner dans le temps les donnéesrécoltés.

Nous avons mené à bien afin cette tâche en proposant une solution basée sur Docker commedemandé.

Pour récolter les données, nous navons pas utilisé netdata/cadvisor comme conseillé carsuite à nos recherches et nos différents tests nous avons constaté que netdata renvoi les mêmestypes de métrique que node exporter et posséder une erreur au niveau des versions utilisées,dont une mauvaise interprétation des données sur prometheus.

Il nous a été demandé de créer différents échantillonnages au sein de notre collecte. Pour cefaire InfluxDB a remplit son rôle et a permis un échantillonnage court, moyen et long dans letemps.

Afin de visualiser les résultats nous avons créé un dashboard sur grafana avec différentesvariables afin de voir en un seul clic les différents échantillonnages en fonction des différentesbases.

Pour créer les alertes, nous avons utilisé grafana alert mais beaucoup derreurs ont été dé-tectés lorsque nous voulions en créer une avec des variables.

Pour palier à ce problème nous avons utilisé prometheus alert manager afin de créer desalertes en fonction des labels que nous avons utilisées.

Ce projet nous aura permis de découvrir des parties non abordées en cours de docker, maisaussi davoir de nouvelles connaissances dans le domaine de la métrologie.



Bibliographie

Liens

https ://docs.docker.com/https ://prometheus.io/https ://graphite.readthedocs.io/https ://machineperson.github.io/https ://octoperf.com/blog/2015/06/08/jmeter-vs-gatling/http ://docs.grafana.org/https ://blog.eleven-labs.com/fr/monitorer-ses-containers-docker/https ://blog.octo.com/monitorer-votre-infra-avec-telegraf-influxdb-et-grafana/https ://my-netdata.io/


https://docs.docker.com/

https://prometheus.io

https://graphite.readthedocs.io/

https://machineperson.github.io/

https://octoperf.com/blog/2015/06/08/jmeter-vs-gatling/

http://docs.grafana.org/

https://blog.eleven-labs.com/fr/monitorer-ses-containers-docker/

https://blog.octo.com/monitorer-votre-infra-avec-telegraf-influxdb-et-grafana/

https://my-netdata.io/


Annexes

How to create cluster docker

Installation Docker

apt-get update

sudo apt-get -y install \apt-transport-https \ca-certificates \curl \gnupg2 \software-properties-common

curl -fsSL https ://download.docker.com/linux/debian/gpg | sudo apt-key add -

sudo apt-key fingerprint 0EBFCD88

sudo add-apt-repository \"deb [arch=amd64] https ://download.docker.com/linux/debian \$ (lsb_release -cs) \stable"

sudo apt-get -y update

sudo apt-get -y install docker-ce

Installation Docker-machine

curl -L https ://github.com/docker/machine/releases/download/v0.16.1/docker-machine-‘uname -s‘-‘uname -m‘ >/usr/local/bin/docker-machine

chmod +x /usr/local/bin/docker-machinesudo ln -s /usr/local/bin/docker-machine /usr/bin/docker-machine

Installation Infrastructure

Mise en place Clusterdocker-machine create -d virtualbox leaderdocker-machine create -d virtualbox worker

Initialiser le tokendocker-machine ssh leader "docker swarm init –advertise-addr192.168.99.100"

Lier worker à leaderdocker-machine ssh worker "docker swarm join –token <token> 192.168.99.100 :2377"



Le token a été initialisé par lors de la commande précédente.

Vérifier que Leader est lié à Worker

docker-machine ssh leader "docker node ls"

Installer Docker-compose (sur noeuds)

Leader

Docker-machine ssh leaderDocker-composecurl -L https ://github.com/docker/compose/releases/download/1.24.0-rc1/docker-compose-

‘uname -s‘-‘uname -m‘ -o /usr/local/bin/docker-composechmod +x /usr/local/bin/docker-composesudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

WorkerDocker-machine ssh workerDocker-composecurl -L https ://github.com/docker/compose/releases/download/1.24.0-rc1/docker-compose-

‘uname -s‘-‘uname -m‘ -o /usr/local/bin/docker-composechmod +x /usr/local/bin/docker-composesudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose



Leader

docker-compose.yml

version: '2.1'

networks:monitor-net:

driver: bridge

volumes:prometheus_data: {}grafana_data: {}

services:

prometheus:image: prom/prometheus:latestcontainer_name: prometheusvolumes:

- ./prometheus/:/etc/prometheus/- prometheus_data:/prometheus

command:- '--config.file=/etc/prometheus/prometheus.yml'- '--storage.tsdb.path=/prometheus'- '--web.console.libraries=/etc/prometheus/console_libraries'- '--web.console.templates=/etc/prometheus/consoles'- '--storage.tsdb.retention.time=200h'- '--web.enable-lifecycle'

restart: unless-stoppedports:

- "9090:9090"networks:

- monitor-netlabels:

org.label-schema.group: "monitoring"

nodeexporter:image: prom/node-exporter:v0.17.0container_name: nodeexporter_leaderuser: rootprivileged: truevolumes:

- /proc:/host/proc:ro- /sys:/host/sys:ro- /:/rootfs:ro

command:- '--path.procfs=/host/proc'- '--path.rootfs=/rootfs'



- '--path.sysfs=/host/sys'- '--collector.filesystem.ignored-mount-points=^/(sys|proc|dev|host|etc)'


- "9100:9100"networks:



cadvisor:image: google/cadvisor:v0.32.0container_name: cadvisor_leadervolumes:

- /:/rootfs:ro- /var/run:/var/run:rw- /sys:/sys:ro- /var/lib/docker/:/var/lib/docker:ro#- /cgroup:/cgroup:ro #doesn't work on MacOS only for Linux


- "8080:8080"networks:



grafana:image: grafana/grafana:latestcontainer_name: grafanavolumes:

- grafana_data:/var/lib/grafana- ./grafana/datasources:/etc/grafana/datasources- ./grafana/dashboards:/etc/grafana/dashboards- ./grafana/setup.sh:/setup.sh

entrypoint: /setup.shenvironment:

- GF_SECURITY_ADMIN_USER=${ADMIN_USER:-admin}- GF_SECURITY_ADMIN_PASSWORD=${ADMIN_PASSWORD:-admin}- GF_USERS_ALLOW_SIGN_UP=false


- "3000:3000"networks:





influxdb:image: influxdb:latestcontainer_name: influxdbports:- "8083:8083"- "8086:8086"- "8090:8090"

env_file:- 'env.influxdb'

volumes:# Data persistency

# sudo mkdir -p /srv/docker/influxdb/data

- /srv/docker/influxdb/data:/var/lib/influxdbenvironment:

- INFLUXDB_DB=prometheus- INFLUXDB_ADMIN_USER=admin- INFLUXDB_ADMIN_PASSWORD=password- INFLUXDB_USER=prometheus- INFLUXDB_USER_PASSWORD=password- INFLUXDB_READ_USER=grafana- INFLUXDB_READ_USER_PASSWORD=password

labels:org.label-schema.group: "monitoring"

prometheus-influxdb-adapter:image: kaorimatz/prometheus-influxdb-adapterports:

- 9201:9201environment:

- WRITE_INFLUXDB_URL=http://prometheus:password@influxdb:8086command: [

"--log.level=debug","--read.influxdb.field=max_over_time:max","--read.influxdb.field=min_over_time:min","--read.influxdb.field=sum_over_time:sum","--read.influxdb.field=mean","--read.influxdb.retention-policy=1h:1h","--read.influxdb.retention-policy=5m:5m","--read.influxdb.retention-policy=1m","--read.influxdb.rpc-address=influxdb:8082",

]depends_on:

- influxdblabels:




prometheus.yml

global:scrape_interval: 15sevaluation_interval: 15s

# Attach these labels to any time series or alerts when communicating with

# external systems (federation, remote storage, Alertmanager).

external_labels:monitor: 'docker-host-alpha'

# Load and evaluate rules in this file every 'evaluation_interval' seconds.

rule_files:- "alert.rules"

# A scrape configuration containing exactly one endpoint to scrape.

scrape_configs:- job_name: 'nodeexporter'

scrape_interval: 5sstatic_configs:

- targets: ['192.168.99.100:9100']- targets: ['192.168.99.101:9100']

- job_name: 'cadvisor'scrape_interval: 5sstatic_configs:

- targets: ['192.168.99.100:8080']- targets: ['192.168.99.101:8080']

alerting:alertmanagers:- scheme: http

static_configs:- targets:

- 'alertmanager:9093'

# Remote write configuration (for Graphite, OpenTSDB, or InfluxDB).

remote_write:- url: "http://192.168.99.100:9201/write"

# Remote read configuration (for InfluxDB only at the moment).

remote_read:- url: "http://192.168.99.100:9201/read"



Worker

docker-compose.yml

version: '2.1'

services:

nodeexporter:image: prom/node-exporter:v0.17.0container_name: nodeexporteruser: rootprivileged: truevolumes:

- /proc:/host/proc:ro- /sys:/host/sys:ro- /:/rootfs:ro

command:- '--path.procfs=/host/proc'- '--path.rootfs=/rootfs'- '--path.sysfs=/host/sys'- '--collector.filesystem.ignored-mount-points=^/(sys|proc|dev|host|etc)($$|/)'


- '9100:9100'labels:


cadvisor:image: google/cadvisor:v0.32.0container_name: cadvisorvolumes:

- /:/rootfs:ro- /var/run:/var/run:rw- /sys:/sys:ro- /var/lib/docker/:/var/lib/docker:ro#- /cgroup:/cgroup:ro #doesn't work on MacOS only for Linux


- '8080:8080'labels:


db:image: mysql:5.7volumes:

- db_data:/var/lib/mysqlrestart: alwaysenvironment:



MYSQL_ROOT_PASSWORD: somewordpressMYSQL_DATABASE: wordpressMYSQL_USER: wordpressMYSQL_PASSWORD: wordpress

labels:org.label-schema.group: "vie"

wordpress:depends_on:

- dbimage: wordpress:latestports:

- "8000:80"restart: alwaysenvironment:

WORDPRESS_DB_HOST: db:3306WORDPRESS_DB_USER: wordpressWORDPRESS_DB_PASSWORD: wordpressWORDPRESS_DB_NAME: wordpress

labels:org.label-schema.group: "vie"

volumes:db_data: {}



Fichier denregistrement gatling

import scala.concurrent.duration._import io.gatling.core.Predef._import io.gatling.http.Predef._import io.gatling.jdbc.Predef._

class WordPressRapport extends Simulation {

^Îval httpProtocol = http^Î^Î.baseURL("http://192.168.99.101")^Î^Î.inferHtmlResources()^Î^Î.acceptHeader("text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8")^Î^Î.acceptEncodingHeader("gzip, deflate")^Î^Î.acceptLanguageHeader("fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3")^Î^Î.userAgentHeader("Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0")

^Îval headers_0 = Map("Upgrade-Insecure-Requests" -> "1")

^Îval headers_1 = Map("Accept" -> "*/*")

val uri2 = "http://1.gravatar.com/avatar"

^Îval scn = scenario("WordPressRapport")^Î^Î.exec(http("request_0")^Î^Î^Î.get("/")^Î^Î^Î.headers(headers_0)^Î^Î^Î.resources(http("request_1")^Î^Î^Î.get("/wp-includes/js/wp-emoji-release.min.js?ver=5.1.1")^Î^Î^Î.headers(headers_1)))^Î^Î.pause(4)^Î^Î.exec(http("request_2")^Î^Î^Î.get("/?s=Article")^Î^Î^Î.headers(headers_0))^Î^Î.pause(9)^Î^Î.exec(http("request_3")^Î^Î^Î.get("/2019/03/06/bonjour-tout-le-monde/")^Î^Î^Î.headers(headers_0))^Î^Î.pause(13)^Î^Î.exec(http("request_4")^Î^Î^Î.post("/wp-comments-post.php")^Î^Î^Î.headers(headers_0)^Î^Î^Î.formParam("comment", "Bonjour")^Î^Î^Î.formParam("author", "Benja")^Î^Î^Î.formParam("email", "[email protected]")^Î^Î^Î.formParam("url", "x")^Î^Î^Î.formParam("submit", "Laisser un commentaire")



^Î^Î^Î.formParam("comment_post_ID", "1")^Î^Î^Î.formParam("comment_parent", "0")^Î^Î^Î.resources(http("request_5")^Î^Î^Î.get("/2019/03/06/bonjour-tout-le-monde/?unapproved=2&moderation-hash=0c4e3d62425fbc7d3f786e96d3f7872f")^Î^Î^Î.headers(headers_0),

http("request_6")^Î^Î^Î.get("/wp-includes/js/comment-reply.min.js?ver=5.1.1")^Î^Î^Î.headers(headers_1),

http("request_7")^Î^Î^Î.get(uri2 + "/1d2ab164559aaf8a30eebf516d2f63ad?s=60&d=mm&r=g")^Î^Î^Î.headers(headers_1)))

^ÎsetUp(scn.inject(atOnceUsers(1000),^ÎrampUsers(1000) over(360.seconds))).protocols(httpProtocol)}

}


Documents

Auteurs : Berard Benjamin, ﬀ Maxime, Lancetti Aymeric, Galichet … · 2019. 3. 25. · Lancetti Aymeric, Galichet Victor Tuteur : Stéphane Casset Mercredi 27 mars 2019 page 1