Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Bug]: Plain OTLP path does not attach LoggingHandler when logger_name is omitted

Aperta Adatta ai principianti
#287 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@vincimech010233 ci sta già lavorando.

Dal 12/10/2026.

  • #288 di @vincimech010233 — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
python
Ambito
observability

Direzione di ricerca

Leggi la configurazione OTLP di base, in cui logger_name viene letto e la creazione dell’handler è protetta da una condizione, quindi confrontala con il percorso di Azure Monitor descritto nell’issue. Riproduci l’issue in un processo Python nuovo usando lo script fornito e verifica se il logger root ha un LoggingHandler. Il lavoro è concluso quando i log standard di Python raggiungono la pipeline OTLP configurata se logger_name viene omesso, mantenendo la protezione contro gli handler duplicati.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Distro
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
  1. Install the latest release:

    pip install microsoft-opentelemetry==1.4.0
    
  2. 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")
    
  3. Observe that the printed result is False. The standard Python log has no OTel logging handler and does not enter the OTLP logs pipeline.

  4. Change initialization to:

    use_microsoft_opentelemetry(logger_name="root")
    
  5. Observe that an OTel LoggingHandler is attached and the standard Python log enters the OTLP logs pipeline.

Environment
  • microsoft-opentelemetry: reproduced with 1.4.0; originally observed with 1.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.

Lingua principale
Python
Stelle
1
Fork
21
Merge medio
1g 10h
PR unite (30g)
13

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/opentelemetry-distro-python

Tutte le issue di microsoft/opentelemetry-distro-python

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.