Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Logs UI] Use the Super date picker in the log stream #54280

Merged
merged 123 commits into from
Mar 19, 2020

Conversation

afgomez
Copy link
Contributor

@afgomez afgomez commented Jan 8, 2020

Summary

Part of #49154

This PR replaces the point-in-time datepicker from the Logs UI with the EuiSuperDatePicker to allow users to specify a range.

Changes

LogSummaryState and LogEntriesState now keep track of the date range. We represent the range with two pairs of values:

  • startDateExpression, endDateExpression: the datemath expression (i.e. now-10m, now)
  • startTimestamp, endTimestamp: the resolved datemath expression, in milliseconds.

The endTimestamp is dynamic when endDate is now. This allows the streaming to always fetch the most recent entries.


The minimap now has a fixed range, which corresponds to the startDate and endDate. The minimap is no longer drag-able anymore either.


LogSummaryState has now two elements to consider: the date range and the log position cursor. They can be set with different callbacks and each change might trigger a refetching of entries. That means that if the user has both values (start and end dates, and a position) set in the initial URL, the page will fetch twice. To prevent this, we have added a flag to the LogSummaryState that determines if it has been initialized or not. If it's not initialized, consumers of the API should not do anything.


The GraphQL implementation of the API has been removed.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

For maintainers

@afgomez afgomez force-pushed the 49154-logs-super-date-picker branch 5 times, most recently from b082ee9 to f83254b Compare January 15, 2020 17:54
@afgomez afgomez force-pushed the 49154-logs-super-date-picker branch from 077aed4 to 2be7fbe Compare January 16, 2020 15:36
@afgomez afgomez force-pushed the 49154-logs-super-date-picker branch from 2be7fbe to b21a2e9 Compare January 17, 2020 09:42
@afgomez afgomez force-pushed the 49154-logs-super-date-picker branch from b21a2e9 to 02d8b59 Compare January 29, 2020 15:18
@afgomez afgomez force-pushed the 49154-logs-super-date-picker branch 4 times, most recently from c839bf2 to 6a89955 Compare February 6, 2020 09:04
@afgomez afgomez force-pushed the 49154-logs-super-date-picker branch from 5856911 to 6dddc6b Compare February 7, 2020 12:54
@elasticmachine
Copy link
Contributor

💔 Build Failed


Test Failures

Kibana Pipeline / x-pack-intake-agent / X-Pack Jest Tests.x-pack/legacy/plugins/infra/public/containers/logs/log_summary.useLogSummary hook queries for new summary buckets when the start and end date changes

Link to Jenkins

Standard Out

Failed Tests Reporter:
  - Test has not failed recently on tracked branches


Stack Trace

Error: expect(jest.fn()).toHaveBeenLastCalledWith(...expected)

Expected: ObjectContaining {"endTimestamp": 1581081970183, "startTimestamp": 1581081960182}
Received: {"bucketSize": 100, "endTimestamp": 1581081970183, "query": null, "sourceId": "SOURCE_ID", "startTimestamp": 1581081960183}

Number of calls: 1
    at Object.it (/var/lib/jenkins/workspace/elastic+kibana+pipeline-pull-request/kibana/x-pack/legacy/plugins/infra/public/containers/logs/log_summary/log_summary.test.tsx:133:33)

Kibana Pipeline / x-pack-intake-agent / X-Pack Jest Tests.x-pack/legacy/plugins/infra/public/components/logging/log_text_stream.LogEntryFieldColumn should output a
    when displaying an Array of values

Link to Jenkins

Standard Out

Failed Tests Reporter:
  - Test has not failed recently on tracked branches


Stack Trace

Error: expect(received).toBe(expected) // Object.is equality

Expected: true
Received: false
    at Object.it (/var/lib/jenkins/workspace/elastic+kibana+pipeline-pull-request/kibana/x-pack/legacy/plugins/infra/public/components/logging/log_text_stream/log_entry_field_column.test.tsx:35:36)
    at Object.asyncJestTest (/var/lib/jenkins/workspace/elastic+kibana+pipeline-pull-request/kibana/node_modules/jest-jasmine2/build/jasmineAsyncInstall.js:102:37)
    at resolve (/var/lib/jenkins/workspace/elastic+kibana+pipeline-pull-request/kibana/node_modules/jest-jasmine2/build/queueRunner.js:43:12)
    at new Promise (<anonymous>)
    at mapper (/var/lib/jenkins/workspace/elastic+kibana+pipeline-pull-request/kibana/node_modules/jest-jasmine2/build/queueRunner.js:26:19)
    at promise.then (/var/lib/jenkins/workspace/elastic+kibana+pipeline-pull-request/kibana/node_modules/jest-jasmine2/build/queueRunner.js:73:41)
    at process._tickCallback (internal/process/next_tick.js:68:7)

Kibana Pipeline / x-pack-intake-agent / X-Pack Jest Tests.x-pack/legacy/plugins/infra/public/components/logging/log_text_stream.LogEntryFieldColumn should output just text when passed a non-Array

Link to Jenkins

Standard Out

Failed Tests Reporter:
  - Test has not failed recently on tracked branches


Stack Trace

Error: expect(received).toEqual(expected) // deep equality

Expected: "foo"
Received: "\"foo\""
    at Object.it (/var/lib/jenkins/workspace/elastic+kibana+pipeline-pull-request/kibana/x-pack/legacy/plugins/infra/public/components/logging/log_text_stream/log_entry_field_column.test.tsx:92:30)
    at Object.asyncJestTest (/var/lib/jenkins/workspace/elastic+kibana+pipeline-pull-request/kibana/node_modules/jest-jasmine2/build/jasmineAsyncInstall.js:102:37)
    at resolve (/var/lib/jenkins/workspace/elastic+kibana+pipeline-pull-request/kibana/node_modules/jest-jasmine2/build/queueRunner.js:43:12)
    at new Promise (<anonymous>)
    at mapper (/var/lib/jenkins/workspace/elastic+kibana+pipeline-pull-request/kibana/node_modules/jest-jasmine2/build/queueRunner.js:26:19)
    at promise.then (/var/lib/jenkins/workspace/elastic+kibana+pipeline-pull-request/kibana/node_modules/jest-jasmine2/build/queueRunner.js:73:41)
    at process._tickCallback (internal/process/next_tick.js:68:7)

and 4 more failures, only showing the first 3.

History

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

@elastic elastic deleted a comment from kibanamachine Feb 7, 2020
@afgomez afgomez force-pushed the 49154-logs-super-date-picker branch 2 times, most recently from b9e1fde to 4752771 Compare February 10, 2020 13:13
@afgomez afgomez marked this pull request as ready for review February 10, 2020 14:23
@afgomez afgomez requested a review from a team as a code owner February 10, 2020 14:23
@afgomez afgomez added Feature:Logs UI Logs UI feature release_note:enhancement Team:Infra Monitoring UI - DEPRECATED DEPRECATED - Label for the Infra Monitoring UI team. Use Team:obs-ux-infra_services labels Feb 10, 2020
@elasticmachine
Copy link
Contributor

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

@katrin-freihofner
Copy link
Contributor

I think it looks good in general. A few things that I found confusing:

  • The timestamps in the minimap seem off

Screenshot 2020-02-11 at 10 06 34

...and...

Screenshot 2020-02-11 at 10 07 39

  • When extending the timeframe the point in time I'm looking at should not be reset in my opinion.
    date-picker

  • When selecting a timestamp a year ago the loading seems broken. (I can see log lines appearing and then it is loading again....)
    year-view

  • The "this week" time selection does not work for me.

Screenshot 2020-02-11 at 10 06 49

@katrin-freihofner
Copy link
Contributor

One more question came to my mind: with this change, the Stream live functionality is more hidden (date picker needs to be set to from X to now and then I have to scroll to the very bottom to click Stream live). @mukeshelastic any thoughts on this?

Alejandro Fernández Gómez added 10 commits March 11, 2020 15:28
The UI uses `null` extensively. It's easier to allow `null` as a value
in the API than to refactor the UI to use `undefined` instead of `null`,
so let's go with that.
The new API uses io-ts so we have removed the assertions that involve
type checking. If these would be false the test will still fail when
decoding the response.
@afgomez
Copy link
Contributor Author

afgomez commented Mar 17, 2020

@katrin-freihofner sorry for the late reply 🙈

For < 1280px screens:

  • Can we shrink the date picker further?

AFAIK no :(

  • We could definitely save some space with adjustments of the padding, no icons in the customize and highlights button

I think I'd go for no text instead of no icons, but maybe the UX becomes too bad?

I think the buttons will need to be moved out eventually. There's an issue somewhere about using an existing searchbar+datepicker component that exists in kibana already, and if we use it we won't be able to add the buttons in between the search bar and the date selector, so this might be a good chance to think where they could go

  • Have we ever discussed moving the date picker in the same row as the tabs?
    I don't recall, but could be a solution. However, it will be in conflict with my previous sentence.

Copy link
Member

@weltenwort weltenwort left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're almost there...

Alejandro Fernández Gómez added 3 commits March 17, 2020 15:47
Instead of using `useMemo` to update the timestamps we will explicitly
set them up when the user selects a new date range or, if the
`endTimestamp` is `now`, when the user scrolls down.

This still enables infinite scroll and live streaming, but avoids a lot
of unnecessary fetching.
@afgomez afgomez force-pushed the 49154-logs-super-date-picker branch from d0897d9 to af41535 Compare March 17, 2020 16:08
Copy link
Member

@weltenwort weltenwort left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't provoke any unnecessary refetches now. There's just one problem left with the streaming, it seems.

startLiveStreaming: useCallback(() => {
setIsStreaming(true);
jumpToTargetPosition(null);
updateDateRange({ startDateExpression: 'now-1d', endDateExpression: 'now' });
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently the live streaming doesn't fetch new entries.

I think the updateDateRange has to happen on a an interval (useInterval from react-use, for example), doesn't it? It looks like streamEntriesEffect in the log_entries/index.ts drives the timestamp change right now, which sounds the wrong way around. Shouldn't updating the time range on an interval should drive the loading effect? Then that streamEntriesEffect wouldn't have to await the timeout anymore, but could just react to timestamp changes as long as the isStreaming prop is true.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I tried this locally and now I understand why you were hesitant to make such changes 🙈

So now my question becomes: If we revert that latest change about the timestamp calculation, can we commit to immediately start cleaning this up so we don't release something that puts a large burden on the Elasticsearch cluster for a simple browser scroll?

If yes, then it might be prudent to roll back to the continuous endTimestamp update and follow this up with a refactoring of the data flow. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the updateDateRange has to happen on a an interval

I'm not sure. updateDateRange also refreshes the startTimestamp, shifting the range and forcing a reload (...I think, because the effect that triggers a full reload has a isStreaming condition somewhere).

It looks like streamEntriesEffect in the log_entries/index.ts drives the timestamp change right now, which sounds the wrong way around. Shouldn't updating the time range on an interval should drive the loading effect?

Yep, it's not obvious. The state for the streaming is handled in logPosition but the behaviour is handled in logEntries.

I wouldn't change it now. We can address this when we redo this data flow.

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

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

Copy link
Member

@weltenwort weltenwort left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I can't say that I feel totally confident into the data fetching logic (due to no fault of your work in this PR!), it seems to work pretty reliably and doesn't perform excessive refetches in my tests. I'm looking forward to the data flow cleanup. ✨

Thank you for sticking with it. ❤️ This was a very difficult change, but you mastered it. 👏

Copy link
Contributor

@Zacqary Zacqary left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Glad to see this come together!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Logs UI Logs UI feature release_note:enhancement Team:Infra Monitoring UI - DEPRECATED DEPRECATED - Label for the Infra Monitoring UI team. Use Team:obs-ux-infra_services v7.7.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants