OTLP
The OpenTelemetry Protocol (OTLP) specifies how OpenTelemetry-related components exchange telemetry data. This includes instrumented applications, intermediary services such as the Collector, as well as backends to which the data is eventually sent.
OTLP primarily defines message structures, encoding, and endpoints and relies on HTTP or gRPC as the underlying transport protocols.
Dynatrace currently only supports OTLP over HTTP and binary-encoded messages.
Both HTTP and gRPC serialize the data payload using Google's Protocol Buffers and their binary encoding (requires a content type of application/x-protobuf
) or textual JSON (requires a content type of application/json
).
Request and response messages
OTLP defines different gRPC message types for each signal.
ExportTraceServiceRequest
for tracesExportMetricsServiceRequest
for metricsExportLogsServiceRequest
for logs
Responses are provided using the applicable response message (for example, ExportTraceServiceResponse
for traces).
OTLP over HTTP
- Both HTTP 1.1 and HTTP 2 can be used—HTTP 3 is not yet supported
- The default TCP port is 4318
- The default paths are
/v1/traces
for traces/v1/metrics
for metrics/v1/logs
for logs
- The request method is
POST
- The request and response bodies are serialized from their respective protobuf messages in one of the following formats:
- In their binary, protobuf format and
application/x-protobuf
- As a mapped JSON document and
application/json
- In their binary, protobuf format and
OTLP over gRPC
- gRPC uses HTTP 2
- The default TCP port is 4317
- Requests and responses follow the OTLP message types
Converting protocols
If you need two OpenTelemetry components to communicate with each other, but they use different protocols or encodings (for example, HTTP and gRPC, or binary and JSON), consider using OpenTelemetry's Collector proxy.
In addition to general data transformation support, the Collector also supports the conversion of protocols (for example, gRPC to HTTP) and encoding types.