Azure / Azure/azure-functions-python-worker

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

未关闭
#1,870 0 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

feature python
主要语言
Python
星标
357
派生
116
平均合并
32 分钟
30 天内合并 PR
1

描述

### 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

```shell
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
| Env vars set | Current worker behavior | Proposed worker behavior |
|--------------|------------------------|--------------------------|
|PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY=true + APPLICATIONINSIGHTS_CONNECTION_STRING|Auto-calls configure_azure_monitor()|Unchanged|
|PYTHON_ENABLE_OPENTELEMETRY=true + OTEL_EXPORTER_OTLP_ENDPOINT|No-op in worker (host only)|Auto-wires SDK with OTLP exporters|
|Both|Azure Monitor wins|Dual export (matches host behavior)|

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.

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

首先跟踪 worker 对 PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY 的处理,并将其与文档所述的 PYTHON_ENABLE_OPENTELEMETRY 和 host.json 中 telemetryMode 的行为进行比较。查看 OTLP-Python 文档选项卡以及 azure.monitor.opentelemetry.configure_azure_monitor() 路径。完成标准是:worker 端的 OTLP exporter 遵循列出的 OTEL 环境变量,测试覆盖行为矩阵,并且官方文档描述无代码设置。

由索引模型根据 Issue 内容生成。

评估

技术栈
python
领域
backend, documentation, observability-sre
Issue 类型
功能
难度
4/5
预计耗时
3-5 天
活跃度
冷清
描述清晰度
基本清楚
新手友好度
45/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。