Connecting OpenTelemetry Traces to Dynatrace via OTLP

The Goal: Unified Service Mapping from OTLP

To get OpenTelemetry (OTel) traces into Dynatrace, you must configure an OpenTelemetry Collector to act as a bridge. The primary objective is to ensure that spans emitted by your application are correctly attributed to services in the Dynatrace Service Flow view, allowing you to visualize end-to-end latency and error rates across distributed boundaries.

The critical takeaway is that Dynatrace requires a specific exporter configuration and a token with the correct API scopes to ingest OTLP data. Without these, traces will either be dropped by the collector or rejected by the Dynatrace tenant with a 401 Unauthorized error.

The Mechanism: OTLP Collector Pipeline

The OpenTelemetry Collector operates as a pipeline: it receives data from your app, processes it (optional), and exports it to the backend. For Dynatrace, the otlp receiver accepts data from your SDKs, and the dynatrace exporter pushes that data to your tenant endpoint.

Configuration Example

Below is a standard config.yaml for an OpenTelemetry Collector (version 0.70.0 or newer) configured for Dynatrace ingestion. This configuration assumes the collector is running as a standalone binary or container.

receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  dynatrace:
    # Replace {tenant-id} and {environment} with your actual Dynatrace URL
    url: https://{tenant-id}.live.dynatrace.com/api/v2/otlp
    api_token: "dt0c01.ST...your_token_here..."

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [dynatrace]

Implementation Requirements

• Permissions: The API token used in the api_token field must have the otlp.ingest (or equivalent API/metrics) scope. If the token lacks these permissions, the collector logs will show repeated 401 errors.
• Network: The collector must have outbound HTTPS access to the Dynatrace tenant endpoint on port 443.
• Protocol: Ensure your application SDKs are configured to use OTLP over HTTP/2 or gRPC, as these are the supported transport methods for the OTLP receiver.

Verification and Diagnostics

Once the collector is deployed, you can verify the connection using these steps:

1. Connectivity Check

Run this command from the machine hosting the collector to ensure the tenant is reachable. Replace {tenant} with your environment ID:

# Run on the Collector host
curl -I https://{tenant}.live.dynatrace.com/api/v2/health

Expected Result: An HTTP 200 OK response. A 404 or timeout indicates a firewall or DNS issue.

2. Log Inspection

Check the collector's stdout or log file. Look for the following patterns:

• Success: No errors regarding the dynatrace exporter.
• Failure: "exporting failed: 401 Unauthorized" indicates an invalid or insufficient API token.
• Failure: "context deadline exceeded" typically points to a network timeout or proxy blocking the request.

3. UI Validation

Navigate to the Service Flow menu in the Dynatrace UI. If configured correctly, you will see your application appearing as a service node, with edges connecting it to downstream dependencies (databases, other APIs) based on the trace spans.

Limitations and Common Pitfalls

Span Naming and Attribution

Dynatrace uses the service.name attribute from the OTel resource to identify the service. If your application does not explicitly set this attribute, Dynatrace may group traces under a generic name like "unknown_service," making the Service Flow view difficult to navigate.

Licensing Constraints

While OTLP ingestion is supported, the full visualization of distributed traces and the Service Flow UI typically require a Full Stack license tier. Users on lower tiers may see the data ingested but lack the interface to analyze the trace topology.

Protocol Mismatches

A common mistake is configuring the application SDK to send OTLP via HTTP/1.1 while the collector expects HTTP/2. This often results in "silent" trace loss where the application thinks the data was sent, but the collector cannot parse the stream.

Rollback Procedure

Because this configuration changes the data flow of your observability pipeline, you can revert the state by:

1. Updating the config.yaml to remove the dynatrace exporter from the service.pipelines.traces.exporters list.
2. Restarting the OpenTelemetry Collector process to apply the change.
3. Revoking the API token in the Dynatrace Access Tokens menu to ensure no further data can be pushed from that specific credential.