You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
#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
The text was updated successfully, but these errors were encountered: