Avant-propos

Présentation de Prometheus et Grafana

1. Origine de Prometheus

Prometheus est un projet initié au sein de la société SoundCloud en 2012. À cette époque, elle avait des difficultés à suivre ses propres applications. La surveillance s’appuyait alors sur les outils StatsD et Graphite. Prometheus fut créé afin de répondre aux limitations de ces outils. Il trouve son inspiration dans des solutions existantes comme par exemple Borgmon (outil de surveillance interne de Google).

Le développement de Prometheus est dirigé par les impératifs suivants :

Faire de l’acquisition de données avec une grande quantité d’informations différentes.
Disposer d’un outil simple à déployer et à exploiter.
Avoir une grande capacité de mise à l’échelle.
Disposer d’un langage de requête simple.

Le premier déploiement de Prometheus en production chez SoundCloud remonte à 2013 et la première version stable date de juillet 2016. En novembre 2017 sort la version 2.0. Cette dernière change les capacités du moteur et notamment son mécanisme de stockage interne. Depuis, le moteur sort des versions régulièrement introduisant des nouveautés ou des optimisations en continu. À noter, la sortie en décembre 2024 de la version 3.0 qui introduit le support des labels compatibles au format UTF-8.

2. Origine de Grafana

Grafana est un outil de visualisation. Pour fonctionner, il s’appuie principalement sur le contenu de bases de données de séries temporelles (Time Series DataBase soit TSDB) mais peut également se brancher à d’autres types de sources de données (bases de données relationnelles, produit de surveillance, etc.). À l’origine, il s’agit d’un clone de Kibana (outil de visualisation d’Elasticsearch) dans sa version 3. Le but initial du projet était de simplifier la création de tableaux de bord et de dialoguer avec Graphite. Grafana et Graphite ont tous les deux été créés initialement par la société Orbitz.

La version v1.0.0 de Grafana remonte à 2014. La principale caractéristique de Grafana - comparé à Kibana - est de disposer de très nombreux connecteurs :

Connexions à la plupart des bases de données relationnelles ou de type séries temporelles.
Connexions aux moteurs de stockage de documents comme Elasticsearch.
Connexions aux outils de surveillance traditionnelle (Zabbix, Nagios Checkmk (anciennement connu sous le nom de Check_MK), etc.).

La version 1 avait pour but de démocratiser...

Contexte

1. Une brève histoire de l’univers de la surveillance informatique

Ces outils apportent de nombreux changements dans la façon d’appréhender la surveillance informatique. Avant l’arrivée de ces deux outils, le secteur était principalement occupé par des outils similaires à Nagios ou Zabbix d’un côté (pour la partie surveillance et alerting) et RRD/Graphite de l’autre (pour la partie visualisation).

Les outils de surveillance utilisent des sondes pour connaître l’état d’un système. En cas de détection d’erreurs, le moteur procède à de nouveaux tests pour s’assurer que l’erreur est bien réelle et non intermittente. Passé un certain délai, le système génère une alerte pour prévenir qu’il y a un problème.

Voici ci-dessous un exemple de ces grandes phases :

Malheureusement, en dehors de l’état brut de l’indicateur surveillé, il n’est pas possible d’avoir de tendance sur l’état interne du système (évolution de l’espace disque, la charge CPU, le nombre d’appels, etc.).

C’est là qu’interviennent les outils de visualisation : leur rôle est de compléter la surveillance pour donner une tendance sur les métriques d’un système. L’ancêtre de ces outils est MRTG (Multi Router Traffic Grapher, soit générateur de graphiques de trafic pour routeurs multiples). Il fut écrit initialement par Tobias Oetiker en 1994 pour répondre à ce besoin. Son principal problème était que, initialement, le stockage des métriques se faisait à l’aide de fichiers texte. Le rendu des graphiques se faisait en convertissant ces fichiers sous forme d’images au format GIF.

L’outil RRD (Round Robin Database, soit base de données circulaire) découle directement de cet outil. Il fut créé en 1999 par la même personne pour répondre aux problématiques de performances. Le principal avantage par rapport à son ancêtre vient du fait qu’il est écrit en C et qu’il est beaucoup plus performant. Les sources de données s’appuient majoritairement sur le contenu d’entrées SNMP (Simple Network Management Protocol, que l’on peut traduire par protocole de gestion de réseau simple) ou sur le résultat du lancement de scripts.

Une base de données RRD se présente sous la forme d’un fichier autosuffisant contenant des séries temporelles. Lors de la création d’un de ces fichiers, l’administrateur peut configurer plusieurs conteneurs de séries temporelles. Chacune d’entre elles contient une résolution différente ainsi qu’une fenêtre temporelle différente. Un cas typique d’utilisation de ce type de base de données est d’échantillonner avec une grande résolution sur une courte période et de baisser cette résolution sur le plus long terme :

Résolution d’une minute sur une période de 2 jours.
Résolution de cinq minutes sur une période de 10 jours.
Résolution de trente minutes sur une période de 90 jours.
Résolution de six heures sur une période de 4 ans.

Cet outil manque toutefois de souplesse :

Un changement d’échantillonnage entraîne des opérations complexes à réaliser.
Les fichiers générés ne contiennent aucune information sur la donnée stockée.
L’acquisition de grandes quantités de données reste problématique.

Graphite sort ensuite en 2008. Il s’agit d’un projet contenant trois briques distinctes :

Le module Carbon : en charge de récupérer les séries temporelles.
Le module Whisper : en charge du stockage des séries temporelles.
Le module Graphite Webapp (aussi appelé Graphite-Web) : interface de restitution et d’affichage des séries temporelles.

Whisper est très similaire en termes de fonctionnement à celui des bases de données de type RRD. Il a été principalement conçu pour améliorer la gestion de certains cas limites qui étaient mal gérés. En revanche, il n’apporte pas de meilleures performances ni de réels changements dans la façon de gérer la surveillance.

Les deux systèmes (surveillance et acquisition des métriques) sont toujours découplés. Il est bien sûr possible de créer une sonde en s’appuyant sur les métriques de Graphite mais il s’agit généralement de bricolage et aucunement d’une solution native et pérenne.

2. Environnement cloud et containers Docker

Le secteur informatique a connu pas mal de bouleversements ces dernières années dans la gestion des applications :

Introduction des services dans le nuage (lancement d’AWS en 2006).
Introduction des containers Docker (sortie en 2013).

Ces deux événements ont de fait bousculé le fonctionnement traditionnel des applications ou la gestion des infrastructures. Avant cela, les administrateurs pouvaient gérer leurs serveurs individuellement à la main. Avec l’augmentation des capacités, ainsi que l’explosion de la demande, l’automatisation a pris le pas sur les opérations manuelles. Les serveurs portent maintenant des identifiants et sont plutôt gérés comme un cheptel. En anglais, ce débat porte le nom de pet vs cattle, pet désignant un animal de compagnie et cattle désignant un troupeau.

Dans le cas des containers, la logique est poussée encore plus loin étant donné que le simple déploiement d’une application résulte dans la création d’un nouveau container suivie de la suppression de l’ancien.

Dans ce contexte, l’utilisation d’outils de surveillance traditionnels n’est plus adaptée : il est nécessaire d’automatiser le suivi des applications. De la même manière, les alertes ne sont plus associées...