[Lens] Time scaling without date histogram

[alexwizp]

Closes: #79656

Summary

In #77811 the option to apply a time unit to the value of a time series is discussed (e.g. per hour, per day independent of the underlying Elasticsearch interval).

The same function could also be provided for non-timebased charts as long as a time range filter can be applied because the used index pattern has a configured default timefield.

In this case the time scaling would behave as if the complete time range is a single large bucket and scaled accordingly.

A visualization which can be realized using this is to show the rate of ingested documents per hour for the complete current time range by using a metric visualization on count with time scale applied to it.

Which operations suppport Normalize by unit ?

• count
• sum

Screens

Screen.Recording.2022-09-07.at.15.39.12.mov

[elasticmachine]

Pinging @elastic/kibana-vis-editors @elastic/kibana-vis-editors-external (Team:VisEditors)

[alexwizp]

@elasticmachine merge upstream

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[alexwizp]

@elasticmachine merge upstream

[flash1293]

The time scaling mode is defined on the operation, no need to define it on each individual column. We also don't do this in other places (and you are not reading the time scaling mode from the column anywhere, only from the operation definition)

[alexwizp]

good point!

[alexwizp]

@elasticmachine merge upstream

[flash1293]

This code is removing the time scale on every change if there is no date histogram:

kibana/x-pack/plugins/lens/public/indexpattern_datasource/operations/time_scale_utils.ts

Line 81 in 316b1a0

timeScale: undefined,

Kapture.2022-09-12.at.11.43.10.mp4

[alexwizp]

Thank you, @flash1293. I didn't find any regression on removing that timeScale: undefined,

Plus it fixes that case

Screen.Recording.2022-09-12.at.13.27.40.mov

[flash1293]

This mostly works fine, but on testing the details I noticed that we are not taking the reduced time range per dimension into account:

In such a configuration it's fetching the data for the reduced time range, then doing the normalization on the full time range. We could fix this by passing the reduced time range into the lens_time_scale call as a new argument:

kibana/x-pack/plugins/lens/public/indexpattern_datasource/to_expression.ts

Line 308 in 41a37eb

targetUnit: [col.timeScale!],

In the implementation, the reduced time range is the maximum length (if the search context time range is smaller than the reduced time range, just use it, otherwise cap it by the length of the reduced time range)

[VladLasitsa]

LGTM

[alexwizp]

@elasticmachine merge upstream

[alexwizp]

@elasticmachine merge upstream

[alexwizp]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: feee302

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
lens	1.2MB	1.2MB	-34.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
lens	34.7KB	34.8KB	+32.0B

History

• 💔 Build #72275 failed 4adc17e
• 💚 Build #72109 succeeded b4303bc
• 💚 Build #71766 succeeded ff37208
• 💚 Build #71607 succeeded 8314a9f
• 💚 Build #71199 succeeded 305f14a

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @alexwizp

[flash1293]

Tested and everything works as expected now, LGTM