eyalkoren

Actually, without this, how would there even be edges `proxy -> d` and `proxy -> d2`? Based on what info?

I will assume "C" in the last comments was meant to be "B", even though the last one is confusing because there is a `c -> d` connection as well...

One more thing to notice- if service B had two nodes behind a load balancer and the user chose to assign each its own unique service name, say - B1...

@dgieselaar response headers are of course an option that opens even more possibilities, however it means an implementation of a new capability by all agents, including the potential added complications...

Let's assume we have these data: ``` { "key" : { "span.destination.hash" : "hashed-service-a-lb:3004", "transaction.upstream.hash" : null, "service.name" : "a", "span.destination.service.resource" : "lb:3004" }, "doc_count" : 278 }, { "key"...

In this case it is actually straightforward to rely on both I think. In other cases, there may be contradictions, so we will have to decide how we treat those....

I believe with the current discussed approach you would be able to draw B and C with proper metrics, but not D. I don't think we can rely on attributing...

> but calls that fail at the gateway or network issues would also fall into that bucket. Exactly, so in this regard it means adding complication but being left with...

We need to consider how proper it is to use attributes for behavioral configurations, or even using specially-prefixed attributes altogether. The major incentive for using OTel API is vendor neutrality....

Following the feedback above, the attribute name used in the Java agent was changed to `co.elastic.discardable`.