Azure / Azure/azure-functions-python-worker

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

Đang mở
#1,870 0 bình luận 1 reaction 0 người được giao Xem trên GitHub
feature python
Ngôn ngữ chính
Python
Star
357
Fork
116
Merge trung bình
32 phút
Pull request đã merge (30 ngày)
1

Mô tả

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

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Hướng nghiên cứu

Bắt đầu bằng cách theo dõi việc xử lý ở worker đối với PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY và so sánh với hành vi được ghi trong tài liệu của PYTHON_ENABLE_OPENTELEMETRY và telemetryMode trong host.json. Xem lại tab tài liệu OTLP-Python và đường dẫn azure.monitor.opentelemetry.configure_azure_monitor(). Hoàn thành khi các OTLP exporter phía worker tuân theo các biến môi trường OTEL được liệt kê, các bài kiểm thử bao phủ ma trận hành vi và tài liệu chính thức mô tả thiết lập không cần mã.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
python
Lĩnh vực
backend, documentation, observability-sre
Loại issue
Tính năng
Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức độ hoạt động
Ít trao đổi
Độ rõ ràng
Khá rõ ràng
Mức phù hợp với người mới
45/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.