[APM] Keep context when drilling down into to a service from another

[roshan-elastic]

📖 Problem

When users drill into dependencies between services, they are presented with latency, throughput and error rates between them. However, they aren't able to drill into which APIs are being called, which are slow/erroring and drill into the actual transactions themselves:

The user has no way to drill down into this in more detail - it is a 'black box'

Currently, as users click through on the dependency to learn more about the relationship between the two services, the context is lost:

As the user clicks into the service to the 'newsletter-otel' service to understand more about the dependency, the context of 'emailService' is lost

Background

A video explanation:

understanding.depedencies.and.drilling.down.mp4

👤 User Stories

• As an SRE, when I see high latency between two services...I want to see which APIs are most affected and drill into the transactions which were high in latency

• As an SRE, when I see errors between two services...I want to see which APIs are most affected and drill into the transactions which were erroring

💡 Solution

TBC

✔️ Acceptance criteria

draft

1. Must Have

Must be delivered in this issue in order for the release to be valuable

Name	Description	Notes
The user must be able to see which APIs are being called	e.g. /subscribe. This must show the latency, throughput and error rate	This must be from the dependency tab where the latency, throughput and error rate are presented
The user must be able to easily drill into samples of the affected transactions	They must be able to dig into the overall transactions but also per API	-
The solution must involve no typing by the user	The user should not need to understand ECS or fields	"No elastic expertise needed"

2. Should Have

Name	Description	Notes
-	-	-

3. Could Have

Would be nice to have but not critical

Name	Description	Notes
-	-	-

4. Will Not Have (for now)

Explicitly will not be looked at within this issue

Name	Description	Notes
-	-	-

[roshan-elastic]

Hey @smith, this just came up in an escalation for a deal support request. I'm not sure how this should be prioritised but do you think anyone like @sqren might be able to cast his eye over it to get a sense of whether a solution might quite challenging or whether there may be an easy way to achieve this?

Note : I haven't added this to the project backlog as I wanted to check whether this should actually be a project

[roshan-elastic]

cc @akhileshpok

[elasticmachine]

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

[sorenlouv]

I think this makes sense. We haven't spend much time on improving this dependency work flow after the initial release and I see this as a natural next iteration which we have previously discussed doing (but never got around to).

[roshan-elastic]

Note : Next steps, I'll work with @smith to see at what stage it looks sensible to try and tackle this.

[roshan-elastic]

Hey @smith - do you think this is too big for the backlog?

I'm trying to figure out whether this is something that could be prioritised in the sustenance backlog or should be a small project (in which case, I'd create one and get it prioritised in the new process).

I'm thinking it should probably be a project but would be good to get your take on this.

[smith]

Probably a project, as we probably want to design the flows around this.

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.