What happened:
InitTracing in pkg/common/observability/tracing/telemetry.go only recognizes OTEL_TRACES_EXPORTER=otlp; every other value, including none, falls through to the console (stdouttrace) exporter, which is also what runs when the variable is unset. Setting OTEL_TRACES_EXPORTER=none does not disable span export.
What you expected to happen:
OTEL_TRACES_EXPORTER=none should behave the way it does in llm-d-router's pkg/common/observability/tracing package: no exporter or batcher gets registered, so no spans leave the process, while spans are still created and the trace-context propagator stays installed, so downstream components still see a valid, correlated trace context. An unrecognised value should be reported instead of silently falling back to console.
How to reproduce it (as minimally and precisely as possible):
- Set OTEL_TRACES_EXPORTER=none and start the payload processor.
- Spans are still pretty-printed to stdout by the console exporter instead of being suppressed.
Anything else we need to know?:
This is part of aligning the InitTracing implementations across the llm-d repos on one OTEL_TRACES_EXPORTER=none|otlp|console convention, described in llm-d/llm-d#2388 (proposal: selective tracing for llm-d). llm-d-router and llm-d-workload-variant-autoscaler already implement the three-value switch; llm-d-kv-cache and llm-d-batch-gateway still need the same alignment.
/cc @nirrozenbaum
What happened:
InitTracing in pkg/common/observability/tracing/telemetry.go only recognizes OTEL_TRACES_EXPORTER=otlp; every other value, including none, falls through to the console (stdouttrace) exporter, which is also what runs when the variable is unset. Setting OTEL_TRACES_EXPORTER=none does not disable span export.
What you expected to happen:
OTEL_TRACES_EXPORTER=none should behave the way it does in llm-d-router's pkg/common/observability/tracing package: no exporter or batcher gets registered, so no spans leave the process, while spans are still created and the trace-context propagator stays installed, so downstream components still see a valid, correlated trace context. An unrecognised value should be reported instead of silently falling back to console.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
This is part of aligning the InitTracing implementations across the llm-d repos on one OTEL_TRACES_EXPORTER=none|otlp|console convention, described in llm-d/llm-d#2388 (proposal: selective tracing for llm-d). llm-d-router and llm-d-workload-variant-autoscaler already implement the three-value switch; llm-d-kv-cache and llm-d-batch-gateway still need the same alignment.
/cc @nirrozenbaum