Créer un exportateur Prometheus peut être compliqué, mais ce n'est pas obligatoire. Dans cet article, nous allons vous apprendre les bases de Prometheus et vous présenter deux guides étape par étape qui vous montrent comment implémenter un exportateur basé sur Python. Le premier guide concerne un exportateur tiers qui publie des métriques sur l'application que vous souhaitez surveiller de manière autonome. Le second couvrira les exportateurs qui exposent les métriques d'applications intégrées.
Prometheus est le principal outil de surveillance des métriques de séries chronologiques qui applique ses propres concepts depuis son introduction en 2012. Plus précisément, l'approche pull de collecte de données de Prometheus, associée aux exportateurs et aux visualisations flexibles, comprend Graphite et InfluxDB. Il se distingue également par rapport à d'autres outils de surveillance populaires tels que / products / influxdb-overview /).
L'approche d'extraction de collecte de données consiste en ce que le composant serveur (serveur Prometheus) récupère périodiquement les métriques du composant client. Cette attraction est communément appelée "ferraille" dans le monde Prométhée. Grâce au scraping, le composant client est uniquement responsable de le rendre disponible pour la génération de métriques et le scraping.
Graphique, InfluxDB et de nombreux autres outils utilisent une approche de type push dans laquelle le composant client génère une métrique et la pousse vers le composant serveur. Par conséquent, le client décide quand envoyer les données, que le serveur en ait besoin ou soit prêt à les collecter.
L'approche pull de Prometheus est innovante. En demandant le scraping au serveur plutôt qu'au client, nous ne collectons des métriques que lorsque le serveur est en marche et que les données sont prêtes. Cette approche nécessite que chaque composant client active une fonctionnalité spécifique appelée l'exportateur Prometheus.
L'exportateur fait partie intégrante de l'environnement de surveillance Prometheus. Chaque programme qui agit en tant que client Prometheus a un exportateur en son centre. L'exportateur se compose de capacités logicielles qui génèrent des données métriques et d'un serveur HTTP qui expose la métrique générée disponible via un point de terminaison particulier. Les métriques sont publiées selon un format spécifique que le serveur Prometheus peut lire et capturer (scrap). Plus loin dans cet article, nous expliquerons comment créer des métriques, leurs formats et comment les rendre disponibles pour le scraping.
Une fois les métriques récupérées et enregistrées par le serveur Prometheus, vous devrez alors les visualiser, mais il existe de nombreuses façons de le faire. Le moyen le plus simple est d'utiliser le navigateur d'expression Prometheus (https://prometheus.io/docs/visualization/browser/). Cependant, comme il ne dispose que de fonctionnalités de visualisation de base, le navigateur d'expression est principalement utilisé à des fins de débogage (vérification de la disponibilité ou de la dernière valeur d'une métrique particulière). Pour une visualisation meilleure et plus avancée, les utilisateurs choisissent souvent d'autres outils tels que Grafana [https://grafana.com/]. De plus, dans certains contextes, l'utilisateur interroge directement l 'API Prometheus pour obtenir les métriques qui doivent être visualisées. Vous pouvez avoir un système de visualisation sur mesure à faire.
La figure ci-dessous montre l'architecture de base d'un environnement Prometheus avec un composant serveur, deux composants client et un système de visualisation externe.
Du point de vue de l'application, il existe deux situations dans lesquelles vous pouvez implémenter l'exportateur Prometheus: l'exportation de métriques d'application intégrées et l'exportation de métriques à partir d'outils autonomes ou tiers.
C'est généralement le cas lorsque le système ou l'application expose les métriques clés de manière native. L'exemple le plus intéressant est celui où l'application est créée à partir de zéro. En effet, toutes les exigences nécessaires pour fonctionner en tant que client Prometheus peuvent être étudiées et intégrées lors de la conception. Vous devrez peut-être intégrer l'exportateur dans votre application existante. Cela nécessite la mise à jour du code (et même de la conception) pour ajouter les fonctionnalités nécessaires pour fonctionner en tant que client Prometheus. L'intégration dans une application existante peut être risquée, car elle peut entraîner une régression sur les fonctionnalités de base de l'application si elle n'est pas effectuée avec soin. Si vous devez le faire, effectuez des tests approfondis pour éviter de provoquer des régressions dans votre application (par exemple, des bogues ou une surcharge de performances due à des modifications de code ou de conception).
Les métriques requises peuvent être collectées ou calculées en externe. Un exemple de ceci est lorsqu'une application fournit une API ou un journal à partir duquel les données métriques peuvent être récupérées. Vous pouvez utiliser ces données telles quelles, mais vous devrez peut-être en faire plus pour générer la métrique (cet exportateur MySQL est un exemple).
Si vous avez besoin de calculer des métriques tout au long du processus d'agrégation avec un système dédié, vous pouvez également avoir besoin d'un exportateur externe. À titre d'exemple, considérons un cluster Kubernetes qui a besoin d'une métrique indiquant les ressources de processeur utilisées par un ensemble de pods regroupés par étiquette. Ces exportateurs peuvent s'appuyer sur l'API Kubernetes et fonctionner comme suit:
Obtenez l'utilisation actuelle du processeur et l'étiquette de chaque pod
Additionnez l'utilisation en fonction de l'étiquette du pod
Rendre les résultats disponibles pour le grattage
Cette section fournit des instructions étape par étape sur la façon d'implémenter l'exportateur Prometheus à l'aide de Python. Voici deux exemples qui couvrent les types de métriques suivants:
--Compteur: représente une métrique dont la valeur ne peut qu'augmenter avec le temps. Cette valeur sera remise à zéro au redémarrage. De telles métriques peuvent être utilisées pour exporter le temps de fonctionnement d'un système (le temps écoulé depuis le dernier redémarrage de ce système).
--Gauge: représente une métrique dont la valeur peut être augmentée ou diminuée arbitrairement au fil du temps. Il peut être utilisé pour exposer l'utilisation de la mémoire et du processeur au fil du temps.
Considérez deux scénarios. Dans le premier scénario, envisagez un exportateur autonome exposant l'utilisation du processeur et de la mémoire de votre système. Le deuxième scénario est une application Web Flask qui expose la réponse aux demandes et la disponibilité.
Ce scénario montre un exportateur Python dédié qui collecte et publie périodiquement l'utilisation du processeur et de la mémoire du système.
Ce programme nécessite que vous installiez la bibliothèque cliente Prometheus pour Python.
$ pip install prometheus_client
Vous devez également installer la puissante bibliothèque psutil pour extraire la consommation des ressources système.
$ pip install psutil
Le code d'exportateur final ressemble à ceci (voir le résumé de la source):
Vous pouvez télécharger le code et l'enregistrer dans un fichier.
$ curl -o prometheus_exporter_cpu_memory_usage.py \
-s -L https://git.io/Jesvq
Vous pouvez démarrer l'exportateur avec la commande suivante:
$ python ./prometheus_exporter_cpu_memory_usage.py
Navigateur local http://127.0.0.1:9999 Vous pouvez vérifier les métriques publiées via. Parmi les autres métriques intégrées activées par la bibliothèque Prometheus, les métriques suivantes doivent être fournies par l'exportateur (les valeurs peuvent varier en fonction de la charge de l'ordinateur):
C'est simple. Cela est dû à la magie de la bibliothèque cliente Prometheus officiellement disponible en Golang, Java, Python et Ruby. Ils cachent la plaque chauffante et facilitent la mise en place de l'exportateur. Les bases de notre exportateur peuvent être résumées dans l'entrée suivante.
Ce scénario montre un exportateur Prometheus pour l'application Web Flask. Contrairement à la version autonome, l'exportateur d'applications Web Flask dispose d'une application de répartition WSGI qui agit comme une passerelle qui achemine les demandes vers les clients Flask et Prometheus. Cela se produit car le serveur HTTP activé par Flask ne peut pas être utilisé de manière cohérente pour agir également en tant que client Prometheus. De plus, le serveur HTTP activé par la bibliothèque cliente Prometheus ne gère pas les requêtes Flask.
WSGI Pour permettre l'intégration avec les applications wrapper, Prometheus est une méthode de bibliothèque spécifique pour créer des applications WSGI qui fournissent des métriques (https://wsgi.readthedocs.io/en/latest/) make_wsgi_app) est fourni.
L'exemple suivant (Source Essentials)-Flacon application hello-world qui a été légèrement modifiée pour gérer les requêtes avec un temps de réponse aléatoire- Affiche un exportateur Prometheus qui fonctionne avec les applications Flask. (Voir la méthode hello à la ligne 18). Les applications Flash sont accessibles via le contexte racine (/ endpoint), mais l'exportateur Prometheus est activé via le point de terminaison / metrics (voir la ligne 23 où l'application de répartition WSGI est créée). Deux métriques sont publiées pour l'exportateur Prometheus.
--Service Uptime: C'est le compteur (ligne 8) qui expose le temps qui s'est écoulé depuis le dernier lancement de l'application. Le compteur est mis à jour toutes les secondes par un thread dédié (ligne 33).
Installez des dépendances supplémentaires pour que le programme fonctionne.
$ pip install uwsgi
Ensuite, utilisez WGSI pour lancer le programme.
$ curl -o prometheus_exporter_flask.py \
-s -L https://git.io/Jesvh
Démarrez ensuite le service en tant qu'application WSGI.
$ uwsgi --http 127.0.0.1:9999 \
--wsgi-file prometheus_exporter_flask.py \
--callable app_dispatch
--wsgi-file doit pointer vers un fichier programme Python, mais la valeur de l'option -callable doit correspondre au nom de l'application WSGI déclarée dans le programme (ligne 23).
Encore une fois, vous pouvez voir les métriques publiées via votre navigateur local: http://127.0.0.1:9999/metrics Parmi les autres métriques intégrées publiées par la bibliothèque Prometheus, vous devez trouver la métrique suivante publiée par l'exportateur (les valeurs peuvent varier en fonction de la charge de l'ordinateur):
Les différents exportateurs sont maintenant prêts à être récupérés par le serveur Prometheus. Apprenez-en plus ici.
Dans cet article, j'ai d'abord expliqué les concepts de base de l'exportateur Prometheus, puis j'ai expliqué deux exemples d'implémentation documentés à l'aide de Python. Ces exemples tirent parti des meilleures pratiques de Prometheus et peuvent être utilisés comme point de départ pour créer vos propres exportateurs afin de répondre aux besoins de votre application particulière. Nous n'avons pas vraiment parlé d'intégration avec le serveur Prometheus ou de visualisations qui peuvent être gérées par des outils comme Grafana. Si ces sujets vous intéressent, veuillez vérifier ici (https://qiita.com/MetricFire/items/cc9fe9741288048f4588).
Si vous voulez essayer Prometheus mais que vous ne voulez pas vous soucier des efforts de configuration et de maintenance, ou passer du temps, MetricFire = Japon & utm_content = First% 20Contact% 20with% 20Prometheus% 20Exporters) Hosted Prometheus [Essai gratuit](https://www.hostedgraphite.com/accounts/signup-metricfire/?signup=japan&utm_source=blog&utm_medium=Qiita&utm_source=blog&utm_medium=Qiita_Campaign=Qiita&utm = First% 20Contact% 20with% 20Prometheus% 20Exporters) Veuillez essayer. Réservez une démo (https://calendly.com/metricfire-chatwithus/chat?utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=First%20Contact%20with%20Prometheus%20Exporters) pour vous renseigner directement sur la solution de surveillance Prometheus. Vous pouvez également.
Rendez-vous dans un autre article!