feat(rum-core): capture XHR/Fetch spans using resource timing

[vigneshshanmugam]

• fix capture Fetch/XHR calls using ResourceTiming API #740
• This PR addresses the problem when the agent is downloaded asynchronously and we miss the XHR and fetch spans that happened before the patch agent script kicks in. However, we wont be able to propagate the trace header and distributed tracing for these cases wont work.
• Span names & types are not in sync with the patched ones as we want to distinguish them and would make it clear for the users that distributed tracing for the spans captured via resource.* wont work.

// resource
name - 'http://example.com/fetch'
type - 'resource.fetch'

// patched
name - 'GET http://example.com/fetch'
type - 'external.http'

• Ignore the Intake API endpoint using resource name, as we could end up creating lots of spans for every events beacon and we cannot rely on bootstrap time and start time (browser bugs) for this endpoint alone.

• Comparison logic is modified to take two things in to account

  1. Full URL's including query params as the web page may call the same endpoint with different queries and we have to capture them as separate spans
  2. Span start time as same request with same query params could happen before our patch kicked in and we have to capture them as different spans.

TODO

• handle when /example request happened before agent script kicks in and another /example request caught via patching. These are two separate requests and we must create two spans instead of one.
• Add more tests for the filtering logic with relative and absolute URL's.
• Ignore intake API from spans

[apmmachine]

💚 Build Succeeded

Expand to view the summary

Build stats

• Build Cause: [Branch indexing]

• Start Time: 2020-07-01T01:46:06.344+0000

• Duration: 102 min 24 sec

Test stats 🧪

Test	Results
Failed	0
Passed	950
Skipped	10
Total	960

Steps errors

Expand to view the steps failures

• Name: Bundlesize

  • Description: #!/bin/bash set -o pipefail npm run bundlesize|tee bundlesize.txt

  • Duration: 1 min 34 sec

  • Start Time: 2020-07-01T01:51:54.744+0000

  • log

• Name: Start Elastic Stack 8.0.0-SNAPSHOT - @elastic/apm-rum-core - saucelabs

  • Description:

  • Duration: 8 min 0 sec

  • Start Time: 2020-07-01T02:19:04.506+0000

  • log

• Name: Error signal

  • Description:

  • Duration: 0 min 0 sec

  • Start Time: 2020-07-01T02:27:04.926+0000

  • log

• Name: Error signal

  • Description: The test failed

  • Duration: 0 min 0 sec

  • Start Time: 2020-07-01T03:12:26.171+0000

  • log

[hmdhk]

Thanks @vigneshshanmugam

A simpler solution for this issue might be to store the time we patch XHR (execution time) and use that time to capture spans from the resource timing, i.e. all the resources that have their start time before our execution time should be captured from the resource timing and all the rest are captured by the xhr patch. this would avoid having to loop over the spans to find the unique ones. Have you considered this solution?

side note: the execution time can be stored in the state object that will be introduced with #813

[vigneshshanmugam]

@jahtalab Nice suggestion 👍, I had the similar thought initially(not now) when i started working on RUM on why we were using filterUrls instead of patch time. I thought the reason we didn't go for that solution was due to two reasons.

1. We cannot rely on Resource timing startTime since it can be buggy in browsers.
2. Users can disable instrumentation of XHR and Fetch.

But as you said, It's simpler solution without doing the URL and for loop dance. ? I am happy with modifying the PR. WDYT?

[apmmachine]

📦 Bundlesize report

Filename	Size(bundled)	Size(gzip)	Diff(gzip)
elastic-apm-opentracing.umd.min.js	59.5 KiB	19.1 KiB
elastic-apm-rum.umd.min.js	53.6 KiB	17.6 KiB

[hmdhk]

@vigneshshanmugam , Have you looked at the tests? is there an issue?

[vigneshshanmugam]

@jahtalab Its just travis. The tests passed though- https://travis-ci.org/github/elastic/apm-agent-rum-js/builds/703572041. I am going to ignore it.