-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[APM] Fixing time comparison types #101423
Conversation
Pinging @elastic/apm-ui (Team:apm) |
@elasticmachine merge upstream |
@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. |
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 |
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? |
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. |
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 I don't understand what "day before" should compare against (calendar to reduce mental gymnastics) |
@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. |
@elasticmachine merge upstream |
Agree, let's keep what we have now but open a separate discussion about how this can be improved. |
x-pack/plugins/apm/public/context/url_params_context/helpers.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/apm/public/context/url_params_context/helpers.ts
Outdated
Show resolved
Hide resolved
.mockReturnValue(moment('2021-06-02T17:00:00.000Z').utc()); | ||
expect(helpers.getExactDate('now/d')?.toISOString()).toEqual( | ||
'2021-06-02T17:00:00.000Z' |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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' | ||
); |
There was a problem hiding this comment.
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.
x-pack/plugins/apm/public/context/url_params_context/helpers.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/apm/public/context/url_params_context/helpers.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/apm/public/components/shared/time_comparison/index.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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.
@sqren are you sure? this is what I got by only removing the Both |
This is what I see:
How do you get that number? According to my logic it should be |
And what do you see when you select |
x-pack/plugins/apm/public/context/url_params_context/helpers.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/apm/public/context/url_params_context/helpers.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/apm/public/context/url_params_context/helpers.ts
Outdated
Show resolved
Hide resolved
jenkins, retest this please |
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
* 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>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
* 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>
…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
Tests OK. Comparisons working as expected. |
Before:
After:
Problem:
Last 24 hours
is selectedThis 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