SDK: Samplers should be able to modify tracestate

[lmolkova]

What are you trying to achieve?

Samplers may need to modify tracestate to enable vendor-specific sampling algorithms.

Additional context.

One of the examples is described here: open-telemetry/oteps#135, where sampling score is calculated by the first service and downstream services can still use the score instead of re-calculating it using a potentially different algorithm.

The spec does not define type for tracestate and implementations use simple string or have a specific type.

Proposal:

1. Update SamplingResult to have Tracestate with the type used by the OTel API specific to the language.

2. Add requirement for SDK to populate tracestate received from sampler on span-to-be-created.

3. [questionable] If aggregated sampler (with nested ones) is configured, outer sampler should take care of merging tracestate. Alternative is adding tracestate argument to ShouldSample callback to propagate outer changes to inner samplers.

[anuraaga]

Hey - just wanted to check, is this the same as in #854?

Also, do they solve open-telemetry/opentelemetry-proto#166? That is looking at adding a dedicated field for sampling decisions but if we need to propagate it anyways, just parsing it out of tracestate seems simpler.

[bogdandrutu]

From @narayaruna

Use case:
In order to implement one or more custom sampling strategies. For example - control service participation in a trace. Imagine the following topology.

A -> B -> C -> D

Service A doesn't sample the incoming request however the trace context is initialized and sent downstream with sampling decision set to false.
Service B is configured to start a trace for all (100% sampling) the requests matching the path /foo. It encodes this sampling decision in the trace state so any downstream services can participate.
Service C doesn't do anything but propagates the context down.
Service D is configured to participate in the trace initiated by Service B. It looks up the trace state and makes a sampling decision to record the spans.
Basically the ask is to provide hooks/API changes to support such a use case. Specifically, in this example service B will need access to modify trace state where the sampling decision is taken. Service D will need access to the trace state to make a sampling decision.

[bogdandrutu]

@anuraaga this is not resolving open-telemetry/opentelemetry-proto#166, this issue asks for the ability to modify trace-state in the Sampler API, one use-case may be to record a sampling decision and propagate it, but there are other use-cases as well. Also most likely because this is a custom field in the tracestate (vendor specific) we cannot consume it in the collector.

[anuraaga]

@bogdandrutu Thanks, I don't quite understand the point about not being able to consume in the collector. Don't we copy the trace state in as is in OTLP which would be visible in the collector?

https://github.com/open-telemetry/opentelemetry-proto/blob/master/opentelemetry/proto/trace/v1/trace.proto#L80

If so, my understanding is the ability to mutate trace state with sampling decisions would automatically also allow exporting it to collector too, without having to add a new field.

[Oberon00]

I would also expect the collector to be able to consume all custom fields. It might be equipped with a vendor-specific exporter after all that needs to read vendor-specific fields.

[bogdandrutu]

The collector does not know how to parse vendor specific values in the TraceState so will not be able to consume that. If we do have a OTel entry in the TraceState that may be something the collector may know how to interpret.

[Oberon00]

Vendor-specific modules can be added to the Collector, can't they?