fix(azure-monitor-opentelemetry): configure_azure_monitor args were overwritten

[temporaer]

Description

After calling configure_azure_monitor, all kwargs are saved in a configurations object. This configurations object is then amended with default values, before the actual configuration begins.

During this configuration, some user-provided values get overwritten by hard-coded defaults.

This PR fixes at least some obvious cases of this happening.

Cc'ing @rads-1996, who introduced the breaking change.

All SDK Contribution checklist:

• The pull request does not introduce [breaking changes]
• CHANGELOG is updated for new features, bug fixes or other significant changes.
• I have read the contribution guidelines.

General Guidelines and Best Practices

• Title of the pull request is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.

[github-actions]

Thank you for your contribution @temporaer! We will review the pull request and get back to you soon.

[Copilot]

Pull Request Overview

This PR addresses a bug where user-provided configuration values passed to configure_azure_monitor() were being overwritten by default values during the configuration process. The fix changes three instances of direct dictionary assignment to use setdefault(), ensuring that user-provided values are preserved.

Key changes:

• Changed error-handling code paths to use setdefault() instead of direct assignment for SAMPLING_TRACES_PER_SECOND_ARG and SAMPLING_RATIO_ARG
• Applied the same pattern to the default case when no sampler type is specified
• This ensures user-provided kwargs take precedence over both environment variables (in error cases) and hard-coded defaults

[Copilot]

The error message logged here states "Defaulting to %s" (where %s is default_value), but with the change to use setdefault(), the actual behavior may not match this message. If the user provided a value via configure_azure_monitor() kwargs, that user-provided value will be preserved rather than defaulting to default_value. The log message should be updated to reflect this, or the value that will actually be used should be logged.

Consider logging the actual value that will be used after calling setdefault():

configurations.setdefault(SAMPLING_TRACES_PER_SECOND_ARG, default_value)
_logger.error(
    "Value of %s must be a positive number for traces per second. Using value: %s (exception: %s)",
    OTEL_TRACES_SAMPLER_ARG,
    configurations[SAMPLING_TRACES_PER_SECOND_ARG],
    e,
)

[Copilot]

The error message logged here states "Defaulting to %s" (where %s is default_value), but with the change to use setdefault(), the actual behavior may not match this message. If the user provided a value via configure_azure_monitor() kwargs, that user-provided value will be preserved rather than defaulting to default_value. The log message should be updated to reflect this, or the value that will actually be used should be logged.

Consider logging the actual value that will be used after calling setdefault():

configurations.setdefault(SAMPLING_RATIO_ARG, default_value)
_logger.error(
    "Value of %s must be a float. Using value: %s (exception: %s)",
    OTEL_TRACES_SAMPLER_ARG,
    configurations[SAMPLING_RATIO_ARG],
    e,
)

[Copilot]

The error message is misleading. It says "Defaulting to %s: %s" and substitutes environment variable names (OTEL_TRACES_SAMPLER and OTEL_TRACES_SAMPLER_ARG) rather than the actual value that will be used.

Consider revising to show the actual value being used:

_logger.error(
    "Invalid value '%s' for %s. Supported values are '%s' and '%s'. Using sampling_ratio=%s",
    sampler_type,
    OTEL_TRACES_SAMPLER,
    RATE_LIMITED_SAMPLER,
    FIXED_PERCENTAGE_SAMPLER,
    configurations.get(SAMPLING_RATIO_ARG, default_value),
)

[rads-1996]

@temporaer This behavior is by design, we check the sampler type provided by the user and if the arguments are not valid only then we assign the default values. Is there a case you can provide where this logic is being violated. Also, for the ApplicationInsights Sampler the logic of using the default value was already present.