Prometheus Starter Kit

Description

Prometheus est une solution open-source (Apache 2.0) de monitoring et d’alerting développée à l’origine chez SoundCloud. Il a été le deuxième projet soutenu par la CNCF, juste après Kubernetes. Il est aujourd’hui massivement adopté et est supporté par une grande communauté d’utilisateurs et de contributeurs.

Ses caractéristiques les plus marquantes sont :

• un modèle de données basé sur des séries temporelles, identifiées par un nom, une valeur et un ensemble de paires clé-valeur (il est aussi compatible avec d'autres bases du même type comme InfluxDB, OpenTSDB, et d’autres)
• un système de collecte basé sur du Pull HTTP(S)
• pas de stockage distribué, chaque serveur Prometheus se suffit à lui-même
• un langage (PromQL) permettant de requêter les métriques
• une configuration qui peut être statique ou basée sur différents fournisseurs de service discovery

La fréquence de collecte est paramétrable suivante les targets groups, mais gardez en tête qu’il s’agira d’un mode best-effort. Avec l’accumulation de targets, il est possible que Prometheus vienne moins souvent que prévu collecter vos métriques, puisqu’il sera occupé à faire le tour de toutes vos targets.

Architecture

Prometheus en lui-même est responsable uniquement :

• de la découverte de targets auprès desquelles collecter des métriques
• de la collecte (pull)
• du filtrage et de l’enrichissement des métriques, en fonction de règles
• du stockage des métriques

Il est possible d’utiliser un Push Gateway si vous avez le besoin d’un intermédiaire qui stocke des valeurs en attente du prochain passage de Prometheus.

La partie alerting est assurée par un démon à part : l’Alert Manager.

La partie visualisation / dashboarding est déléguée à un autre composant, capable de requêter Prometheus en PromQL via son API. Le plus généralement, il s’agit de Grafana, qui mériterait une série de billets à lui tout seul.

Exporters

Prometheus collecte des métriques certes, mais auprès de qui ? Les émetteurs de métriques sont appelés des exporters. Ils peuvent prendre la forme de démons légers qui mettent à disposition les métriques. Si vous souhaitez exposer nativement des données de vos applications, il existe aussi des librairies à intégrer dans vos bases de code.

L’un des plus simples et qui vous fournira un bon cas d'école est le node exporter. Il vous renseignera sur les organes vitaux d’un host (CPU, RAM, IO, etc). Il vous permettra aussi de poser des fichiers au format Prometheus et les exposera pour vous à côté des métriques collectées.

À regarder également, le projet NetData qui découvre énormément de métriques et les expose au format Prometheus. Il peut servir de sonde à large spectre pour avoir un bon aperçu de la santé de votre parc de machines.

Service Discovery

L’un des gros points forts de Prometheus est sa capacité à découvrir de nouvelles targets à collecter, en se basant sur des outils de service discovery. On configure Prometheus pour être capable d’interroger le Service Discovery et il tiendra à jour sa liste de targets en suivant les évolutions du registre de service auquel il est branché. Parmi les intégrations intéressantes, on peut mettre en lumière :

• AWS EC2
• Google Compute Engine
• Azure VM
• Consul
• Kubernetes

Scalabilité

Fédération

Le modèle choisi par Prometheus pour des déploiements d’envergure où un unique serveur ne suffit plus est celui de la fédération hiérachique.

Pour vous donner une idée, il s’agit de :

• découper son périmètre de collecte en shards et d’y assigner un serveur Prometheus par shard.
• mettre en place un serveur Prometheus de fédération qui collecte des métriques auprès des autres Prometheus “de première ligne”.

Chaque étage de fédération offre la possibilité de rajouter dynamiquement des labels pour pouvoir identifier quel serveur Prometheus a fait la collecte initiale de la métrique. Attention toutefois à l’accumulation des données et à a réseau sur le serveur de fédération.

Rétention de données

Prometheus fait le choix de ne stocker ses données que sur le serveur qui porte le démon de collecte. Il n’y a pas de fonctionnalité de stockage multi-noeud par défaut. Il faut donc dimensionner son disque en fonction du nombre de métriques collectées et ajuster la durée de rétention avant suppression. Vous trouverez la règle pour calculer vos besoins sur la page dédiée au stockage dans la documentation officielle.

Si vous avez le besoin de stocker vos données dans des échelles supérieures, il faudra vous appuyer sur d’autres solutions de stockage avec lesquelles Prometheus viendra s’intégrer. Parmi les projets intéressants à évaluer, suivant vos besoins :

• Thanos, qui va s’appuyer sur des services de stockage objet (S3, Swift, GCS, …) pour assurer du stockage long terme et servir d’intermédiaire pour l’interrogation.
• Cortex, qui est capable d’assurer du stockage en exploitant un cluster de machines de stockage et/ou du stockage objet.

Ces 2 projets ont le même objectif mais proposent des fonctionnalités différentes. Je vous invite à les comparer pour déterminer lequel vous convient le mieux.

Pour la suite

Prometheus est un excellent outil de collecte de métriques, rapide, fiable et simple à déployer. Ses intégrations Service Discovery et stockages externes en font un outil versatile qui a déjà fait émerger des projets compagnons (comme le Prometheus Operator pour Kubernetes).

Des outils plus traditionnels comme Centreon ont déjà des plugins pour venir collecter de la donnée auprès de Prometheus. L’adopter n’impliquera pas de jeter tout ce que vous avez déjà. Nous vous encourageons à tester Prometheus, juste pour voir s’il existe un périmètre de votre stratégie de monitoring qui pourrait bénéficier de ses avantages.

Have fun. Hack in peace.