Présentation de 4 façons de surveiller les applications Python à l'aide de Prometheus

introduction

Bien que Prometheus ait été conçu à l'origine pour des applications multithreads mono-processus plutôt que multi-processus, il est maintenant populaire pour la surveillance applications Python. Devient un outil pour.

Prometheus a été développé dans l'environnement Soundcloud et a été inspiré par Google's Borgmon. Dans l'environnement d'origine, Borgmon s'appuie sur la méthode simple de Service Discovery. Vous pouvez facilement trouver tous les travaux en cours d'exécution dans votre cluster.

Prometheus hérite de ces hypothèses, en supposant qu'une cible est un seul processus multithread. La bibliothèque cliente Prometheus est basée sur l'hypothèse que les métriques proviennent de différentes bibliothèques et sous-systèmes de plusieurs threads d'exécution s'exécutant dans un espace d'adressage partagé.

Pour commencer, accédez à MetricFire [Essai gratuit]( Veuillez vous inscrire sur https://www.hostedgraphite.com/accounts/signup-metricfire/?signup=japan&utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=How%20to%20monitor%20Python%20Applications%20with%). Dans cet essai, vous pouvez commencer à utiliser Prometheus sur votre plate-forme tout de suite et mettre en pratique ce que vous avez appris de cet article.

Problèmes d'intégration de Prometheus dans les applications Python WSGI

Lorsque j'exécute une application Python sur le serveur d'applications WSGI, je commence à avoir des problèmes. Dans les applications WSGI, les demandes sont affectées à de nombreux travailleurs différents plutôt qu'à un seul processus. Chacun de ces travailleurs devient une application multi-processus en étant déployé à l'aide de plusieurs processus.

Lorsque ce type d'application est exporté vers Prometheus, Prometheus obtient plusieurs travailleurs différents qui répondent aux demandes de scrape. Chaque ouvrier répond avec des valeurs connues, donc Prometheus peut gratter la contre-mesure et la renvoyer comme 100, immédiatement après qu'elle est retournée comme 200. Chaque travailleur exporte ses propres valeurs, de sorte que la contre-mesure mesure des informations aléatoires plutôt que l'ensemble du travail.

Il existe quatre solutions pour gérer ces problèmes:

1. Additionner tous les nœuds de calcul

Avec des étiquettes uniques pour chaque métrique, vous pouvez toutes les interroger en même temps et interroger efficacement l'ensemble du travail. Par exemple, si vous étiquetez chaque travailleur comme nom_travailleur, vous pouvez écrire une requête comme celle-ci:

sum by (instance, http_status) (sum without (worker_name) (rate(request_count[5m])))

Cela regroupe tous les nœuds de travail pour un travail à la fois. Cependant, le problème avec cela est que le nombre de métriques dont vous disposez montera en flèche.

2. Mode multi-processus

Cette méthode est recommandée par nous chez MetricFire. Cette méthode utilise le client Prometheus Python (https://github.com/prometheus/client_python), qui gère les applications multi-processus sur le serveur d'applications gunicorn et surveille votre propre application avec Prometheus.

Pour plus d'informations sur l'utilisation d'un client Python avec MetricFire pour surveiller vos propres services, consultez l'article Surveillance des applications Web Python avec Prometheus (https://qiita.com/MetricFire/items/57b95f6de1f608ef7c44). regarde s'il te plait. Cet article décrit chaque étape de l'utilisation de Prometheus pour surveiller une application Web Python.

3. Client Django Prometheus

Cette méthode spécifie chaque travailleur comme une cible complètement distincte. Le client Django Prometheus configure chaque worker pour écouter les requêtes de scrape Prometheus via son propre port.

4. Exportateur StatsD

Cette méthode rejette l'idée que Prometheus doit frotter directement l'application. Au lieu de cela, configurez Prometheus pour exporter les métriques de votre application vers une instance StatsD exécutée localement et obtenir une instance StatsD en votre nom. Cela vous donne plus de contrôle sur ce que chaque compteur compte.

Résumé

Prometheus ne peut pas surveiller nativement les applications multi-processus, mais ces quatre solutions sont de bonnes solutions de contournement. Cela permet à Prometheus d'être le principal outil de surveillance de toute l'entreprise pour les ressources informatiques et APM.

Pour plus d'informations sur l'utilisation de Prometheus pour surveiller les applications Python, consultez l'article Exportateur basé sur Python (https://www.metricfire.com/blog/first-contact-with-prometheus) et Kubernetes. Voir la série sur le développement et le déploiement d'API Python à l'aide de (https://www.metricfire.com/blog/develop-and-deploy-a-python-api-with-kubernetes-and-docker).

Pour essayer Prometheus et mettre en pratique ce que vous avez appris de cet article, [MetricFire](https://try.metricfire.com/japan/?utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=How%20to%20monitor%20Python% 20Applications% 20with% 20Prometheus) [Essai gratuit](https://www.hostedgraphite.com/accounts/signup-metricfire/?signup=japan&utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=How%20to%20 avec 20Python%20 Vérifiez% 20 Prometheus). Vous pouvez utiliser Prometheus directement sur notre plateforme pour commencer à surveiller les métriques sans configuration. Veuillez également nous contacter directement en Réserver une démo .. Nous sommes toujours heureux de vous entendre sur les besoins de surveillance de votre entreprise.

Rendez-vous dans un autre article!