search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.66k stars 8.1k forks source link

When units are converted, charts generate with original units instead of those converted. #17628

Closed sgelastic closed 3 years ago

sgelastic commented 6 years ago

Kibana version: Kibana 6.2

Elasticsearch version: Elasticsearch 6.2

Server OS version: CentOS 7.2 x64

Browser version: Safari 11.0.1

Browser OS version: MacOS 10.13.1

Original install method (e.g. download page, yum, from source, etc.): yum

Description of the problem including expected versus actual behavior:

When using the goal, gauge or other visualizations, with conversion, the graph displays in the original values instead of converted ones displayed inside. Per images below, customer has a field called mtfb that is measured in seconds. He wants this to be converted to hrs instead of very high number of seconds for easier reading. Upon doing so, the visualization itself continues to plot as seconds instead of hours, rendering the chart not representative of the number data displayed. confusing behavior As you can see here, we are plotting the value 529497.3... as the average, but displaying the value as 147.08. This is very confusing for administrators when attempting to configure the ranges within the gauge, because the scale is completely different from the value actually displayed inside the gauge that is being visually represented. When the scale is adjusted to seconds, it looks like this: in seconds in seconds When the scale is in hours it looks like this: in hours in hours

In both cases the data printed shows in hours, so it's not really intuitive at first glance what might be wrong. The value represented inside the gauge to match the one actually plotted, so scale can be adjusted with greater precision. It may make more sense to have a toggle to use raw or converted data, but this looks like a potential bug. mtbf field detail mtbf field detail

RAWoutput.zip

timroes commented 3 years ago

We've discusses this, and decided not to implement this. The problem is that field formatters can produce any kind of output (also a non numerical one). At that point we could not really do a larger/greater comparison anymore to calculate the ranges, thus we're required to use some numerical value, meaning we'll require you to use the unformatted value as they are stored in Elasticsearch.