Having issues with Dynatrace configuration for Otel endpoints of Container Apps Environments

Question

Having issues with Dynatrace configuration for Otel endpoints of Container Apps Environments

ManuInNZ 0

Hi there

Following the article https://learn.microsoft.com/en-us/azure/container-apps/opentelemetry-export-dynatrace, we have configured a 'dynatrace' endpoint, and set the variables for a container app with OpenTelemetry enabled (verified locally in Aspire Dashboard).

However no data shod up in the dynatrace services traces.

When using the console of the Container app I am able to force a Dynatrace test span using a local CLI tool but not through the platform agent.

apt-get update && apt-get install -y wget
wget https://github.com/equinix-labs/otel-cli/releases/download/v0.4.5/otel-cli_0.4.5_linux_amd64.tar.
tar xpvf otel-cli_0.4.5_linux_amd64.tar.gz
chmod a+ otel-cli
# Set the OTEL Vars 

export OTEL_EXPORTER_OTLP_ENDPOINT="https://<myinstance>.live.dynatrace.com/api/v2/otlp"
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Api-Token myvalid.key.09w098tw908tr09t830"
export OTEL_SERVICE_NAME="bash-otel-cli-tester"

./otel-cli exec --name "Container-CLI-Test-Span" echo "Sending trace payload via otel-cli..."

On the console I can see the underlying K8S OTEL config vars and I can see data in Azure monitor but not in Dynatrace.

Pravallika KV 17,620 Reputation points Microsoft External Staff Moderator

2026-06-29T18:16:19.2033333+00:00
Hi @ManuInNZ ,

Thanks for reaching out to Microsoft Q&A.

Here are the key things to verify based on Microsoft’s Dynatrace OTLP guide.

Confirm the environment-level Dynatrace destination is configured correctly

In the Azure portal, the Dynatrace destination should be set under:

Container Apps environment → Monitoring → OTel endpoints → Dynatrace → Update

And configured as:

Endpoint: https://<TENANT>.live.dynatrace.com/api/v2/otlp

Key: Dynatrace ingest token

Enable the signal checkboxes:

Logs

Traces

Metrics

Then Save

Also note: the guide explicitly calls out that the destination configuration alone does not guarantee telemetry—your app still must emit telemetry.

Ensure your app is actually emitting telemetry (destination config doesn’t auto-generate data)

“Configuring a managed OpenTelemetry destination doesn't automatically produce telemetry. Your application must also be instrumented to emit traces, metrics, and logs…”

So if Dynatrace shows nothing from the managed agent, the most common causes are:

The workload isn’t instrumented with an OpenTelemetry SDK (or isn’t emitting spans/metrics/logs).

The signals you expect (traces/logs/metrics) aren’t actually being produced by the app.

Make sure you used the required app env vars for OTLP export

The guide lists these required container app environment variables when enabling OTLP export to Dynatrace:

OTEL_SERVICE_NAME = your app/service name

OTEL_TRACES_EXPORTER = otlp

OTEL_METRICS_EXPORTER = otlp

OTEL_LOGS_EXPORTER = otlp

OTEL_EXPORTER_OTLP_METRICS_PROTOCOL = http/protobuf

OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE = DELTA

If metrics aren’t going to Dynatrace, the guide specifically says Dynatrace requires:

OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=DELTA

Don’t confuse the managed agent flow with manual otel-cli tests

Your manual otel-cli test proves:

network/Dynatrace ingestion works from the container

OTLP endpoint/token/header format is acceptable for the CLI

But it doesn’t prove that the managed OpenTelemetry agent + your app’s instrumentation is producing and exporting telemetry.

Verify whether the running app emits the signals (spans/metrics/logs) that the managed agent expects.

Verify in Dynatrace using the Services app

Microsoft recommends using Dynatrace Services app to validate that metrics, logs, and traces appear for the Container Apps service context:

Services app → locate your service → confirm signals are present.

If “nothing shows up” there, the issue is likely instrumentation/export not being triggered (even if the destination is configured).
ManuInNZ 0 Reputation points

2026-06-29T21:00:44.2966667+00:00
As I mentioned in another comment, I did all of that, and when I set the OTEL_* env vars to point directly to Dynatrace, it works for my smoketest app.
i.e., forcing the following values:

OTEL_EXPORTER_OTLP_ENDPOINT # Override from the K8s value

OTEL_EXPORTER_OTLP_HEADERS

OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf # Override from gRPC

Not sure I get the agent feature at environment level right then.
Pravallika KV 17,620 Reputation points Microsoft External Staff Moderator

2026-07-01T00:34:44.7533333+00:00

@ManuInNZ , When you explicitly set OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_HEADERS, and OTEL_EXPORTER_OTLP_PROTOCOL to point directly to Dynatrace, your app is bypassing the Azure Container Apps OpenTelemetry pipeline entirely and exporting straight to Dynatrace. That’s why your smoketest works.

The “environment-level agent” feature only comes into play when the app uses the Azure-injected OpenTelemetry collector configuration (typically via localhost/injected OTLP settings). If you override those OTEL_* exporter settings, you replace that routing, so the Azure-managed collector is no longer used.

So there’s no conflict in what you’re seeing just two different export paths:

Direct export → app sends straight to Dynatrace (works in your test)

Managed Azure pipeline → app sends to Azure collector, which then forwards to Dynatrace (used only if you don’t override OTEL exporter settings)

Your direct setup proves end-to-end connectivity, but the environment agent is meant for decoupling apps from exporters rather than improving the direct export path.
ManuInNZ 0 Reputation points

2026-07-01T20:17:19.8633333+00:00
Well point being that if you do follow the article and indeed try to use the platform level agent it does not work.

Only by forcing traffic straight to Dynatrace do I see it.

To me this proves:

my app does emit OTEL

Dynatrace credentials are valid

Actual traces, metrics and logs are usable, ingested properly in Dynatrace

Which leaves me with the fact that having all other OTEL vars set as per the article and the

otlpConfigurations also, the platform capture and routing just does not work.

is there still an underlying issue with the agent collecting on gRPC and Dynatrace SaaS expecting http/protobuf?

Thanks for your help.

1 answer

Your answer

ManuInNZ 0 Reputation points

2026-06-29T21:00:44.2966667+00:00

As I mentioned in another comment, I did all of that, and when I set the OTEL_* env vars to point directly to Dynatrace, it works for my smoketest app.
i.e., forcing the following values:

OTEL_EXPORTER_OTLP_ENDPOINT # Override from the K8s value

OTEL_EXPORTER_OTLP_HEADERS

OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf # Override from gRPC

Not sure I get the agent feature at environment level right then.
Pravallika KV 17,620 Reputation points Microsoft External Staff Moderator

2026-07-01T00:34:44.7533333+00:00

@ManuInNZ , When you explicitly set OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_HEADERS, and OTEL_EXPORTER_OTLP_PROTOCOL to point directly to Dynatrace, your app is bypassing the Azure Container Apps OpenTelemetry pipeline entirely and exporting straight to Dynatrace. That’s why your smoketest works.

The “environment-level agent” feature only comes into play when the app uses the Azure-injected OpenTelemetry collector configuration (typically via localhost/injected OTLP settings). If you override those OTEL_* exporter settings, you replace that routing, so the Azure-managed collector is no longer used.

So there’s no conflict in what you’re seeing just two different export paths:

Direct export → app sends straight to Dynatrace (works in your test)

Managed Azure pipeline → app sends to Azure collector, which then forwards to Dynatrace (used only if you don’t override OTEL exporter settings)

Your direct setup proves end-to-end connectivity, but the environment agent is meant for decoupling apps from exporters rather than improving the direct export path.
ManuInNZ 0 Reputation points

2026-07-01T20:17:19.8633333+00:00

Well point being that if you do follow the article and indeed try to use the platform level agent it does not work.

Only by forcing traffic straight to Dynatrace do I see it.

To me this proves:

my app does emit OTEL

Dynatrace credentials are valid

Actual traces, metrics and logs are usable, ingested properly in Dynatrace

Which leaves me with the fact that having all other OTEL vars set as per the article and the

otlpConfigurations also, the platform capture and routing just does not work.

is there still an underlying issue with the agent collecting on gRPC and Dynatrace SaaS expecting http/protobuf?

Thanks for your help.

Answer 1

hi ManuInNZ & thx for sharing urs issue here at Q&A portal,

Since otel-cli from inside the container reaches Dynatrace, network and token look ok. That points to the ACA platform OpenTelemetry pipeline/config, not Dynatrace itself. First thing I’d check is whether the Container Apps environment endpoint is actually bound to the app and whether the app has telemetry export enabled at revision level. Seeing Azure Monitor data doesn’t always prove the Dynatrace exporter is active.

Also check the Dynatrace OTLP endpoint format. For Dynatrace, ACA should use https://<tenant>.live.dynatrace.com/api/v2/otlp with header Authorization=Api-Token <token>

If u used the endpoint name dynatrace, make sure the app references that exact endpoint name in the OpenTelemetry config. Cute little typo there and ACA silently sends ur traces to nowhere.

https://learn.microsoft.com/en-us/azure/container-apps/opentelemetry-export-dynatrace

https://learn.microsoft.com/en-us/azure/container-apps/log-options

I’d also check whether ur app is producing OTLP traces to stdout/sdk or only Aspire-local traces. Local Aspire dashboard working doesn’t guarantee ACA platform agent receives spans in Azure.

So deploy a tiny app that emits one basic OTEL span on each request, bind only the Dynatrace endpoint, then hit it and check Dynatrace. If that fails while otel-cli works, open ACA support w/ environment name, endpoint config, app revision, UTC test time, and confirmation that manual OTLP from the container succeeds.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/

ManuInNZ 0 Reputation points

2026-06-29T20:53:54.22+00:00

Thanks Alex

I guess where I am a bit lost at sea on the feature goal then.

When I setup my app (which does emit OTEL) with the env vars to direct to Dynatrace from within the CAE then it works.
I guess I thought the agent was meant to be a collector hosted at platform level, that it would receive the information using gRPC and then pass it on. But if I just need to set the env vars to straight to Dynatrace in the App, what's the point of the agent?