Dapr sidecars not sending trace telemetry to open telemetry provider configured in Azure Container Apps

Hi @Jami Lurock ,

Thanks for reaching out to Microsoft Q&A.

In Azure Container Apps the key is that Dapr tracing support lives at the environment level, not per‐app, and you must be on the OpenTelemetry preview API (2024-08-02-preview) or later so that includeDapr: true is honored. Here’s what to check and try:

1. Verify you configured your managed environment (not just the individual Container App) with the OpenTelemetry block. For example, in an ARM template for your environment:

      
      {
      
      "type": "Microsoft.App/managedEnvironments",
      
      "apiVersion": "2024-08-02-preview",
      
      "name": "<YOUR_ENV_NAME>",
      
      "properties": {
      
       "openTelemetryConfiguration": {
      
         "tracesConfiguration": {
      
           "destinations": [ "otlp" ],
      
           "includeDapr": true
      
         }
      
       }
      
      }
      
      }
      
   

   After you apply that, redeploy your container apps so the sidecar picks up the new setting.
2. Confirm your OTLP endpoint is reachable via gRPC and that the default agent‐injected vars match your collector’s address:
   • You can inspect the CONTAINERAPP_OTEL_TRACING_GRPC_ENDPOINT inside the sidecar (it defaults to the managed agent).
   • If you need a custom endpoint, explicitly set OTEL_EXPORTER_OTLP_ENDPOINT and ensure protocol=grpc.
3. Check the agent’s logs in your environment to see if spans are being dropped or retried (memory buffering/backoff). If you hit buffering limits, you may see retries then drops.
4. Once configured correctly, you should start seeing Dapr spans in your OTLP backend alongside your app spans.

1. This is my configuration for the environment:

  
{
    "type": "Microsoft.App/managedEnvironments",
    "apiVersion": "2025-10-02-preview",
    "name": "[...REDACTED...]",
    "location": "[...REDACTED...]",
    "properties": {
        "openTelemetryConfiguration": {
            "destinationsConfiguration": {
                "otlpConfigurations": [
                    {
                        "name": "otlp",
                        "endpoint": "[...REDACTED...]",
                        "insecure": false,
                        "headers": [
                            {
                                "key": "[...REDACTED...]"
                            }
                        ]
                    }
                ]
            },
            "tracesConfiguration": {
                "includeDapr": true,
                "destinations": [
                    "otlp"
                ]
            },
            "logsConfiguration": {
                "destinations": [
                    "otlp"
                ]
            },
            "metricsConfiguration": {
                "includeKeda": true,
                "destinations": [
                    "otlp"
                ]
            }
        }
    }
}

2. As far as the settings for the Endpoints that is just what Azure Container Apps injects which looks like it goes to the default managed agent.
3. I have looked though the logs and I am not seeing anything that stands out to me. Anything I should search for in particular?
4. I see my traces for my services that go through the same Azure Container apps default agent in both my configured Open Telemetry provider and I also see them in the Azure Container Apps Aspire dashboard but both are missing the trace spans from the dapr sidecars.

By default, Dapr sidecars do not emit traces unless configured. Dapr tracing must be explicitly enabled at the Dapr level.

You should have a Dapr configuration resource, for example:

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: dapr-config
spec:
  tracing:
    samplingRate: "1"

If this configuration is missing or the samplingRate is very low (e.g., "0.0001"), your app traces will appear, but Dapr spans will be missing or extremely rare.

In Azure Container Apps (ACA), the Container App must explicitly reference this Dapr config using the config property:

dapr:
  enabled: true
  appId: my-app
  appPort: 3000
  config: dapr-config

If config is not set, Dapr runs with defaults, which usually means tracing is disabled.

Even if ACA injects OpenTelemetry (OTEL) settings, the Dapr sidecar might still attempt to export to a default Zipkin endpoint or fail to export spans entirely.

To verify, check the sidecar logs for keywords such as trace, tracing, otel, exporter, zipkin, sampling, or span. Look for lines like Tracing is enabled, Starting OpenTelemetry exporter, and Sampling rate set to X; conversely, entries such as Tracing is disabled or Failed to export spans indicate problems.

includeDapr: true only works if the platform-managed Dapr sidecar is correctly wired into the OTEL agent, which has been inconsistent across preview API versions. In some builds, app spans flow to the OTEL agent, but Dapr spans do not, which matches your observed behavior.

To isolate the issue, set the Dapr samplingRate to "1" temporarily, perform simple Dapr calls i.e., service invocation, pub/sub, or state store, and check both the ACA Aspire dashboard and your OTLP backend.

I was under the impression that in Azure container apps you can not add configuration dapr configs because it is a managed enviroment. In my local development environment, I have it set it this way. But in production, I was under the impression that the include includeDapr=true is what handles configuring dapr sidecars.