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

logger_name が読み取られ、handler の作成が条件によって保護されている基本的な OTLP の設定を読み、issue で説明されている Azure Monitor の経路と比較してください。提供されたスクリプトを使って新しい Python プロセスで issue を再現し、root logger に LoggingHandler があるか確認してください。logger_name が省略された場合に標準の Python ログが設定済みの OTLP パイプラインに届き、handler の重複を防ぐ仕組みが維持されていれば完了です。

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.