[ML] APM Correlations: Fix chart errors caused by inconsistent histogram range steps.#138259
Conversation
4c7e405 to
64fff29
Compare
|
Pinging @elastic/ml-ui (:ml) |
...plugins/apm/public/components/app/correlations/use_failed_transactions_correlations.test.tsx
Outdated
Show resolved
Hide resolved
|
Pinging @elastic/apm-ui (Team:apm) |
|
Tested and LGTM 🎉 As for whether to show the continuous line, I think it's less crowded to not show the line when the values are 0 but have no strong opinion about it. |
@walterra I would prefer the lines would disappear if |
| durationMax, | ||
| } = overallHistogramResponse; | ||
|
|
||
| const errorHistogramResponse = await callApmApi( |
There was a problem hiding this comment.
Have you considered not blocking this call? So we'd render the chart with the histogram and load the errors later? We could even add an indication that errors are still being fetched on the UI.
cc: @formgeist
There was a problem hiding this comment.
Good suggestion, I tweaked the loading behavior in 85b2ff2. After loading the overall histogram data we'll now already trigger an update that displays the chart with the available data and updates the progress bar. The updated jest tests also reflect the updated progress steps of the progress bar.
| const { | ||
| overallHistogram, | ||
| totalDocCount, | ||
| percentileThresholdValue, | ||
| durationMin, | ||
| durationMax, | ||
| } = await callApmApi( | ||
| 'POST /internal/apm/latency/overall_distribution/transactions', | ||
| { | ||
| signal: abortCtrl.current.signal, | ||
| params: { | ||
| body: { | ||
| ...fetchParams, | ||
| percentileThreshold: DEFAULT_PERCENTILE_THRESHOLD, | ||
| chartType: LatencyDistributionChartType.latencyCorrelations, |
There was a problem hiding this comment.
This call is exactly the same as the one on x-pack/plugins/apm/public/components/app/correlations/use_failed_transactions_correlations.ts do you think it is worth extracting it and reusing it?
There was a problem hiding this comment.
Since we'd like to get this as a bugfix into 8.4 I'd like to avoid more refactoring, I added a comment to the meta issue in the tech debt section instead to follow up on it (Revisit hooks that fetch correlations results and possibly consolidate duplicate code like fetching the overall histogram.): #118009
| xScaleType={ScaleType.Log} | ||
| yScaleType={ScaleType.Log} | ||
| data={replaceHistogramDotsWithBars(d.histogram)} | ||
| data={replaceHistogramZerosWithMinimumDomainValue(d.histogram)} |
There was a problem hiding this comment.
Do you think wrapping it on a useMemo would help? At least it wouldn't recalculate on every render.
|
@formgeist @qn895 thanks for the feedback I kept original look now with the lines being interrupted when they hit 0. |
|
@cauemarcondes Thanks for your feedback, I addressed your comments, ready for another look. |
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: cc @walterra |
|
Tested latest changes and functionally LGTM 🎉 |
…ram range steps. (elastic#138259) The `AreaSeries` for the latency correlations charts expect the provided timestamp keys for each series to be the same, otherwise there might be errors in how the chart renders the areas. In some cases this could happen because we fetch the data for the areas independently (for example overall latency and failed transactions latency). The fix provided by this PR adds optional `durationMin` and `durationMax` parameters to affected endpoints. This way the `durationMin/Max` returned by the first area request (for example "overall latency") can be passed on to the second request to enforce the same buckets/keys (for example for "failed transaction latency"). (cherry picked from commit 3aabd88)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
…ram range steps. (elastic#138259) (elastic#138637) The `AreaSeries` for the latency correlations charts expect the provided timestamp keys for each series to be the same, otherwise there might be errors in how the chart renders the areas. In some cases this could happen because we fetch the data for the areas independently (for example overall latency and failed transactions latency). The fix provided by this PR adds optional `durationMin` and `durationMax` parameters to affected endpoints. This way the `durationMin/Max` returned by the first area request (for example "overall latency") can be passed on to the second request to enforce the same buckets/keys (for example for "failed transaction latency"). (cherry picked from commit 3aabd88) Co-authored-by: Walter Rafelsberger <walter@elastic.co>
…ram range steps. (elastic#138259) The `AreaSeries` for the latency correlations charts expect the provided timestamp keys for each series to be the same, otherwise there might be errors in how the chart renders the areas. In some cases this could happen because we fetch the data for the areas independently (for example overall latency and failed transactions latency). The fix provided by this PR adds optional `durationMin` and `durationMax` parameters to affected endpoints. This way the `durationMin/Max` returned by the first area request (for example "overall latency") can be passed on to the second request to enforce the same buckets/keys (for example for "failed transaction latency").

Summary
The
AreaSeriesfor the latency correlations charts expect the provided timestamp keys for each series to be the same, otherwise there might be errors in how the chart renders the areas. In some cases this could happen because we fetch the data for the areas independently (for example overall latency and failed transactions latency).The fix provided by this PR adds optional
durationMinanddurationMaxparameters to affected endpoints. This way thedurationMin/Maxreturned by the first area request (for example "overall latency") can be passed on to the second request to enforce the same buckets/keys (for example for "failed transaction latency").This also updates the chart code to make use of some newly available styles in Elastic Charts for orphaned points (elastic/elastic-charts#1505)
Before:
After:
Checklist