When an SRE is troubleshooting issues detected by synthetic monitoring test runs, one of the key questions they need to understand is "where" the problem is occurring. Is it something to do with a third party, content rendering or something else "front end" or is it related to a slow database, long network response etc ie "back-end".
The page load waterfall in synthetics is a key area this determination is made. In order to facilitate seamless issue triage and investigation, we want to:
Link from any network request in that waterfall to the relevant distributed trace for that request during that test run in the APM UI
Gracefully handle requests where this may not
Open links in a new tab so the user does not lose context
optional Suggest instrumenting the application with APM agents where relevant
When an SRE is troubleshooting issues detected by synthetic monitoring test runs, one of the key questions they need to understand is "where" the problem is occurring. Is it something to do with a third party, content rendering or something else "front end" or is it related to a slow database, long network response etc ie "back-end".
The page load waterfall in synthetics is a key area this determination is made. In order to facilitate seamless issue triage and investigation, we want to:
Related historical investigations:
https://github.com/elastic/synthetics/issues/265 https://github.com/elastic/apm-dev/issues/926 https://github.com/elastic/app-obs-dev/issues/13 https://github.com/elastic/app-obs-dev/issues/13