[Logs UI] Sync logs timerange with wider Kibana

[Kerry350]

Summary

This PR implements #79299. It ensures all logs pages (stream, anomalies, and categories) sync their timeranges with wider Kibana, via the data plugin.

The order of precedence now becomes:

• URL params
• Shared Kibana timerange
• Defaults (these shouldn't be needed as the time filter service sets defaults based off the Kibana setting)

⚠️ Semantics change ⚠️

The changes here alter the semantics of the defaults used. Previously the defaults were as follows:

• Stream: now - 1d
• Anomalies: now - 2w
• Categories: now - 2w

Now, the default will be the default set by the time filter service (unless, of course, the user has interacted with the time range and set a new one) when it is instantiated. The default used by the time filter service is from the timePicker.timeDefaults setting under Advanced Settings. This defaults to now - 15m, and as such the default for the logs pages becomes now - 15m, unless the user has set something else.

(I have also kept our original defaults in an || clause but these shouldn't ever be used, it was more in case something went wrong, but if something has gone wrong with the data plugin there are much bigger problems 🤷‍♀️)

Testing

Time ranges should sync between wider Kibana (Discover etc) and all logs pages. This should be two-way.

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[weltenwort]

This looks pretty clean and the time range sync between the tabs feels pretty convenient. 👍

I'm a bit concerned about the semantic changes to the default time ranges. While defaulting to the last 15 minutes seems fine for the logs stream, this value seems impractical for the anomalies and categories tabs. With a bucket span of 15 minutes for the ML jobs there is a high change of not getting any meaningful results on the default view.

No good solution comes to mind, but here are some ideas:

• don't include the anomalies and categories tabs in the sync
• display a warning about the time range being too small for meaningful results

In an unrelated thought, while looking at the data plugin's timefilter service, I noticed it also supports syncing the refresh interval. Would it make sense to also include that?

[Kerry350]

(Note: this is being deferred until the defaults situation can be addressed)

[Kerry350]

Following the semantics change, comment here: #79444 (review) I've pushed changes to try and address the defaults situation.

There were some additional things to consider when I started the implementation, I've highlighted these below:

TimeFilter side:

• getTime on the TimeFilter instance now accepts a set of defaults as a parameter. Solutions can pass what they like here, and if nothing is provided the master constructor defaults are used (derived from the advanced Kibana settings). If time has been touched, then that is always returned.

• When setTime is called (and actually changes something, e.g. the new time is different to the current time) a boolean flag (isTimeTouched) is flipped.

Logs side:

• We can't just use a useEffect that always syncs the time range back to Kibana with setTime, because useEffect will always run on mount, and if we're currently in the defaults fork of the order of precedence (no URL params, and !isTimeTouched), then we will always sync our defaults back to the TimeFilter service, we don't want this. We want to sync user initiated changes.

• The behaviour in wider Kibana (Discover etc) is that URL params that match the defaults, are not synced either (for the initial mount phase). This is the correct behaviour imo. When we first mount and the reconciliation phase is complete, our defaults will always ultimately end up in the URL (if doing a fresh navigation), if a user bookmarks this and loads the URL later, we still don't want those defaults to sync, we want them treated as defaults.

  • Changing back to the defaults in a user initiated fashion, will sync those changes for the session.
  • There's a small argument here that a user could make change A and then change B, change B happens to be the same as the defaults, this gets pushed to the URL (and it's a user change), and then when they reload the URL from a bookmark it's treated as defaults and therefore not synced to wider Kibana. I think this is a small edge case, and once things end up in the URL in a bookmark we can't later make a differentiation.

• I've added two hooks useKibanaTimefilterTime and useSyncKibanaTimeFilterTime to deal with the complexity (well, not really complexity, just repetition). I have not merged these into one hook as we have dependencies between the URL state hook and the time filter hooks that make this unviable. To make them all play together actually makes things more confusing imo. Also, this allows things to opt in to getting / setting time without necessarily having to utilise sync.

  • The sync hook differentiates a mount phase and an update phase (using react-use hooks) to make sure the point above is handled nicely.
  • The useSyncKibanaTimeFilterTime hook plays really nicely with the useUrlState state hook (which anomalies and categories tabs both use). However, the stream is still using a pre-hooks container for handling the URL state with <UrlStateContainer />, and this has it's own initialize phase, as such I have used a separate useEffect for the stream. At a later date I would suggest we swap to the hook for the stream, I can file a ticket.

I think this covers everything 🤔

[weltenwort]

Looks really elegant and seems to work flawlessly - well done 👏

I wonder if the useSync... hook could subsume the other hook once the old url sync component is gone from the logs stream. 🤔 But for now the separation makes sense 👍

[Kerry350]

@weltenwort

I wonder if the useSync... hook could subsume the other hook once the old url sync component is gone from the logs stream.

Yep, I think once everything is on useUrlState we can make that magic 💥 happen.

[Dosant]

AppArch code LGTM

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: a0be0c4

Metrics [docs]

@kbn/optimizer bundle module count

id	before	after	diff
infra	1142	1143	+1

async chunks size

id	before	after	diff
infra	3.8MB	3.8MB	+12.7KB

page load bundle size

id	before	after	diff
data	1.1MB	1.1MB	+162.0B

History

• 💔 Build #80721 failed f8b2123
• 💔 Build #80714 failed f47fe25
• 💔 Build #80713 failed 7aa9c51
• 💔 Build #80473 failed e39df69
• 💚 Build #79577 succeeded e524d1b

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