Mark frontend server spans as synthetic when coming from loadgen

[cedricziel]

Changes

This change will change the way synthetic requests work:

• frontend service will no longer restart the trace
• frontend-proxy will be visible in all traces
• loadgen will be visible in all synthetic traces

This will ensure that service-graphs can correctly be built and we dont artificially hide services, but instead a trace will contain all the hops.

Merge Requirements

For new features contributions please make sure you have completed the following
essential items:

• CHANGELOG.md updated to document new feature additions
• Appropriate documentation updates in the [docs][]

Related: #1180

[julianocosta89]

If we add this change we will drop the example for linked traces.

[cedricziel]

I am sure we can come up with a better one. The current state is hiding too much behind the span link.

I tried looking if we could configure envoy to restart and link, but to no avail :-/

[puckpuck]

We split the traces to showcase trace linking early in the demo's development. Though the traces look nicer when not linked, we specifically try to showcase the OpenTelemetry functionality this PR is removing.

[cedricziel]

@puckpuck I think we it's less about looks, I found it to be confusing when the service graph and trace didn't contain the frontend-proxy. I think we can probably highlight this capability in a better place and I'd be happy to add it somewhere else.

Can you think of a better place that doesn't hide a critical piece of the puzzle? Maybe in a downstream message consumer?

[julianocosta89]

@puckpuck I think we it's less about looks, I found it to be confusing when the service graph and trace didn't contain the frontend-proxy. I think we can probably highlight this capability in a better place and I'd be happy to add it somewhere else.

Can you think of a better place that doesn't hide a critical piece of the puzzle? Maybe in a downstream message consumer?

Quoting the OTel docs here, it seems that the link would be a better fit for the message queue indeed:

Span Links

Links exist so that you can associate one span with one or more spans, implying a causal relationship. For example, let’s say we have a distributed system where some operations are tracked by a trace.

In response to some of these operations, an additional operation is queued to be executed, but its execution is asynchronous. We can track this subsequent operation with a trace as well.

We would like to associate the trace for the subsequent operations with the first trace, but we cannot predict when the subsequent operations will start. We need to associate these two traces, so we will use a span link.

You can link the last span from the first trace to the first span in the second trace. Now, they are causally associated with one another.

Links are optional but serve as a good way to associate trace spans with one another.

I'd be okay with that change.

[puckpuck]

I'm a little hesitant to remove something (child spans for accounting and frauddetection) from our existing traces, but not completely against the idea.

I think it makes sense to have an issue to discuss a better spot for span links and hold off on this PR until we get that resolved and implemented.

[cartersocha]

Vendor support for span link visualization is patchy although we should encourage more representation. Does jaeger display span links well or is just an attribute?

[puckpuck]

Jaeger does support Span Links. Honeycomb does as well.

[cartersocha]

Cool. I’m okay with the change

[julianocosta89]

Dynatrace also supports it

[cedricziel]

Conflicts resolved.

[austinlparker]

Could you post a screenshot of what you're seeing without this PR? I'm a bit confused on if this is working as intended or not.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[julianocosta89]

@cedricziel, did you see this comment?
#1181 (comment)

[cedricziel]

Ahh. Dropped the ball here, sorry. Thanks @julianocosta89 !