[Infra UI] Provide routes for accessing pre-filtered log views

[weltenwort]

This PR introduces a set of routes that can be used as stable entry points into the infra ui with partly pre-populated stated (e.g. filters and time):

• app/infra/#/link-to/container-logs/:containerId[?time=${TIMESTAMP}]
• app/infra/#/link-to/host-logs/:hostname[?time=${TIMESTAMP}]
• app/infra/#/link-to/pod-logs/:podId[?time=${TIMESTAMP}]

It also fixes the links from the waffle map to the logging ui to result in an appropriately filtered view.

A follow-up PR will add uiExports to make similar factory functions available to other Kibana plugins.

Notes and Limitations

• The current implementation of the <Node> component does not know its own true type, which is hard-coded to host. The url generation should already work for container and pod types as well, though. So once the <Node> is fixed in that regard, appropriate urls would be generated.
• The redirection logic might seem a bit more complex than immediately required. It is written such that it supports future linking from outside the infra ui. That means that the exact field names to filter by for various node types are not known in advance. To accommodate that fact, the intermediate routes first resolve the configured sources before redirecting to the final URLs with pre-populated state (as per [Infra UI] Selectively persist UI state in the url (via container components) #22980). This also allows for the urls to act as stable external APIs while leaving us free to change state structure or the way it is represented in the URL.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[weltenwort]

looks like a failure during test setup. jenkins, test this again

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[weltenwort]

flaky reporting test - jenkins, test this

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[weltenwort]

@skh I rebased this on the feature branch

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[weltenwort]

flaky reporting test - jenkins, test this again

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[skh]

Can you elaborate how the timestamp value passed in through the link is used?

When I use the URL path app/infra/#/link-to/container-logs/carlos_metricbeat_1?time=1537302288116 the resulting graphql query uses start: 1537172688116, end: 1537431888116. The URL after redirect uses the timestamp 1537302309387 in the position argument. I'm not sure I understand what's happening there.

[skh]

I have tested with the following URL paths:

app/infra/#/link-to/container-logs/carlos_metricbeat_1?time=1537302288116
app/infra/#/link-to/container-logs/carlos_metricbeat_1

app/infra/#/link-to/host-logs/demo-stack-apache-01?time=1537302288116
app/infra/#/link-to/host-logs/demo-stack-apache-01

app/infra/#/link-to/pod-logs/kube-dns-5dcfcbf5fb-h6j25?time=1537302288116
app/infra/#/link-to/pod-logs/kube-dns-5dcfcbf5fb-h6j25

They behave as expected.

[skh]

Looks good 👍

[weltenwort]

@skh What you are observing there is the result of the asymmetry between what the position being read from the URL is interpreted as and what is being written to the url under that key:

(TL;DR: It's being read as the "desired position" and written as the reported visible position.)

1. A change of (or initialization with) a valid position value causes the xpack/infra/local/log_position/JUMP_TO_TARGET_POSITION action the dispatched.
2. The remote/log_entries and remote/log_summary epics react to that by fetching the log entries and summary buckets surrounding that point in time.
3. The text stream and minimap render those fetched data and report the visible intervals (using xpack/infra/local/log_position/REPORT_VISIBLE_POSITION in the case of the text stream).
4. Those newly reported time key of the "middle visible entry on screen" is then written back to the position search param in the URL.

If, after this sequence of events, the position URL param is different from what was initially passed, that means that no log entry matched the timestamp directly. Instead the position of closest log entry that could be found is written back.

I suspect the request with start and end you mention is the log_summary request that covers an interval centered on the reported middle text stream time key (with some overscan on both sides).

I hope that was somewhat helpful. Let me know if I should try harder to explain. 😉

[skh]

I hope that was somewhat helpful. Let me know if I should try harder to explain.

Indeed it was, thank you!