Add PYTHON_ENABLE_OPENTELEMETRY worker-side auto-init for OTLP exporters (symmetric to PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY)

Start by tracing the worker handling for PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY and compare it with the documented PYTHON_ENABLE_OPENTELEMETRY and host.json telemetryMode behavior. Review the OTLP-Python documentation tab and the azure.monitor.opentelemetry.configure_azure_monitor() path. Done means worker-side OTLP exporters honor the listed OTEL environment variables, tests cover the behavior matrix, and the official docs describe the zero-code setup.

Binding Type

Not specific to a binding; this is an environment-based worker auto-init request affecting overall telemetry/diagnostics experience.

Expected Behavior

When telemetryMode: OpenTelemetry is set in host.json and APPLICATIONINSIGHTS_CONNECTION_STRING is not present, setting PYTHON_ENABLE_OPENTELEMETRY=true (documented for the OTLP tab in the official docs) should cause the worker to auto-initialize a TracerProvider+LoggerProvider with OTLP exporters, respecting the standard OTel env vars:

• OTEL_EXPORTER_OTLP_ENDPOINT
• OTEL_EXPORTER_OTLP_HEADERS
• OTEL_SERVICE_NAME
• OTEL_RESOURCE_ATTRIBUTES
• OTEL_TRACES_EXPORTER, OTEL_LOGS_EXPORTER, OTEL_METRICS_EXPORTER

This mirrors the current experience of PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY, which invokes azure.monitor.opentelemetry.configure_azure_monitor() and provides a zero-code path. This request is for worker-level parity for OTLP exporters: PYTHON_ENABLE_OPENTELEMETRY=true should set up and wire everything so the user does not need any code to export logs, traces, and metrics to OTLP endpoints.

Relevant sample code snipped

Current workaround (for each app):


import os
if os.environ.get("PYTHON_ENABLE_OPENTELEMETRY") == "true" and "APPLICATIONINSIGHTS_CONNECTION_STRING" not in os.environ:
    from opentelemetry import trace
    from opentelemetry.sdk.resources import Resource
    from opentelemetry.sdk.trace import TracerProvider
    from opentelemetry.sdk.trace.export import BatchSpanProcessor, OTLPSpanExporter
    from opentelemetry.sdk.logs import LoggerProvider
    from opentelemetry.sdk.logs.export import BatchLogRecordProcessor, OTLPLogExporter
    trace.set_tracer_provider(
        TracerProvider(
            resource=Resource.create(),  # env picks up OTEL_RESOURCE_ATTRIBUTES, etc.
        )
    )
    trace.get_tracer_provider().add_span_processor(
        BatchSpanProcessor(OTLPSpanExporter())
    )
    logger_provider = LoggerProvider(resource=Resource.create())
    logger_provider.add_log_record_processor(
        BatchLogRecordProcessor(OTLPLogExporter())
    )


Expected: When PYTHON_ENABLE_OPENTELEMETRY=true and OTEL_EXPORTER_OTLP_ENDPOINT is present (and no App Insights connection string), this code path should be automatic. No user code needed.

Additional Information

Summary
When telemetryMode: OpenTelemetry is set in host.json and APPLICATIONINSIGHTS_CONNECTION_STRING is configured, setting PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY=true causes the worker to auto-invoke azure.monitor.opentelemetry.configure_azure_monitor(); users get a fully wired worker with zero code.

There is no equivalent for the OTLP-exporter path. PYTHON_ENABLE_OPENTELEMETRY=true (documented for the OTLP tab) only affects the host process, not worker-side auto-wiring. The OTLP-Python doc tab currently instructs users to write their own LoggerProvider + OTLPLogExporter + BatchLogRecordProcessor setup.

This is surprising, as both env vars look like sibling switches but only one actually configures the worker SDK.

Motivation / Use case

• .NET Aspire orchestrates local dev for distributed apps and injects OTEL_EXPORTER_OTLP_ENDPOINT. Stock OTel auto-init in .NET/Node/Python picks this up for zero-code pipelines. Functions Python is the outlier: users must hand-write the SDK bootstrap and keep it in sync with the prod (App Insights) path. This applies to all non-App-Insights backends (Datadog, Tempo, New Relic, etc.).

Proposed behavior matrix

References

• Docs: https://learn.microsoft.com/azure/azure-functions/opentelemetry-howto?tabs=python (see OTLP-Python tab)
• Sibling host setting: telemetryMode: OpenTelemetry in host.json
• Distro used in App Insights path: azure-monitor-opentelemetry (see source)

Acceptance Criteria

• A documented env-var switch (or extend the existing PYTHON_ENABLE_OPENTELEMETRY) that makes the worker auto-wire an OTLP-exporting SDK.
• Official docs updated so OTLP-Python can match the App Insights 'set one env var' simplicity.
• Tag Azure/azure-functions-host (owns host telemetryMode/host-side OTLP) and MicrosoftDocs/azure-docs for visibility on related behaviors and documentation coverage.