[Bug]: Plain OTLP path does not attach LoggingHandler when logger_name is omitted
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 72/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- python
- Lĩnh vực
- observability
Hướng nghiên cứu
Đọc thiết lập OTLP cơ bản, nơi logger_name được đọc và việc tạo handler được bảo vệ bằng một điều kiện, sau đó so sánh với đường xử lý Azure Monitor được mô tả trong issue. Tái hiện issue trong một tiến trình Python mới bằng script được cung cấp và kiểm tra xem root logger có LoggingHandler hay không. Hoàn thành khi các log Python tiêu chuẩn đến được pipeline OTLP đã cấu hình nếu bỏ qua logger_name, đồng thời vẫn giữ cơ chế bảo vệ tránh tạo handler trùng lặp.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Component
Distro
Description
When use_microsoft_opentelemetry() is configured for plain OTLP export and logger_name is omitted, the distro creates the OTel LoggerProvider, log record processors, and exporter, but does not attach an OTel LoggingHandler to Python logging.
As a result:
- Direct OTel Logs API calls can be exported.
- Standard Python calls such as
logging.getLogger(__name__).info(...)are not exported.
The plain-OTLP setup currently uses an empty string as the default and guards handler creation with a truthiness check:
logger_name: str = otel_kwargs.get(LOGGER_NAME_ARG, "")
if logger_name:
logger = getLogger(logger_name)
# Attach LoggingHandler
This is inconsistent with Python logging semantics:
logging.getLogger("") is logging.getLogger("root")
An empty logger name validly resolves to the root logger, but the truthiness check prevents that resolution.
The behavior is also inconsistent with the Azure Monitor path, which resolves the empty logger name and attaches the handler to the root logger.
This affects callers such as azure-ai-agentserver-core, which configures resources, processors, and exporters but does not currently pass logger_name. Consequently, standard application logs are missing when it uses the plain-OTLP path, while the same logs work through the Azure Monitor path.
Expected Behavior
Plain OTLP and Azure Monitor setup should behave consistently.
When log export is configured and logger_name is omitted or defaults to "", standard Python logging should be connected to the configured OTel LoggerProvider, preferably by attaching one LoggingHandler to the root logger.
If an empty value is intentionally meant to disable Python logging collection, that behavior should be explicit and documented. The default one-call onboarding behavior should export standard Python logs consistently across exporter paths.
Steps to Reproduce
-
Install the latest release:
pip install microsoft-opentelemetry==1.4.0 -
Run the following in a fresh Python process:
import logging import os from microsoft.opentelemetry import use_microsoft_opentelemetry from opentelemetry.sdk._logs import LoggingHandler os.environ["OTEL_EXPORTER_OTLP_ENDPOINT"] = "http://localhost:4318" use_microsoft_opentelemetry() root = logging.getLogger() print( any( isinstance(handler, LoggingHandler) for handler in root.handlers ) ) logging.getLogger(__name__).warning("standard Python log") -
Observe that the printed result is
False. The standard Python log has no OTel logging handler and does not enter the OTLP logs pipeline. -
Change initialization to:
use_microsoft_opentelemetry(logger_name="root") -
Observe that an OTel
LoggingHandleris attached and the standard Python log enters the OTLP logs pipeline.
Environment
microsoft-opentelemetry: reproduced with1.4.0; originally observed with1.3.9- Export path: plain OTLP through
OTEL_EXPORTER_OTLP_ENDPOINT - Azure Monitor exporter: disabled
- Python logging API:
logging.getLogger(__name__) - Runtime: reproducible in a standalone Python process
Suggested Fix
Resolve the logger name even when it is empty, while retaining the existing duplicate-handler protection:
logger = getLogger(logger_name)
if not any(
isinstance(handler, LoggingHandler)
for handler in logger.handlers
):
handler = LoggingHandler(logger_provider=logger_provider)
if logging_formatter:
handler.setFormatter(logging_formatter)
logger.addHandler(handler)
Alternatively, default logger_name to "root".
Resolving the empty name is preferable because it preserves Python's existing empty-name-to-root semantics and aligns the plain-OTLP path with the Azure Monitor path.
- Ngôn ngữ chính
- Python
- Star
- 1
- Fork
- 21
- Merge trung bình
- 1 ngày 10 giờ
- Pull request đã merge (30 ngày)
- 13
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của microsoft/opentelemetry-distro-python
-
[Question]:Có thể làm lại được @nikhilNava đã nhận 83 ngày trước và không có pull request nào đang mở. Đang mởDistro question
microsoft/opentelemetry-distro-python#231 · 12 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của microsoft/opentelemetry-distro-python
Issue tương tự
-
Path subtraction removes repeated suffix characters instead of one suffixCó thể đã có người làm @Gwerdonatus đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
joke2k/django-environ#671 ·
-
good first issue help wanted windows
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 80/100
-
test_pgbouncer deploys the server under test from Charmhub instead of the local build (track/1.31)Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
canonical/temporal-k8s-operator#195 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 4 ngày
-
`burr` fails to start when the Python path has a space in itCó thể đã có người làm @enekoreto đã nhận hôm nay. Đang mởstatus/needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 5 ngày
-
device support request
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
zigpy/zha-device-handlers#5461 ·
Maintainer thường phản hồi trong vòng 4 ngày