Change histogram:maxBars default setting from 100 to 1000

[flash1293]

This PR changes the histogram:maxBars setting from 100 to 1000. This allows the user to configure higher resolution date histogram aggregations without changing advanced settings.

Background

Date histograms are ubiquitous in Kibana. However, for every date histogram the essential question of the used interval needs to be answered. For most chart types (Lens, agg based) there are two modes:

"Auto" (default) - Divide the duration of the time range (configured in the top right) by histogram:barTarget (defaults to 50), with some wiggle room to get a "nice" interval (like 30 seconds, 5 minutes, 6 hours, ...)
"Min interval" (has to be explicitly configured) - If the duration of the time range divided by the chosen interval is smaller than histogram:maxBars (defaults to 100), use it directly. Otherwise, increase the interval until the condition is satisfied - wiggle room for making the interval "nice" still included
In practice this causes the following behavior:

By default, date histograms have ~50 data points, no matter the configured time range
If the user picks a specific interval, they might not get it if it would result in more than ~100 data points
The behavior of "Min interval" was chosen for two reasons:

Protect the cluster - trying to fetch data with too high of a resolution can cause a lot of load on Elasticsearch, the Kibana server and also the users browser (rendering many thousands of data points can cause the browser tab to freeze and make interactions very slow)
Try to show a meaningful chart - if the interval is too small with respect to the current time range, it can't be interpreted in a meaningful way. For example: Rendering one data point per minute makes sense for the last 2 hours, but applied to the last 90 days it would result in 130k data points. As the chart width on the screen won't exceed 2000 in almost all cases even on large screens, there would be 65 data points within a single pixel which can't be represented in a meaningful way. Lowering the resolution is helpful in this situation.
Having a histogram:maxBars setting definitely makes sense to prevent the mentioned issues, but a default limit of 100 is very low for time series analysis.

Impact

Within these Kibana spaces, all "agg based" and Lens visualizations using the date histogram aggregation in any visualization are affected if they have configured a "min interval" (instead of leaving it to auto) and they are attempting to render the visualization on data that would exceed 100 buckets.

For example:
A Lens doc count histogram set to minute buckets rendered over the last 30 days.

Before (3h interval)

After (30m interval)

Number histogram

Within these Kibana spaces, all "agg based" and Lens visualizations using the histogram aggregation in any visualization are affected even if they have an "auto" interval configured. In Lens, number histograms don't allow the specification of an interval, instead a "granularity slider" is provided which is scaled by the histogram:maxBars setting.

Before

After

Mitigation

If the impact described above is not a good fit for your use case, you can restore the old behavior by explicitly setting histogram:maxBars to 100 in the advanced settings menu (this needs to be done for every space).

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServicesSv)

[stratoula]

I am really in favor of this change! I tested it in Lens and agg based and looks great. The users can always change it again if it doesn't match their expectations. LGTM :)

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 6aa89f1

Metrics [docs]

✅ unchanged

History

• 💚 Build #79724 succeeded 54976da
• 💔 Build #79701 failed 4c4857a
• 💔 Build #79431 failed 414ea9d
• 💔 Build #79387 failed 6cd7b1f

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