Monitoring avec Prometheus : La série de tutos

Nouvelle série de tutos, pas vraiment prévue, mais étant en train de refaire mon architecture de monitoring, je me suis dis qu’il fallait l’écrire de suite sinon, j’allais encore mettre ça de côté…

Et pour l’occasion, je vous invite à plonger dans le monde de Prometheus (non, pas le film, bien que je sois l’un des rares à l’avoir apprécié…)

I – Présentation

Monitoring, Métrologie, Supervision ?

Le monitoring, c’est l’art pour un administrateur de traquer ses machines, de suivre l’activité, de voir ce qui merdouille…

Bah oui, on est curieux et on veut savoir ce qui se trame…

Mais dans la notion de Monitoring, on trouve deux « types » de monitoring :

• Métrologie : c’est tout bêtement avoir de jolis courbes qui indiquent l’usage dans le temps de différentes « choses ». Typiquement, CPU, RAM, réseau, etc…etc..
• Supervision : c’est voir rapidement d’un coup d’œil l’état des systèmes. Typiquement, une interface avec plein de choses au vert si tout va bien…

Par chez moi, jusque la, pour la métrologie, Munin était mon ami et côté supervision, Nagios était mon … heu, j’ai jamais vraiment accroché donc on va dire que c’était un invité de passage…

Je me suis souvenu que j’avais commencé un brouillon la dessus, il y a fort fort longtemps. A cette époque, je passais de Cacti à Munin et j’essayais Centreon couplé à Nagios. Mais le brouillon commençait à sentir le fennec… et je me suis dit qu’il y avait surement mieux maintenant.

Et force est de constater qu’en effet, les vénérables ont fait leurs temps et que les solutions « modernes » sont ‘achement sexys 😉

Utilisant le  Stack ELK (Elasticsearch, Logstash et Kibana) pour mes logs, je me suis imaginé tout voir dans Kibana (l’interface graphique). Mais si ELK pour la gestion des logs, c’est simplement parfait, pour les métriques, ce n’est pas la même musique.
Le type de données n’est pas le même, les outils ne sont pas vraiment adaptés…

En creusant un peu, on trouve des solutions qui ont le goût d’ELK (surtout du K en fait), mais orientés métriques et supervisions.

Les bases de données utilisées alors sont des bases TSDB (Time Serie DataBase) qui sont spécialement conçues pour du stockage de métriques.

On trouve plusieurs solutions, mais les deux qui se distinguent sont articulées autour d’ InfluxDB et de Prometheus.

InfluxDB :

• InfluxDB : la base TSDB.
• Telegraf : le collecteur de base qu’on installe sur les machines à surveiller.
• Grafana : l’interface Web qui permet de se faire de jolis tableaux de bords. Clairement, ça fait penser à Kibana, mais pour les métriques.

Prometheus :

• Prometheus : la base TSDB.
• Node Exporter : le collecteur de base.
• Grafana : Et oui, Grafana supporte moult sources de données.

Comparons un peu :

• Au niveau soutien, suivi :

Prometheus semble l’emporter.
Gros plus, les Dashboards pour Grafana sont plus nombreuses (oui, on peut importer des Dashboards proposées sur le site de Grafana, et la, je ne vous dis pas le gain de temps.
Très utile également pour voir comment faire tel ou tel type de graphiques, jauges, et pour apprendre le PromQL, j’en parle plus loin)

• Consommation de ressources :

Ça semble un poil mieux côté Prometheus (mais les deux solutions restent de toute façon très légères à côté d’un ELK et de son Java).

• Exporters :

Dans les deux environnements, on trouve de quoi mesurer des serveurs SQL, HAProxy, Redis, du SNMP, etc.. Mais le choix est plus large côté Prometheus.

Une liste (non exhaustive) : https://prometheus.io/docs/instrumenting/exporters/

Au niveau collecteur basique pour les métriques systèmes (Telegraf pour InfluxDB et Node Exporter pour Prometheus), les deux fournissent la base, mais la aussi Node_Exporter est plus bavard.

• Fonctionnement :

InfluxDB, c’est du PUSH. Ce sont les clients qui poussent vers le serveur.

Prometheus, c’est par défaut du PULL. C’est le serveur qui vient chercher sur les clients. Mais si besoin, on peut faire du PUSH avec l’ajout de Pushgateway (toujours par l’équipe de Prometheus). Utile par exemple en cas de firewall ou de Nat…

• Langage :

InfluxDB, c’est du SQL quasi standard, par ex : Select mavar FROM matable…

Prometheus, c’est un langage proprio, le PromQL.
Pour avoir une variable ? Suffit juste de donner son nom. Pas de select, etc..
C’est plus « simple » même s’il faut « prendre le coup » et c’est la que les DashBoards préconçus sont pratiques car en regardant ce qu’on fait les autres, on comprend.

Pour info, la Doc de PromQL : https://prometheus.io/docs/prometheus/latest/querying/basics/

• Cluster :

InfluxDB ne le permet pas dans sa version « gratuite », faut payer une licence… Argh…

Prometheus, c’est natif, documenté et pas compliqué à mettre en œuvre (dans les articles à venir, je ne l’aborde pas, mais j’en parlerais un jour…)

Je n’ai pas tout comparé point par point, mais vous avez déjà une petite idée des principales différences.

Et pour moi, la cause est entendue, ce sera Prometheus le vainqueur.

Pour la petite histoire, Prometheus est à la base l’outil interne de https://soundcloud.com/, lui même dérivé de l’outil interne de Google, Borgmon. Ils ont rendu le projet public et surtout open-source. Et sincèrement, ce fut une excellente idée.

Dans les articles qui suivent, les téléchargements indiqués sont les dernières versions en date au moment de la rédaction.
Pour être à jour, pensez à regarder ici : https://prometheus.io/download/ et modifiez en conséquence les différents wget que j’indique.

Attention aussi au format yml utilisé pour les fichiers de configs !
Il ne faut pas utiliser de tabulations pour indenter, mais toujours deux espaces.
Si un truc ne démarre pas, 9 chances sur 10 que le problème vienne de la.

Allez, on peut y aller !

II – Les articles

I – Installation de Prometheus

II – Node Exporter

III – Grafana

IV – Alerting

V – BlackBox

VI – Monitorer les services

VII – Text Collector

VIII – Des diagrammes dans Grafana

IX – Autres exporters (Mysql, Haproxy, etc…)

Envie de me soutenir et de me payer un café ? C’est sur la page Don !