What is OTLP?

OTLP basics

OTLP lets OpenTelemetry components exchange telemetry in a consistent format. Applications can export OTLP directly from the SDK to a backend, but many teams send data to a local or central OpenTelemetry Collector first. The Collector handles buffering, batching, enrichment, filtering, and backend-specific headers.

OTLP is the only wire format the OpenTelemetry project defines — if a backend or SDK speaks OpenTelemetry, it speaks OTLP. This is what makes vendor switching cheap: change the exporter endpoint and credentials, not the instrumentation.

OTLP schema and signal types

OTLP defines a protobuf schema that covers all three OpenTelemetry signals in a single shape. See OpenTelemetry signals for the signal types in depth:

• Traces — ExportTraceServiceRequest with a list of ResourceSpans. Each span carries a trace_id, span_id, parent_span_id, attributes, events, status, and timing.
• Logs — ExportLogsServiceRequest with ResourceLogs. Each record carries severity, body, attributes, and (when emitted inside a span) trace_id and span_id.
• Metrics — ExportMetricsServiceRequest with ResourceMetrics. Each metric is a gauge, sum (counter), histogram, exponential histogram, or summary, with optional aggregation temporality and attribute dimensions.

Each request also carries a Resource describing the producer — service.name, host.name, deployment.environment, k8s.pod.name, and other resource attributes. Resource attributes apply to every signal a producer emits and are what backends use to group, filter, and scope telemetry.

OTLP HTTP vs OTLP gRPC

OTLP runs over two transports. Both carry the same protobuf payloads, so the choice is operational, not conceptual. See OTLP HTTP vs gRPC for the full comparison.

• OTLP HTTP sends protobuf (or JSON) in POST bodies. Easy to deploy through any HTTP proxy, load balancer, or firewall. Default port 4318. Use this when in doubt — it works almost everywhere with no extra plumbing.
• OTLP gRPC uses persistent HTTP/2 connections with streaming RPCs. More efficient for high-throughput services because connections are reused. Default port 4317. Requires gRPC-compatible infrastructure (most cloud load balancers support it, some legacy proxies do not).

For application-to-Collector hops on the same host, gRPC has a small edge. For Collector-to-backend over the public internet, HTTP is usually the safer default unless you control both sides of the network.

OTLP endpoints and path conventions

OTLP HTTP uses three paths under a base endpoint:

• POST /v1/traces — trace exports
• POST /v1/logs — log exports
• POST /v1/metrics — metric exports

Most SDKs only need the base URL; they append the path automatically. With Telemtra, set the base to https://ingest.telemtra.io and the SDK will POST to https://ingest.telemtra.io/v1/traces, /v1/logs, and /v1/metrics.

OTLP gRPC uses a single endpoint with three RPC services defined in the protobuf schema. Set the endpoint to host:port (for Telemtra: ingest.telemtra.io:443) and the SDK or Collector picks the right RPC service per signal.

OTLP authentication headers

OTLP itself does not define an authentication scheme — that is the backend's responsibility. Most hosted backends require an API key or token on the exporter request. Keep that key in the Collector or SDK environment, not in application source code or checked-in config.

Telemtra authenticates with the x-api-key header, lowercase. Add it to the Collector exporter:

exporters:
  otlphttp/telemtra:
    endpoint: https://ingest.telemtra.io
    headers:
      x-api-key: ${env:TELEMTRA_API_KEY}

Or set it directly via SDK environment variables (works for every OpenTelemetry SDK that supports OTLP HTTP):

export OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.telemtra.io
export OTEL_EXPORTER_OTLP_HEADERS="x-api-key=${TELEMTRA_API_KEY}"

OTLP environment variables

Every OpenTelemetry SDK reads the same OTEL_* environment variables. The most important ones for OTLP:

• OTEL_EXPORTER_OTLP_ENDPOINT — the base URL or host:port the exporter sends to.
• OTEL_EXPORTER_OTLP_HEADERS — comma-separated key=value pairs added to every request. Use this for the API key header.
• OTEL_EXPORTER_OTLP_PROTOCOL — http/protobuf, http/json, or grpc. Default is grpc in some SDKs, http/protobuf in others — set it explicitly to avoid surprises.
• OTEL_SERVICE_NAME — the resource attribute that becomes the service selector in your backend.
• OTEL_RESOURCE_ATTRIBUTES — comma-separated key=value pairs added to every signal as resource attributes (e.g. deployment.environment=production,host.name=api-1).

Compression and batching

OTLP supports gzip compression on both HTTP and gRPC. SDKs enable it by default or via OTEL_EXPORTER_OTLP_COMPRESSION=gzip. Collectors enable it per exporter:

exporters:
  otlp/telemtra:
    endpoint: ingest.telemtra.io:443
    compression: gzip
    headers:
      x-api-key: ${env:TELEMTRA_API_KEY}

OTLP exports happen in batches, not per span. The Collector's batch processor groups records before export — the default batch size is 8192 records or 200ms, whichever comes first. SDKs have a similar BatchSpanProcessor on the client side.

Common OTLP errors

• 401 / 403 — the API key header is missing, mistyped, or pointing at the wrong workspace. Confirm the header name is x-api-key, lowercase.
• 404 on /v1/traces — the SDK was given a full path (https://ingest.telemtra.io/v1/traces) instead of a base URL, and the SDK appended /v1/traces a second time. Set the base URL only.
• connection refused on :4317 — the backend or Collector does not speak gRPC on that port, or the wrong protocol is set. Switch to OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf and target port 4318 or 443.
• 413 payload too large — reduce send_batch_size on the Collector or the SDK's BatchSpanProcessor max queue size.

OTLP setup tips

• Set stable service names and a deployment.environment resource attribute before telemetry reaches storage. These are what backends group by.
• Use batching and memory limiting in every Collector config. Without them a traffic spike can OOM the host.
• Send noisy logs through the Collector's filter processor or Data Shaper rules before they become expensive.
• Keep API keys in environment variables, secret managers, or Kubernetes Secrets — never in checked-in YAML.
• Pin OTLP exporter versions in build files. The protocol is stable but exporter libraries occasionally change defaults (compression, retry behavior) between major versions.

OTLP FAQ

Further reading

• Telemtra quickstart — OTLP endpoints and headers in copy-paste snippets for every supported stack.
• OTLP HTTP vs gRPC — transport trade-offs in depth.
• What is OpenTelemetry? — the broader project the protocol is part of.
• OpenTelemetry signals — what travels inside an OTLP payload.
• OpenTelemetry Collector quickstart — receive, process, and re-export OTLP.
• opentelemetry.io — OTLP specification
• github.com/open-telemetry/opentelemetry-proto — canonical protobuf schemas