web-dev-qa-db-fra.com

augmenter () dans Prométhée double parfois les valeurs: comment éviter?

J'ai trouvé que pour certains graphiques, j'obtiens des valeurs doubles de Prometheus où devraient être juste celles:

Graph with twos above bars

Requête que j'utilise:

increase(signups_count[4m])

L'intervalle de raclage est réglé sur maximum recommandé de 2 minutes.

Si je recherche les données réelles stockées:

curl -gs 'localhost:9090/api/v1/query?query=(signups_count[1h])'

"values":[
     [1515721365.194, "579"],
     [1515721485.194, "579"],
     [1515721605.194, "580"],
     [1515721725.194, "580"],
     [1515721845.194, "580"],
     [1515721965.194, "580"],
     [1515722085.194, "580"],
     [1515722205.194, "581"],
     [1515722325.194, "581"],
     [1515722445.194, "581"],
     [1515722565.194, "581"]
],

Je vois qu'il n'y a eu que deux augmentations. Et en effet, si je demande ces temps, je vois un résultat attendu:

curl -gs 'localhost:9090/api/v1/query_range?step=4m&query=increase(signups_count[4m])&start=1515721965.194&end=1515722565.194'

"values": [
     [1515721965.194, "0"],
     [1515722205.194, "1"],
     [1515722445.194, "0"]
],

Mais Grafana (et Prometheus dans l'interface graphique) a tendance à définir un step différent dans les requêtes, avec lequel j'obtiens un résultat très inattendu pour une personne peu familière avec le fonctionnement interne de Prometheus.

curl -gs 'localhost:9090/api/v1/query_range?step=15&query=increase(signups_count[4m])&start=1515721965.194&end=1515722565.194'

... skip ...
 [1515722190.194, "0"],
 [1515722205.194, "1"],
 [1515722220.194, "2"],
 [1515722235.194, "2"],
... skip ...

Sachant que increase() est juste n sucre syntaxique pour un cas d'utilisation spécifique de la fonction rate() , je suppose que c'est ainsi que cela est censé fonctionner compte tenu de la conditions.

Comment éviter de telles situations? Comment faire en sorte que Prometheus/Grafana me montre un pour un et deux pour deux, la plupart du temps? Autre qu'en augmentant l'intervalle de raclage (ce sera mon dernier recours).

Je comprends que Prométhée n'est pas un type exact d'outil , donc ça me convient si j'aurais un bon pas toujours, mais la plupart du temps.

Que manque-t-il d'autre ici?

prometheus
14
sanmai

Ceci est connu sous le nom de aliasing et est un problème fondamental dans le traitement du signal. Vous pouvez améliorer cela un peu en augmentant votre taux d'échantillonnage, une plage de 4 m est un peu courte avec une plage de 2 m. Essayez une portée de 10 m.

Ici, par exemple, la requête exécutée à 1515722220 ne voit que les échantillons [email protected] et [email protected]. C'est une augmentation de 1 sur 2 minutes, qui extrapolé sur 4 minutes est une augmentation de 2 - ce qui est comme prévu.

Tout système de surveillance basé sur des métriques aura des artefacts similaires, si vous voulez une précision de 100%, vous avez besoin de journaux.

15
brian-brazil

increase() doublera toujours (approximativement) l'augmentation réelle avec votre configuration.

La raison en est que (comme actuellement mis en œuvre):

  1. increase() est (comme vous l'avez observé) du sucre syntaxique pour rate() c'est-à-dire que c'est la valeur qui serait renvoyée par rate() multipliée par le nombre de secondes dans la plage que vous spécifié. Dans votre cas, c'est rate() * 240.
  2. rate() utilise l'extrapolation dans son calcul. Dans la grande majorité des cas, une plage de 4 minutes renvoie exactement 2 points de données, presque exactement à 2 minutes d'intervalle. Le taux est ensuite calculé comme la différence entre le dernier et le premier (c'est-à-dire les 2 points dans votre cas) divisée par la différence de temps des 2 points (environ 120 secondes dans 99,99% des cas) multipliée par la plage que vous avez demandée (exactement 240 secondes ). Donc si l'augmentation entre les 2 points est nulle, le taux est nul. Si l'augmentation entre les 2 points est 1.0, La rate() calculée sera proche de 2.0 / 240 Et, par conséquent, la increase() sera 2.0.

Cette approche fonctionne généralement bien avec des compteurs qui augmentent en douceur (par exemple, si vous avez un nombre d'inscriptions plus ou moins fixe toutes les 2 minutes). Mais avec un compteur qui augmente rarement (tout comme votre compteur d'inscriptions) ou un compteur hérissé (comme l'utilisation du processeur), vous obtenez des surestimations étranges (comme l'augmentation de 2 que vous voyez).

Vous pouvez essentiellement inverser la mise en œuvre de Prometheus et obtenir (quelque chose de très proche) l'augmentation réelle en multipliant avec (requested_range - scrape interval) Et en divisant par requested_range, En reculant essentiellement l'extrapolation que Prometheus fait.

Dans votre cas, cela signifierait

increase(signups_count[4m]) * (240 - 120) / 240

ou, plus succinctement,

increase(signups_count[4m]) / 2

Il vous oblige à être conscient à la fois de la longueur de la plage et de l'intervalle de raclage, mais il vous donnera ce que vous voulez: "un pour un et deux pour deux, la plupart du temps". Parfois, vous obtiendrez 1.01 Au lieu de 1.0 Parce que les éraflures étaient à 119 secondes, pas à 120 secondes d'intervalle et parfois, si votre évaluation est étroitement alignée avec l'éraflure, certains points à droite sur la frontière pourraient être inclus ou non dans un calcul de point de données, mais c'est toujours une meilleure réponse que 2.0.

4
Alin Sînpălean