Gestion des alertes dans uneinfrastructure

Prometheus/Alert-Manager

Auteurs :Faivre AlexandreVillanueva ItzelMazza Lucas

Benotmane Younes

Tuteur : Stéphane Casset

Année universitaire 2019/2020

Sujet: Alert ASRALL

Table des matières1 Remerciements 3

2 Introduction 4

3 Contexte 53.1 Les systèmes d’informations dans les entreprises . . . . . . . . . . . . 53.2 La fiabilité des systèmes . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 La surveillance (Monitoring) . . . . . . . . . . . . . . . . . . . . . . . 53.4 Les alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.5 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Problématique 10

5 Objectifs et Contrainte 115.1 Métrologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.2 Distribution des alertes . . . . . . . . . . . . . . . . . . . . . . . . . . 135.3 Groupage des alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.4 Désactivation temporaire des alertes . . . . . . . . . . . . . . . . . . . 145.5 Historique d’un incident . . . . . . . . . . . . . . . . . . . . . . . . . 145.6 Commenter les incidents . . . . . . . . . . . . . . . . . . . . . . . . . 155.7 Une Adaptation sur le support . . . . . . . . . . . . . . . . . . . . . . 165.8 Contrainte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6 Solution 176.1 Les Entreprises de Surveillance des SI . . . . . . . . . . . . . . . . . . 176.2 Pager duty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186.3 VictorOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.4 OpsGenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7 Infrastructure 247.1 Schéma de l’infrastructure du Projet Tuteure . . . . . . . . . . . . . . 24

8 Architecture 248.1 Conteneurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

8.1.1 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258.1.2 Docker Compose . . . . . . . . . . . . . . . . . . . . . . . . . 268.1.3 Docker Swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

8.2 Sondes(exporters) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288.2.1 Cadvisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288.2.2 Netdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298.2.3 Node-Exporter . . . . . . . . . . . . . . . . . . . . . . . . . . 29

8.3 Gestionnaire de données . . . . . . . . . . . . . . . . . . . . . . . . . 308.3.1 Prometheus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308.3.2 Alert-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

8.4 Outils de visualisation des données . . . . . . . . . . . . . . . . . . . 338.4.1 Grafana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338.4.2 Alerta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8.5 Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

1

Sujet: Alert ASRALL

8.5.1 Redis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388.5.2 MongoDB et SQLite . . . . . . . . . . . . . . . . . . . . . . . 39

9 Problèmes rencontrés 409.1 Promgen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409.2 Alerta-mailer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

10 Bilan et Prospective 42

11 L’organisation du travail 4411.1 Outils de travail utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . 44

12 Répartition de tâches 47

13 Conclusion 48

14 Bibliographie 4914.1 Liens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

15 Annexes 50

2

Sujet: Alert ASRALL

1 RemerciementsNous remercions l’ensemble des membres du jury ainsi tous le corps enseignants

pour tous les conseils, leurs enseignements, et leur remarques.

Nous remercions également Monsieur Lucas Nussbaum, Debian Projet Leader(DPL), maître de conférence à l’Université de Lorraine et chercheur auprès du la-boratoire LORIA, pour nous avoir donné l’envie d’aller plus loin dans l’univers dumonde libre.

Un merci a Monsieur Philippe Dosch, responsable de la formation pour nousavoir accompagner, écoute, mais surtout, pour la patience ainsi que la pédagogied’on, il a fait preuve toute l’année.

Un dernier grand remercient pour Monsieur Stéphane CASSET pour tout le sou-tient apporter durant le projet. Notamment lors de la configuration de l’infrastruc-ture. Sur l’utilisation de docker, ainsi que sur la compréhension globale de tous leprojet depuis ces débuts.

3

Sujet: Alert ASRALL

2 IntroductionLe mot alerte a pour origine la locution : (Estre) a l’herte, qui signifie « (être)

sur ses gardes » 1 Un monde sans risques n’a aucune perspective d’évolution de plus,nous ne pouvons jamais nous fier totalement a quelque chose qui nous est inconnu.Il faudra alors rester vigilant ou « en alerte » pour comprendre les problèmes futurs.Les risques d’insécurité sont nombreux et très faciles à se représenter :

• Les catastrophes naturelles et humaines (guerre)• Les crimes.• La communication (réseaux sociaux).• La météo

Grâce aux exemples ci-dessus nous pouvons constater que les alertes ne résolvespas les problèmes, elles nous offrent un guide pour les comprendre par conséquent,une alerte sera toujours liée de manière intangible á une cause.

C’est justement avec les informations obtenues avec les alertes que nous arri-vons a trouver la solution a un problème donné. Nous pouvons prendre différentsexemples comme :

• Les chiens garde pour les voleurs.• Les alarmes sonores des villes pour les catastrophes.• La télévision pour les enfants disparues.• Les notifications Facebook pour s’adonner a d’autres activités.

Avec des activités de plus en plus variées et nombreuses notre attention (vigi-lance) et divise entre celle-ci. Plus nous avançons dans le temps et plus nous tâchesaugmentées. C’est à cause de ça que nous ne pouvons pas nous permettre d’êtreseulement en alerte par nous-mêmes. Donc il nous faut un intermédiaire fiable, maissurtout de confiance. Voici la raison d’exister des alertes.

1. https ://fr.wikipedia.org/wiki/Alerte

4

Sujet: Alert ASRALL

3 Contexte

3.1 Les systèmes d’informations dans les entreprises

Nous pouvons constater la numérisation de nos besoins en avançant dans le temps(Netflix), quant au rôle d’une entreprise est de répondre à ses besoins ; elle doit avoirla prévenance d’adapter ces outils en conséquence.Ces moyens numériques destinée a un usage professionnel n’ont pas les mêmes coûtsen ressources que celui réservé a un usage privé. En contrepartie, les performancesoffertes par ces équipements et beaucoup plus important. En revanche, leur durée devie et beaucoup moins longue. Ses différentes raisons poussent à vouloir une fiabilitéconséquente sur ses équipements.

3.2 La fiabilité des systèmes

Nos besoins doivent être comblés aussi vite que bien ; de plus, cela doit être faiten toute sécurité bien entendu, mais il ne s’agit pas de notre contexte principal.Ainsi, nous ne parlerons que des performances et de la disponibilité comme critèrede sélection.

• Performance : C’est la capacité de faire un nombre d’actions en un tempsdonné.

• Haute disponibilité : C’est la capacité d’un service à rester actif malgré lesproblèmes.

L’objectif principal d’un administrateur système et réseau sera de maintenir cesdeux critères et de résoudre le plus rapidement possible tout problème qui viendraismenacer ces conditions. Pour cela, il existe 2 outils indispensables.

3.3 La surveillance (Monitoring)

Le premier type d’outils est ceux de surveillance. L’objectif principal sera d’avoirun statut en temps réel d’un équipement ou d’un service avec un tableau de bord. Ilspeuvent garder un historique des précédents états de la fonctionnalité, et l’affichersous forme de graphique. Cela permet notamment de savoir à quel moment unproblème a pu avoir lieu. Donc, de restreindre les causes de l’incident technique.En conclusion, nous avons un état présent et passé du service surveillé. Un outil desurveillance doit être capable de superviser un grand nombre d’équipements. Pourcela, il doit récolter beaucoup d’informations à des intervalles réguliers. De plus, sesdonnées doivent être faciles d’accès pour notre outil en question ; c’est pour celaquelles sont toutes centralisé en un point.

5

Sujet: Alert ASRALL

3.4 Les alertes

Les alertes ou notifications sont utilisées pour nous avertir lorsque qu’une ano-malie se présente sur notre système. Ces différentes anomalies sont repérées grâceaux variables générées avec les méthodes de récoltes des outils de surveillance.

Avec ces variables, nous établissons une condition sur leurs valeurs et décidonspar rapport à nos besoins si la machine nous prévient ou non. Toutes ces variablessont uniquement numériques. Ces seuils ou conditions peuvent se baser sur une va-leur unique. Par exemple, l’état d’une machine 1 pour allumer et 0 pour étain. Oualors, partir sur un plus grand nombre de variables, le seul élément obligatoire etque tous ces conditions mise ensemble ne fasse ressortir qu’un seul résultat. Un peucomme une fonction en mathématique.

Cela signifie qu’il existe différents types d’alertes en fonction de leur degré d’im-portance. Toutes les alertes sont envoyées par des messages qui peuvent être confi-gurés par différents programmes ou services pour alerter l’utilisateur ou l’adminis-trateur d’un événement. Cela signifie que les alertes sont importantes, car elles vousaident à identifier rapidement les problèmes et, de cette façon, accélérer leur solutionsera plus rapide.

3.5 Nagios

Nagios est un système de surveillance open source, qui permet aux administra-teurs de surveiller ainsi que de nous prévenir en cas de comportement inhabitueldu système d’information. Cet outil avec énormément de fonctionnalité nous aide àidentifier quel sont les points de défaillance. Si cela permet de prendre des décisionspour résoudre des problèmes avant qu’ils ne dégénèrent.

Alors nous pouvons voir Nagios comme un ordonnanceur de tâches et d’événe-ments. Son fonctionnement est assez simple : à chaque instant donné, Nagios exécutedifférents plugins pour collecter des informations sur les états des machines ce quinous permet d’avoir une analyse du système.

Figure 1 – Menu

6

Sujet: Alert ASRALL

Dans la démo de Nagios, nous pouvons constater que le menu se découpe en 6catégories. Nous avons les menus rapides qui permettent d’avoir une vue globale denotre infrastructure.

Quick View : Raccourci vers les différentes autres fonctionnalités ci-dessous pourun accès rapide. Un peu, comme les raccourcis sur le bureau Windows. C’est laseule section disposant d’un moteur de filtre sur toutes les machines pour faciliterles recherches.

Figure 2 – Interface

Programme (services) avec la possibilité d’exécuter certaines actions en sélec-tionnant l’objet désiré. Il peut selon nos besoins regrouper les différents objets pargroupe, ou similarité présente.

Figure 3 – Options

Graphs : Affiche un historique sur des tableaux des ainsi que différents incidentsparvenus jusqu’à Nagios. Avec cette section, il lui est possible d’établir des rapportsainsi que des suivi sur toutes les mesures effectuées. Il pourra nous l’afficher sousdifférentes formes comme le montre ces images.

7

Sujet: Alert ASRALL

Figure 4 – Graphs

Maps : Dans cette section, nous pourrons avoir l’ensemble des éléments surveillépar Nagios de manière graphique. Comme le plan d’interconnexion des hôtes et desservices. Ou encore, des tableaux d’états par rapport à des métriques choisi corres-pondant à des hôtes. Puis une vision simplifier sur les besoins personnalisé d’unemachine grâce à Nagios.

Figure 5 – Maps

Incident management : Il s’agit de la boite à outil pour l’administrateur fournipar Nagios. Il offre un historique des événements importants de Nagios. Une basede connaissance pour les problèmes résolus. Toutes informations sur les notificationsimportantes ce géré ici. On peut dire que c’est un système d’alerte. Lui, en revanchene les envoie pas sur des périphériques distants. On doit tous constater sur place.

Figure 6 – Notification Nagios

8

Sujet: Alert ASRALL

Monitoring Process : Cette section contiendra toutes les procédures en rapportavec les tests de charge pour savoir si Nagios fonctionne de manière optimale. Ainsi,même le système de surveillance à un suivit pour savoir si ce sont les cibles ou bienles outils qui à besoin de maintenance.

Figure 7 – Performance

D’autre part, Nagios est complétée par des plusieurs plugins, des extensionstierces, ce qui en fait un écosystème complet et personnalisable avec sa communautéactive. Néanmoins, nous sommes en droit de nous demander pourquoi nous voulonsremplacer Nagios ?Nous avons vu que Nagios peut tous faire dans son domaine. Mais cela impacteraitnotre infrastructure de manière dramatique s’il venait à avoir un problème. En in-formatique, nous appelons cela un SPOF (Single Point Of Failure) ou unique pointde défaillance. Nous voulons palier à cela en dispersant les machines importantesainsi que leurs rôles.

9

Sujet: Alert ASRALL

4 ProblématiqueNous avons survolé les fonctionnalités de Nagios dans la précédente partie. Au

vu de son grand nombres de fonctionnalités, nous sommes en droit de nous poserla question “pourquoi nous voulons remplacer Nagios ?”. Tout d’abord, Nagios n’estpas exempt de défaut.

Nagios fonctionne de manière binaire lorsqu’il doit reconnaître l’état d’un hôteou d’un service. Cela veut dire que lorsqu’il récupère une métriques ; il écrase le pré-cédent. Vu que Nagios ne conserve rien en mémoire, il devient difficile alors d’avoirun suivi sur une cible surveillé.

Cette notion de conservation des mesures est primordiale pour pouvoir manipulerles données afin d’obtenir des résultats via des opérations plus complexe. Prenonsun exemple concret pour mettre en images cette idée. Imaginons un administrateursystème soumis à des astreintes de nuit (00 h - 4h).

Un switch présent dans notre architecture est défectueux. Pour Nagios, son travailconsiste à envoyer des alertes dès que les hôtes et/ou services sont défectueux. Donc,il enverra une alerte pour le switch, mais aussi pour tous les équipements relié à ceswitch et bien entendu, cela est aussi le cas pour chaque service hébergé sur les hôtes.

Cela va nous faire monter un nombre d’alertes faramineux pour un problèmeunique à la base. De plus, en revenant sur le contexte qui sont les astreintes denuit. Cela veut dire qu’il faut fouiller dans toutes ces informations pour retrouver lasource du problème. Quel problème fait ressortir cette situation ?

• Nous sommes noyés par les informations émisse par notre solution de sur-veillance.

• De préférence, nous désirons que ce problème soit résolu le plus rapidement etefficacement possible.

• Donc, la qualité d’une alerte et beaucoup plus important que leurs quantités.• Aucune métrique n’est conservée en cas de problème récurrent (analyses sur

le temps impossible)

Voilà les problèmes récurrents au système de surveillance, cela est une raisonplausible d’exister du projet alerting. Notre travail consistera à répondre à ces dif-férentes problématiques. Elle nous permettrons de définir nos besoins en terme defonctionnalité souhaité dans notre cahier des charges.

Ce projet partira d’une infrastructure déjà présent fait avec des logiciels libres.(docker,prometheus,Alert-Manager,etc.). Il s’agit d’une contrainte imposée par notreprojet, qui va nous restreindre quant aux solutions logicielles à utiliser dans ce pro-jet. Néanmoins, nous allons commencer dans le chapitre suivant à connaître d’autressolutions plausibles avec différents critères significatifs.

10

Sujet: Alert ASRALL

5 Objectifs et Contrainte

5.1 Métrologie

La métrologie est la science de la mesure. Elle définit les principes et les mé-thodes permettant de garantir et maintenir la confiance envers les mesures résultantdes processus de mesure. Il s’agit d’une science transversale qui s’applique dans tousles domaines où des mesures quantitatives sont effectuées. 2

Mais alors, comment la métrologie s’applique telle à l’informatique ? Concentrons-nous surtout sur les domaines des réseaux et des applications logiciel.

• Les réseaux : leurs rôles vont principalement être le transport de l’informa-tion d’un point A vers un point B et vice-versa. De plus, ils permettront decontrôler l’acheminement des informations par différentes méthodes :

— Filtrer différent accès avec des règles de pare-feu 3 ou des Access List— Rediriger les données envoyés via le routage 4 . Bien entendu, pour que

toutes ces méthodes puissent être mises en place, il faut un schéma clairdu réseau pour faciliter ces procédures.

• Les applications logicielles : ici, les actions plus complexe et interactivepeuvent être mise en œuvre. Elles assureront un suivi des authentifications, lechiffrement 5 . Elles ne serviront pas uniquement à sécuriser une connexion ;ils permettront de récolter des informations à partir de type de logiciel. Uneapplication qui centralise les informations et une l’autre qui enverra les infor-mations ; un travail d’équipe.

• Ces différents outils nous permettront de comprendre l’infrastructure et ainsiaméliorer les performances et l’ergonomie pour les utilisateurs. La métrologievient en complément de la supervision et permet de remonter des graphiques detendances et évaluer toute anomalie future et faire par conséquent des actionscorrectives avant le déclenchement des alertes de supervision pour intervenirdans l’urgence en cas de problème, mais aussi anticiper l’évolution de celle-cipour avoir des actions pro-active.

Visualiser une montée en charge des indicateurs systèmes, c’est l’assurance decomprendre les vagues de visiteurs, de détecter un problème, d’anticiper le besoinde ressource. La métrologie en informatique nous permet d’envisager 3 types dematériel à surveiller et une méthode de réflexion pro-active :

2. https ://fr.wikipedia.org/wiki/Métrologie3. ACL et Pare-feu : liste de règles qui décide si on laisse passer les données ou non4. Routage : liste de règles qui dit où envoyer les données5. Chiffrement : coder des données pour les rendre illisibles sauf par le destinataire

11

Sujet: Alert ASRALL

• Supervision physique : Mise en place de scénarios avec applications spéci-fiques.

• Supervision système d’exploitation : Utilisation processeur, processuszombis, mémoire, utilisateurs connectés.

• Supervision serveurs applicatifs : Bon fonctionnement des serveurs web,des proxy, des applications et des bases de données.

• Supervision scénarios : Mise en place de scénarios avec applications spéci-fiques.

Bien que la métrologie permet un grand nombre de fonctionnalités. Dans leschapitre suivant nous nous concentrerons sur nos besoins pour savoir quel typefonctionnalité nous cherchons. En revanche chaque solution à son chapitre dédié.Par conséquent, la réponse sur comment nous allons les utiliser sera expliquer dansle cadre de ces chapitres.

12

Sujet: Alert ASRALL

5.2 Distribution des alertes

Notre Infrastructure aura beau être totalement en place. Si elle surveille, maisne nous prévient pas. Les incidents seront résolus bien trop tard. Il nous faut doncun moyen de signalement quand nous sommes dans l’entreprise. Sans oublier, quandnous sommes aussi à l’extérieur.

Ce sera le rôle d’Alerta d’envoyer les notifications d’alerte reçu de Alert-Manager.Mais le seul souci sera d’avoir un serveur SMTP 6. Nous pouvons voir dans le fichierde configuration d’Alerta comment nous pouvons le configurer correctement.N.B : alerta-mailer est une extension proposée par la communauté git d’alerta.

Figure 8 – Fichier de configuration

5.3 Groupage des alertes

Comme cité dans la problématique, nous pouvons nous retrouver noyer par l’opu-lence d’information avec des problèmes mineur. Les solutions que nous désironsdoivent être capables d’utiliser les différents points communs des alertes pour lesregrouper sous une seule étiquette et de les réorganiser hiérarchiquement de manièreergonomique.

Figure 9 – Fichier de configuration

Tout ce regroupement devra se faire depuis les fichiers de configuration d’Alerta.Mais cela nous verrons cela dans le chapitre du rapport dédié.

6. SMTP (Simple Mail Transfert Protocol) : machine qui envoie des mails

13

Sujet: Alert ASRALL

5.4 Désactivation temporaire des alertes

Ici, nous avons 2 manières d’aborder un incident. La première sera dans le casou nous arrivons à trouver directement la cause. Puis à le régler, alors le systèmede surveillance actualisera les mesures pour que tous reviennent en ordre. L’alertedisparaîtra donc d’elle-même. Dans le second cas, il nous donner à faire beaucoup demodifications pour résoudre un problème donné. Mais nous avons donné des condi-tions précises à notre système d’alertes et de surveillance. Par conséquent, il nousenverra une alerte à chaque modification.

Par confort d’utilisation et de méthodologie, nous voulons pouvoir mettre soussilence ces alertes sans aucune importance de méthodologie, nous voulons pouvoirmettre sous silence ces alertes sans aucune importance.

Figure 10 – Groupage des alertes

5.5 Historique d’un incident

Ici, nous allons prendre le cas d’une investigation sur un incident récurrent. Ilfaudra que notre solution nous prévienne des cas similaires déjà rencontrés. À quelmoment et surtout dans quel contexte.

Est ce que d’autres machines ou service ont déjà été touché par ce problème ?Ou bien alors de réagir de manière pro-active en ayant une évolution sur le tempsdes mesures de notre machine surveillé. Cela nous aidera à trouver les variablesconcernées pour faire des alertes prédictives sur un disque dur.

14

Sujet: Alert ASRALL

Figure 11 – Server

5.6 Commenter les incidents

Nous sommes partis des besoins qui s’appliquent à une seule personne. Mais dansle cas ou nos sommes dans une infrastructure nécessitant chacun leur spécialiste ? Ilfaudra avoir un suivi sur les actions mené à la résolution d’un incident. Cela offriraune organisation et ainsi une optimisation pour trouver la solution d’incident.

Figure 12 – Alerta

15

Sujet: Alert ASRALL

5.7 Une Adaptation sur le support

Dans le chapitre sur les solutions alternatif proposé au projet. Un des critères desélection était la compatibilité avec les smartphones. Un outil qui nous accompagnele jour comme la nuit. Alors pour être au fait de nos nouvelles alertes, il faudraitque ce critère soit respecté ou au minimum avoir un site web s’adaptant à la taillede notre outil de poche.

5.8 Contrainte

Il y a tout de même une multitude de solutions proposé pour un seul et mêmeobjectif. Mais il faut quand de même éclaircir une condition par rapport à leur choix.Nous nous sommes vu imposer un certain nombre de contraintes dans le contextede ce projet ; les voici :

• Notre rôle est d’adapter une infrastructure existante pour répondre au besoinactuelle.

• L’utilisation du duo Prometheus - Alert-Manager est obligatoire.• Nous avons absolument carte blanche sur tous le reste à partir du moment ou

nous arrivons à l’adapter à l’infrastructure existante.• Au vu des essai entre Alerta et Karma. Nous sommes arrivées à la conclusion

que par son nombre de fonctionnalités et sa communauté, qu’Alerta sera l’outilque nous utiliserons dans ce projet. Toutes les explications techniques serontvues dans le chapitre dédié.

16

Sujet: Alert ASRALL

6 Solution

6.1 Les Entreprises de Surveillance des SI

Bien que des solutions logicielles existent pour subvenir à nos besoins de sur-veillance ; qu’il soit gratuit ou payant même en partie. Nous pouvons aussi passerpar une autre alternative que l’open source. Il y a aussi des solutions commercial ;qui ont prouvé leur efficacité au fil de leur utilisation par leur client. Bien que cessolutions soient plus onéreuses que celle exposé précédemment, elle reste bien plusefficace en facilité de mise en place ainsi qu’en ergonomie de remonter de problème.

• Il existe des entreprises répondant à ces besoins par des fonctionnalités variées.On pourra constater que même si chacune de ses solutions a quelque chose quiles démarque de la concurrente. On ne peut que constater des fonctionnalités“de base” présente dans leur cahier des charges.

• Il faut bien comprendre que ces entreprises ont pour but d’optimiser le tempsde résolution de problèmes. Avec cela, nous savons désormais que l’informationdans la surveillance d’un si peut nous noyer par son opulence, avec des infor-mations peu ou pas du tout pertinente sur la source de notre incident. Donc,un trie des information émises par le si est plus que primordial. Ajoutées àcela, que pour une résolution efficace, toutes ces données doivent remonter entemps réel.

Une fois que l’on a réfléchi à l’acheminement de l’information. Ces solutions ré-pondent à l’optique de la conservation des données par l’intérimaire d’un systèmede gestion de ticket. Bien que la méthodologie diffère légèrement d’une solution àl’autre. On peut retrouver :

• L’heure.• La machine concernée.• Le technicien en charge.

• Couplé à la puissance d’un moteur de filtre par mots. Les enquêtes d’incidentsn’en deviennent que plus facile. Une fois que l’on a réfléchi à la manière dontdoivent être émises ces alertes. Il faudra réfléchir à qui sera le destinataire. Ici,il ne faut pas penser qu’à un administrateur unique, mais à toute une équipeavec chacun des membres ayant leur spécialité. Il est alors aussi importantde savoir quel destinataire reçoit ses alertes. Et là, nous sommes dans le casoptimiste ou tous se passe bien.

• Mais, ce n’est jamais le cas dans les SI. Par conséquent, il nous faut des règlesstratégique en cas d’absences utilisateurs (redirection de contact utilisateur)voire même des actions spécifique comme des commandes pour certaines. Encomplément de cette fonctionnalité avec les moyens de distribution classiquepour (téléphone, sms, mail, notification) offrir une couverture de contact opti-mal même dans le cas de grand déplacement. Et oui, toutes ces solutions ont

17

Sujet: Alert ASRALL

leur application smartphone dédie et le champ d’action ne se limite pas qu’àconstater les alertes. Elles sont aussi efficaces que leur homologue sur le web.

• Maintenant, la plupart des équipes informatiques suivant des rythmes de tra-vail dit “follow the sun”. Avec la démocratisation d’Internet et la délocalisationpour de la main d’œuvre moins cher. Les entreprises disposant de très grandeinfrastructure procède pour avoir des humains s’occupant de celle-ci 24h/24 et7 j/7. Il utilise la rotation de personnel en horaire de journée, en plus de tenircompte des décalages horaires de chaque pays des résidents. On dit “follow thesun”, car le personnel travaille en suivant les zones de jours de la planète. Cequi donne une disponibilité de services en continue.

• Enfin, nous sommes en droit de nous poser une dernière question concernantce recours alternatif. Si moi-même, je décidais de sauter le pas, il faudra que jereparte d’une infrastructure totalement neuve. Avec des mois de travail pouradapter ce nouveau système. Et bien non, car ces entreprises de fourniture deservices, on pense à l’intégration à des solutions existante. Chacune choisit samanière de se connecter à l’infrastructure. Mais la facilité d’intégration et dedistribution depuis notre SI fait pencher l’avis de beaucoup de multinationalesvers ce nouveau recours.

Maintenant que nous avons fait pu le tour de sur ce que ces solutions avait toutesen commun. Voyons voir maintenant ce qui les différencie. Comme ça, nous pourronsaussi comprendre un peu ce qui à motiver des entreprises à les choisir.

6.2 Pager duty

Figure 13 – Comparaison

18

Sujet: Alert ASRALL

Toutes les autres applications doivent faire un export pour l’importer ensuite surun URL dans les solutions choisi comme google calendar. Toutes sauf Pager Duty,qui une fois la connexion à l’API faite synchronise automatique toutes les informa-tions nécessaires avec notre calendrier habituel.

Malgré mes recherches, pager Duty est le seul à fournir son application pour lesmontres connectées. Ce qui peut s’avérer pratique quand nous ne voulons pas resterconstamment sur notre smartphone.

Il dispose aussi d’une option numéro de secours que je n’ai pas trouvé d’autressolutions. Bien entendues, toutes les solutions peuvent créer des stratégies de no-tifications. Néanmoins, ajouter un numéro de secours évite de créer des solutionscomplexes pour des besoins simples. En rajoutant à cela, sa vue, globalisée desincidents pour constater quel sont les cibles impactées. Il montre l’impact globalsur l’infrastructure qu’il surveille. De plus, il dispose de template de réponse, co-ordonnant les personnes à contacter ainsi que la stratégie de redirection en cas depersonnel manquant.

Pour finir, il créer une base de connaissance par rapport à tous les incidentssurvenu ainsi que la méthode de résolution de celui-ci. En bonus, il sait retrouverles problèmes similaires déjà rencontrés. Sur le site de pager duty, une bibliothèquede tous les utilisateurs de pager duty est disponible pour comparer ces problèmesavec d’autres entreprises pour avoir une portée plus grande.

6.3 VictorOps

Figure 14 – Logo VictorOps

La puissance de victorOps est dans sa simplicité avec une interface très minima-liste mais redoutablement efficace. 3 colonnes sont disponibles lors de son utilisation :

• Utilisateurs de la solution.• Arrivé des incidents en temps réel• Trie des incidents constatés.

19

Sujet: Alert ASRALL

• On pourrait croire que cela est compliqué de suivre un incident sur la secondecolonne. Néanmoins, le moteur de filtre présent est d’une efficacité redoutable.Il n’y a aucune différence entre écrire une phrase sur google et la puissanceson moteur de filtres. Cela le rend bien plus intuitif à utiliser.

Figure 15 – Interface

En rajoutant les résumés d’incident qui sont eux aussi très explicites. Même si ceformat d’affichage correspond mieux pour le suivi d’état. Il fait quand même le travailde manière très acceptable en montrant 4 étapes vérification. (nom, description,graphique sur le temps, description de l’hôte.

Figure 16 – Interface

20

Sujet: Alert ASRALL

6.4 OpsGenie

Figure 17 – Logo OpenGenie

Nous terminerons par OpsGenie qui quant à lui tirera sa carte du jeu avec uneconfiguration complètement graphique. Que ce soit pour la configuration de l’appli-cation web, ou des machines. Grâce à son interface homogène ainsi que sa colorisationpertinente. On pourra apprécier son ergonomie ainsi que les détails importants quiseront mis en valeur.

Avec cela, pour la redirection de notification OpsGenie est le seul à gérer larépétition de stratégie face aux autres solutions présentées.

21

Solutions

installation à partir d’un isolongue(debain 9)

facile(debain 9)

payant facile(commande)facile(installationdepuis pip)

prêt àl’emploi(docker,pip)

configuration graphiquelongue,difficile, peuintuitive

graphiquefait parl’entreprisezenoss

facile

longue(beaucoup demodule àconfigurer)

simple

Restrictiond’accès

Menu,Services,actions nonlecture-

écriture surressources

disponibleavec ajoutdu zenpack

avec plugin squid nonvia serveurweb

Visualisation intuitive minimaliste

beaucoupd’info maistrès bienorganiser

totalementdynamique,un cliquenous donnelesinformationsque l’onveut

beaucoupd’information,indigeste auniveau del’organisation destableau

minimaliste maistrès efficace

simple(infofacilementtrouvable)

CompatibilitéSmartphone

centreon maps

nagiosmobile(trèspeud’ergonomie)

non

Intégrationnouvellehôte

très simplesimple(fichier deconfiguration)

Activationd’agent +

decouverte

découvertevia protocolSNMP

simple (fichier de configuration)

configurationYAMLprudencesur lasyntaxe

Store deplugins

oui

présentmais tréspeu deplugin

équivalent àcentreonmais avecbeaucoupd’alternativepayante

contient le strictmininum

Store NagiosDepuisExporters

auto-découverte

disponible aveclicence entreprise

grâce auplugin

non

DiscoveryMapping(pluginpayant)

script Github (voirannexe)

nonsi exportersactif

démo (voirannexe)

ouiinscriptionnécessaire

oui non oui

Sujet: Alert ASRALL

7 Infrastructure

7.1 Schéma de l’infrastructure du Projet Tuteure

Figure 18 – Schéma de l’infrastructure du Projet Tuteuré

8 ArchitectureNous sommes partis d’une base existante avec un Prometheus, Alert-Manager,

Grafana et des sondes. À partir de laquelle nous avons ajouté Alerta.Toute l’architecture est basée sur des conteneurs Docker, on utilise aussi Docker-

Swarm afin de disposer d’un cluster pour nos conteneurs.

8.1 Conteneurs

Les conteneurs sont très différents des technologies de virtualisation type virtual-box, libvirt.

Ils partagent les ressources ainsi que l’OS de l’hôte.Les VM ont besoin d’un hyperviseur, qui servira à simuler une machine physique

en tant que VM. Elles intègrent un OS sur lequel les applications sont exécutées.Cette simple différence entraîne un gain de vitesse, de performance ainsi que de

rendre les conteneur beaucoup plus léger.

24

Sujet: Alert ASRALL

Figure 19 – Différences entre conteneurs et VM

8.1.1 Docker

Docker est un logiciel open-source permettent de créer, déployer et gérer desconteneurs d’applications.

Figure 20 – Logo Docker

Avec Docker, vous pouvez utiliser les conteneurs comme des machines virtuellesextrêmement légères et modulaires. De plus, ces conteneurs offrent une grande flexi-bilité : vous pouvez les créer, les déployer, les copier et les déplacer d’un environne-ment à l’autre, ce qui vous permet d’optimiser vos applications pour le cloud.

Docker à amélioré la technologie de conteneurisation de Linux, LXC, afin que lesprocessus 7 soient totalement isolé les uns des autres. Afin d’obtenir cette isolation,Docker utilise les cgroups 8, LXC et diverses autres technologies du noyau Linux.

7. Un processus est un programme informatique en cours d’exécution.8. Technologie permettent, entre autres, d’isoler les processus grâce à des espaces de nommage

(namespace)

25

Sujet: Alert ASRALL

Cette isolation entraîne une certaine indépendance entre les machines. Il estcependant possible de créer des réseaux pour que les conteneurs communiquententre elles.

Le but des conteneurs est cette indépendance : la possibilité d’exécuter plusieursprocessus et applications séparément pour mieux utiliser leur infrastructure tout enconservant la sécurité que vous auriez avec des systèmes séparés.

8.1.2 Docker Compose

Docker Compose est un outil développé par Docker, il permet de définir et delancer facilement une architecture applicative multi-conteneur.

Figure 21 – Logo Docker Compose

Un exemple très courant est d’avoir une application web qui demande une basede donnée, en utilisant Docker compose, il est possible de séparer ces applicationssur plusieurs conteneurs.

Pour ce faire, il faut définir les conteneurs dans des fichiers YAML, la syntaxeest très importante et il est possible de définir les mêmes options qu’avec Docker.

26

Sujet: Alert ASRALL

Exemple d’une définition d’un service en YAML :

Figure 22 – Fichier YAML d’alerta

On définis l’image à utiliser, on monte les volumes, on défini la commande à lancerau démarrage du conteneur (une ligne par argument), on fait de la redirection deports 9, on dis que le conteneur dépend du conteneur db, on définis des variablesd’environnement, on définis les réseaux du conteneurs.

Une fois le ou les fichiers définis, il est possible de lancer la totalité de l’architec-ture avec une seul commande.

8.1.3 Docker Swarm

Docker Swarm à été développé par Docker qui permet de créer un cluster multi-machines, de le gérer et de lancer des conteneurs sur ce dernier.

Un cluster est un groupe de machines indépendant qui fonctionne comme un seulet même système.

Figure 23 – Logo Docker Swarm

9. Pour pouvoir avoir accès à l’application en dehors du conteneur

27

Sujet: Alert ASRALL

Pour ce faire, dans chaque cluster, au moins un nœud de gestion (manager) doitêtre déclaré, les workers, eux, peuvent être un nombre quelconque. Une fois ce(s)noeud(s) définis, le ou les nœuds de gestion vont être responsable du cluster ainsique de la répartition des tâches. Les Workers, eux, vont exécuter les tâches donnéespar les nœuds de gestion.

Dans un Swarm, on parle de service pour se référer à un conteneur. Chaque ser-vice peut alors être dans l’un des deux modes suivant :

— Service répliqué : quand un service est répliqué, il s’exécute sur un nombre derépliques défini. Chacune de ces répliques est une instance du conteneur définidans le service, il s’exécute alors sur plusieurs hôtes.

— Services globaux : lorsqu’un service est global, tous les nœuds disponibles ducluster vont démarrer une tâche pour le service en question. (que ce soit unmanager où un worker)

Voici le résultat de la commande qui liste les services sur un swarm avec 1manager et 1 worker :

Figure 24 – Liste des service docker

Une des utilisations de Docker Swarm peut être la répartition de charge. En effet,il dispose de fonctions de répartition des charges. Quand un service est répliqué surplusieurs hôtes, Docker va automatiquement distribuer les requêtes aux différentesinstances du service.

8.2 Sondes(exporters)

Désormais, il est temps d’aborder le rôle des sondes dans notre infrastructure.Il en existe de différents types pour des besoins différents. Les citations ci-dessousle démontreront. Mais quelle est leur utilité première ? Les sondes sont des agents àmettre sur les machines à surveiller dans notre parc informatique. Toutes les infor-mations sont bien centralisées, sauf qu’il est nécessaire de les installer.

8.2.1 Cadvisor

Cadvisor ou aussi connu comme Advisor est un programme qui permet d’avoir unrendu de l’utilisation des ressources d’un conteneur et qui exporte toutes ces statis-

28

Sujet: Alert ASRALL

tiques vers une machine pour rassembler l’ensemble des informations. Ainsi, il aidea contrôler les métriques des conteneurs Docker, il fait l’analyse et la compréhensionde l’utilisation des ressources et des caractéristiques du rendement des conteneursen fonctionnement. Il a été créé par Google, il est aussi originaire de Docker et àété rendu publique le 9 juin 2014. Nous pouvons l’utiliser de manière totalementindépendante ou refaire montre ces statistiques vers une machine Prometheus...

Figure 25 – Logo Cadvisor

8.2.2 Netdata

Netdata est un outil de monitoring distribuée qui fournit des informations entemps réel de tout ce qui se passe dans la machine que cela soit physique ou bienvirtuel. De plus, il peut s’exécuter tout seul ou peut être intégré à d’autres outilsde monitoring. (Prometheus, Grafana) Netdata est un logiciel libre et open sourcequi actuellement fonctionne sous Linux,MacOS et FreeBSD. Il ne se contente pas derécolter des informations, il permet aussi de nous créer des alertes nous avertissantd’une métrique importante (Ex : taille disponible dans un disque dur). Dans lecadre de notre projet tuteuré, nous avons essayer les 2 méthodes pour déterminerune préférence. Vu que Netdata peut stocker, alerter et surveiller en même temps.Elle est tout de même plus pratique. Cette solution est optimale pour la surveillanced’une machine en 1 point, ne consommant que 2

Figure 26 – Logo Netdata

8.2.3 Node-Exporter

Il expose des mesures au niveau de la machine, principalement du noyau de votresystème d’exploitation, il est uniquement destiné à surveiller la machine elle-même,et non les différents processus ou services qui s’y trouvent.

29

Sujet: Alert ASRALL

8.3 Gestionnaire de données

8.3.1 Prometheus

Prometheus est le cœur de l’infrastructure, c’est un logiciel qui permet de sur-veiller et de générer des alertes sur un parc informatique.

Figure 27 – Logo Prometheus

Il récolte les métriques auprès des agents (et non pas des machines directement)pour les stocker dans une base de donnée

Il est possible de définir des "targets" 10 et des "rules" 11

Les targets sont à définir dans le fichier de configuration de Prometheus et per-met à ce dernier de savoir vers qui aller chercher les métriques.

Figure 28 – Exemple de target Prometheus

Il est alors possible de modifier les labels des métriques récupérée, dans le "re-label configs", en précisant le label source, le label de destination et ce qu’il fautremplacer (par exemple, en utilisant une expression régulière)

Les rules sont définis dans un fichier yml, elles permettent à Prometheus de gé-nérer des alertes grâce à des requêtes sur les métriques.

10. Permet de décrire les agents à contacter pour obtenir des métriques11. Les rules servent à créer des alertes

30

Sujet: Alert ASRALL

Figure 29 – Exemple de rule Prometheus

Le langage pour réaliser les requêtes permet d’utiliser des fonctions permettant,par exemple, de prédire la valeur d’une métrique dans x secondes (ce qui est utilisépour les alertes prédicatives).Des fonctions plus basiques permettent aussi de réaliser certaines opérations mathé-matiques. (sommes, moyennes etc...)

8.3.2 Alert-Manager

Alert-Manager va gérer les alertes qu’il reçoit de Prometheus.

On y trouve toutes les alertes de Prometheus.

Figure 30 – Interface Alert-Manager

On peut ensuite développer une alerte pour en savoir plus, avoir les labels etd’autres options.

Figure 31 – Une alerte sous Alert-Manager

31

Sujet: Alert ASRALL

Il est possible d’interagir avec les alertes pour, par exemple, les mettre sous si-lence.C’est possible avec le bouton "Silence" qui aura pour but de rediriger vers la pagede création de silence.

Figure 32 – Silence sous Alert-Manager

Une fois l’alerte sous silence, et ce pendant toute la durée du silence, elle n’ap-paraîtra plus dans Alert-Manager.

Le bouton Info sert à afficher certaines informations concernant l’alerte tel quela description, le résumé et la valeur de l’alerte.

Figure 33 – Bouton Info d’Alertmanager

Finalement, le bouton Source redirige vers la page correspondante sur Prome-theus.

En plus de tout cela, Alert-Manager va gérer le faite d’envoyer les alertes sur,par exemple, Alerta.

32

Sujet: Alert ASRALL

8.4 Outils de visualisation des données

8.4.1 Grafana

Grafana est un outil très souvent associé à Prometheus qui permet la visualisationdes données des métrique de Prometheus sous la forme de dashboard 12.

Figure 34 – Logo Grafana

Il permet de très facilement avoir des dashboard sur, par exemple, les exporters,Cadvisor et Prometheus.

Figure 35 – Dashboard des conteneurs Docker

Cette facilité vient du fait que la communauté crée des dashboard très facilementimportable. Il est aussi possible de créer ses propres dashboard.Il est également possible de gérer les alertes directement depuis Grafana.

On peut définir des alertes directement dans l’onglet Alert d’un panel :

Figure 36 – Définition Alerte Grafana

12. Un dashboard ( Ou tableau de bord en français) permet de visualiser une grande quantitéd’information rapidement. Un exemple simple est celui du tableau de bord d’une voiture qui, enquelque sorte, est un dashboard.

33

Sujet: Alert ASRALL

On choisit un nom, la fréquence à laquelle l’alerte sera évaluer, pendant combiende temps l’alerte sera en attente, et la condition.

Ici, l’alerte sera active si, pendant 5 minutes, l’utilisation totale de la RAM estsupérieur à 4 GO.

Il est aussi possible de gérer l’envoie de notification. Grafana propose beaucoupde moyens pour envoyer des notifications.

Figure 37 – Notifications sous Grafana

Par exemple, en envoyant les alertes sur un serveur Discord :

Figure 38 – Notification serveur Discord

34

Sujet: Alert ASRALL

Ensuite, de nouveau ou on définis l’alerte, tout en bas, on peut choisir d’envoyerun message en utilisant la notification créée.

Figure 39 – Définition Alerte avec notification

Après quoi, on va pouvoir retrouver l’état de l’alerte dans l’onglet Alerting.On y vois soit Pending qui signifie que la durée du For n’est toujours pas terminée,soit OK où Alerting qui signifie que l’alerte est en cours.

Figure 40 – État d’une alerte

35

Sujet: Alert ASRALL

Voici donc le résultat sur Discord avec une alerte de test :

Figure 41 – Message Discord d’une alerte

Il n’est cependant possible de faire ces alertes qu’avec certains graph.

8.4.2 Alerta

Alerta est un outils qui permet de visualiser les alertes générées par Prometheus,cependant les alertes proviennent d’Alertmanager.

Il se présente sous la forme d’une interface graphique sur laquelle les différentesalertes apparaissent

Figure 42 – Interface Alerta

36

Sujet: Alert ASRALL

Il est possible de configurer l’interface et, par exemple, de changer la couleur desalertes en fonction de leur gravité, directement dans le fichier de configuration :

Figure 43 – Fichier de configuration

Afin de pouvoir trier les alertes plus facilement sur l’interface, il est possible dedéfinir un Environnement, un Service, une Ressource et un Événement.

— Environnement : Il s’agit du premier "niveau" de trie, le plus global. Il est trèsutile si on dispose d’un environnement de test avant la production.

— Service : Niveau intermédiaire compris dans l’environnement. Chaques envi-ronnement ont leurs services. Ils peuvent correspondre à la sonde d’où lesdonnées proviennent.

— Ressource : Avant dernier niveau qui correspond en général à la machine (ouconteneur) lié à l’alerte

— Évènement : Dernier niveau, le plus précis, qui correspond à l’événement de laressource qui est lié à l’alerte.

Tout ceci est à définir sur Prometheus grâces aux labels.

Figure 44 – Labels de Prometheus

37

Sujet: Alert ASRALL

En réalité, seul certains de ces labels sont important. Par exemple, alertnamecorrespond à l’événement sur Alerta. Service correspond au Service, Instance cor-respond à la Ressource.

Aucun environnement n’a été défini donc alerta va attribuer celui par défaut,soit Production.

Il y a d’autres champs, mais ils sont assez explicites.

Quand Alerta reçoit une alerte, il va vérifier si elle a existé déjà. Si ce n’est pasle cas, l’alerte sera ajoutée. Si c’est le cas, son statut sera mis à jour, si ce dernier achangé. Si le statut n’a pas changé, l’alerte sera considéré comme dupliqué.

Quand alerta reçois une alerte, il va la traiter :— Premièrement, Alerta va vérifier si l’alerte existe déjà (en utilisant l’environ-

nement, le service, la ressource et l’évent)— Deuxièmement, si elle n’existe pas, elle sera ajoutée. Sinon, son statut sera mis

à jour.— Cependant, si le statut n’a pas changé, l’alerte sera considérer comme doublon

et le champ correspondant sera incrémenté de 1

8.5 Base de données

8.5.1 Redis

Redis est un système de stockage de données clé-valeur 13 en mémoire utilisé parles exporters et prometheus.

Figure 45 – Logo Redis

Contrairement à une base de donnée comme postgres où mySQL, Redis stocke lesdonnées directement en RAM, ce qui permet d’obtenir de meilleures performancesqu’un stockage sur un disque dur. Ce qui fait que Redis est plutôt utilisé pour fairedu cache.

La base de donnée dispose aussi d’un mécanisme dit "publish-subscribe" qui per-met d’envoyer directement les nouvelles données de la base de données aux clientsconcernée sans que ceux-ci aient à faire une requête.

Ce mécanisme assez simple utilise un système de publication et d’abonnement.Les exporter publie les données des métriques, chaque message est associer à une

13. Ce type de stockage permet d’associer une clé à une valeur, comme par exemple le hash d’unmot de passe.

38

Sujet: Alert ASRALL

catégorie. Ainsi, tous les destinataires s’abonnent aux catégories et recevront lesmessages du ou des catégories.

Ce qui permet d’effacer les données de la RAM une fois qu’elles sont envoyer.

8.5.2 MongoDB et SQLite

MongoDB est un SGBD (système de gestion de base de données) orienté docu-ments utilisés par Alerta.

Il s’agit d’un type de SGBD où les données sont modélisées sous forme de do-cument un peu dans le style JSON. Il n’y a donc ni tables, ni jointures, ni mêmed’enregistrement.

Figure 46 – Logo MongoDB

SQLite est une bibliothèque proposant un moteur de base de donnée relationnelleutilisé par Grafana.

La particularité de SQLite est qu’il fonctionne sans serveur, il est donc plus per-formant et simple à mettre en place puisque ne nécessite aucune installation.

Figure 47 – Logo SQLite

Les deux sont utilisées pour stocker les données d’une application, MongoDBstocke les données d’Alerta (utilisateurs, paramètres...) tandis que SQLite stocke lesutilisateurs ainsi que les dashboard de Grafana.

39

Sujet: Alert ASRALL

9 Problèmes rencontrés

9.1 Promgen

• Le container est bien actif, par conséquence je peux accéder à l’interface webde Promgen.

• Néanmoins, il me montre une erreur interne lors de la tentative d’accès.En observant les logs des containers, on peu voir que le workers sort de sonétat. Il est très probable que ce soit un problème de configuration.

• Piste de solution pour Promgen :

https://github.com/line/promgen/tree/master/promgen/tests/examples

9.2 Alerta-mailer

Un autre problème qu’on a eu concerne alerta-mailer.C’est un service utilisable avec alerta qui permet d’envoyer les alertes par mail.

Mailhog à été mis en place dans un autre conteneur. Il s’agit d’un serveur demail disposant d’une interface web pour lire les mails.

Il s’installe simplement et ne demande pas de configuration particulière.Il est ensuite possible de tester qu’il reçoit bien des mail avec telnet par exemple.

Figure 48 – Mail depuis alerta

Figure 49 – Mailhog

40

Sujet: Alert ASRALL

On constate que le mail envoyé depuis alerta et celui reçu sur Mailhog ont lemême identifiant, ce qui signifie qu’il s’agit du même mail. Mailhog est donc enmesure de recevoir des mails.

Figure 50 – Signal de présence alerta-mailer

Ici, on constate, qu’après l’avoir configuré correctement, alerta-mailer s’est bienconnecté à Alerta. Cependant impossible de recevoir de mails sur mailhog.Nous ne savons pas d’où peut venir le problème ni comment le corriger.

10 Bilan et ProspectiveCe qui fonctionne :

Objectif MéthodeÉtablir un cahier des charges Chapitre MétrologieGestion de la résolution de l’alerte (casd’astreinte technique) Connexion SSH sur infra de démo

Gestion de la désactivation temporaired’un ensemble d’alertes (cas d’opéra-tions de maintenance)

Option dans les solutions étudiées(alerta, karma, Alert-Manager)

État de l’art sur les solutions de ges-tions des alertes Chapitre Solution du Rapport

Une interface « user friendly » pour lestâches courantes (désactivation, priseen compte, résolution)

Chapitre Karma et Alerta

Gestion du groupage des alertes Karma - Chapitre Karma et AlertaCluster Docker Swarm avec deuxnoeuds (1 manager et 1 worker) Sur Infrastructure de démo

Récupération de métrique par Prome-theus Chapitre sur Prometheus

Visualisation de métriques Grafana Karma - Chapitre GrafanaAlert-Manager de Prometheus Chapitre Alert-ManagerDétection de faux positifs Temps d’attente d’alerteDétection de corrélation Alerte predictive

Adaptation d’infrastructure Dockerexistante

Partie d’une infrastructure donnée,nous avons fait marcher les solutions ci-dessus

41

Sujet: Alert ASRALL

Ce qu’on aurait pu faire avec plus de temps• Gestion de la prise en compte de l’alerte (cas d’astreinte technique)• Gestion de la distribution des alertes via des canaux différents (e-mail, sms,

messagerie instantanée, appli mobile, etc.) En fonction du type d’alerte, de laplage horaire, etc.

Avec ce bilan de nos réussites et échecs. Nous pouvons constater que le principalproblème dans tout notre projet alerte n’a pas été la gestion des alertes. Le soucià été l’acheminement de celui-ci jusqu’au personne concerné par elle. Avec le tempsnécessaire, nous aurions mis en place un serveur de mail avec des utilisateurs dédiéaux alertes ainsi qu’à la supervision du système d’information.

Une fois cette étape mise en place, nous aurions pris le temps d’étudier d’autrescanaux de diffusions (slack, teams, discord, zoom, etc.). S’il y avait eu aussi uneautre possibilité. Cela aurait été de configurer un service d’authentification uniquepour notre machine de surveillance. Ainsi, les différents problèmes d’accès et desécurité informatique auraient pu être abordés dans ce sujet. Nous aurions eu uneplus grande variété de sujet à explorer.

42

Sujet: Alert ASRALL

11 L’organisation du travailPour l’organisation du projet, nous avons mis une place importante dans la

communication tout le long du projet. Cela nous a permis de pouvoir avancer à unbon rythme et ainsi de diviser la charge de travail de manière équitable en fonctiondes spécialités de chacun.

Avec un rythme de travail soutenue tout au long du projet, nous avons eu deuxréunions par semaine :

• La première avec le tuteur : Au cours de cette réunion, nous vérifions lesprogrès réalisés et, en cas de doute ou de problème, notre tuteur nous aide àles résoudre.

• La seconde entre les membres de l’équipe : Afin de pouvoir définir toutes lestâches et le temps pour chacune d’entre elles ; et aussi résoudre les problèmesrencontrés pendant le projet.

Il est vrai qu’il est important d’avoir un bon rythme de travail, surtout en prenanten compte que certains membres du groupe ont eu des difficultés à suivre le rythme.Mais grâce au point fort de chacun, les lacunes des autres ont pu être palier demanière complémentaire. Cette communication, ainsi que l’esprit d’équipe basé surle volontarisme de chacun. Nous a réussi pour poursuivre ce projet.

11.1 Outils de travail utilisé

D’abord, nous avons dès le début du projet mis en place différents outils pourl’organisation de celui-ci. De cette façon, tout est plus clair et cela nous permetd’avoir une organisation entre les membres de l’équipe ainsi qu’une meilleure ges-tion du temps de travail.

Dès le début, nous avons renseigné notre avancement du projet sur Trello qui estune application de gestion de projet. Il fonctionne à la manière d’un tableau fami-lial sur le quelle nous collerions des post-it pour ne rien oublier. Les fonctionnalitéssuivant nous ont été utile dans le cadre de l’échange d’informations.

— La gestion des membres d’équipe— La mise en catégorie des événements— Des dates limite pour avoir un avancement en détail de chaque tâche du projet.— Une description plus détaillée, si le titre de l’événement ne suffit pas.— La gestion de fichier pour conserver des traces des actions (un combo redou-

table avec flameshot).— Une liste de points à atteindre pour l’accomplissement de l’objectif.— Un suivi d’activité pour les membres du groupe. Ne nous à servir qu’à partir

du moment ou nous avons commencer le télétravail

D’autre part, nous avons également utilisé deux autres outils, Flameshot qui estun logiciel de capture d’écran avec flameshot nous avons changé le raccourci clavier

43

Sujet: Alert ASRALL

Figure 51 – Notre site sur Trello

Figure 52 – Logo Flameshot

afin de rendre la capture plus rapide et plus facile.

Les fonctionnalités suivant nous ont été utile dans le cadre de l’échange d’infor-mations.

1. Il est beaucoup plus rapide de prendre des captures d’écran.2. Avoir les photos pour Trello, Joplin et le rapport.

44

Sujet: Alert ASRALL

Figure 53 – Capture d’écran

Le dernier outil que nous utilisons est Joplin, une application gratuite de prise denotes en open source. Nous avons choisi Joplin parce qu’il est plus rapide de prendredes notes sur notre ordinateur que sur une feuille de papier.

Figure 54 – Logo Joplin

Les fonctionnalités suivant nous ont été utile dans le cadre de l’échange d’infor-mations.

1. Permet de générer directement des notes de manière plus structurée, puisquenous pouvons ajouter des listes, des tableaux, pour n’en citer que quelques-uns.

2. Convertir les notes facilement en format PDF.

45

Sujet: Alert ASRALL

Figure 55 – interface Joplin

12 Répartition de tâches

Figure 56 – Tableau Organisation

46

Sujet: Alert ASRALL

13 ConclusionCe projet Tuteure a été enrichissant à plusieurs points de vue.

Le but de notre projet était d’établir une solution de métrologie centralisée avecPrometheus et Alert-Manager afin de gérer les alertes. Nous avons mené à biencette tâche en proposant une solution basée sur Docker dans une infrastructurePrometheus/Alert-Manager, comme vous l’avez demandé.

Au fur et à mesure de l’avancement du projet, nous avons appris beaucoup d’in-formations qui ont étayé nos connaissances des conteneurs Docker, Prometheus etAlert-Manager afin de créer des alertes.

Finalement, ce projet nous aura permis de découvrir des parties qui n’étaientpas couvertes dans Docker, mais aussi d’acquérir de nouvelles connaissances dans ledomaine de la métrologie et de la surveillance.

47

Sujet: Alert ASRALL

14 Bibliographie

14.1 Liens

— https://docs.docker.com/

— https://prometheus.io/

— https://docs.grafana.org/

— https://my-netdata.io/

48

Sujet: Alert ASRALL

15 AnnexesDemo Solutions

• Centreon : https://demo.centreon.com/centreon/index.php• Nagios : http://nagiosxi.demos.nagios.com/nagiosxi/login.php?• Zabbix : https://zabbix.org/zabbix/• Zenoss : Inscription nécessaire• Munin : http://demo.munin-monitoring.org/• Shinken : Non• Prometheus : http://demo.robustperception.io:9090/consoles/index.html

• Demo Alerta : https://try.alerta.io• Demo Karma : https://karma-demo.herokuapp.com

Auto-discovery Munin : https://github.com/benlemasurier/munin-autodiscover

49