File-based configuration for .NET in Splunk Observability Cloud

File‑based configuration allows you to manage .NET Auto‑Instrumentation settings through a YAML file.

Overview

File‑based configuration allows you to configure OpenTelemetry using a YAML file instead of relying solely on environment variables. This feature is currently experimental and intended for advanced scenarios where centralized, declarative configuration is preferred.

Activate file‑based configuration

Set the following environment variable to enable the file‑based configuration subsystem:

CODE 
OTEL_EXPERIMENTAL_FILE_BASED_CONFIGURATION_ENABLED=true

By default, this feature is deactivated.

Specify the configuration file location

To override the default config.yaml path, define:

CODE 
OTEL_EXPERIMENTAL_CONFIG_FILE=/path/to/config.yaml

Use environment variable substitution in YAML

The configuration file supports variable expansion using:

  • Direct substitution: ${ENVIRONMENT_VARIABLE}

  • Substitution with fallback: ${ENVIRONMENT_VARIABLE:-value} (fallback is applied when the variable is undefined or empty)

Note: For more details, see: OpenTelemetry YAML File Format Specification.

Not supported configurations

File‑based configuration does not support all .NET Auto‑Instrumentation settings. Several options that control runtime behavior, process startup, and CLR profiler activation cannot be defined in YAML and must continue to be configured through environment variables.

Some settings must be applied early in the application startup sequence, before the file‑based configuration system is loaded. Because of this, they cannot be reliably expressed in a configuration file without risking incorrect initialization of the instrumentation.

The list below outlines all settings that are not supported by file‑based configuration and must remain environment‑variable–based. Future releases of .NET Auto‑Instrumentation may extend YAML support to include additional parameters.

General
Environment variable Description
OTEL_DOTNET_AUTO_HOME Installation location.
OTEL_DOTNET_AUTO_EXCLUDE_PROCESSES Names of the executable files that the profiler cannot instrument.
OTEL_DOTNET_AUTO_NETFX_REDIRECT_ENABLED Enables automatic redirection of the assemblies used by the automatic instrumentation on the .NET Framework.
Limits
Environment variable Description
OTEL_ATTRIBUTE_VALUE_LENGTH_LIMIT Maximum allowed attribute value size.
OTEL_ATTRIBUTE_COUNT_LIMIT Maximum allowed span attribute count.
OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMIT Maximum allowed attribute value size.
OTEL_SPAN_ATTRIBUTE_COUNT_LIMIT Maximum allowed span attribute count.
OTEL_SPAN_EVENT_COUNT_LIMIT Maximum allowed span event count.
OTEL_SPAN_LINK_COUNT_LIMIT Maximum allowed span link count.
OTEL_EVENT_ATTRIBUTE_COUNT_LIMIT Maximum allowed attribute per span event count.
OTEL_LINK_ATTRIBUTE_COUNT_LIMIT Maximum allowed attribute per span link count.
OTEL_LOGRECORD_ATTRIBUTE_VALUE_LENGTH_LIMIT Maximum allowed log record attribute value size.
OTEL_LOGRECORD_ATTRIBUTE_COUNT_LIMIT Maximum allowed log record attribute count.
Rule engine
Environment variable Description
OTEL_DOTNET_AUTO_RULE_ENGINE_ENABLED Enables RuleEngine.
.NET CLR profiler
.NET Framework variable .NET Core variable Description
COR_ENABLE_PROFILING CORECLR_ENABLE_PROFILING Enables the profiler.
COR_PROFILER CORECLR_PROFILER CLSID of the profiler.
COR_PROFILER_PATH CORECLR_PROFILER_PATH Path to the profiler.
COR_PROFILER_PATH_32 CORECLR_PROFILER_PATH_32 Path to the 32-bit profiler. Bitness-specific paths take precedence.
COR_PROFILER_PATH_64 CORECLR_PROFILER_PATH_64 Path to the 64-bit profiler. Bitness-specific paths take precedence.
OTLP
Environment variable Description
OTEL_EXPORTER_OTLP_CERTIFICATE Path to the CA certificate file (PEM format) used to verify the server's TLS certificate.
OTEL_EXPORTER_OTLP_CLIENT_CERTIFICATE Path to the client certificate file (PEM format) for mTLS authentication.
OTEL_EXPORTER_OTLP_CLIENT_KEY Path to the client private key file (PEM format) for mTLS authentication.
.NET runtime
Environment variable Description
DOTNET_STARTUP_HOOKS Specifies managed assemblies to load during startup.
DOTNET_ADDITIONAL_DEPS Additional .deps.json files to include.
DOTNET_SHARED_STORE Path to additional shared assemblies.
Internal logs
Environment variable Description
OTEL_DOTNET_AUTO_LOG_DIRECTORY Directory of the .NET Tracer logs.
OTEL_LOG_LEVEL SDK log level.
OTEL_DOTNET_AUTO_LOGGER Auto-Instrumentation diagnostic logs sink.
OTEL_DOTNET_AUTO_LOG_FILE_SIZE Maximum size (in bytes) of a single log file created by the Auto-Instrumentation.
Instrumentations that turn off URL query redaction
Environment variable Description
OTEL_DOTNET_EXPERIMENTAL_ASPNETCORE_DISABLE_URL_QUERY_REDACTION Whether the ASP.NET Core instrumentation turns off redaction of the url.query attribute value.
OTEL_DOTNET_EXPERIMENTAL_HTTPCLIENT_DISABLE_URL_QUERY_REDACTION Whether the HTTP client instrumentation turns off redaction of the url.full attribute value.
OTEL_DOTNET_EXPERIMENTAL_ASPNET_DISABLE_URL_QUERY_REDACTION Whether the ASP.NET instrumentation turns off redaction of the url.query attribute value.

Configuration examples

The following examples illustrate how to define common OpenTelemetry settings using file‑based configuration. Each example shows the expected YAML structure and the corresponding configuration options supported by the .NET Auto‑Instrumentation.

General configuration

This section contains the fundamental global settings that control the behavior of the SDK and the file‑based configuration system. These options are typically the first ones users adjust when enabling, disabling, or tuning the overall telemetry pipeline.

CODE 
# The file format version.
# The yaml format is documented at
# <https://github.com/open-telemetry/opentelemetry-configuration/tree/main/schema>
# By default, the latest version is used.
file_format: "1.0-rc.1"
# Configure if the SDK is disabled or not.
# If omitted or null, false is used
disabled: false
# Configure if the Fail Fast is enabled or not.
# If omitted or null, false is used
fail_fast: false
# Configure if the Flush On Unhandled Exception is enabled or not.
# If omitted or null, false is used.
flush_on_unhandled_exception: false
# Configure if the Logs Include Formatted Message is enabled or not.
# If omitted or null, false is used.
logs_include_formatted_message: false

Tracer provider configuration

This section provides examples of configuring the tracer provider, including batch and simple processors as well as different exporters. Each example shows how to enable and tune a specific processor or exporter type while preserving.

Batch processor - OTLP/HTTP
This example shows how to configure a batch processor that exports traces using the OTLP/HTTP protocol.
PYTHON 
tracer_provider:
  processors:
    # Batch processor for OTLP HTTP
    - batch:
      # Configure delay interval (in milliseconds) between two consecutive exports.
      # Value must be non-negative.
      # If omitted or null, 5000 is used.
      schedule_delay: 5000
      # Configure maximum allowed time (in milliseconds) to export data. 
      # Value must be non-negative. A value of 0 indicates no limit (infinity).
      # If omitted or null, 30000 is used.
      export_timeout: 30000
      # Configure maximum queue size. Value must be positive.
      # If omitted or null, 2048 is used.
      max_queue_size: 2048
      # Configure maximum batch size. Value must be positive.
      # If omitted or null, 512 is used.
      max_export_batch_size: 512
      # Configure exporters.
      exporter:
        # Configure the OTLP with HTTP transport exporter to enable it.
        otlp_http:
          # Configure endpoint, including the trace specific path.
          # If omitted or null, http://localhost:4318/v1/traces is used
          endpoint: http://localhost:4318/v1/traces
          # Configure max time (in milliseconds) to wait for each export. 
          # Value must be non-negative. A value of 0 indicates no limit (infinity).
          # If omitted or null, 10000 is used.
          timeout: 10000
          # Configure headers. Entries have higher priority than entries from .headers_list.
          # If an entry's .value is null, the entry is ignored.
          headers:
            - name: api-key
              value: "1234"
          # Configure headers. Entries have lower priority than entries from .headers.
          # The value is a list of comma separated key-value pairs matching the format of OTEL_EXPORTER_OTLP_HEADERS. See https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/exporter.md#configuration-options for details.
          # If omitted or null, no headers are added.
          headers_list: ${OTEL_EXPORTER_OTLP_TRACES_HEADERS}
Batch Processor — OTLP/gRPC
This example shows how to configure a batch processor that exports traces using the OTLP gRPC protocol. The configuration is minimal because OTLP/gRPC shares most settings with OTLP/HTTP.
CODE 
tracer_provider:
  processors:
    # Batch processor for OTLP gRPC
    - batch:
        exporter:
          # Configure exporter to be OTLP with gRPC transport.
          otlp_grpc:
            # Configuration otlp_grpc is the same as otlp_http.
            # On .NET Framework, the grpc OTLP exporter protocol is not supported.
Batch Processor — Zipkin (Deprecated)
This example demonstrates how to configure a Zipkin exporter. The Zipkin configuration is deprecated and will be removed in a future release.
CODE 
tracer_provider:
  processors:
    # Batch processor for Zipkin
    # This configuration is deprecated and will be removed in upcoming release.
    - batch:
        exporter:
          zipkin:
            # Configure endpoint.
            # If omitted or null, http://localhost:9411/api/v2/spans is used.
            endpoint: http://localhost:9411/api/v2/spans
Simple Processor — Console
This example shows how to configure a simple processor that exports traces directly to the console. It is primarily useful for debugging and local development.
CODE 
tracer_provider:
  processors:
    # Simple processor for Console
    - simple:
        exporter:
          console:

Meter provider configuration

This section provides examples of configuring metric readers and exporters. It covers periodic push‑based readers (OTLP/HTTP, OTLP/gRPC, Console) as well as pull‑based Prometheus scraping.
Periodic Reader — OTLP/HTTP
This example shows how to configure a periodic metric reader that exports metrics using the OTLP HTTP protocol. It includes interval, timeout, headers, and temporality settings.
PYTHON 
meter_provider:
  readers:
    # Periodic reader for OTLP HTTP
    - periodic:
        # Configure delay interval (in milliseconds) between start of two consecutive exports.
        # Value must be non-negative.
        # If omitted or null, 60000 is used.
        interval: 60000
        # Configure maximum allowed time (in milliseconds) to export data.
        # Value must be non-negative. A value of 0 indicates no limit (infinity).
        # If omitted or null, 30000 is used.
        timeout: 30000
        # Configure exporter.
        exporter:
          # Configure exporter to be OTLP with HTTP transport.
          otlp_http:
            # Configure endpoint, including the metric specific path.
            # If omitted or null, http://localhost:4318/v1/metrics is used.
            endpoint: http://localhost:4318/v1/metrics
            # Configure max time (in milliseconds) to wait for each export.
            # Value must be non-negative. A value of 0 indicates no limit (infinity).
            # If omitted or null, 10000 is used.
            timeout: 10000
            # Configure headers. Entries have higher priority than entries from .headers_list.
            # If an entry's .value is null, the entry is ignored.
            headers:
              - name: api-key
                value: "1234"
            # Configure headers. Entries have lower priority than entries from .headers.
            # The value is a list of comma separated key-value pairs matching the format of OTEL_EXPORTER_OTLP_HEADERS. See https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/exporter.md#configuration-options for details.
            # If omitted or null, no headers are added.
            headers_list: ${OTEL_EXPORTER_OTLP_TRACES_HEADERS}
            # Configure temporality preference.
            # Values include: cumulative, delta.
            # If omitted or null, cumulative is used.
            temporality_preference: cumulative
Periodic Reader — OTLP/gRPC
This example demonstrates how to configure a periodic metric reader that exports metrics using the OTLP gRPC protocol. The configuration is minimal because OTLP/gRPC shares the same structure as OTLP/HTTP.
CODE 
meter_provider:
  readers:
    # Periodic reader for OTLP gRPC
    - periodic:
        # Configure exporter.
        exporter:
          # Configure exporter to be OTLP with gRPC transport.
          otlp_grpc:
          # Configuration otlp_grpc is the same as otlp_http.
          # On .NET Framework, the grpc OTLP exporter protocol is not supported.
Periodic Reader — Console
This example shows how to configure a periodic reader that exports metrics to the console. It is useful for debugging and local development.
CODE 
meter_provider:
  readers:
    # Periodic reader for Console
    - periodic:
        # Configure exporter.
        exporter:
          # Configure exporter to be console.
          console:
            # Configure temporality preference.
            # Values include: cumulative, delta.
            # If omitted or null, cumulative is used.
            temporality_preference: cumulative
Pull Reader — Prometheus
This example demonstrates how to configure a pull‑based metric reader for Prometheus scraping.
CODE 
meter_provider:
  readers:
    # Pull reader for Prometheus
    - pull:
        # Configure exporter.
        exporter:
          # Configure exporter to be Prometheus.
          prometheus:

Logger provider configuration

This section provides examples of configuring the logger provider, including batch and simple processors as well as OTLP/HTTP, OTLP/gRPC, and console exporters. These examples demonstrate how logs are collected, batched, and exported.
Batch Processor — OTLP/HTTP
This example shows how to configure a batch processor that exports logs using the OTLP HTTP protocol. It includes batching parameters, queue limits, headers, and timeout settings.
PYTHON 
logger_provider:
  processors:
    # Batch processor for OTLP HTTP
    - batch:
        # Configure delay interval (in milliseconds) between two consecutive exports.
        # Value must be non-negative.
        # If omitted or null, 5000 is used.
        schedule_delay: 5000
        # Configure maximum allowed time (in milliseconds) to export data.
        # Value must be non-negative. A value of 0 indicates no limit (infinity).
        # If omitted or null, 30000 is used.
        export_timeout: 30000
        # Configure maximum queue size. Value must be positive.
        # If omitted or null, 2048 is used.
        max_queue_size: 2048
        # Configure maximum batch size. Value must be positive.
        # If omitted or null, 512 is used.
        max_export_batch_size: 512
        # Configure exporter.
        exporter:
          # Configure the OTLP with HTTP transport exporter to enable it.
          otlp_http:
            # Configure endpoint, including the logs specific path.
            # If omitted or null, http://localhost:4318/v1/logs is used.
            endpoint: http://localhost:4318/v1/logs
            # Configure headers. Entries have higher priority than entries from .headers_list.
            # If an entry's .value is null, the entry is ignored.
            headers:
              - name: api-key
                value: "1234"
            # Configure headers. Entries have lower priority than entries from .headers.
            # The value is a list of comma separated key-value pairs matching the format of OTEL_EXPORTER_OTLP_HEADERS.
            # If omitted or null, no headers are added.
            headers_list: api-key=1234
            # Configure max time (in milliseconds) to wait for each export.
            # Value must be non-negative. A value of 0 indicates no limit (infinity).
            # If omitted or null, 10000 is used.
            timeout: 10000
Batch Processor — OTLP/gRPC
This example demonstrates how to configure a batch processor that exports logs using the OTLP gRPC protocol. The configuration is minimal because OTLP/gRPC shares the same structure as OTLP/HTTP.
CODE 
logger_provider:
  processors:
    # Batch processor for OTLP gRPC
    - batch:
        exporter:
          # Configure exporter to be OTLP with gRPC transport.
          otlp_grpc:
          # Configuration otlp_grpc is the same as otlp_http.
          # On .NET Framework, the grpc OTLP exporter protocol is not supported.
Simple Processor — Console
This example shows how to configure a simple processor that exports logs directly to the console. It is primarily useful for debugging and local development.
CODE 
logger_provider:
  processors:
    # Simple processor for Console
    - simple:
        exporter:
          console:

Sampler configuration

This section provides examples of configuring different sampling strategies for traces. Sampling determines which spans are recorded and exported, allowing users to control data volume and cost.
Parent Based — Always On
This example shows how to configure a parent‑based sampler where the root sampler is always_on. It also demonstrates how to configure behavior for sampled and non‑sampled parents, both local and remote.
CODE 
tracer_provider:
  # Configure the sampler. If omitted, parent based sampler with a root of always_on is used.
  sampler:
    # Configure sampler to be parent_based.
    parent_based:
      # Configure root sampler.
      # If omitted or null, always_on is used.
      root:
        # Configure sampler to be always_on.
        always_on:
      # Configure remote_parent_sampled sampler.
      # If omitted or null, always_on is used.
      remote_parent_sampled:
        # Configure sampler to be always_on.
        always_on:
      # Configure remote_parent_not_sampled sampler.
      # If omitted or null, always_off is used.
      remote_parent_not_sampled:
        # Configure sampler to be always_off.
        always_off:
      # Configure local_parent_sampled sampler.
      # If omitted or null, always_on is used.
      local_parent_sampled:
        # Configure sampler to be always_on.
        always_on:
      # Configure local_parent_not_sampled sampler.
      # If omitted or null, always_off is used.
      local_parent_not_sampled:
        # Configure sampler to be always_off.
        always_off:
Parent Based — Trace ID Ratio
This example demonstrates how to configure a parent‑based sampler where the root sampler uses a trace ID ratio. This allows sampling a percentage of traces while still respecting parent sampling decisions.
CODE 
tracer_provider:
  # Configure the sampler. If omitted, parent based sampler with a root of always_on is used.
  sampler:
    # Configure sampler to be parent_based.
    parent_based:
      # Configure root sampler.
      # If omitted or null, always_on is used.
      root:
        # Configure sampler to be always_on.
        trace_id_ratio:
          # Configure ratio between 0.0 and 1.0.
          ratio: 0.25
Always On
This example shows how to configure a sampler that samples every trace. It is useful for debugging or low‑traffic environments.
CODE 
tracer_provider:
  # Configure the sampler. If omitted, parent based sampler with a root of always_on is used.
  sampler:
    # Configure sampler to be always_on.
    always_on:
Always Off
This example demonstrates how to configure a sampler that omits trace sampling. No traces will be recorded or exported.
CODE 
tracer_provider:
  # Configure the sampler. If omitted, parent based sampler with a root of always_on is used.
  sampler:
    # Configure sampler to be always_off.
    always_off:

Resource configuration

This section provides a complete example of configuring resource attributes and resource detectors. Resources describe the entity producing telemetry, such as the service name, host, process, or cloud environment.
PYTHON 
resource:
  # Configure resource attributes. Entries have higher priority than entries from .resource.attributes_list.
  # Entries must contain .name and .value, and may optionally include .type. If an entry's .type omitted or null, string is used.
  # The .value's type must match the .type. Values for .type include: string, bool, int, double, string_array, bool_array, int_array, double_array.
  # By default service.name is generated automatically if not explicitly configured.
  # If the application is hosted on IIS in .NET Framework this will be SiteName\VirtualPath (e.g., MySite\MyApp).
  # Otherwise, it will use the name of the application entry Assembly.
  # You can override this value manually below.
  attributes:
    - name: service.name
      value: unknown_service
      type: string
    - name: attribute_key
      value: ["value1", "value2", "value3"]
      type: string_array

  # Alternatively, configure via a comma-separated list (same format as OTEL_RESOURCE_ATTRIBUTES).
  attributes_list: ${OTEL_RESOURCE_ATTRIBUTES}

  # Resource Detectors Configuration
  detection/development:
    # If no detectors are specified, none will be added automatically.
    detectors:
      azureappservice: # Detects Azure App Service resource information
      container:       # Detects container resource info (container.* attributes) [Core only]
      host:            # Detects host resource info (host.* attributes)
      operatingsystem: # Detects OS-level attributes (os.*)
      process:         # Detects process-level attributes (process.*)
      processruntime:  # Detects process runtime attributes (process.runtime.*)

Plugins configuration

This section provides an example of configuring plugins that extend the functionality of .NET auto‑instrumentation. Plugins allow users to load custom logic at startup. The example includes both the explicit plugin list and the environment‑based plugins_list option.
PYTHON 
plugins/development:
  # Configure plugins. Entries have higher priority than entries from .plugins_list.
  # List of plugins to load. Each entry is the full type name, followed by the assembly name.
  # For example: MyNamespace.MyPlugin, MyAssembly, Version=1.0.0, Culture=neutral, PublicKeyToken=null
  plugins:
    - Test1.Plugins.Plugin, Test1.Plugins, Version=1.0.0, Culture=neutral, PublicKeyToken=null
    - Test2.Plugins.Plugin, Test2.Plugins

  # Alternatively, configure via a colon-separated list (same format as OTEL_DOTNET_AUTO_PLUGINS).
  plugins_list: ${OTEL_DOTNET_AUTO_PLUGINS}

Propagator configuration

This section provides an example of configuring text‑map propagators, which control how trace context and baggage are injected and extracted across process boundaries. The configuration supports multiple propagators combined into a composite, and also allows specifying propagators via environment variables.
PYTHON 
propagator:
  # Composite propagators are evaluated together. 
  # Entries from .composite_list are appended here (duplicates are filtered out).
  composite:
    tracecontext: # W3C Trace Context propagator
    baggage:      # W3C Baggage propagator
    b3:           # B3 single-header propagator
    b3multi:      # B3 multi-header propagator

  # Alternatively, configure via a comma-separated list (same format as OTEL_PROPAGATORS).
  composite_list: ${OTEL_PROPAGATORS}

Instrumentation Configuration

This section provides examples of configuring automatic instrumentation for traces, metrics, and logs. Each instrumentation entry corresponds to a specific library or framework that can be individually controlled.
Traces instrumentation
This example lists all available .NET trace instrumentations that can be enabled. Each entry corresponds to an instrumentation component that captures spans from a specific library or technology.
CODE 
instrumentation/development:
  dotnet:
    traces:
      aspnet:              # ASP.NET
      aspnetcore:          # ASP.NET Core
      azure:               # Azure SDK
      elasticsearch:       # Elastic.Clients.Elasticsearch
      elastictransport:    # Elastic.Transport
      entityframeworkcore: # Entity Framework Core
      graphql:             # GraphQL
      grpcnetclient:       # Grpc.Net.Client
      httpclient:          # System.Net.Http.HttpClient
      kafka:               # Confluent.Kafka
      masstransit:         # MassTransit
      mongodb:             # MongoDB.Driver
      mysqlconnector:      # MySqlConnector
      mysqldata:           # MySql.Data
      npgsql:              # Npgsql
      nservicebus:         # NServiceBus
      oraclemda:           # Oracle.ManagedDataAccess
      rabbitmq:            # RabbitMQ.Client
      quartz:              # Quartz
      sqlclient:           # Microsoft.Data.SqlClient & System.Data.SqlClient
      stackexchangeredis:  # StackExchange.Redis
      wcfclient:           # WCF Client
      wcfcore:             # CoreWCF.Primitives
      wcfservice:          # WCF Service
Metrics instrumentation
This example lists all available .NET metric instrumentations that can be enabled. These instrumentations emit metrics from common .NET libraries and frameworks.
CODE 
instrumentation/development:
  dotnet:
    metrics:
      aspnet:              # ASP.NET metrics
      aspnetcore:          # ASP.NET Core metrics
      httpclient:          # HttpClient metrics
      netruntime:          # .NET Runtime metrics
      nservicebus:         # NServiceBus metrics
      process:             # Process metrics
      sqlclient:           # SQL Client metrics
Logs instrumentation
This example lists all available .NET log instrumentations. These instrumentations capture logs from popular logging frameworks and forward them through the OpenTelemetry pipeline.
CODE 
instrumentation/development:
  dotnet:
    logs:
      ilogger:             # Microsoft.Extensions.Logging
      log4net:             # Log4Net
      nlog:                # NLog

Instrumentation options

This section provides examples of configuring advanced options for specific instrumentations. These settings allow fine‑tuning of captured data, such as enabling SQL text collection, controlling HTTP header capture, or configuring log bridges.
CODE 
instrumentation/development:
  dotnet:
    traces:
      graphql:
        # Whether the GraphQL instrumentation can pass raw queries through the graphql.document attribute. Queries might contain sensitive information.
        # Default is false
        set_document: false

      oraclemda: 
        # Whether the Oracle Client instrumentation can pass SQL statements through the db.statement attribute. Queries might contain sensitive information. If set to false, db.statement is recorded only for executing stored procedures.
        # Default is false
        set_db_statement_for_text: false

      sqlclient:
        # Enables IL rewriting of SqlCommand on .NET Framework to ensure CommandText is available for instrumentation.
        # Default is false
        netfx_ilrewrite_enabled: false

      aspnet:
        # A comma-separated list of HTTP header names. ASP.NET instrumentations will capture HTTP request header values for all configured header names.
        capture_request_headers: "X-Key,X-Custom-Header,X-Header-Example"
        # A comma-separated list of HTTP header names. ASP.NET instrumentations will capture HTTP response header values for all configured header names.
        capture_response_headers: "X-Key,X-Custom-Header,X-Header-Example"

      aspnetcore:
        # A comma-separated list of HTTP header names. ASP.NET Core instrumentations will capture HTTP request header values for all configured header names.
        capture_request_headers: "X-Key,X-Custom-Header,X-Header-Example"
        # A comma-separated list of HTTP header names. ASP.NET Core instrumentations will capture HTTP response header values for all configured header names.
        capture_response_headers: "X-Key,X-Custom-Header,X-Header-Example"

      httpclient:
        # A comma-separated list of HTTP header names. HTTP Client instrumentations will capture HTTP request header values for all configured header names.
        capture_request_headers: "X-Key,X-Custom-Header,X-Header-Example"
        # A comma-separated list of HTTP header names. HTTP Client instrumentations will capture HTTP response header values for all configured header names.
        capture_response_headers: "X-Key,X-Custom-Header,X-Header-Example"

      grpcnetclient:
        # A comma-separated list of gRPC metadata names. Grpc.Net.Client instrumentations will capture gRPC request metadata values for all configured metadata names.
        capture_request_metadata: "X-Key,X-Custom-Header,X-Header-Example"
        # A comma-separated list of gRPC metadata names. Grpc.Net.Client instrumentations will capture gRPC response metadata values for all configured metadata names.
        capture_response_metadata: "X-Key,X-Custom-Header,X-Header-Example"

    logs:
      log4net:
        # Logs bridge is disabled by default
        # More info about log4net bridge can be found at https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/blob/main/docs/log4net-bridge.md
        bridge_enabled: true

      nlog:
        # Logs bridge is disabled by default
        # More info about NLog bridge can be found at https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/blob/main/docs/nlog-bridge.md
        bridge_enabled: true

Trace Response Header configuration

Enables injection of trace context into HTTP responses produced by ASP.NET and ASP.NET Core instrumentations. This capability helps correlate frontend activity with backend traces when analyzing distributed transactions. The example below shows how to activate this behavior using file‑based configuration.
CODE 
# Instrumentation configuration
instrumentation/development:
  # Dotnet instrumentation configuration
  dotnet:
    # Traces instrumentation configuration
    traces:
      # ASP.NET
      aspnet:
        # Configure response header injection
        # Adds server trace information to HTTP response headers.
        # If omitted or null, true is used.
        response_header_enabled: true
      # ASP.NET Core
      aspnetcore:
        # Configure response header injection
        # Adds server trace information to HTTP response headers.
        # If omitted or null, true is used.
        response_header_enabled: true

Additional sources

This section provides examples of configuring additional ActivitySource, legacy Activity sources, and Meter sources. These settings allow users to include custom or manually instrumented components in the telemetry pipeline.
JSON 
instrumentation/development:
  dotnet:
    traces:
      # List of additional System.Diagnostics.ActivitySource names to be added to the tracer at the startup. 
      # Use it to capture manually instrumented spans.
      additional_sources:
        - Another.Source.Name

      # Alternatively, configure via a comma-separated list (same format as OTEL_DOTNET_AUTO_TRACES_ADDITIONAL_SOURCES).
      additional_sources_list: ${OTEL_DOTNET_AUTO_TRACES_ADDITIONAL_SOURCES}

      # List of additional legacy source names to be added to the tracer at the startup. 
      # Use it to capture System.Diagnostics.Activity objects created without using the System.Diagnostics.ActivitySource API.
      additional_legacy_sources:
        - Legacy.Source.Name

      # Alternatively, configure via a comma-separated list (same format as OTEL_DOTNET_AUTO_TRACES_ADDITIONAL_LEGACY_SOURCES).
      additional_legacy_sources_list: ${OTEL_DOTNET_AUTO_TRACES_ADDITIONAL_LEGACY_SOURCES}

    metrics:
      # List of additional System.Diagnostics.Metrics.Meter names to be added to the meter at the startup. 
      additional_sources:
        - MyProduct.MyLibrary.Metrics

      # Alternatively, configure via a comma-separated list (same format as OTEL_DOTNET_AUTO_METRICS_ADDITIONAL_SOURCES).
      additional_sources_list: ${OTEL_DOTNET_AUTO_METRICS_ADDITIONAL_SOURCES}

Profiler configuration

Defines settings that control the behavior of the .NET profiling subsystem when enabled through file‑based configuration. The following example shows how to specify profiler activation and sampling parameters.
Important: Profiling configured through file‑based configuration requires at least one provider—tracer_provider or meter_provider—to also be defined using file‑based configuration. Otherwise, profiling settings are not applied. Call‑graph generation additionally requires the baggage propagator to be configured through file‑based configuration
CODE 
# Distribution configuration
distribution:
  # Splunk-specific configuration
  splunk:
    # Profiling configuration
    profiling:
      # Exporter configuration
      exporter:
        # Configure exporter to be OTLP Log exporter with HTTP transport.
        otlp_log_http:
          # Configure endpoint, including the logs specific path.
          # If omitted or null, http://localhost:4318/v1/logs is used.
          endpoint: "http://localhost:4318/v1/logs"
          # Configure interval for exporting collected stack data. 
          # Minimum value is 500.
          # If omitted or null, 500 is used.
          schedule_delay: 500
          # Configure timeout for exporting stack data.
          # If omitted or null, 3000 is used.
          export_timeout: 3000
      # Always-on profiling configuration    
      always_on:
        # Configure CPU call stack profiler
        cpu_profiler:
          # Configure frequency with which call stacks are sampled.
          # If omitted or null, 10000 is used.
          sampling_interval: 10000
        # Configure memory allocation profiler
        memory_profiler:
          # Configure maximum memory samples collected per minute. 
          # Maximum value is 500.
          # If omitted or null, 200 is used.
          max_memory_samples: 200
      # Configure Callgraph snapshot profiler
      callgraphs:
        # Configure sampling interval.
        # If omitted or null, 40 is used.
        sampling_interval: 40
        # Configure probability of selecting a trace. 
        # Maximum value is 0.1.
        # If omitted or null, 0.01 is used.
        selection_probability: 0.01
        # Configure if the High-resolution Timer is enabled or not.
        # If omitted or null, false is used.
        high_resolution_timer_enabled: false