prometheus - concepts de base
Dès lors que l’on envisage de mettre en place du logiciel spécifique en place, il est indispensable de penser à la supervision de l’ensemble et idéalement depuis l’intérieur. Les logiciels développés doivent donc proposer des points de supervision et de monitoring de la performance qu’elle soit technique ou fonctionnelle. Les deux principaux moyens sont les logs et les métriques. Ils ne servent pas les mêmes objectifs, interessons nous à la seconde catégorie.
La solution prometheus offre la possibilité de collecter des métriques dans les infrastructures et les logiciels développés maison afin d’effectuer de la supervision mais également de la gestion d’alerte sur seuil. Si vous ne connaissez pas cette solution, voici quelques lignes pour rapidement comprendre son fonctionnement.
Si vous n’avez pas vu toute la série sur le sujet, voici la table des sujets abordés dans les différents articles :
- prometheus - concepts de base : introduction à prometheus, principes de fonctionnement, usages
- prometheus - bien démarrer en python : comment instrumenter son code python afin de fournir les services de métrologie pour prometheus
- prometheus et grafana : intégration de prometheus avec l’outil de dataviz grafana
- prometheus avec consul : intégration avec consul pour la découverte automatique des services à intégrer dans prometheus
- prometheus - bien démarrer en java : comment instrumenter du code java spring afin de remonter les métriques dans prometheus
Introduction
Contrairement à des solutions de supervision plus globales, comme centreon par exemple, qui implémentent une méthode de communication avec des agents, prometheus met en place un dialogue client/serveur assez efficace qui autorise des intervalles d’interrogation courts (de l’ordre de quelques secondes). Il va donc être possible de suivre les micro évolutions des logiciels et infrastructures afin d’être capable de réagir rapidement. Autant pour la supervision graphique ce n’est pas capital, autant pour le troubleshooting et la gestion des alertes c’est assez important.
Fonctionnement
La solution prometheus est basée sur la collecte de métrique et le stockage des résultats dans une base temporelle. Les métriques sont composées d’un jeu de clés et de valeurs permettant de les manipuler par famille et ainsi de faciliter les regroupements et donc les requêtes de traitement.
A intervalle régulier, prometheus interroge les agents spécifiques. La collecte est donc tirée depuis un point central, on retrouve le modèle de SNMP par exemple. Si vous vous posez déjà la question de la performance par rapport à un grand nombre de points à interroger ou de valeurs à traiter dans la base de donnée interne, prometheus permet de construire une fédération de plusieurs instances.
Une fois les métriques collectées et stockées, deux options principales :
- utiliser les métriques pour de la supervision via un grapheur comme grafana par exemple
- utiliser le système d’alerte afin de prendre des actions en réaction, que ce soit un simple envoie de courriel, sms ou message dans slack à une actions orchestrée dans un pipeline de résolution
La collecte
Les cibles collectées à intervalle régulier sont appelées des instances, le processus d’interrogation est nommé scraping. Il est possible directement de récupérer des informations via des exporters standards :
- pour les bases de données comme mysql, mongodb, postgresql ou elasticsearch
- pour les serveurs web : apache, nginx, le cache varnish, le loadbalancer haproxy
- pour les middleware de gestion de message : kafka, rabbitmq, AWS SQS
- pour les systèmes via node_exporter et statd_exporter
Il est également possible de pousser des métriques vers un point relais (pushgateway), même si cette solution n’est pas conseillée elle reste nécessaire pour la supervision de métriques en provenance d’objets éphémères comme les batchs par exemple.
Développements
Pour les développements internes, ils devront présenter un point de collecte permettant à prometheus de venir chercher régulièrement les données (scrapper). L’intérêt de cette instrumentation est qu’elle permet aux développeurs de remonter les informations qui leurs semblent pertinentes, qu’elles soient techniques (comme un nombre d’invocation ou le temps passé dans une fonction) ou qu’elle soient fonctionnelles (nombre d’acte métier par exemple).
Le point de collecte se comporte comme un web service retournant une liste de clés/valeurs accompagnés de commentaires explicatifs (si instrumentés dans votre code bien sûr). On retrouve également des informations sur le type de plateforme (ligne #3), le language utilisé, la mémoire utilisée (#6, #9), la date de démarrage de l’application (#12) ou encore le CPU utilisé (#15). Voici un exemple de quelques lignes issues du lab en python ({% post_link prometheus-bien-demarrer-en-python bien démarrer avec python %}) que je vous prépare pour la suite…
# HELP python_info Python platform information
# TYPE python_info gauge
python_info{implementation="CPython",major="3",minor="4",patchlevel="8",version="3.4.8"} 1.0
# HELP process_virtual_memory_bytes Virtual memory size in bytes.
# TYPE process_virtual_memory_bytes gauge
process_virtual_memory_bytes 310210560.0
# HELP process_resident_memory_bytes Resident memory size in bytes.
# TYPE process_resident_memory_bytes gauge
process_resident_memory_bytes 22781952.0
# HELP process_start_time_seconds Start time of the process since unix epoch in seconds.
# TYPE process_start_time_seconds gauge
process_start_time_seconds 1526153399.19
# HELP process_cpu_seconds_total Total user and system CPU time spent in seconds.
# TYPE process_cpu_seconds_total counter
process_cpu_seconds_total 0.38
# HELP process_open_fds Number of open file descriptors.
# TYPE process_open_fds gauge
process_open_fds 7.0
# HELP process_max_fds Maximum number of open file descriptors.
# TYPE process_max_fds gauge
process_max_fds 1024.0
Les langages supportés sont nombreux avec en standard go, java & scala, python, ruby, via des librairies externes on trouve également node, php, rust, C, C++, bash (pas mal pour certains petits batchs)…
La charge de développement est très modérée pour le développeur et se fait en un minimum de ligne de code. On trouve quelques types différents de métrique permettant de gérer des cas différents de supervision :
- le compteur (counter) : valeur cumulative
- la jauge (gauge) : valeur entière pouvant être incrémentée ou décrémentée
- l’histogramme (histogram) : permet de distribuer des valeurs (temps de réalisation ou taille par exemple) sur un ensemble de poches
- le résumé (summary) : permet de tracer le nombre d’appel et le temps passé sur un bloc de code, comme une fonction par exemple, il peut également suivre les quantiles (dépend du niveau de l’implémentation du client, pas disponible en python)
Enfin, le fait que l’application embarque directement son point de collecte rend très simple la mise au point. On peut en effet travailler hors sol sans prometheus et regarder le résultat de l’interrogation du web service directement pour se rendre compte de l’avancement du développement.
La découverte des instances
Le fichier de configuration de prometheus permet de positionner les instances à scraper, mais une des clés est la découverte automatique des instances via des systèmes d’annuaire. Ceci ouvre la voie à la supervision des infrastructures modernes et largement élastiques (très différent de centreon sur ce point par exemple). On pourra donc notamment avoir accès à des métriques sur des nouveaux composants sans pour autant que les équipes de production ou de supervision n’aient à changer des configurations complexes.
Une utilisation simple est de faire s’enregistrer les applications dans un consul, elles seront ainsi automatiquement ajoutées (ou supprimées) aux cibles collectées. On utilisera cette solution pour les collectes systèmes via node_exporter qui dispose d’une configuration dédiée afin de réaliser cet enregistrement de façon automatique.
Il est également possible d’interroger des systèmes de cloud comme AWS EC2, Microsoft azure SD ou Google Cloud Platform via GCE.
Il est enfin possible d’instrumenter son propre cloud interne via openstack, kubernetes, mesosphere marathon, la dernière solution ouvrira les pistes restantes via un fichier qui servira de base de données et relu à chaque modification.
Requetage
Une des forces de prometheus est la richesse de son langage d’interrogation. Il offre directement sur la console web de l’outil de quoi regarder les métriques et les grapher de façon simple. Les fonctions mathématiques et statistiques permettent de manipuler les valeurs stockées et toutes utilisables via l’API, on les retrouvera donc dans notre grafana préféré par exemple.
On pourra disposer de nombreuses fonctions de manipulation des intervales de temps (avantage d’avoir une base de données de type time series), la possibilité d’utiliser des expressions régulières dans les filtres, tous les opérateurs mathématiques simples ainsi que des fonctions plus complexes comme par exemple un opérateur de régression linéaire (utile pour calculer l’atteinte d’un seuil dans le temps comme un espace disque saturé ou un débordement de mémoire), un outil de calcul de taux sur une période de temps ou encore un outil de topn.
Architecture
On trouve de nombreux retours d’expérience de la mise en place de prometheus sur des infrastructures complexes et il apparait de plus en plus souvent dans les patterns d’architecture de systèmes élastiques, notamment les micro-services.
Afin de simplifier au plus la vie des ops, on peut embarquer un prometheus dans son stack applicatif et le rendre disponible soit à un prometheus plus haut dans la hiérarchie de fédération ou à des systèmes tiers de représentation comme grafana. L’avantage du polling initié par prometheus est qu’il n’y a rien à faire de spécial dans les applications (ie circuit braker) puisque dans le pire des cas elles ne seront pas interrogées.
En termes de performances, on trouve dans les retours d’expérience le chiffre de 100k métriques traitées par seconde pour un serveur prometheus (probablement pas un tout petit néanmoins) :
- 1000 metriques par instance (assez fin déjà donc)
- 1000 instances scrapées toutes les 10 secondes ou 6000 instances scrapées chaque minute
Bibliographie
Quelques liens pour aller un peu plus loin et vous faire votre propre idée:
- Regain control thanks to Prometheus (KubeCon 2017)
- OMG! Prometheus (oct 2015, Benjamin Staffin)
- Prometheus, un outil pour les monitorer tous ! (devoxx 2018, Ian Beauvais)
- Prometheus Monitoring for Java Developers (devoxx 2016, Fabian Stäber)
Photo from Nick Hillier