Header Propagation

Header propagation is commonly implemented using distributed tracing libraries. Signadot Workspaces supports the following header formats in HTTP 1/2 and gRPC and the corresponding tracing libraries.

OpenTelemetry Tracing

There are two mechanisms of propagation that are supported from the OpenTelemetry specification: baggage and tracestate. In both of these cases, a key named sd-workspace is used to persist information pertaining to Workspaces.

If you're making use of OpenTelemetry instrumentation in your services, baggage and tracestate headers are propagated automatically.

Jaeger Tracing

A header named uberctx-sd-workspace is expected to be propagated by your services. If you're making use of Jaeger instrumentation in your services, headers in this format are propagated automatically.

Datadog Tracing

A header named ot-baggage-sd-workspace is expected to be propagated by your services. If you're using Datadog's Go language instrumentation libraries, headers in this format are propagated automatically. Support in other languages depends on the library being used and the mode in which it's used.

Custom Instrumentation

If you are not using the above libraries, we recommend that you make use of the baggage header as described in the W3C Baggage Specification. Services would need to propagate this header from each incoming request to any outgoing requests the original handler makes.

The headers that will be set on the entry-point service when using a Signadot preview URL will be in the following format and the application must propagate this header as-is (or with modifications according to the W3C spec) to other services in the system.

baggage: sd-workspace=<workspace-id>

Did this page help you?