Comment interroger Prometheus sur Ubuntu 14.04 Partie 1

Prometheus est un système de surveillance open source et une base de données de séries chronologiques. L’un des aspects les plus importants de Prometheus est son modèle de données multidimensionnel ainsi que le langage de requête associé. Ce langage de requête vous permet de découper vos données dimensionnelles en tranches afin de répondre aux questions opérationnelles de manière ad-hoc, d’afficher les tendances dans des tableaux de bord ou de générer des alertes sur les défaillances de vos systèmes.

Dans ce tutoriel, nous allons apprendre à interroger Prometheus 1.3.1. Afin de pouvoir utiliser des exemples de données appropriés, nous allons configurer trois instances de service de démonstration identiques qui exportent des métriques synthétiques de différents types. Nous allons ensuite configurer un serveur Prometheus pour récupérer et stocker ces métriques. À l’aide des exemples de métriques, nous apprendrons ensuite à interroger Prometheus, en commençant par des requêtes simples et en passant à d’autres plus avancées.

Après ce didacticiel, vous saurez comment sélectionner et filtrer des séries chronologiques en fonction de leurs dimensions, de leur agrégation et de leur transformation, ainsi que pour effectuer des calculs arithmétiques entre différents indicateurs. Dans un tutoriel de suivi, Comment interroger Prometheus sur Ubuntu 14.04, partie 2 , nous allons nous appuyer sur les connaissances de ce didacticiel pour couvrir des cas d’utilisation plus avancés des requêtes.

Pour suivre ce tutoriel, vous aurez besoin de:

Dans cette étape, nous allons télécharger, configurer et exécuter un serveur Prometheus pour supprimer trois instances de service de démonstration (pas encore en cours d’exécution).

Tout d’abord, téléchargez Prométhée:

Extraire l’archive:

Créez un fichier de configuration Prometheus minimal sur le système de fichiers hôte sous + ~ / prometheus.yml +:

Ajoutez le contenu suivant au fichier:

~ / prometheus.yml

Enregistrez et quittez nano.

Cet exemple de configuration amène Prometheus à gratter les instances de démonstration. Prometheus fonctionne avec un modèle d’extraction. C’est pourquoi il doit être configuré pour connaître les points d’extrémité sur lesquels extraire les métriques. Les instances de démonstration ne sont pas encore en cours d’exécution, mais elles fonctionneront sur les ports + 8080 +, + 8081 + et + 8082 + plus tard.

Démarrez Prometheus en utilisant + nohup + et en tant que processus d’arrière-plan:

Le + nohup au début de la commande envoie la sortie au fichier` + ~ / nohup.out` au lieu de + stdout. Le + + + à la fin de la commande permettra au processus de continuer à s’exécuter en arrière-plan tout en vous donnant votre invite pour des commandes supplémentaires. Pour ramener le processus au premier plan (c’est-à-dire au processus en cours d’exécution du terminal), utilisez la commande + fg + sur le même terminal.

Si tout se passe bien, dans le fichier + ~ / nohup.out +, vous devriez voir une sortie similaire à celle-ci:

Sortie de départ de Prométhée

Dans un autre terminal, vous pouvez surveiller le contenu de ce fichier avec la commande + tail -f ~ / nohup.out +. Au fur et à mesure que le contenu est écrit dans le fichier, il sera affiché au terminal.

Par défaut, Prometheus chargera sa configuration à partir de + prometheus.yml + (que nous venons de créer) et stockera ses données de métrique dans +. / Data + dans le répertoire de travail en cours.

L’indicateur + -storage.local.memory-chunks + ajuste l’utilisation de la mémoire de Prometheus à la très petite quantité de RAM du système hôte (seulement 512 Mo) et à un petit nombre de séries chronologiques stockées dans ce didacticiel.

Vous devriez maintenant pouvoir accéder à votre serveur Prometheus à + ​​http: //: 9090 / +. Vérifiez qu’il est configuré pour collecter des métriques des trois instances de démonstration en sélectionnant + http: //: 9090 / status + et en localisant les trois points de terminaison cibles du travail + demo + dans la section * Targets *. La colonne * State * des trois cibles doit indiquer l’état de la cible sous la forme * DOWN * car les instances de démonstration n’ont pas encore été démarrées et ne peuvent donc pas être supprimées:

image: https: //assets.digitalocean.com/articles/prometheus_querying/demo.png [Les instances de démonstration doivent être affichées en tant que DOWN]

Dans cette section, nous allons installer et exécuter les trois instances de service de démonstration.

Téléchargez le service de démonstration:

Extrait le:

Exécutez le service de démonstration trois fois sur des ports distincts:

+ + + Lance les services de démonstration en arrière-plan. Ils n’enregistrent rien, mais exposent les métriques Prometheus sur le point de terminaison HTTP + / metrics + sur leurs ports respectifs.

Ces services de démonstration exportent des métriques synthétiques sur plusieurs sous-systèmes simulés. Ceux-ci sont:

Les métriques individuelles sont introduites dans les exemples d’interrogation des sections suivantes.

Le serveur Prometheus devrait maintenant commencer automatiquement à gratter vos trois instances de démonstration. Allez sur la page d’état de votre serveur Prometheus à l’adresse + http: //: 9090 / status + et vérifiez que les cibles du travail + démo + affichent maintenant l’état * UP *:

image: https: //assets.digitalocean.com/articles/prometheus_querying/demo_up.png [Les cibles de démonstration doivent être affichées comme UP]

Dans cette étape, nous nous familiariserons avec l’interface Web intégrée d’interrogation et de représentation graphique de Prometheus. Bien que cette interface soit idéale pour l’exploration de données ad-hoc et l’apprentissage du langage de requête de Prometheus, elle ne convient pas pour la création de tableaux de bord persistants et ne prend pas en charge les fonctionnalités de visualisation avancées. Pour créer des tableaux de bord, voir l’exemple Comment ajouter un tableau de bord Prometheus à Grafana.

Allez sur + http: //: 9090 / graph + sur votre serveur Prometheus. Ça devrait ressembler à ça:

image: https: //assets.digitalocean.com/articles/prometheus_querying/interface.png [Interface d’interrogation et de représentation graphique de Prometheus]

Comme vous pouvez le voir, il y a deux onglets: * Graph * et * Console *. Prometheus vous permet d’interroger des données selon deux modes différents:

Étant donné que Prometheus peut s’adapter à des millions de séries chronologiques, il est possible de créer des requêtes très coûteuses (considérez cela comme similaire à la sélection de toutes les lignes d’une grande table dans une base de données SQL). Pour éviter que les requêtes expirent ou surchargent votre serveur, il est recommandé de commencer par explorer et construire des requêtes dans la vue * Console * plutôt que de les représenter immédiatement sous forme de graphique. L’évaluation d’une requête potentiellement coûteuse à un moment donné consomme beaucoup moins de ressources que d’essayer de représenter graphiquement la même requête sur une période donnée.

Une fois que vous avez suffisamment réduit la requête (en termes de série sélectionnée pour le chargement, de calculs à effectuer et de nombre de séries chronologiques en sortie), vous pouvez passer à l’onglet * Graph * pour afficher l’expression évaluée au fil du temps. . Savoir quand une requête est assez bon marché pour être représentée graphiquement n’est pas une science exacte, cela dépend de vos données, de vos exigences en matière de latence et de la puissance de la machine sur laquelle vous exécutez votre serveur Prometheus. Vous aurez une idée de cela avec le temps.

Puisque notre serveur de test Prometheus ne récupérera pas beaucoup de données, nous ne pourrons pas formuler de requêtes coûteuses dans ce didacticiel. Tous les exemples de requêtes peuvent être consultés sans risque dans les vues * Graph * et * Console *.

Pour réduire ou augmenter la plage de temps du graphique, cliquez sur les boutons * - * ou * + *. Pour déplacer l’heure de fin du graphique, appuyez sur les boutons * << * ou * >> *. Vous pouvez empiler un graphique en cochant la case * empilé *. Enfin, le * Res. (s) * input vous permet de spécifier une résolution de requête personnalisée (non nécessaire dans ce tutoriel).

Avant de commencer à interroger, examinons rapidement le modèle de données et la terminologie de Prometheus. Prometheus stocke fondamentalement toutes les données sous forme de série chronologique. Chaque série temporelle est identifiée par un nom de métrique, ainsi que par un ensemble de paires clé-valeur que Prometheus appelle labels. Le nom de la métrique indique l’aspect global d’un système mesuré (par exemple, le nombre de demandes HTTP traitées depuis le démarrage du processus, + http_requests_total +). Les étiquettes servent à différencier les sous-dimensions d’une métrique telle que la méthode HTTP (par ex. + method =" POST "+) ou le chemin (par ex. + path =" / api / foo "+). Enfin, une séquence d’échantillons forme les données réelles d’une série. Chaque échantillon comprend un horodatage et une valeur, les horodatages ayant une précision milliseconde et les valeurs étant toujours des valeurs à virgule flottante de 64 bits.

La requête la plus simple que nous pouvons formuler renvoie toutes les séries ayant un nom de métrique donné. Par exemple, le service de démonstration exporte une métrique + demo_api_request_duration_seconds_count + qui représente le nombre de demandes HTTP d’API synthétiques gérées par le service factice. Vous vous demandez peut-être pourquoi le nom de la métrique contient la chaîne + duration_seconds +. En effet, ce compteur fait partie d’une métrique plus large de l’histogramme nommée + demo_api_request_duration_seconds + qui suit principalement une distribution des durées de demandes mais expose également un nombre total de demandes suivies (suffixé par + _count + ici) comme sous-produit utile.

Assurez-vous que l’onglet de requête * Console * est sélectionné, entrez la requête suivante dans le champ de texte en haut de la page, puis cliquez sur le bouton * Exécuter * pour exécuter la requête:

Etant donné que Prometheus surveille trois instances de service, vous devriez voir une sortie tabulaire contenant 27 séries chronologiques résultantes avec ce nom de mesure, une pour chaque instance de service suivi, chemin, méthode HTTP et code de statut HTTP. Outre les étiquettes définies par les instances de service elles-mêmes (+ method +, + path +, et + status +), la série aura des étiquettes appropriées + job + et + + instance + qui distinguent les différentes instances de service. . Prometheus associe ces étiquettes automatiquement lors du stockage de séries chronologiques à partir de cibles récupérées. Le résultat devrait ressembler à ceci:

image: https: //assets.digitalocean.com/articles/prometheus_querying/api_requests.png [La demande d’API compte comme une sortie tabulaire]

La valeur numérique indiquée dans la colonne du tableau de droite est la valeur actuelle de chaque série temporelle. N’hésitez pas à représenter graphiquement la sortie (cliquez sur l’onglet * Graph *, puis à nouveau sur * Exécuter *) pour cette requête et les suivantes afin de voir comment les valeurs évoluent dans le temps.

Nous pouvons maintenant ajouter des corrélateurs d’étiquettes pour limiter les séries renvoyées en fonction de leurs libellés. Les identificateurs d’étiquette suivent directement le nom de la métrique entre accolades. Dans la forme la plus simple, ils filtrent les séries qui ont une valeur exacte pour une étiquette donnée. Par exemple, cette requête n’affichera que le nombre de requêtes pour les requêtes + GET +:

Les correspondants peuvent être combinés à l’aide de virgules. Par exemple, nous pourrions en outre filtrer les métriques uniquement à partir de l’instance + localhost: 8080 + et du travail + demo +:

Le résultat ressemblera à ceci:

image: https: //assets.digitalocean.com/articles/prometheus_querying/api_filtered.png [La demande d’API filtrée compte comme une sortie tabulaire]

Lors de la combinaison de plusieurs correspondants, tous doivent correspondre pour sélectionner une série. L’expression ci-dessus ne renvoie que le nombre de demandes d’API pour l’instance de service exécutée sur le port 8080 et où la méthode HTTP était + GET +. Nous veillons également à ne sélectionner que des mesures appartenant au travail + demo +.

Outre la correspondance d’égalité, Prometheus prend en charge la correspondance de non-égalité (+! = +), La correspondance d’expression régulière (+ + ~ ~ +), ainsi que la correspondance négative d’expression régulière (+! ~ +). Il est également possible d’omettre complètement le nom de la métrique et d’interroger à l’aide de correspondeurs d’étiquettes. Par exemple, pour répertorier toutes les séries (quel que soit le nom de métrique ou le travail) où le libellé + chemin + commence par + / api +, vous pouvez exécuter la requête suivante:

L’expression régulière ci-dessus doit se terminer par +. * + Car les expressions régulières correspondent toujours à une chaîne complète dans Prometheus.

La série chronologique résultante sera un mélange de séries avec différents noms de métriques:

image: https: //assets.digitalocean.com/articles/prometheus_querying/regex_matched.png [Série conforme à Regex en tant que sortie tabulaire]

Vous savez maintenant comment sélectionner des séries chronologiques par leurs noms de métrique, ainsi que par une combinaison de leurs valeurs d’étiquette.

Dans cette section, nous allons apprendre à calculer les taux ou les deltas d’une mesure au fil du temps.

Une des fonctions les plus fréquentes que vous utiliserez dans Prometheus est + rate () +. Plutôt que de calculer directement les taux d’événement dans le service instrumenté, Prometheus permet généralement de suivre les événements à l’aide de compteurs bruts et de laisser le serveur Prometheus calculer les taux ad-hoc pendant le temps de la requête (ce qui présente un certain nombre d’avantages, comme le fait de ne pas perdre de pics de taux. entre les éraflures, ainsi que de pouvoir choisir des fenêtres de moyenne dynamique au moment de la requête). Les compteurs commencent à «+ 0 » au démarrage d'un service surveillé et sont incrémentés de manière continue au cours de la durée de vie des processus de service. Parfois, lorsqu'un processus surveillé redémarre, ses compteurs se réinitialisent à « 0 +» et recommencent à monter. La représentation graphique des compteurs bruts n’est généralement pas très utile, car vous ne verrez qu’une ligne de plus en plus longue avec des réinitialisations occasionnelles. Vous pouvez voir cela en représentant graphiquement le nombre de demandes d’API du service de démonstration:

Cela ressemblera un peu à ceci:

image: https: //assets.digitalocean.com/articles/prometheus_querying/raw_counters.png [Représentation graphique de compteurs bruts]

Pour rendre les compteurs utiles, nous pouvons utiliser la fonction + rate () + pour calculer leur taux d’augmentation par seconde. Nous devons dire + rate () + sur quelle fenêtre de temps faire la moyenne du taux en fournissant un sélecteur de plage après le matcher de série (comme + [5m] +). Par exemple, pour calculer l’augmentation par seconde de la métrique de compteur ci-dessus, calculée en moyenne sur les cinq dernières minutes, tracez la requête suivante:

Le résultat est maintenant beaucoup plus utile:

image: https: //assets.digitalocean.com/articles/prometheus_querying/graphing_rates.png [Représentation graphique des compteurs]

+ rate () + est intelligent et ajuste automatiquement les réinitialisations de compteur en supposant que toute diminution de la valeur d’un compteur est une réinitialisation.

Une variante de + rate () + est + irate () +. Alors que + rate () + fait la moyenne du taux de tous les échantillons dans la fenêtre temporelle donnée (cinq minutes dans ce cas), + irate () + ne regarde jamais en arrière deux échantillons dans le passé. Vous devez toujours spécifier une fenêtre temporelle (telle que + [5m] +) pour savoir jusqu’où il convient de regarder dans le temps pour ces deux échantillons. + irate () + réagit plus rapidement aux changements de taux et est donc généralement recommandé pour une utilisation dans les graphiques. En revanche, + rate () + fournit des taux plus lisses et il est recommandé de les utiliser pour les expressions d’alerte (car les pics de taux courts seront atténués et ne vous réveilleront pas la nuit).

Avec + irate () +, le graphique ci-dessus ressemblerait à ceci, mettant en évidence de faibles creux intermittents dans les taux de demande:

image: https: //assets.digitalocean.com/articles/prometheus_querying/graphing_instant.png [Représentation graphique des taux instantanés de compteurs]

+ rate () + et + irate () + calculent toujours un taux par seconde. Parfois, vous voudrez connaître le montant total par lequel un compteur a augmenté au cours d’une fenêtre de temps mais reste correct pour les réinitialisations de compteur. Vous pouvez y parvenir avec la fonction + expand () +. Par exemple, pour calculer le nombre total de demandes traitées au cours de la dernière heure, interrogez:

Outre les compteurs (qui ne peuvent qu’augmenter), il existe des métriques de jauge. Les jauges sont des valeurs qui peuvent monter ou descendre avec le temps, comme une température ou un espace disque libre. Si nous voulons calculer les changements de jauges au fil du temps, nous ne pouvons pas utiliser la famille de fonctions + rate () + / + irate () + / + + + augment () +. Celles-ci sont toutes orientées vers les compteurs, car elles interprètent toute diminution de la valeur métrique comme une réinitialisation du compteur et la compensent. Au lieu de cela, nous pouvons utiliser la fonction + dériv () +, qui calcule la dérivée par seconde de la jauge sur la base d’une régression linéaire.

Par exemple, pour voir à quelle vitesse l’utilisation d’un disque fictif exporté par notre service de démonstration augmente ou diminue (en Mo par seconde) en fonction d’une régression linéaire des 15 dernières minutes, nous pouvons interroger:

Le résultat devrait ressembler à ceci:

image: https: //assets.digitalocean.com/articles/prometheus_querying/disk_usage.png [Représentation graphique de la dérivée de l’utilisation du disque]

Pour en savoir plus sur le calcul des deltas et des tendances dans les jauges, voir aussi http://prometheus.io/docs/querying/functions/#delta [+ delta () +] et http://prometheus.io/docs/ interrogation / fonctions / # prédire_linéaire [+ prédire_linéaire () +]].

Nous savons maintenant comment calculer les taux à la seconde avec un comportement de moyennage différent, comment les réinitialisations de compteur sont traitées dans les calculs de taux, ainsi que comment calculer les dérivées pour les jauges.

Dans cette section, nous allons apprendre à agréger des séries individuelles.

Prometheus collecte des données très détaillées, ce qui peut donner lieu à de nombreuses séries pour chaque nom de métrique. Cependant, souvent, vous ne vous souciez pas de toutes les dimensions et vous pouvez même avoir trop de séries pour les représenter toutes en même temps de manière raisonnable. La solution consiste à agréger certaines dimensions et à ne conserver que celles qui vous intéressent. Par exemple, le service de démonstration suit les requêtes HTTP de l’API avec + method +, + path + et + status +. Prometheus ajoute d’autres dimensions à cette métrique lors de son extraction à partir de l’exportateur de nœud: les étiquettes + instance + et + job + 'qui permettent de savoir à partir duquel les métriques ont été traitées. Maintenant, pour voir le taux de requête total sur toutes les dimensions, nous pourrions utiliser l’opérateur d’agrégation `+ sum () +:

Cependant, cela agrège sur all dimensions et crée une seule série de sortie:

image: https: //assets.digitalocean.com/articles/prometheus_querying/summing.png [Résumant toutes les dimensions de taux de demande]

Cependant, vous souhaiterez généralement conserver quelques-unes des dimensions de la sortie. Pour cela, + sum () + et d’autres agrégateurs prennent en charge une clause + without (<noms de libellés>) + qui spécifie les dimensions à agréger. Il existe également une alternative en face de la clause + by (<noms de libellés>) + qui vous permet de spécifier les noms de libellés à conserver. Si nous voulions connaître le débit total des demandes totalisé sur les trois instances de service et tous les chemins, mais en divisant le résultat par la méthode et le code d’état, nous pourrions interroger:

Ceci est équivalent à:

La somme résultante n’est pas groupée par + instance,` + chemin` et + job:

image: https: //assets.digitalocean.com/articles/prometheus_querying/preserving.png [Préserver certaines dimensions lors de la somme]

Prometheus prend en charge les opérateurs d’agrégation suivants, chacun prenant en charge une clause + by () + ou + without () + pour sélectionner les dimensions à conserver:

Vous avez maintenant appris à agréger une liste de séries et à ne conserver que les dimensions qui vous tiennent à cœur.

Dans cette section, nous allons apprendre à faire de l’arithmétique dans Prométhée.

Comme exemple d’arithmétique le plus simple, vous pouvez utiliser Prométhée comme calculatrice numérique. Par exemple, exécutez la requête suivante dans la vue * Console *:

Vous obtiendrez une valeur de sortie scalaire unique de «+ 33 +»:

image: https: //assets.digitalocean.com/articles/prometheus_querying/scalar.png [Résultat arithmétique scalaire]

Une valeur scalaire est une simple valeur numérique sans étiquette. Pour rendre cela plus utile, Prometheus vous permet d’appliquer des opérateurs arithmétiques courants (+, + - +, + * +, + / +, `+ + + +) à des vecteurs de séries temporelles entières. . Par exemple, la requête suivante convertit le nombre d’octets traités par un dernier travail de traitement par lots simulé exécuté en MiB:

Le résultat sera affiché en MiB:

image: https: //assets.digitalocean.com/articles/prometheus_querying/mib.png [Octets traités convertis par le MiB]

Il est courant d’utiliser une arithmétique simple pour ces types de conversions d’unités, bien que de bons outils de visualisation (comme Grafana) gèrent également les conversions pour vous.

Une spécialité de Prométhée (et là où Prométhée brille vraiment!) Est l’arithmétique binaire entre deux séries chronologiques. Lorsqu’un opérateur binaire est utilisé entre deux séries de séries, Prometheus sélectionne automatiquement les éléments dont les ensembles d’étiquettes sont identiques à gauche et à droite de l’opération et applique l’opérateur à chaque paire correspondante pour produire la série en sortie.

Par exemple, la métrique + demo_api_request_duration_seconds_sum + nous indique combien de secondes ont été consacrées à répondre aux requêtes HTTP, tandis que + demo_api_request_duration_seconds_count + nous indique comment étaient les requêtes many HTTP. Les deux métriques ont les mêmes dimensions (+ méthode n,` + chemin + , + statut`, + instance,` + travail`). Pour calculer le temps de latence moyen des demandes pour chacune de ces dimensions, il suffit de demander le rapport entre le temps total passé en demandes et le nombre total de demandes.

Notez que nous encapsulons également une fonction + rate () + autour de chaque côté de l’opération pour ne prendre en compte que le temps d’attente pour les demandes survenues au cours des 5 dernières minutes. Cela ajoute également de la résilience contre les réinitialisations de compteur.

Le graphique de latence de requête moyen résultant devrait ressembler à ceci:

image: https: //assets.digitalocean.com/articles/prometheus_querying/average_latency.png [Représentation graphique du temps de latence moyen d’une demande]

Mais que faisons-nous lorsque les étiquettes ne correspondent pas exactement des deux côtés? Cela se produit surtout lorsque nous avons des séries chronologiques de tailles différentes des deux côtés de l’opération, car un côté a plus de dimensions que l’autre. Par exemple, le travail de démonstration exporte le temps CPU fictif utilisé dans différents modes (+ idle, + + utilisateur`,` + système`) en tant que métrique + demo_cpu_usage_seconds_total + avec la dimension de libellé + mode +. Il exporte également un nombre total de CPU fictif sous la forme + demo_num_cpus + (aucune dimension supplémentaire sur cette métrique). Si vous tentez de diviser l’un par l’autre pour obtenir l’utilisation moyenne du processeur en pourcentage pour chacun des trois modes, la requête ne produira aucun résultat:

Dans ces correspondances un à plusieurs ou plusieurs à un, nous devons indiquer à Prometheus le sous-ensemble d’étiquettes à utiliser pour la correspondance, et nous devons également spécifier comment gérer la dimension supplémentaire. Pour résoudre la correspondance, nous ajoutons une clause + on (<noms de libellés>) + à l’opérateur binaire qui spécifie les libellés pour lesquels une correspondance doit être établie. Pour étoffer et regrouper le calcul en fonction des valeurs individuelles des dimensions supplémentaires du grand côté, nous ajoutons une clause + group_left (<noms de libellés>) + ou + group_right (<noms de libellés>) + qui répertorie les dimensions supplémentaires à gauche ou à droite, respectivement.

La requête correcte dans ce cas serait:

Le résultat devrait ressembler à ceci:

image: https: //assets.digitalocean.com/articles/prometheus_querying/average_cpu.png [Représentation graphique de l’utilisation moyenne du processeur par mode]

Le + sur (travail, instance) + indique à l’opérateur de ne faire correspondre que les séries de gauche et de droite sur leurs libellés + job + et + instance + (et donc pas sur le libellé + mode +, ce qui ne à droite), tandis que la clause + group_left (mode) + indique à l’opérateur de s’aérer et d’afficher une moyenne d’utilisation du processeur par mode. Ceci est un cas de correspondance plusieurs à un. Pour effectuer la correspondance inverse (un à plusieurs), utilisez une clause + group_right (<noms de libellés>) + de la même manière.

Vous savez maintenant comment utiliser l’arithmétique entre des séries de séries temporelles et comment traiter des dimensions variables.

Dans ce didacticiel, nous avons configuré un groupe d’instances de service de démonstration et les avons surveillées avec Prometheus. Nous avons ensuite appris comment appliquer diverses techniques d’interrogation aux données collectées pour répondre aux questions qui nous intéressent. Vous savez maintenant comment sélectionner et filtrer des séries, comment agréger des dimensions, ainsi que pour calculer des taux, des dérivés ou des calculs arithmétiques. Vous avez également appris à aborder la construction de requêtes en général et à éviter de surcharger votre serveur Prometheus.

Pour en savoir plus sur le langage de requête de Prometheus, notamment sur la manière de calculer les centiles à partir d’histogrammes, sur la gestion des métriques basées sur l’horodatage ou sur la recherche de la santé des instances de service, rendez-vous à l’adresse https://www.digitalocean.com/community/. tutoriels / procédure à suivre-Prométhée sur Ubuntu-14-04-partie-2 [Comment interroger Prométhée sur Ubuntu 14.04, partie 2].