[APM] Time spent by span type chart rendering problem

[crespocarlos]

Summary

The Time spent by span type chart has problems rendering the data when:

1 - There are big gaps between metric collection. This causes the percentage calculation to generate really small numbers eg subBucket.total_self_time_per_subtype.value=3539 and sumAllSelfTimes=36963655477 results in 4.7769449682984235e-8

2 - For some reason, the chart renders the data points incorrectly in this situation. In the example below HTMLWrappedInJSON value is 0 at that timestamp, but the line spikes as if the value was 100%

Possible fix

• On percentage calculation we need to clamp and format the number using fixed-point notation, eg: Math.min(Math.max(percentage, 0), 1).toFixed(12)
• On the breakdown_chart , there seem to be something on AreaSeries usage missing, that is present on timeseries_component

How to reproduce

• Run this script
  • node ./generate_transaction_spent_by_span_response.js > response.json
• Override the response of .*/internal/apm/services/.*/transaction/charts/breakdown with the json above
• Navigate to Service Overvview > Transactions tab

[elasticmachine]

Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services)

[miloszmarcinkowski]

2 - For some reason, the chart renders the data points incorrectly in this situation. In the example below HTMLWrappedInJSON value is 0 at that timestamp, but the line spikes as if the value was 100%

The chart represents values proportionally with alphabetical order (from the bottom to the top). Therefore, if the one value spikes, it raises the lines for all the following values.

Consider this example (2nd value occupies 99%, therefore 3rd value spikes to the top):

In this example, I swapped the order, so the 1st value occupies 99%. This causes the 2nd and 3rd values to spike to the top:

This isn't clearly visible in the example from SDH because their chart is broken due to negative numbers being provided. That is the reason for lines to cross. I addressed the problem in my PR. However, it would be good to investigate APM server to find why negative values happened in the first place.

SHD scenario with negative values (original): Customer HAR:

SHD scenario with negative values clamped to zero (after fix):