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.

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 traces
• ExportMetricsServiceRequest for metrics
• ExportLogsServiceRequest 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

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.