SupervisionSystème

Supervision – Métrologie – Alerting avec Prometheus

Présentation rapide de Prometheus

Dans le monde en constante évolution de DevOps, où les micro-services et les architectures distribuées deviennent la norme, le besoin de comprendre l’état interne des applications se développe rapidement. Le monitoring whitebox vous donne des détails sur l’état interne de votre application, comme le nombre total de requêtes HTTP sur votre serveur web ou le nombre d’erreurs enregistrées. En revanche, le test blackbox (par exemple, Nagios) vous permet de vérifier un système ou une application (par exemple, en vérifiant l’espace disque ou en sondant un hôte) pour voir si un hôte ou un service est vivant, mais ne vous aide pas à comprendre comment il a pu arriver à l’état actuel. Prometheus est une solution open source de surveillance en whitebox qui utilise une base de données de séries chronologiques pour fournir des requêtes, des graphiques et des alertes basés sur des données de séries chronologiques.

Plusieurs entreprises utilisent Nagios comme seul outil de surveillance pour leurs systèmes et applications. Cela fonctionne bien pour l’usage auquel il est destiné, mais il ne fournit pas tous les détails. Imaginons que  Nagios m’est alerte que l’espace disque est plein à 90%. La vérification de l’espace disque a fonctionné comme prévu, mais ne m’indique pourquoi le disque se remplit. Plus important encore, cela n’indique pas combien de temps il me reste avant que le disque soit plein. La surveillance whitebox  permettrait de voir la vitesse à laquelle le disque se remplissait.

Ces mesures sont stockées dans sa base de données pour analyse ultérieure, visualisation et alerte. Il existe déjà des bibliothèques clients officielles écrites pour correspondre au langage dans lequel votre application peut être écrite, y compris Go, Java, Scala, Python, Ruby, et de nombreuses autres bibliothèques tierces non officielles. Les métriques que vous devez mettre en œuvre doivent être dans un format que Prometheus peut comprendre, mais Prometheus maintient un certain nombre d’exportateurs qui aident à exporter les métriques existantes à partir de systèmes tiers, tels que les statistiques du système Linux ou Memcached.

Spécification et avantage de Prometheus

  • Produit Open Source
  • Développé initialement par Sound Cloud et inspiré de Borgmon (outils de récolte et de centralisation utilisé par Google.
  • Outils intégrés à la « Cloud Native Computing Foundation » cncf.io
  • Version 1.0 en juillet 2016
  • Version 2.2 mars 2018
  • Utilisateur de l’outil : SoundCloud, Redhat, DigitalOcean, Docker
  • Livré sous forme de binaire statique développé en Go
  • Monitoring simple est accessible à tout le monde
  • Blackbox monitirong est du simple monitoring comparable à ce qu’un utilisateur pourrait faire, test de l’accessibilité d’une service en tapant une URL…
  • Whitebox monitoring
  • Stocker sur le filesystem local
  • Haut disponibilité en faisant tourner plusieurs instances Voir : Thanos
  • Prometheus travail avec des time serie multi-diemensional
  • Une métrique à un nom, des valeur (float64), timestamp
  • Langage PromQL permettant de requêter les données time serie
  • Pas d’agent sur les serveur à monitorer, le collecte des Time series ce fait via le model pull, c’est prometheus qui va aller chercher l’information sur les machine cliente.

Ce que Prometheus ne fait pas et ces inconvenants

  • Collect de Log https://www.elastic.co/fr
  • Tracer de requête entre service
  •  La rétention de la data est de 15 jours par défaut mais peut être modifier, prometheus n’est pas fait pour garder la data sur le long terme mais il peut travailler avec des solutions comme influxdb qui se chargerons de cette tâche. https://www.influxdata.com/

L’architecture de Prometheus et fonctionnement

  • Le composant principal est le prometheus serveur (le binaire Go) Il s’occupe de la partie poling il va interroger des nœuds externes Exporteur, NodeExporter demon installer sur les nœuds qui est requêter pour aller récupérer des métrique.
  • PushGateway, prometheus est en mode principal pus, pour la collect demétrique. C’est donc lui qui va intéroger des target (cible) pour récupérer de l’information.
  • Mécanisme de service discorecy pour scraper (récupérer) les informations sur les target.
  • Un système d’alerte est disponible avec AlertManager en fonction de certains seuils préalablement défini, puis notification vers e-mail ou Slock https://get.slack.hel
  • Blackbox exporter : permet du monitoring simple en requettant les des protocoles : http, tcp, icmp. En interprétant les résultats des ces requêtes et les temps de réponses.
  • Intégration via le nœud exporter, kubernetese, docker container via Cadvisor

Push VS Pull

En mode Push : c’est les applications qui vont envoyer, pousser des données vers le serveur, impliquant donc le paramétrage des machines à monitorer en leur indiquant la destination pour la métrique, le format des données. Ce mode de travail n’est pas adapté à des infrastructures ou vous avez des centaines ou milliers de serveur à monitorer. Sauf si vous utiliser des logiciels de gestion de configuration comme Ansible. Sellons les applications, si l’infrastructure de monitoring tombe, l’application va continuer à envoyer des requêtes à l’infrastructure.

Le mode Pull est simple à mettre en œuvre, il est implémenté par prometheus par défaut, va aller chercher l’information et contrôler le flux de données, il y à donc moins de risque que le serveur prométhéums soit surcharger par l’arriver massive de données de l’extérieur. En mode pull, les application, serveur n’ont pas connaissance de l’infrastructure de monitoring. Il faut déclarer un nouveau composant, application, serveur, ou container quand il va arriver sur l’infrastructure mais via ServiceDiscorev cette tache peut être simplifié malgré des latences sur la découverte de services.

Les métriques

Prometheus enregistre toutes les données sous forme de séries temporelles : des flux de valeurs horodatées appartenant à la même métrique. Prometheus peut générer des séries temporelles dérivées temporaires à la suite de requêtes.

Noms et étiquettes métriques:

Chaque série temporelle est identifiée de façon unique par son nom métrique et un ensemble de paires de valeurs clés, également appelées étiquettes.

Le nom métrique spécifie la caractéristique générale d’un système qui est mesuré (par exemple http_requests_total – le nombre total de requêtes HTTP reçues). Il peut contenir des lettres et des chiffres ASCII, ainsi que des tirets de soulignement et des deux-points. Il doit correspondre au regex[a-zA-Z_ :][a-zA-Z0-9_ :]*.

Remarque : Les deux-points sont réservés aux règles d’enregistrement définies par l’utilisateur. Ils ne devraient pas être utilisés par les exportateurs ni par des instruments directs.

Les étiquettes permettent le modèle de données dimensionnelles de Prometheus : toute combinaison donnée d’étiquettes pour le même nom de métrique identifie une instanciation dimensionnelle particulière de cette métrique (par exemple : toutes les requêtes HTTP qui utilisent la méthode POST vers le gestionnaire /api/tracks). Le langage de requête permet le filtrage et l’agrégation en fonction de ces dimensions.

Les noms d’étiquettes peuvent contenir des lettres ASCII, des chiffres, ainsi que des caractères de soulignement. Ils doivent correspondre au regex[a-zA-Z_][a-zA-Z0-9_]*. Les noms d’étiquettes commençant par __ sont réservés à un usage interne.

Les valeurs des étiquettes peuvent contenir n’importe quel caractère Unicode.

Voir aussi les meilleures pratiques pour nommer les métriques et les étiquettes.

Échantillons:

Les échantillons forment les données des séries chronologiques réelles. Chaque échantillon se compose de :

  • une valeur flottante64
  • un horodatage de précision à la milliseconde

Notation:

Étant donné un nom métrique et un ensemble d’étiquettes, les séries chronologiques sont fréquemment identifiées à l’aide de cette notation :

<nom métrique>{<nom de l’étiquette>=<valeur de l’étiquette>, ….}.

Par exemple, une série temporelle avec le nom métrique api_http_requests_total et les étiquettes method=”POST” et handler=”/messages” pourrait être écrite comme ceci :

api_http_requests_total{method=”POST”, handler=”/messages”}

Les types de métriques

Compteur:

Un compteur est une métrique cumulative qui représente un seul compteur à augmentation monotone dont la valeur ne peut qu’augmenter ou être remise à zéro au redémarrage. Par exemple, vous pouvez utiliser un compteur pour représenter le nombre de demandes servies, de tâches effectuées ou d’erreurs.

N’utilisez pas un compteur pour exposer une valeur qui peut diminuer. Par exemple, n’utilisez pas de compteur pour le nombre de processus en cours d’exécution ; utilisez plutôt une jauge.

Jauge:

Une jauge est une métrique qui représente une seule valeur numérique qui peut arbitrairement monter et descendre.

Les jauges sont généralement utilisées pour les valeurs mesurées comme les températures ou l’utilisation actuelle de la mémoire.

Histogramme:

Un histogramme échantillonne les observations (généralement des choses comme la durée des requêtes ou la taille des réponses)il fournit également une somme de toutes les valeurs observées.

Un histogramme dont le nom métrique de base est <basename> expose plusieurs séries temporelles pendant une raclée :

compteurs cumulatifs pour les seaux d’observation, exposés sous la forme <basename>_bucket{le=”<bucket inclusive bound>”}.

la somme totale de toutes les valeurs observées, exposées sous la forme <basename>_sum

le nombre d’événements qui ont été observés, exposés sous la forme <basename>_count (identique à <basename>_bucket{le=”+Inf”} ci-dessus)

Utilisez la fonction histogram_quantile() pour calculer des quantiles à partir d’histogrammes ou même d’agrégations d’histogrammes. Un histogramme permet également de calculer un score Apdex. Lorsque vous travaillez sur des seaux, rappelez-vous que l’histogramme est cumulatif. Voir les histogrammes et les sommaires pour plus de détails sur l’utilisation des histogrammes et les différences par rapport aux sommaires.

 

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *