go-test-trace
go-test-trace copied to clipboard
Document go-test-trace global trace context propagation to go test
Currently, go-test-trace propagates the global context to go test via TRACE_CONTEXT environmental variable, but this feature is not documented and it's not clear what the limitations are.
Buildkit supports OTEL_TRACE_PARENT
OTEL_TRACE_STATE
for propagation https://github.com/moby/buildkit/blob/44891f4cb975ac70d62d40139ba819fe855da59c/util/tracing/env/traceenv.go#L21-L23 https://github.com/moby/buildkit/blob/44891f4cb975ac70d62d40139ba819fe855da59c/util/tracing/exec/traceexec.go#L23-L29 . It isn't my invention and there is prior tooling but not spec atm. @Aneurysm9 seemed ok for making something like this at least semi-official.
The grpc endpoint address in env is defined in spec though https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/exporter.md#configuration-options and is automatically supported by library but I think the way endpoint is overwritten from a flag disables this behavior https://github.com/rakyll/go-test-trace/blob/main/main.go#L63
See also https://github.com/open-telemetry/opentelemetry-specification/issues/740.
There's a few examples of tools that have settled on TRACEPARENT
and TRACESTATE
environment variables. TIL that Buildkit also has environment variable support.
Maybe it would be worth weighing in there as it seems there is some growing effort towards standardising? It would be great if this Just Worked™ out of the box.
Once https://github.com/open-telemetry/opentelemetry-specification/issues/740 is settled, I'm happy to adopt what's there. I agree that standardization is useful, so we have the primitive utilities for propagation available in every language.
Switched to TRACEPARENT interim, let's adjust it to whatever open-telemetry/opentelemetry-specification#740 ends up choosing.