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

[APM] Fixing time comparison types #101423

Merged
merged 9 commits into from
Jun 16, 2021

Conversation

cauemarcondes
Copy link
Contributor

@cauemarcondes cauemarcondes commented Jun 4, 2021

Before:
image (2)
image (3)

After:
Screen Shot 2021-06-04 at 14 46 34
Screen Shot 2021-06-04 at 14 46 43
Screen Shot 2021-06-04 at 14 48 14
Screen Shot 2021-06-04 at 14 48 24
Screen Shot 2021-06-04 at 14 48 41
Screen Shot 2021-06-04 at 14 48 55
Screen Shot 2021-06-04 at 14 59 03

Problem:

  • When Last 24 hours is selected
    This is the how the url looks like apm/services?rangeFrom=now-24h/h&rangeTo=now
    And this is the conversion from relative to absolute time start: "2021-06-02T16:00:00.000Z", end: "2021-06-03T16:02:52.650Z"
    When I get the difference in DAYS between the start and end I get 1.001998263888889
    The result is more than one day, even though last 24 hours is selected.
    What causes this? The extra /h on rangeFrom=now-24h/h rounds the start date.
    If we remove the extra /h this is the result of the conversion: start: "2021-06-02T16:07:23.280Z", end: "2021-06-03T16:07:23.280Z" now we have exactly 1 day.
    The same thing happens when Last 7 days is selected, because of the extra /d we the difference is always bigger than 7 days.

Solution

The right way to calculate the difference between the start and end dates is to use both absolute values instead of the rounded ones. So a new property was added inside the routeParams to represent the exact start and end dates, and these values are used to get comparison types available withing the time raange

@cauemarcondes cauemarcondes requested a review from a team as a code owner June 4, 2021 19:00
@botelastic botelastic bot added the Team:APM All issues that need APM UI Team support label Jun 4, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/apm-ui (Team:apm)

@cauemarcondes
Copy link
Contributor Author

@elasticmachine merge upstream

@dgieselaar
Copy link
Member

@cauemarcondes I'm having a little trouble understanding the changes 😄 do you mind helping me out by writing down some notes about why certain changes were necessary? Also happy to zoom about it later today.

@cauemarcondes
Copy link
Contributor Author

@cauemarcondes I'm having a little trouble understanding the changes 😄 do you mind helping me out by writing down some notes about why certain changes were necessary? Also happy to zoom about it later today.

Sorry, @dgieselaar I added more details in the description.

@dgieselaar
Copy link
Member

I wonder whether we are making it too hard on ourselves here by trying to make decisions upfront about what would be valuable to the user. Can we simplify this by allowing the user to pick any offset, regardless of the currently selected time range? cc @sqren @formgeist

@sorenlouv
Copy link
Member

sorenlouv commented Jun 9, 2021

Can we simplify this by allowing the user to pick any offset, regardless of the currently selected time range?

Are you proposing to have a secondary date picker, where the user can select an arbitrary start date for the comparison range?

I'm a bit on the fence on this one. The advantages is that it would reduce our (code) logic, and allow the user to make any kind of comparisons they want.

At the same time I think reducing the users choice to simply a list of comparison options (instead of selecting a date in a date picker) is better UX. Especially if the user is looking at "Today", it's handy to allow them to compare with "Yesterday" and "Last week" with as few clicks (and as little cognitive load) as possible.

WDYT @formgeist?

@formgeist
Copy link
Contributor

I agree that we have these specific options in place to avoid cognitive load for the user. We did discuss at one point to allow for offset intervals such it would always use the same interval as selected but you could essentially choose whether it was +1 or +4 weeks. I think this came up in a discuss comment on our feedback request. I think we should open this up for discussion and potential iteration but I wouldn't consider this a prerequisite before merging this PR that essentially makes our logic more consistent.

@dgieselaar
Copy link
Member

Are you proposing to have a secondary date picker, where the user can select an arbitrary start date for the comparison range?

No, just to not filter the predefined options. So just always show "day before", "week before", "period before".

@sorenlouv
Copy link
Member

sorenlouv commented Jun 9, 2021

No, just to not filter the predefined options. So just always show "day before", "week before", "period before".

If a user is viewing the time range 14th to 21st of May, and selects "week before", the comparison should be against 7th to 14th of May.

I don't understand what "day before" should compare against

(calendar to reduce mental gymnastics)

image

@dgieselaar
Copy link
Member

@sqren it's a 1 day offset. so if you select last 7 days, you'd be comparing it against last 8 days - last day. It feels somewhat useless, but IMHO there's some complexity involved here in trying to make the displayed options super relevant, and I'm not sure if we've solved all edge cases now.

@cauemarcondes
Copy link
Contributor Author

@elasticmachine merge upstream

@sorenlouv
Copy link
Member

I think we should open this up for discussion and potential iteration but I wouldn't consider this a prerequisite before merging this PR that essentially makes our logic more consistent.

Agree, let's keep what we have now but open a separate discussion about how this can be improved.

Comment on lines 185 to 187
.mockReturnValue(moment('2021-06-02T17:00:00.000Z').utc());
expect(helpers.getExactDate('now/d')?.toISOString()).toEqual(
'2021-06-02T17:00:00.000Z'
Copy link
Member

Choose a reason for hiding this comment

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

How does this test verify that the date is not being rounded when the original date is already rounded.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, it actually doesn't make much sense to expect for a specific date. I'd rather spy the datemath.parse and check if it was called correctly.

Comment on lines 175 to 180
jest
.spyOn(datemath, 'parse')
.mockReturnValue(moment('2021-06-02T17:56:49.260Z').utc());
expect(helpers.getExactDate('now-24h/h')?.toISOString()).toEqual(
'2021-06-02T17:56:49.260Z'
);
Copy link
Member

Choose a reason for hiding this comment

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

You should also call datemath.parse('now-24h/h') directly to show that the default behaviour is to round.

Copy link
Member

@sorenlouv sorenlouv left a comment

Choose a reason for hiding this comment

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

Remove isRangeToNow should be enough to solve the problem. Still, the refactoring and added tests should stay.

@cauemarcondes
Copy link
Contributor Author

Remove isRangeToNow should be enough to solve the problem. Still, the refactoring and added tests should stay.

@sqren are you sure? this is what I got by only removing the isRangeToNow and selecting last 24hours:
Screen Shot 2021-06-14 at 11 45 39

Both Day before and Week before should be available, but instead only Week before is. That's because the difference is 1.031450949074074.

@sorenlouv
Copy link
Member

sorenlouv commented Jun 14, 2021

@sqren are you sure? this is what I got by only removing the isRangeToNow and selecting last 24hours:

This is what I see:

image

image

That's because the difference is 1.031450949074074.

How do you get that number? According to my logic it should be 24 hours - 1 millisecond = 0.999999988 days (thanks Google)

image

This is also what I'm seeing when logging the dateDiff:
image

@cauemarcondes
Copy link
Contributor Author

@sqren are you sure? this is what I got by only removing the isRangeToNow and selecting last 24hours:

This is what I see:

image

image

That's because the difference is 1.031450949074074.

How do you get that number? According to my logic it should be 24 hours - 1 millisecond = 0.999999988 days (thanks Google)

image

This is also what I'm seeing when logging the dateDiff:
image

And what do you see when you select Last 7 days?

@cauemarcondes
Copy link
Contributor Author

jenkins, retest this please

@cauemarcondes
Copy link
Contributor Author

@elasticmachine merge upstream

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
apm 4.3MB 4.3MB +686.0B

History

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

@cauemarcondes cauemarcondes added the auto-backport Deprecated - use backport:version if exact versions are needed label Jun 16, 2021
@cauemarcondes cauemarcondes merged commit adc95c1 into elastic:master Jun 16, 2021
@cauemarcondes cauemarcondes deleted the apm-fix-time-comparison branch June 16, 2021 18:32
kibanamachine added a commit to kibanamachine/kibana that referenced this pull request Jun 16, 2021
* fixing time comparison types

* fixing ts issues

* addressing PR comments

* addressing PR comments

* addressing PR comments

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
@kibanamachine
Copy link
Contributor

💚 Backport successful

Status Branch Result
7.x

This backport PR will be merged automatically after passing CI.

kibanamachine added a commit that referenced this pull request Jun 16, 2021
* fixing time comparison types

* fixing ts issues

* addressing PR comments

* addressing PR comments

* addressing PR comments

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

Co-authored-by: Cauê Marcondes <55978943+cauemarcondes@users.noreply.github.com>
jloleysens added a commit to jloleysens/kibana that referenced this pull request Jun 17, 2021
…egrations-to-global-search

* 'master' of github.com:elastic/kibana: (46 commits)
  [Lens] Add some more documentation for dynamic coloring (elastic#101369)
  hide not searchable results when no term (elastic#102401)
  [Lens] Fix Formula functional test with multiple suggestions (elastic#102378)
  Fix trusted apps modified by field displayed as a date field (elastic#102377)
  [Lens] Docs for time shift (elastic#102048)
  update readme of logs-metrics-ui (elastic#101968)
  Refactor observability plugin breadcrumbs (elastic#102290)
  [Index Patterns] Move rollup config to index pattern management v2 (elastic#102285)
  [Security Solution][Endpoint] Isolate Action should only be available to Platinum+ licenses (elastic#102374)
  [build] Updates Ironbank templates (elastic#102407)
  Update security best practices document (elastic#100814)
  [Enterprise Search] Set up initial KibanaPageTemplate  (elastic#102170)
  [Reporting/Docs] Add section to troubleshooting guide to explain the StatusCodeError logs (elastic#102278)
  [DOCS] Updating Elastic Security Overview topic  (elastic#101922)
  [Uptime] refactor Synthetics Integration package UI (elastic#102080)
  [Task Manager] Log at different levels based on the state (elastic#101751)
  [APM] Fixing time comparison types (elastic#101423)
  [RAC] Update alert documents in lifecycle rule type helper (elastic#101598)
  [ML] Functional tests - fix and re-activate alerting flyout test (elastic#102368)
  [Reporting] remove unused reference to path.data config (elastic#102267)
  ...

# Conflicts:
#	x-pack/plugins/fleet/kibana.json
@smith
Copy link
Contributor

smith commented Jul 16, 2021

Tests OK. Comparisons working as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
apm:comparison apm:test-plan-7.14.0 apm:test-plan-done Pull request that was successfully tested during the test plan auto-backport Deprecated - use backport:version if exact versions are needed release_note:fix Team:APM All issues that need APM UI Team support v7.14.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants