[Lens] Zooming in on counter rate chart can land on a empty chart

[dej611]

Describe the feature:

Lens' Counter rate operation relies on client side computation over a max ES agg which can lead, in some zooming in scenarios, into an empty chart scenario unless the user knows exactly the frequency documents are stored.

In this example I've simulated a regular document updates every 10 minutes, therefore if the date range offers a bucket window bigger than 10m the chart is showing a line, but zooming in at a point where the bucket window is < 10 minutes (i.e. 5 minutes in the gif) makes the line go away:

User has to force the minimum interval to match the update frequency of 10 minutes to make the chart appear again.

The root issue here is that Lens relies on a max agg that will return, in the case of 5 minutes, a null value every other bucket leading to a NaN rate value:

• 5 (t0) - null (t1) => NaN
• null (t1) - 5 (t2) => NaN
• ...etc

One instance of this has been already logged on #163706

Describe a specific use case for the feature:

I think there's not a simple solution here for the problem, but just throwing some ideas:

• With the current Lens counter rate implementation, we could detect this scenario and compute on the fly a minimal interval to "suggest" to the user (via the warning UX?) to quickly fix it
• Replace completely the Lens implementation with the ES rate agg as in [lens] [optimization] use es rate aggregation when possible #152537

[elasticmachine]

Pinging @elastic/kibana-visualizations (Team:Visualizations)

[timductive]

We talked and decided that we should investigate using the ES rate agg in every case to fix this (Marco's 2nd option above).

[markov00]

In order to provide better transparency of priorities, issues that will not be prioritized within the next 24 months are being closed.

Tracking request in Lens general improvements ice box #184459