Grafana: Graphique: limites de l'échelle automatique Y (min max)

Merci, idée intéressante. Semble un petit cas de bord. Mais je suis d'accord, pourrait être utile à certains moments.

Ouais, je voulais juste avoir mes pensées sur papier. :Bière:

Je ne pense pas que ce soit un cas extrême.
Réglez AutoScale vers le haut. Définissez 0-100 comme valeur minimale, mais laissez le graphique évoluer aussi grand qu'il le souhaite. Cela a semé la panique à plusieurs reprises parmi les directeurs et les vice-présidents jusqu'à ce que je leur fasse voir l'échelle à laquelle il se trouvait.

+1 Une grande partie des données de séries chronologiques que je visualise dans grafana se trouve à zéro + bruit, ce qui rend les graphiques désordonnés et peu clairs.

+1 d'un utilisateur Grafana.net.

L'échelle minimale aiderait pour des choses comme les interfaces réseau, où certains de nos liens privés / VPN sont inactifs (~ 20 ko / s) mais lorsqu'ils sont utilisés, ils sont de 50 à 100 Mo / s. Si je règle l'échelle à 100 Mo / s et que c'est fini, je ne sais pas et si je la règle à 200 Mo / s, je ne peux pas voir clairement les données alors qu'elles ne sont que de 5 à 10 Mo / s.

Je comprends que cette fonction n'est probablement utile que pour très peu de personnes. Mais j'ai un peu piraté ça. Et j'ai trouvé quelque chose qui fonctionne pour moi. Le commit dans mon fork ajoute une boîte Y-Span à l'onglet Axes.

Où X est un entier ou un flottant:

~X Span X around average
=X Span X around current value
>X Span is atleast X
<X Span is clamped to X

https://github.com/thoj/grafana/commit/7dcdccbd42e9f63b7388e439f7194fe7ead8039a

Exemple de pourquoi j'en ai besoin:

Un intérêt pour un PR?

@thoj Ce serait un excellent ajout. Nous utilisons des seuils pour certains graphiques et aimerions toujours les afficher, mais toujours en mettant à l'échelle le graphique pour afficher des points bien supérieurs au seuil. "> X" fonctionnerait bien ici (et

@lpalm Ouais! Je vais ajouter une pull request pour essayer de lancer la discussion,

implémenté dans https://github.com/grafana/grafana/pull/6051

Est-ce dans le train de versions 4.0.x? J'essaye d'utiliser "<" et ">" dans les paramètres de l'axe Y mais en vain.

pas eu à le retourner, nous voulions une entrée / une interface utilisateur plus conviviale que simplement une fonctionnalité cachée que le champ de saisie prend en charge des expressions telles que > et < , nous avons donc rétabli la fonctionnalité en attendant le temps de comprendre l'interface utilisateur

Pourrions-nous avoir cela dans une boîte de dépôt en plus de Y-min et Y-max?

Salut,

J'ai créé cette fonctionnalité pour un projet graphite il y a quelque temps et suis arrivé à la conclusion suivante que je ne voudrais jamais utiliser yMax , car je veux toujours connaître les valeurs du graphique, ce que je ne ferai pas avec yMax .
Y a-t-il quelqu'un qui pense que yMax est une fonction utile ou yMax devrait- repensé pour fonctionner comme minYMax ?

Je veux dire, si je règle yMax sur x et que le compteur dépasse x, est- ce que quelqu'un ne voudrait pas voir à quel point il dépasse la limite?

J'utilise yMax quand j'ai des pourcentages pour m'assurer que le 100% est toujours exactement en haut du graphique (même s'il y a un petit bribe)

J'ai également besoin de yMax. Cela est dû à certains signaux bruyants qui ont des pointes très hautes qui déforment les graphiques.

@iksaif oui, mais cela ne devrait pas exiger que yMax soit corrigé. Puisque votre graphique ne dépassera jamais 100% et que votre yMax dynamique serait alors 100% votre graphique aurait exactement le même aspect qu'avec l'implémentation actuelle de yMax ?

@thoj cela ne ressemble pas à une métrique fiable? Ne voudriez-vous pas plutôt que ces pics soient exclus du graphique ou si vous vous souciez d'eux, connaissez-vous réellement la valeur?

@Kvistian ils le feraient, il arrive, pour des raisons, qu'il affiche 100,02%, et j'aime le fait que je puisse plafonner cela.

Il y a aussi des moments où je veux seulement voir quand je veux "zoomer" et je peux utiliser yMax pour le faire.

Ok, mais vous êtes d'accord sur le fait que la plupart des cas nécessiteraient un yMax dynamique? Dans ce cas, serait-il judicieux de rendre le yMax dynamique et une nouvelle fonction comme staticYMax ou fixedYMax pour ces cas yMax dynamique par défaut puisque c'est le cas d'utilisation général.

On dirait que définir la limite inférieure du haut du graphique pourrait être utile, mais je ne changerais pas la sémantique du yMax existant (qui est vraiment le y maximum qui peut être affiché).

Il serait intéressant de savoir comment cette chose est nommée dans d'autres logiciels similaires

@Kvistian Tout le monde ne veut pas utiliser grafana pour afficher uniquement de jolies métriques propres à partir de serveurs. Je souhaite afficher les métriques des processus physiques qui sont bruyants et peuvent parfois renvoyer des données étranges. Voir mes exemples et explications ici: https://github.com/grafana/grafana/pull/5720

@thoj Je n'ai pas suggéré de le supprimer si c'est une fonctionnalité utile, je me suis simplement demandé si c'était le cas. Mais il semble qu'il existe des cas d'utilisation pour cela, donc dans ce cas, il ne devrait pas être supprimé. Mais personnellement, je pense qu'il devrait y avoir plus de cas où vous souhaiteriez un yMax dynamique. Quand je suis tombé sur le problème avec le graphite, j'ai en fait supposé que yMax résoudrait mon problème (puisque je ne voyais aucun cas utile pour un yMax statique

Je ne me soucie pas vraiment de savoir si cela s'appelle yMax ou minYMax , je pensais juste que yMax ressemblait plus à une fonction default qui devrait résoudre le cas d'utilisation le plus courant.

J'affiche une valeur d'état de charge de la batterie (SOC) et j'aimerais vraiment pouvoir définir une limite supérieure et inférieure tout en préservant la mise à l'échelle automatique dans ces limites.

Voici quelques images du problème auquel je suis confronté en définissant ou non la valeur Y-Max.

Si je ne définit pas la valeur Y-Max, le graphique montre les valeurs SOC sur l'échelle Y> 100%, ce qui ne se produira jamais. En d'autres termes, dans le cas de l'état de charge de la batterie:

0% <= y_scale_values <= 100%

Si je _do_ définit la valeur Y-Max, alors lorsque j'ai des valeurs SOC faibles pendant longtemps, le graphique ne se met pas à l'échelle automatiquement, comme le montre l'image ci-dessous.

Ce que je voudrais, c'est pouvoir définir une limite supérieure (100%) et inférieure (0%) tout en conservant la mise à l'échelle automatique du tracé dans ces limites, comme c'est le cas au moment où les limites Y ne sont pas définies.

Il suffit d'ajouter notre cas d'utilisation. Nous surveillons un site Web et avons un niveau de base de trafic de vérification de l'état de santé pour les instances `` fonctionnelles '', que j'aimerais afficher sous forme de ligne graphique `` basse '' (par exemple, 0,1 requête / s mais l'axe serait au minimum de 1, tandis que permettant toujours à l'axe du graphique de se mettre à l'échelle lorsque le trafic «réel» arrive.

Il y a un hack pour avoir une valeur maximale minimale de l'axe Y.

Créez une métrique Baseline pour l'échelle minimale souhaitée. Ici, j'ai choisi 1s pour le temps CPU:

Ajoutez des remplacements pour la métrique de base pour la faire disparaître du graphique:

C'est ça.

Le seul inconvénient est que vous pouvez voir la ligne de base de votre survol:

J'en ai également besoin pour l'affichage IO.

par exemple, la vitesse de lecture peut être de 50 kb / min ou 500 Mo / min, la définition d'une échelle minimale - par exemple 100 Mo / min par défaut rendrait mes graphiques beaucoup plus cohérents.

+1
S'il vous plaît?

@dstensnes Veuillez ne pas laisser de commentaires de ce formulaire sur les problèmes de GitHub. Vous pouvez ajouter une réaction à la publication initiale pour montrer que vous aimeriez cette fonctionnalité. Lorsque vous commentez des +1, toutes les personnes qui suivent ce problème reçoivent un e-mail de notification sans aucune information pertinente. C'est simplement une mauvaise forme.

D'accord, je peux vivre avec ça :) Est-ce que quelqu'un regarde les réactions? J'ai remarqué maintenant que vous pouvez trier sur la quantité de réactions, donc c'est au moins quelque chose. Merci

Je pense que les cas d'utilisation de la plupart des gens seraient couverts en ajoutant une case à cocher «limite souple» à côté des champs Y-Min et Y-Max. Si vous déplacez Y-Max vers la ligne suivante, il devrait y avoir suffisamment d'espace à la fois pour la case à cocher et pour l'étiquette, et la fonctionnalité devrait être assez explicite :)

Je ne sais pas comment cela peut être considéré comme un cas de pointe, la principale application que nous avons est le trafic réseau, mais sur la plupart des graphiques, vous ne voulez pas voir de petites valeurs affichées sous forme de "montagnes".

existe-t-il actuellement une solution de contournement pour ce faire?

Des mises à jour à ce sujet? Cela rend très difficile la mise en place de bons tableaux de bord.

Une idée d'interface utilisateur serait d'avoir:

• YMax (soft) - Le haut du graphique s'étend toujours au moins ici
• YMax (dur) - Le haut du graphique ne s'étend jamais au-delà d'ici
• YMin (soft) - Le bas du graphique s'étend toujours au moins ici
• YMin (difficile) - Le bas du graphique ne s'étend jamais au-delà d'ici

Une autre prise sur celui-ci pourrait être une étendue minimale pour l'axe Y définissant que l'intervalle entre le courant Y-bas et Y-haut ne devrait jamais être inférieur à la valeur donnée. De cette façon, le rendu est libre de définir où l'axe des y doit commencer et se terminer - et en même temps éviter les changements mineurs dans les valeurs à rendre comme des montagnes.

Je trouve aussi que c'est un problème très courant avec les données bruyantes et la plupart des données sont bruyantes.

Je pense que le vrai problème est que les valeurs aberrantes faussent l'échelle de l'axe Y, faisant disparaître tout le reste. La façon dont je vois la bonne solution est de permettre à la plage de l'axe Y d'être dynamique en fonction des données affichées tout en réduisant les valeurs aberrantes extrêmes. La meilleure façon de procéder serait de baser la plage sur les écarts types par rapport à la moyenne des données affichées. Par exemple, si vous définissez 1 écart type sur tout ce qui est supérieur à 1 écart type au-dessus de la moyenne, le graphique sera rogné. C'est à la fois facile à configurer, peut facilement être calculé du côté client, donc cela ne dépend pas de la source de données et serait raisonnablement facile à comprendre pour les gens.

Depuis près de 2 ans:

rétabli la fonctionnalité en attendant le temps de comprendre l'interface utilisateur

Veuillez ramener > et < pendant qu'une meilleure interface utilisateur est envisagée.

J'attends désespérément une fonctionnalité comme celle qui a été supprimée il y a 2 ans!

Même les graphiques modélisés qui surveillent la même métrique sur différents systèmes, côte à côte, donnent des images inexactes car les échelles sont automatiquement ajustées indépendamment en fonction des données actuelles du graphique.

Il y a un hack pour avoir une valeur maximale minimale de l'axe Y.

Créez une métrique Baseline pour l'échelle minimale souhaitée. Ici, j'ai choisi 1s pour le temps CPU:

Ajoutez des remplacements pour la métrique de base pour la faire disparaître du graphique:

C'est ça.

Le seul inconvénient est que vous pouvez voir la ligne de base de votre survol:

Pour ceux qui lisent les solutions utiles de baseline des info-bulles dans le remplacement.

@bobrik @ sb3tcs Bonjour, j'aimerais utiliser votre solution de contournement, mais Grafana se retrouve avec une erreur de syntaxe de requête si tout ce que je mets dans la requête est juste 20 ou un autre nombre. Comment créer la métrique de base? Ou mon Grafana 5.1 est-il trop ancien pour prendre en charge ce type de requête?

J'ai utilisé des fonctions chaînées sur une deuxième requête pour empêcher les graphiques de zoomer trop sur l'axe des y.
Dans cet exemple, je trace le graphique des utilisateurs connectés à partir de plusieurs serveurs dans un graphique.

J'ai ajouté une requête supplémentaire avec les mêmes points de données:
offset (-20) aggregateBy (1m, min) removeBelowValue (0) setAlias ​​(hidden_min)

Cela change le zoom dynamique de
min à max
à
min-20 (sans entrer dans les négatifs) jusqu'à max

Pour masquer le faux graphique:
remplacement de la visualisation avec l'expression régulière "/hidden_.*/"
Lignes: faux
Légende: faux
Masquer dans l' info-bulle: vrai

Vous pourriez probablement même synchroniser l'axe des y entre plusieurs graphiques. Comme un panneau par serveur et collectez le min / max à partir des points de données de tous les serveurs de chaque panneau.

J'ai trouvé une autre solution de contournement. Je viens d'ajouter une série de temps min et max avec les balises min et max. La ligne était comme ça
weather,sensorID=min temperature=0
weather,sensorID=max temperature=20
Ceux-ci sont ajoutés au graphique et cachés comme mentionné ci-dessus. Le seul problème est que vous devez l'injecter régulièrement.
Voici à quoi cela ressemble, il peut être nécessaire de régler la température maximale sur 19 afin qu'il ajuste automatiquement l'axe à 20.

Edit: insérez au maximum 19 et cela a fonctionné.

Je suis tombé sur ce fil à la recherche d'une solution pour définir un y-max flexible dans Grafana. Pour mon cas d'utilisation, je représente graphiquement la latence et le volume des demandes pour une API. Je veux définir un y-max flexible à environ 500 ms (0,5 seconde), afin de mieux voir la nuance des appels à faible latence en excluant les valeurs aberrantes pointues et en ajustant automatiquement le y-max lorsque la latence maximale est inférieure ce seuil.

J'ai essayé de régler: y-min à 0 et y-max à <0,5, mais mon axe y disparaît complètement ou ignore le y-min. Ce problème s'est produit indépendamment de la représentation graphique de la latence et des requêtes de volume de demande ensemble / séparément. Y a-t-il eu de nouveaux progrès sur cette question? Ce serait vraiment bénéfique pour mon équipe.

J'inclus quelques captures d'écran de mon graphique avec y-max configuré différemment (chaque cas est étiqueté par le titre du graphique)

si vous ne voulez pas représenter graphiquement des valeurs supérieures à 500 ms, vous pouvez essayer d'utiliser removeAboveValue (0.5)
puis indiquez au graphique comment les valeurs nulles doivent être gérées

aucun indice s'il existe un moyen d'utiliser les paramètres calculés pour cette fonction

Une solution de contournement de base légèrement plus à jour est la suivante:

Cela empêche la requête de base d'apparaître dans le graphique, la légende et l'info-bulle de survol, et l'empêche également de provoquer des problèmes d'empilement.

Ce n'est pas vraiment un cas de pointe, mais plutôt un cas très courant. Je pense en fait que c'est très souvent que l'on veut un axe y avec des valeurs min / max "douces". La raison principale de la définition de l'échelle de l'axe y est que l'on souhaite l'aligner avec la plage de données attendue, et également avoir plusieurs graphiques avec l'axe y aligné afin de pouvoir facilement comparer les valeurs.

Il serait intéressant de savoir comment cette chose est nommée dans d'autres logiciels similaires

Highchartjs l'appelle softMin / softMax.
https://api.highcharts.com/highcharts/yAxis

AnyChart l'appelle soft min / max.
https://docs.anychart.com/Axes_and_Grids/Scales#soft

Chartjs a l'option "suggéréMin / Max" pour gérer ce cas d'utilisation.
https://www.chartjs.org/docs/latest/axes/cartesian/linear.html#axis -range-settings

amCharts les appelle min / max et strictMin / Max.
https://www.amcharts.com/docs/v4/reference/valueaxis/#strictMinMax_property

RRDtool par exemple a des limites "soft" par défaut quand on utilise la mise à l'échelle automatique, mais a une option appelée rigid qui force des limites "strictes" sur l'échelle.

[-u | - valeur limite supérieure] [-l | - valeur limite inférieure] [-r | --rigid] [--allow-shrink]

Par défaut, le graphique sera mis à l'échelle automatiquement afin d'ajuster l'axe y à la plage des données. Vous pouvez modifier ce comportement en définissant explicitement les limites. L'axe y affiché va alors au moins de la limite inférieure à la limite supérieure. L'autoscaling permettra toujours d'étirer ces limites à moins que l'option rigide ne soit définie. allow-shrink modifie le comportement de rigide en autorisant la réduction automatique de l'échelle, le graphique ne dépassera pas les limites spécifiées par l'utilisateur.
https://oss.oetiker.ch/rrdtool/doc/rrdgraph.en.html

Tableau a une fonctionnalité permettant d'autoriser une plage d'axe uniforme pour toutes les lignes ou colonnes, et vous pouvez choisir de ne le faire que pour l'axe y, par exemple. Cela résout le problème d'une manière légèrement différente, mais c'est toujours le même cas d'utilisation où l'on veut que plusieurs graphiques aient la même plage / échelle d'axe.

Bien qu'une grande partie de la discussion à ce sujet se soit concentrée sur la mise en œuvre de valeurs minimales et maximales douces séparées pour la mise à l'échelle, je pense qu'il y a beaucoup de valeur à implémenter une fonction de "plage d'axe y minimale" dans le cadre de cela, distincte de la " "min / max, comme l'a suggéré l'affiche originale. Les minimums et maximums souples seraient utilisés pour spécifier des positions fixes sur l'axe y qui doivent toujours être visibles pendant la mise à l'échelle automatique. Cela peut être utilisé lorsque vous avez une plage connue de valeurs de l'axe y que vous souhaitez toujours voir visible, ce qui est utile pour éviter que de petites variations n'apparaissent sous forme de pics et de creux exagérés en raison de l'effet de zoom de la mise à l'échelle automatique. Cependant, cela ne fonctionne que si vous savez quelles seront ces valeurs de l'axe des y au moment de la conception, ce qui n'est pas toujours le cas, en particulier pour les personnes qui créent des modèles à utiliser par les utilisateurs finaux qui peuvent avoir différents modèles de matériel et de charge.

Une option de plage minimale de l'axe y pour la mise à l'échelle automatique supprimerait cette exigence. Lorsqu'il est utilisé sur un ensemble de valeurs où la plage des données (c'est- abs(max(Y)-min(Y)) dire

Petit morceau de pseudo-code pour démontrer le calcul:

minRange = 25
dataRange = abs(max(Y)-min(Y))
if dataRange < minRange:
    yAxisExtension = (minRange - dataRange) / 2
    yAxisMin = min(Y) - yAxisExtension
    yAxisMax = max(Y) + yAxisExtension

Cette approche ne repoussera pas les valeurs aberrantes de l'échelle, comme le ferait un centrage sur la moyenne.

À titre d'exemple de cas d'utilisation, imaginez que vous concevez un tableau de bord pour surveiller les données de NUT / upsd et que vous créez le graphique de consommation d'énergie. Alors que mon onduleur peut en moyenne 400W, celui de quelqu'un d'autre peut en moyenne 100W ou 1000W, selon à quoi ressemble sa configuration matérielle. Il n'est pas possible de le savoir à l'avance. La quantité d'énergie consommée est généralement assez constante sur une courte échelle de temps, ce qui signifie qu'elle est sujette à une exagération sur l'axe y lors de la mise à l'échelle automatique. Il s'agit d'un cas d'utilisation parfait pour une plage minimale de l'axe y, dans laquelle vous pouvez faire des hypothèses raisonnables sur l'échelle de la variance sur une période donnée, mais pas sur l'ampleur de la valeur absolue.

Si un capteur a une résolution limitée, tout ce que vous voyez est le bruit de quantification lorsque la quantité varie très peu dans l'intervalle de temps sélectionné. Je voudrais par exemple voir une portée y minimale pour ne pas trop amplifier ce bruit de quantification dans le graphique.
Dans le cas d'une petite plage de valeurs y sur les axes y gauche et droit, il serait bien de `` déplacer '' le centre de l'axe y vers la moitié supérieure et le centre de l'autre axe y vers le bas moitié. Supprime les intersections inutiles de valeur Y gauche / droite. Bien sûr, si les deux axes Y affichent la même quantité, les axes ne doivent pas être déplacés comme ça, mais il existe déjà l'option «synchroniser les axes y».