Honor standard OpenTelemetry OTLP env vars for exporter enablement

[Copilot]

The OTLP exporter was gated solely behind the SDK-specific DOTNET_CLI_TELEMETRY_ENABLE_EXPORTER flag, ignoring the standard OpenTelemetry OTLP env-var conventions. Users who configured an OTLP endpoint via the standard variables saw no export.

Changes

• TelemetryClient.cs — s_enableOtlpExporter now ORs the existing opt-in with a new IsOtlpExporterConfiguredByStandardEnvVars() check. AddOtlpExporter() continues to be called with no inline config, so OtlpExporterOptions reads endpoint/protocol/headers/timeout from the standard env vars itself.
• EnvironmentVariableNames.cs — Added OtlpExporterEnvVars, the set of standard names whose presence indicates user intent to enable OTLP: OTEL_EXPORTER_OTLP_{ENDPOINT,PROTOCOL,HEADERS,TIMEOUT} plus the _TRACES_* and _METRICS_* signal-specific variants.
• telemetry.md — Documents the new enablement conditions and the supported env-var set.

Resulting enablement logic:

enable OTLP exporter
  if DOTNET_CLI_TELEMETRY_ENABLE_EXPORTER is true
  or any OTEL_EXPORTER_OTLP_* variable is set

[Copilot]

Pull request overview

This PR updates the .NET SDK/CLI telemetry pipeline to enable the OpenTelemetry OTLP exporter not only via the SDK-specific DOTNET_CLI_TELEMETRY_ENABLE_EXPORTER flag, but also when users configure OTLP using standard OTEL_EXPORTER_OTLP_* environment variables (so that standard OpenTelemetry configuration “just works”).

Changes:

• Add a centralized list of standard OTLP env var names used to infer exporter intent (EnvironmentVariableNames.OtlpExporterEnvVars).
• Update TelemetryClient OTLP enablement to OR the existing SDK flag with detection of any configured standard OTLP env vars.
• Document the new enablement behavior and the recognized env var set in telemetry.md.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/Common/EnvironmentVariableNames.cs	Adds a set of OTLP-related OTEL_EXPORTER_OTLP_* env var names used to infer OTLP exporter enablement.
src/Cli/dotnet/Telemetry/TelemetryClient.cs	Extends OTLP exporter enablement logic to trigger when standard OTLP env vars are present.
documentation/project-docs/telemetry.md	Documents OTLP exporter enablement and the supported standard env var set.

Comments suppressed due to low confidence (2)

src/Cli/dotnet/Telemetry/TelemetryClient.cs:62

• IsOtlpExporterConfiguredByStandardEnvVars treats an env var set to an empty string as “not configured” (string.IsNullOrEmpty). If the intent is enablement based on presence (as described in the PR and comments), this should check for null rather than emptiness (and/or update the documentation to explicitly require a non-empty value).

        foreach (var name in EnvironmentVariableNames.OtlpExporterEnvVars)
        {
            if (!string.IsNullOrEmpty(Env.GetEnvironmentVariable(name)))
            {
                return true;

src/Cli/dotnet/Telemetry/TelemetryClient.cs:49

• This PR changes OTLP exporter enablement behavior based on standard OTEL_EXPORTER_OTLP_* env vars, but there don’t appear to be any tests covering that enablement path. Please add coverage that verifies OTLP is enabled when a standard OTLP env var is present and remains disabled when none are set (ensuring the test sets env vars before TelemetryClient type initialization).

    private static readonly bool s_enableOtlpExporter =
        Env.GetEnvironmentVariableAsBool(EnvironmentVariableNames.DOTNET_CLI_TELEMETRY_ENABLE_EXPORTER)
        || IsOtlpExporterConfiguredByStandardEnvVars();
    private static readonly int s_flushTimeoutMs = 200;

[joeloff]

@baronfel isn't this odd? The latter set of variables seems to select what is exported (just going off their names) and the first variable seem to control whether exporting is set. If you wanted to configure multiple type of exports, but then toggle exporting, you'd need to unset a lot of variables or am I missing something?

[baronfel]

There's also an OTEL-wide enable/disable that isn't called out here that I'll add.

The SDK-specific knob and the Otel knobs are disjoint controls:

• we added the SDK-specific knob as a fast-to-implement emergency thing
• users that are actually wanting to control the behavior of the OLTP exporter specific should already be familiar with these knobs (from docs/etc). This list TBH shouldn't even be in this doc, we should be linking to the page on the otel docs.

[baronfel]

I didn't call out/check the OTEL-wide disablement env var because it was already being handled correctly by the OTel SDK - so even if a user did configure/customize the OLTP exporter, the overall OTel SDK wouldn't be enabled so nothing would get out.