What would you like to be added?

Add explicit and correct HTTP OTLP endpoint behavior for telemetry exporters, and make signal routing semantics clear for logs, metrics, and traces.

This sub-issue is intentionally scoped to:

• HTTP OTLP URL behavior
• signal-specific routing semantics
• config/runtime alignment for endpoint and protocol handling

This sub-issue is not about:

• OTLP auth headers
• proxy or mTLS support
• shutdown/flush behavior
• tracing span modeling

Why is this needed?

Today, Qwen Code initializes all three HTTP OTLP exporters with the same parsedEndpoint value in packages/core/src/telemetry/sdk.ts.

That creates two problems:

1. HTTP OTLP path behavior is not explicit.
2. Signal routing is too coarse.

In practice, this means a configured endpoint like http://collector:4318 or http://collector:4318/ may not have a clearly defined runtime contract for:

• logs
• metrics
• traces

At the Qwen Code layer, the implementation does not currently make it explicit whether the runtime should:

• append standard /v1/logs, /v1/metrics, /v1/traces paths automatically
• require a fully qualified signal-specific endpoint from the user
• support per-signal endpoint overrides

Without that contract, HTTP OTLP behavior is harder to reason about, harder to document, and harder to validate across different collectors/backends.

Additional context

Current code path:

• packages/core/src/telemetry/sdk.ts parses one telemetry endpoint
• that same endpoint is then passed into all three HTTP OTLP exporters

Suggested scope for this sub-issue:

1. Define the expected HTTP OTLP contract for telemetry.otlpEndpoint.
2. Decide whether Qwen Code should:
   • append standard signal-specific OTLP HTTP paths by default, or
   • require explicit full URLs, or
   • support both with documented precedence.
3. Document the signal routing semantics for logs, metrics, and traces.
4. If needed, introduce signal-specific endpoint overrides for HTTP OTLP.
5. Add tests that lock in the intended behavior.

Suggested acceptance criteria:

• HTTP OTLP endpoint behavior is explicit and documented.
• A maintainer can tell exactly where logs, metrics, and traces will be sent for a given config.
• The implementation is covered by tests for at least the common cases:
  • base collector URL
  • collector URL with trailing slash
  • explicit full path URL
  • signal-specific override if supported