Dynatrace can directly ingest OpenTelemetry OTLP (OpenTelemetry Protocol) data, but it’s not just a passive receiver; it actively transforms and enriches that data to fit its own observability model.
Let’s see it in action. Imagine you have a service instrumented with OpenTelemetry that’s sending traces, metrics, and logs via OTLP to a Dynatrace endpoint.
# On your OpenTelemetry Collector or application
# Example curl command sending a trace
curl -X POST "https://{your-environment-id}.live.dynatrace.com/api/v2/traces/ingest" \
-H "Content-Type: application/json" \
-H "Authorization: Api-Token {your-dynatrace-api-token}" \
-d '{
"spans": [
{
"traceId": "a1b2c3d4e5f67890a1b2c3d4e5f67890",
"spanId": "1a2b3c4d5e6f7890",
"parentSpanId": "0f7e6d5c4b3a2109",
"name": "my-otlp-operation",
"kind": "SPAN_KIND_INTERNAL",
"startTimeUnixNano": "1678886400000000000",
"endTimeUnixNano": "1678886401000000000",
"attributes": [
{"key": "http.method", "value": {"stringValue": "GET"}},
{"key": "service.name", "value": {"stringValue": "my-otlp-service"}}
],
"status": {"code": "STATUS_CODE_OK"}
}
]
}'
# On your Dynatrace environment
# You would then see this trace appear in Dynatrace,
# associated with a service named "my-otlp-service"
# and potentially enriched with additional context.
The core problem OTLP ingestion solves is bridging the gap between the open-standard OpenTelemetry ecosystem and Dynatrace’s proprietary, AI-driven observability platform. Dynatrace doesn’t just store your OTLP data; it uses it to build its "PurePath" concept, correlating traces, metrics, and logs into a unified view. This means an OTLP span isn’t just a span; it becomes part of a transaction that Dynatrace can analyze for anomalies, root causes, and performance bottlenecks.
Internally, Dynatrace’s OTLP endpoint acts as an intelligent gateway. When OTLP data arrives, Dynatrace parses it, maps OpenTelemetry semantic conventions to its own entity model (services, processes, hosts, etc.), and then fuses this information with data from its OneAgent. The service.name attribute from your OTLP data, for instance, is crucial for Dynatrace to identify and categorize the originating service. Similarly, span.kind helps Dynatrace understand the role of an operation within a larger transaction. Attributes are mapped to Dynatrace’s key-value store and can be used for filtering and analysis.
The primary lever you control is how you instrument your applications and configure your OpenTelemetry Collector. Ensuring you adhere to OpenTelemetry semantic conventions, especially for common attributes like service.name, http.method, db.system, and exception.type, is paramount. These conventions are what Dynatrace leverages to automatically detect and classify your services and their dependencies. Without them, your OTLP data might land in Dynatrace but lack the rich context needed for effective analysis.
Dynatrace’s ingestion process is designed to be robust, but it relies heavily on the quality and adherence to semantic conventions in your OTLP data. When you send OTLP metrics, Dynatrace maps them to its metric ingestion API, transforming OTLP metric descriptors into Dynatrace metric keys. For example, an OTLP Sum metric with a unit of ms and name of request.duration might be ingested as a Dynatrace metric like custom.otlp.request.duration.ms. The exemplar field within OTLP metrics, often containing a trace ID and span ID, is particularly valuable as it allows Dynatrace to link specific metric data points back to their originating traces, a crucial step for performance analysis.
The next challenge is often ensuring that logs sent via OTLP are correctly parsed and associated with the right traces and services within Dynatrace.