Grafana: Gráfico: Limites na escala automática Y (mín. Máx)

Obrigado, ideia interessante. Parece um caso pequeno. Mas concordo, às vezes pode ser útil.

Sim, só queria colocar minhas idéias no papel. :Cerveja:

Não acho que este seja um caso extremo.
Configure a escala automática. Defina 0-100 como o valor mínimo, mas permita que o gráfico seja dimensionado com o tamanho desejado. Isso causou pânico algumas vezes entre os diretores e vice-presidentes até que eu os fizesse ver a escala em que estava.

+1 Muitos dos dados da série temporal que eu visualizo em grafana ficam em zero + ruído, e isso faz com que os gráficos pareçam confusos e confusos.

+1 de um usuário Grafana.net.

A escala mínima ajudaria em coisas como interfaces de rede, onde alguns de nossos links privados / vpn estão ociosos (~ 20kb / s), mas quando em uso são 50-100Mb / s. Se eu definir a escala para 100Mb / se acabou, não sei e se eu definir para 200Mb / s, então não posso ver os dados claramente quando estão apenas 5-10Mb / s.

Eu entendo que esta função provavelmente só é útil para poucas pessoas. Mas tenho hackeado um pouco. E eu vim com algo que funciona para mim. O commit em meu fork adiciona uma caixa Y-Span à guia Axes.

Onde X é um número inteiro ou flutuante:

~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

Exemplo de por que eu preciso:

Algum interesse em um PR?

@thoj Seria uma ótima adição. Usamos limites para alguns gráficos e gostaríamos de sempre mostrá-los, mas ainda dimensionando o gráfico para mostrar pontos muito mais altos do que o limite. "> X" funcionaria bem aqui (e

@lpalm Sim! Vou adicionar uma solicitação pull para tentar iniciar a discussão,

implementado em https://github.com/grafana/grafana/pull/6051

Isso está no trem de lançamento 4.0.x? Estou tentando usar "<" e ">" nas configurações do eixo Y, mas sem sucesso.

não precisávamos revertê-lo, queríamos uma entrada / IU mais amigável do que apenas um recurso oculto que o campo de entrada suporta expressões como > e < então revertemos o recurso em espera para descobrir a IU

Poderíamos ter isso em uma caixa de depósito além de Y-min e Y-max?

Oi,

Eu criei esse recurso para projeto de grafite há um tempo e cheguei à seguinte conclusão que eu nunca iria querer usar yMax , já que sempre quero saber os valores do gráfico, o que não farei com yMax .
Há alguém que pensa que yMax é uma função útil ou deveria yMax ser redesenhado para funcionar como minYMax ?

Quer dizer, se eu definir yMax para xe o contador exceder x , alguém não gostaria de ver quanto excedeu o limite?

Eu uso yMax quando tenho porcentagens para me certificar de que 100% está sempre exatamente no topo do gráfico (mesmo se houver uma pequena mancha)

Eu também preciso do yMax. Isso se deve a alguns sinais barulhentos que têm picos muito altos que distorcem os gráficos.

@iksaif sim, mas isso não deve exigir que yMax seja corrigido. Uma vez que seu gráfico nunca excederá 100% e seu yMax dinâmico, então, seria 100% seu gráfico seria exatamente o mesmo da implementação atual de yMax ?

@thoj isso não parece uma métrica confiável? Em vez disso, você não gostaria que esses picos fossem excluídos do gráfico ou, se você se preocupa com eles, realmente sabe o valor?

@Kvistian eles fariam, acontece, por motivos, que exibe 100,02%, e eu gosto do fato de que posso limitar isso.

Além disso, há momentos em que só quero ver quando quero "aumentar o zoom" e posso usar yMax para fazer isso.

Ok, mas você concorda que a maioria dos casos exigiria um yMax dinâmico? Nesse caso, faria sentido tornar o yMax dinâmico e uma nova função como staticYMax ou fixedYMax para esses casos yMax dinâmico como padrão, pois é o caso de uso geral.

Parece que definir o limite inferior da parte superior do gráfico pode ser útil, mas eu não mudaria a semântica do yMax existente (que, na verdade, é o máximo y que pode ser exibido).

Seria interessante descobrir como essa coisa é nomeada em outro software semelhante

@Kvistian Nem todo mundo quer usar o grafana para exibir apenas métricas limpas dos servidores. Quero exibir métricas de processos físicos que são barulhentos e podem retornar dados estranhos às vezes. Veja meus exemplos e explicações aqui: https://github.com/grafana/grafana/pull/5720

@thoj Não sugeri removê-lo se for um recurso útil, simplesmente questionei se era. Mas parece que existem alguns casos de uso para ele, então, nesse caso, não deve ser removido. Mas, pessoalmente, acho que deve haver mais casos em que você gostaria de um yMax dinâmico. Quando me deparei com o problema do grafite, na verdade presumi que yMax resolveria meu problema (já que não conseguia ver nenhum caso útil para um yMax estático real). Em última análise, é apenas um problema de nomenclatura neste momento.

Eu realmente não me importo se ele se chama yMax ou minYMax , apenas pensei que yMax se parece mais com uma função default que deve resolver o caso de uso mais comum.

Estou exibindo um valor de estado de carga da bateria (SOC) e adoraria o recurso de ser capaz de definir um limite superior e inferior, preservando a escala automática dentro desses limites.

Aqui estão algumas imagens do problema que estou enfrentando ao definir ou não definir o valor Y-Max.

Se eu _não_ definir o valor Y-Max, o gráfico mostra os valores SOC na escala Y> 100%, o que nunca ocorrerá. Em outras palavras, no caso de estado de carga da bateria:

0% <= y_scale_values <= 100%

Se eu _do_ definir o valor Y-Max, então, quando eu tiver valores SOC baixos por um longo tempo, o gráfico não será escalonado automaticamente, como mostra a imagem abaixo.

O que eu gostaria é poder definir um limite superior (100%) e inferior (0%), mas ainda ter a escala automática do gráfico dentro desses limites, como faz no momento em que os limites Y não estão definidos.

Apenas adicionando nosso caso de uso. Estamos monitorando um site e temos um nível básico de tráfego de verificação de integridade para instâncias 'funcionais', que gostaria de exibir como uma linha gráfica 'baixa' (por exemplo, 0,1 solicitação / s, mas o eixo seria no mínimo 1, embora ainda permitindo que o eixo do gráfico seja escalado para cima quando o tráfego 'real' chegar.

Há um truque para ter um valor mínimo do eixo Y máximo.

Crie uma métrica Baseline para a escala mínima desejada. Aqui eu escolhi 1s para tempo de CPU:

Adicione substituições para a métrica de linha de base para fazê-la desaparecer do gráfico:

É isso aí.

A única desvantagem é que você pode ver a linha de base ao passar o mouse sobre ela:

Eu também preciso disso para exibir IO.

por exemplo, a velocidade de leitura pode ser 50kb / min ou 500 MB / min, definindo alguma escala mínima - por exemplo 100 MB / min como padrão tornaria meus gráficos muito mais consistentes.

+1
Por favor?

@dstensnes Por favor, não deixe comentários neste formulário sobre questões do GitHub. Você pode adicionar uma reação à postagem inicial para mostrar que gostaria desse recurso. Quando você comenta + 1s, todos que seguem este problema recebem um e-mail de notificação sem nenhuma informação relevante. É simplesmente uma má forma.

Ok, eu posso viver com isso :) Alguém já viu as reações? Percebi agora que você pode classificar a quantidade de reações, então isso é pelo menos alguma coisa. obrigado

Acho que os casos de uso da maioria das pessoas seriam cobertos pela adição de uma caixa de seleção "limite flexível" ao lado dos campos Y-Min e Y-Max. Se você mover Y-Max para a próxima linha, deve haver espaço suficiente para a caixa de seleção e o rótulo, e a funcionalidade deve ser bastante autoexplicativa :)

Não tenho certeza de como isso pode ser considerado um caso extremo, o principal aplicativo que temos é o tráfego de rede, mas na maioria dos gráficos você não quer ver valores minúsculos mostrados como "montanhas".

existe atualmente uma solução alternativa para fazer isso?

Alguma atualização para isso? Isso está dificultando muito a configuração de bons painéis.

Uma ideia de IU seria ter:

• YMax (suave) - O topo do gráfico sempre se estende pelo menos até aqui
• YMax (difícil) - O topo do gráfico nunca se estende além daqui
• YMin (suave) - A parte inferior do gráfico sempre se estende pelo menos até aqui
• YMin (difícil) - A parte inferior do gráfico nunca se estende além daqui

Outra hipótese poderia ser um intervalo mínimo para o eixo Y, definindo que o intervalo de Y-low atual para Y-high nunca deve ser menor do que o valor fornecido. Dessa forma, a renderização é livre para definir onde o eixo y deve começar e terminar - e ao mesmo tempo evitar pequenas alterações nos valores a serem renderizados como montanhas.

Eu também acho que este é um problema muito comum com dados ruidosos e a maioria dos dados são ruidosos.

Acho que o verdadeiro problema é que os valores atípicos distorcem a escala do eixo Y, fazendo com que todo o resto desapareça. Na minha opinião, a solução certa é permitir que o intervalo do eixo Y seja dinâmico com base nos dados exibidos enquanto corta os valores extremos de valores discrepantes. A melhor maneira de fazer isso seria basear o intervalo nos desvios padrão da média dos dados exibidos. Por exemplo, se definir 1 desvio padrão do que qualquer coisa que seja mais do que 1 desvio padrão acima da média, seria cortado no gráfico. Ambos são fáceis de configurar, podem ser facilmente calculados no lado do cliente, portanto, não depende da fonte de dados e seria razoavelmente fácil para as pessoas entenderem.

Quase 2 anos atrás:

reverteu o recurso em espera para descobrir a interface do usuário

Traga de volta > e < enquanto uma IU melhor é considerada.

Estou esperando desesperadamente por um recurso como aquele que foi removido 2 anos atrás!

Mesmo gráficos modelados que monitoram a mesma métrica em sistemas diferentes, lado a lado fornecem visuais imprecisos, pois as escalas são ajustadas automaticamente de forma independente com base apenas nos dados atuais do gráfico.

Há um truque para ter um valor mínimo do eixo Y máximo.

Crie uma métrica Baseline para a escala mínima desejada. Aqui eu escolhi 1s para tempo de CPU:

Adicione substituições para a métrica de linha de base para fazê-la desaparecer do gráfico:

É isso aí.

A única desvantagem é que você pode ver a linha de base ao passar o mouse sobre ela:

Para aqueles que leem a útil solução alternativa de baseline das dicas de ferramentas na substituição.

@bobrik @ sb3tcs Olá, gostaria de usar sua solução alternativa, mas o Grafana termina com um erro de sintaxe de consulta se tudo o que eu colocar na consulta for apenas 20 ou algum outro número. Como criar a métrica de linha de base? Ou meu Grafana 5.1 é muito antigo para suportar esse tipo de consulta?

Usei algumas funções encadeadas em uma segunda consulta para evitar que os gráficos aumentassem muito o zoom no eixo y.
Neste exemplo, eu represento os usuários conectados de vários servidores em um gráfico.

Eu adicionei uma consulta adicional com os mesmos pontos de dados:
offset (-20) aggregateBy (1m, min) removeBelowValue (0) setAlias ​​(hidden_min)

Isso muda o zoom dinâmico de
min até max
para
min-20 (embora não vá para negativos) até max

Para ocultar o gráfico falso:
substituição de visualização com regex "/hidden_.*/"
Linhas: falsas
Legenda: falsa
Ocultar na dica: verdadeiro

Você provavelmente poderia até sincronizar o eixo y entre vários gráficos. Como um painel por servidor e reúna mín. / Máx. De pontos de dados de todos os servidores em cada painel.

Eu encontrei outra solução alternativa. Acabei de adicionar uma série de tempos mín. E máx. Com a tag mín e máx. A linha era assim
weather,sensorID=min temperature=0
weather,sensorID=max temperature=20
Esses são adicionados ao gráfico e ocultados como mencionado acima. O único problema é que você precisa injetá-lo regularmente.
Aqui está o que parece, pode ser necessário definir a temperatura máxima para 19 para que ele ajusta automaticamente o eixo para 20.

Editar: insira no máximo 19 e funcionou.

Me deparei com este tópico em busca de uma solução para definir um y-max flexível no Grafana. Para meu caso de uso, estou gerando um gráfico de latência e volume de solicitação para uma API. Quero definir um y-máx flexível para cerca de 500 ms (0,5 segundos), para que eu possa ver melhor a nuance das chamadas de latência mais baixa, excluindo outliers pontiagudos e ajustando automaticamente o y-max quando a latência máxima está abaixo esse limite.

Tentei definir: y-min para 0 ey-max para <.5, mas meu eixo y desaparece totalmente ou ignora o y-min. Esse problema aconteceu independentemente de representar graficamente a latência e as consultas de volume de solicitação juntas / separadamente. Houve algum novo progresso nesta questão? Seria muito benéfico para minha equipe.

Estou incluindo algumas capturas de tela do meu gráfico com y-max configurado de forma diferente (cada caso identificado pelo título do gráfico)

se você não quiser representar graficamente valores acima de 500 ms, você pode tentar usar removeAboveValue (0,5)
em seguida, diga ao gráfico como os valores nulos devem ser tratados

nenhuma pista se existe uma maneira de usar parâmetros calculados para esta função

Uma solução alternativa um pouco mais atualizada é a seguinte:

Isso impede que a consulta de linha de base apareça no gráfico, na legenda e na dica de ferramenta instantânea e também evita que ela cause problemas de empilhamento.

Este não é realmente um caso extremo, mas sim um caso muito comum. Na verdade, acho que é muito comum que se queira um eixo y com valores mín / máx "suaves". A principal razão para definir a escala do eixo y é que se deseja alinhá-la com o intervalo de dados esperado e também ter vários gráficos com eixo y alinhado para que seja possível comparar facilmente os valores.

Seria interessante descobrir como essa coisa é nomeada em outro software semelhante

Highchartjs chama de softMin / softMax.
https://api.highcharts.com/highcharts/yAxis

AnyChart chama de soft min / max.
https://docs.anychart.com/Axes_and_Grids/Scales#soft

Chartjs tem a opção "suggestedMin / Max" para lidar com este caso de uso.
https://www.chartjs.org/docs/latest/axes/cartesian/linear.html#axis -range-settings

amCharts os chama de min / max e strictMin / Max.
https://www.amcharts.com/docs/v4/reference/valueaxis/#strictMinMax_property

RRDtool, por exemplo, tem limites "suaves" por padrão quando se usa escala automática, mas tem uma opção chamada rigid que força limites "rígidos" na escala.

[-u | --valor limite superior] [-l | - valor limite inferior] [-r | --rígido] [--permitir-encolher]

Por padrão, o gráfico será escalonado automaticamente para ajustar o eixo y ao intervalo dos dados. Você pode alterar esse comportamento definindo explicitamente os limites. O eixo y exibido irá então variar pelo menos do limite inferior ao limite superior. O escalonamento automático ainda permitirá que esses limites sejam estendidos, a menos que a opção rígida seja definida. allow-shrink altera o comportamento do rígido ao permitir a redução automática da escala, o gráfico não ultrapassará os limites especificados pelo usuário.
https://oss.oetiker.ch/rrdtool/doc/rrdgraph.en.html

O Tableau tem um recurso que permite um intervalo uniforme de eixos para todas as linhas ou colunas, e você pode optar por fazer isso apenas para o eixo y, por exemplo. Isso resolve o problema de uma maneira ligeiramente diferente, mas ainda é o mesmo caso de uso em que se deseja que vários gráficos tenham o mesmo intervalo / escala de eixo.

Embora grande parte da discussão em torno disso tenha se concentrado na implementação de valores mínimos e máximos suaves separados para dimensionamento, acho que há muito valor na implementação de um recurso de "intervalo mínimo do eixo y" como parte disso, distinto do "intervalo suave "mín. / máx., conforme sugerido pelo pôster original. Os mínimos e máximos suaves seriam usados ​​para especificar posições fixas no eixo y, que devem estar sempre visíveis durante o escalonamento automático. Isso pode ser usado quando você tem um intervalo conhecido de valores do eixo y que você sempre deseja ter visível, o que é útil para evitar que pequenas variações apareçam como picos e vales exagerados devido ao efeito de zoom da escala automática. No entanto, isso só funciona se você souber quais serão os valores do eixo y em tempo de design, o que nem sempre é o caso, especialmente para pessoas que criam modelos para uso por usuários finais que podem ter hardware e padrões de carga diferentes.

Uma opção de intervalo mínimo do eixo y para escala automática removeria esse requisito. Quando usado em um conjunto de valores onde o intervalo dos dados (ou seja, abs(max(Y)-min(Y)) ) não excede o intervalo mínimo do eixo y configurado, os valores mínimo e máximo no eixo y seriam definidos de forma que os dados é centralizado verticalmente. Isso evita o problema de exagerar pequenas variâncias, sem que o designer do gráfico precise saber os valores exatos do eixo y com antecedência.

Um pedaço rápido de pseudocódigo para demonstrar o cálculo:

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

Essa abordagem não irá empurrar outliers para fora da escala, como o faria centrar sobre a média.

Como exemplo de caso de uso, imagine que você está projetando um painel para monitorar dados do NUT / upsd e está montando o gráfico de uso de energia. Embora meu no-break possa ter uma média de 400 W, o de outra pessoa pode ter uma média de 100 W ou 1000 W, dependendo da configuração de seu hardware. Não é possível saber isso com antecedência. A quantidade de energia consumida geralmente é razoavelmente constante em uma escala de tempo curta, o que significa que está sujeita a exageros no eixo y quando o escalonamento automático é executado. Este é um caso de uso perfeito para um intervalo mínimo do eixo y, em que você pode fazer suposições razoáveis ​​sobre a escala da variação em um determinado período de tempo, mas não a magnitude do valor absoluto.

Se um sensor tem resolução limitada, tudo o que você vê é o ruído de quantização quando a quantidade varia muito pouco no intervalo de tempo selecionado. Eu gostaria de ver um intervalo mínimo de y, por exemplo, para não amplificar muito esse ruído de quantização no gráfico.
No caso de um pequeno intervalo de valor y nos eixos y esquerdo e direito, seria bom "deslocar" o centro de um eixo y em direção à metade superior e o centro do outro eixo y em direção à parte inferior metade. O irá suprimir interseções desnecessárias dos valores Y esquerdo / direito. Claro, se ambos os eixos Y mostram a mesma quantidade, os eixos não devem ser deslocados dessa forma, mas já existe a opção 'sincronizar eixos y'.