Define a standard way to identify synthetics request

[pmm-sumo]

What are you trying to achieve?

Perhaps we could come with a standard way to define that a request is a synthetics call and might be handled accordingly by the service. E.g. special sampling rules could be applied there, etc. Preferably, such information could be kept in a context and stored as a span attribute.

Additionally, it could include ID of the request or even provide new trace ID, which could be used to link the trace and the synthetics request.

The information could be included using trace context or using a specially defined header

Additional context.

Related issue (trace context boundary handling): open-telemetry/opentelemetry-specification#1633

[reyang]

Discussed during the 04/23 triage meeting.
We think OpenTelemetry might want to cover this via semantic convention - if a server library / instrumentation library knows something is a synthetics request, we might want to emit a special attribute so users can act on it (e.g. filter it out).
We think OpenTelemetry might NOT want to define a protocol / context / baggage propagation to unify the synthetics scenarios.

[pmm-sumo]

I think that semantic convention is only a part of the solution. I think that eventually this should be somehow automatically extracted from the request (headers, context, baggage or something else) by the client library.

[yurishkuro]

It is always exceptionally hard to standardize on classification/taxonomy. What is a "synthetic" request? I can think of a number of different explanations, serving different use cases and potentially requiring different handling (e.g. blackbox testing, integration testing, load testing - all different). So simply having synthetic=true is not the answer.