Je consomme diverses métriques de jauge de Kafka à Prometheus à l'aide d'une application python personnalisée. Les métriques doivent être consommées plus ou moins dans le même temps (millisecondes). Je ne parviens à supprimer que la dernière métrique de l'exemple ci-dessous, car les trois premières sont immédiatement écrasées.
my_metric_aaa_111{labelA = "aaa", labelB = "111"} 8
Je peux supprimer les quatre métriques en leur attribuant un nom de métrique unique, par exemple:
my_metric{labelA = "aaa", labelB = "111"} 8
my_metric{labelA = "aaa", labelB = "222"} 12
my_metric{labelA = "bbb", labelB = "111"} 7
**my_metric{labelA = "bbb", labelB = "222"} 15**
mais cela ne semble pas être la meilleure pratique et travailler avec de telles métriques est très difficile en général plus tard dans Grafana.
Je peux aussi pousser les métriques en série pour être mis au rebut et réduire l'intervalle de mise au rebut dans la configuration de Prometheus, mais cela va à l'encontre de l'idée générale de la solution.
En dehors des suggestions dont je ne suis absolument pas conscient - est-il possible de garder pour Prometheus la même métrique à mettre au rebut où seules les valeurs d'étiquette diffèrent? La seule discussion que j'ai trouvée à ce sujet est ici sans réponse: https://github.com/prometheus / pushgateway / issues / 65 .
Si ce qui précède n'est pas possible, puis-je en quelque sorte fusionner / joindre / combiner le nom des métriques plus tard dans Prometheus / Grafana pour pouvoir travailler avec elles en fonction de leurs étiquettes? Cela signifie-t-il supprimer la terminaison inutile _aaa_111 dans l'exemple ci-dessus pour travailler avec tout comme une seule métrique?
3 Réponses :
Vous pouvez modifier le nom de la tâche Pushgateway, en utilisant une combinaison d'étiquettes ou une valeur unique. Ainsi, prometheus pourrait récupérer toutes vos métriques, et elles ne sont pas écrasées par d'autres.
Dans votre cas, si vous exportez: my_metric {labelA = "aaa", labelB = "111"} 8 vers une tâche appelée, some_job_aaa_111 .
Vous pouvez tester manuellement l'envoi de certaines métriques: echo "my_metric {labelA = \" aaa \ ", labelB = \" 111 \ "} 8" | curl --data-binary @ - http: // localhost: 9091 / metrics / job / some_job_aaa_111
Dans le pushgateway Prometheus, vous verriez le suivant:
Dans Prometheus, le travail pushgateway, devient dans une étiquette que vous pouvez facilement ignorer, comme la prochaine sortie de Prometheus:
Merci Asier - cela semble fonctionner :) J'essayais de contourner le problème et j'ai concaténé chaque nom de métrique à partir des valeurs d'étiquette par exemple. my_metric_aaa_111 {labelA = "aaa", labelB = "111"} 8 puis dans Grafana, utilisez regex comme {__name __ = ~ "my_metrics. +", labelA = "aaa"} qui fonctionne également mais intuitivement, votre solution est plus efficace. Le cas principal est l'application python qui a besoin d'une refonte, mais c'est un sujet différent.
Autre solution : rendez l'action de scraping plus fréquemment répétitive en utilisant l'attribut scrape_interval sur prometheus.yml . Si vous vous basez sur les minutes, convertissez-le en secondes ou en millisecondes pour éviter les conditions de concurrence.
- job_name: 'pushgateway'
honor_labels: true
scrape_interval: 50ms
metrics_path: /metrics
static_configs:
- targets:
- localhost:9091
Vous pouvez également avoir différentes clés de regroupement lorsque vous poussez vers la passerelle push (et cela sera plus beau que d'avoir le même préfixe et des suffixes différents pour les noms de travail)
Qu'entendez-vous par «les trois premiers sont immédiatement écrasés»? une métrique est identifiée de manière unique par son nom et l'ensemble d'étiquettes . Dans votre exemple, ce sont quatre métriques différentes et seront analysées en tant que telles.
Merci @Michael de m'avoir indiqué la bonne direction. Si pour Prometheus les quatre métriques sont considérées comme uniques, je devrai me pencher sur l'application de producteur python pour découvrir ce qui ne va pas.