Grafana: Graph: Limits on Y auto scale (min max)

Thanks, interesting idea. Seems a little edge case. But I agree, could be useful at times.

Yeah, I just wanted to get my thoughts on paper. :beer:

I do not think this is a edge case.
Set AutoScale up. Set 0-100 as the min rage but allow the graph to scale as large as it wants. This has caused panic a few times among the Directors and VPs until I had them look at the scale it was at.

+1 A lot of the time series data which I visualize in grafana sits at zero+noise, and this makes the graphs look messy and unclear.

+1 from a Grafana.net user.

The minimum scale would help for things like network interfaces, where some of our private / vpn links are idle (~20kb/s) but when in use are 50-100Mb/s. If I set the scale to 100Mb/s and it's over, I don't know and if I set it to 200Mb/s then I can't see data clearly when it's only 5-10Mb/s.

I understand that this function is probably only useful for very few people. But I've been hacking on this a bit. And I've come up with something that works for me. The commit in my fork adds a Y-Span box to the Axes tab.

Where X is a integer or float:

~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

Example of why i need it:

Any interest in a PR?

@thoj That would be a great addition. We use thresholds for some graphs and would like to always show it, but still scaling the graph to show points much higher than the threshold. ">X" would work well here (and

@lpalm Yeah! I'll add a pull request to try to get the discussion going,

implemented in https://github.com/grafana/grafana/pull/6051

Is this in the 4.0.x release train? I'm trying to use "<" and ">" in the Y-axis settings but to no avail.

no had to revert it, we wanted a more user friendly input / UI than just hidden feature that the input field supports expressions like > and < so reverted the feature in wait for time to figure out the UI

Could we have this in a dropbox besides Y-min and Y-max?

Hi,

I created this feature for graphite project a while back and came to the following conclusion that I would never ever want to use yMax, since I always want to know the values of the graph, which I won't with yMax.
It there anyone who thinks that yMax is a useful function or should yMax just be re-designed to work as minYMax?

I mean, if I set yMax to x and the counter exceeds x would anyone not want to see how much it exceeded the limit?

I use yMax when I have percentages to make sure that the 100% is always exactly at the top of the graph (even if there is a small blip)

I also need yMax. This is due to some noisy signals that have very tall spikes that distort the graphs.

@iksaif yes, but that shouldn't require yMax to be fixed. Since your graph won't ever exceed 100% and your dynamic yMax then would be 100% your graph would look exactly the same as with the current implementation of yMax?

@thoj that doesn't sound like a reliable metric? Wouldn't you instead want those spikes excluded from the graph or if you care about them actually know the value?

@Kvistian they would, it happens, for reasons, that it displays 100.02%, and I like the fact that I'm able to cap that.

Also there are times when I only want to see when I want to "zoom in" and I can use yMax to do that.

Ok, but you agree on that most cases would require a dynamic yMax? In that case, would it make sense to make the yMax dynamic and a new function like staticYMax or fixedYMax for those edge cases? Thus, having a dynamic yMax as default since it's the general use case.

Sounds like setting the lower bound of the top of the graph could be useful but I wouldn't change the semantic of the existing yMax (which, really is the maximum y that can be displayed).

Would be interesting to find how this thing is named in other similar software

@Kvistian Not everyone wants to use grafana to only display nice clean metrics from servers. I want to display metrics from physical processes that are noisy and can return weird data sometimes. Se my examples and explanations here: https://github.com/grafana/grafana/pull/5720

@thoj I didn't suggest to remove it if it's a useful feature, I simply questioned if it is. But it seems like there are some use cases for it, so in that case it shouldn't be removed. But personally I feel that there should be more cases where you would like a dynamic yMax. When I stumbled up on the problem with graphite I actually assumed that yMax would solve my problem (since I couldn't see any useful case for an actual static yMax). Ultimately it's just a naming problem at this point.

I don't really care if it's called yMax or minYMax, just thought that yMax feels more like a default function that should solve the most common use case.

I am displaying a battery state of charge (SOC) value and would really love the feature of being able to set an upper and lower limit while preserving auto-scaling within these limits.

Here are some images of the problem I'm facing by setting or not setting the Y-Max value.

If I _don't_ set the Y-Max value then the graph shows SOC values on the Y scale > 100% which will never occur. In other words, in the case of battery state of charge:

0% <= y_scale_values <= 100%

If I _do_ set the Y-Max value, then when I have low SOC values for a long time the graph doesn't auto-scale, as show in the image below.

What I would like is to be able to set an upper (100%) and lower limit (0%) but still have the plot auto-scale within these limits as it does at the moment when the Y limits aren't set.

Just adding our use case. We are monitoring a website and have a baseline level of healthchecking traffic for 'working' instances, which I'd like to display as a graphically 'low' graph line (e.g. 0.1 request/sec but the axis would be minimum of 1, whilst still enabling the graph axis to scale upwards when the 'real' traffic arrives.

There's a hack to have a minimal maximum Y axis value.

Create a Baseline metric for the minimal scale you want. Here I picked 1s for CPU time:

Add overrides for the baseline metric to make it disappear from the graph:

That's it.

The only drawback is that you can see the baseline of you hover it:

I also need this for IO display.

for example read speed can be 50kb/min or 500MB/min, setting some minimum scale - for example 100MB/min as default would make my graphs way more consistent.

+1
Please?

@dstensnes Please don't leave comments of this form on GitHub issues. You can add a reaction to the initial post to show you'd like this feature. When you comment +1's, everyone following this issue gets a notification email without any relevant info. It's simply bad form.

Okay, i can live with that :) Does anyone ever look at the reactions though? I noticed now that you can sort on the amount of reactions, so that is at least something. Thanks

I think most peoples use cases would be covered by adding a "soft limit" checkbox next to the Y-Min and Y-Max fields. If you move Y-Max down to the next row there should be enough space both for the checkbox and the label, and the functionality should be pretty self explanatory :)

I am not sure how this can be considered an edge case, the main application we have is network traffic but on most graphs you don't want to see tiny values shown as "mountains".

is there currently a workaround to do that ?

Any updates to this? This is making setting up good dashboards very hard.

One UI idea would be to have:

• YMax(soft) - Top of graph always extends to at least here
• YMax(hard) - Top of graph never extends beyond here
• YMin(soft) - Bottom of graph always extends to at least here
• YMin(hard) - Bottom of graph never extends beyond here

Another take on this one could be a minimum span for Y-axis defining that the span from current Y-low to Y-high should never be less than the given value. That way the render is free to set where y axis should begin and end - and in the same time avoid minor changes in values to be rendered as mountains.

I too find that this is a very common problem with noisy data and most of the data is noisy.

I think the real problem is that outlier values skew the scale of the Y axis making everything else disappear. The way I see the right solution is to allow the Y axis range to be dynamic based on the displayed data while trimming extreme outlier values. The best way to do that would be to base the range on standard deviations from the average of the displayed data. For example, if setting 1 standard deviation than anything that is more than 1 standard deviation above the average would be trimmed on the graph. This is both easy to configure, can easily be calculated on the client side so it doesn't depend on the data source and would be reasonably easy for people to understand.

From almost 2 years ago:

reverted the feature in wait for time to figure out the UI

Please bring back > and < while a better UI is considered.

I'm desperately waiting for such a feature as the one that was removed 2 years ago!

Even templated charts that monitor the same metric on different systems, side by side give inaccurate visuals as the scales are auto adjusted independently based solely on the current data on the chart.

There's a hack to have a minimal maximum Y axis value.

Create a Baseline metric for the minimal scale you want. Here I picked 1s for CPU time:

Add overrides for the baseline metric to make it disappear from the graph:

That's it.

The only drawback is that you can see the baseline of you hover it:

For those who read @bobrik's helpful work-around, these days you may also hide the baseline item from tooltips in the override as well.

@bobrik @sb3tcs Hi, I'd like to use your workaround, but Grafana ends up with a query syntax error if all I put into the query is just 20 or some other number. How to create the baseline metric? Or is my Grafana 5.1 too old to support this kind of query?

I used some chained functions on a second query to prevent the graphs from zooming in to much on the y-axis.
In this example I graph logged in users from multiple servers in one graph.

I added an additional query with the same data points:
offset(-20) aggregateBy(1m,min) removeBelowValue(0) setAlias(hidden_min)

This changes the dynamic zoom from
min up to max
to
min-20 (while not going into negatives) up to max

To hide the fake graph:
visualization override with regex "/hidden_.*/"
Lines:false
Legend:false
Hide in tooltip:true

You could probably even sync the y-axis between multiple graphs. Like a panel per server and gather min/max from data points of all the servers in each panel.

I found another workaround. I just added a min and max timeseries with the min and max tag. The line was like this
weather,sensorID=min temperature=0
weather,sensorID=max temperature=20
Those get added to the graph and hidden like mentioned above. Only issue is that you need to inject it on a regular basis.
Here is how it looks, may need to set max temperature to 19 so it auto adjusts the axis to 20.

Edit: insert max as 19 and it worked.

I stumbled upon this thread looking for a solution to setting a flexible y-max in Grafana. For my use case, I am graphing request latency and volume for an API. I want to set a flexible y-max to about 500 ms (.5 seconds), so that I can better see the nuance to the lower-latency calls by excluding spiky outliers and auto adjusting the y-max when the maximum latency is below that threshold.

I tried setting: y-min to 0 and y-max to <.5, but then my y-axis either disappears entirely or ignores the y-min. This problem happened regardless of graphing the latency and request volume queries together/separately. Has there been any new progress on this issue? It would be really beneficial to my team.

I'm including a few screenshots of my graph with y-max configured differently (each case labelled by graph title)

if you don't want to graph values above 500ms you could try to use removeAboveValue(0.5)
then tell the graph how the null values should be handled

no clue if there is a way to use calculated parameters for this function

A slightly more up-to-date baseline workaround is as follows:

This stops the baseline query appearing in the graph, legend, and hover tooltip, and also prevents it from causing issues with stacking.

This is not an really an edge case, but rather a very common case. I actually think it's very often that one wants an y-axis with "soft" min/max values. The main reason for setting the y-axis scale is that one want to align it with expected data range, and also to have multiple graphs with aligned y-axis so one can easily compare values.

Would be interesting to find how this thing is named in other similar software

Highchartjs calls it softMin/softMax.
https://api.highcharts.com/highcharts/yAxis

AnyChart calls it soft min/max.
https://docs.anychart.com/Axes_and_Grids/Scales#soft

Chartjs has "suggestedMin/Max" option for handling this use-case.
https://www.chartjs.org/docs/latest/axes/cartesian/linear.html#axis-range-settings

amCharts calls them min/max and strictMin/Max.
https://www.amcharts.com/docs/v4/reference/valueaxis/#strictMinMax_property

RRDtool for example has "soft" limits by default when one uses autoscale, but has an option called rigid that forces "hard" limits on the scale.

[-u|--upper-limit value] [-l|--lower-limit value] [-r|--rigid] [--allow-shrink]

By default the graph will be autoscaling so that it will adjust the y-axis to the range of the data. You can change this behavior by explicitly setting the limits. The displayed y-axis will then range at least from lower-limit to upper-limit. Autoscaling will still permit those boundaries to be stretched unless the rigid option is set. allow-shrink alters behavior of rigid by allowing auto down scale, graph will not overrun user specified limits.
https://oss.oetiker.ch/rrdtool/doc/rrdgraph.en.html

Tableau has a feature for allowing uniform axis range for all rows or columns, and you can choose to only do so for the y axis, for example. This solves the problem in a slightly different way, but it's still the same use-case where one want multiple charts to have the same axis range/scale.

While a lot of the discussion around this has focused on implementing separate soft min and max values for scaling, I think there is a lot of value in implementing a "minimum y-axis range" feature as part of this, distinct from the "soft" min/max, as the original poster suggested. The soft minimums and maximums would be used to specify fixed positions on the y-axis which must always be visible during auto-scaling. This can be used when you've got a known range of y-axis values that you always want to have visible, which is useful for preventing small variances appearing as exaggerated peaks and troughs due to the zooming effect of auto-scaling. However, this only works if you know what those y-axis values are going to be at design time, which isn't always the case, especially for people building templates for use by end-users who might have different hardware and load patterns.

A minimum y-axis range option for auto scaling would remove this requirement. When used on a set of values where the range of the data (i.e. abs(max(Y)-min(Y))) does not exceed the configured minimum y-axis range, the minimum and maximum values on the y-axis would be set such that the data is centered vertically. This avoids the issue of exaggerating small variances, without the graph designer needing to know the exact y-axis values ahead of time.

Quick bit of pseudocode to demonstrate the calculation:

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

This approach will not push outliers off the scale, like centering about the mean would.

As an example use-case, imagine you're designing a dashboard for monitoring data from NUT/upsd, and you're putting together the power usage graph. While my UPS might average 400W, someone else's might average 100W or 1000W, depending on what their hardware setup looks like. It isn't possible to know this ahead of time. The amount of power drawn is usually fairly constant over a short time scale, though, meaning that it is prone to y-axis exaggeration when autoscaling is performed. This is a perfect use-case for a minimum y-axis range, where you can make reasonable assumptions about the scale of the variance over a given time period, but not the magnitude of the absolute value.

If a sensor has limited resolution, all you see is the quantization noise when the quantity varies very little in the selected time span. I would like to see a minimum y-span for instance to not amplify this quantization noise too much in the graph.
In the case of little y-value span in both left and right y-axes, it would be nice to 'nudge' the center of the one y-axis towards the upper half and the center of the other y-axis towards the lower half. The will suppress unnecessary left/right Y-value intersections. Of course if both Y-axes show the same quantity, the axes should not be nudged like that, but there is already the 'synchronize y-axes' option.