Telemtra
Sign in Start free
/docs/otlp-http-vs-grpc
port 4318 vs 4317
free plan / 1 gb-mo
telemtra.io
// otlp transport

OTLP HTTP vs gRPC:
which transport to use.

OpenTelemetry's OTLP protocol can travel over HTTP/protobuf or gRPC. They carry the same data, but the operational properties differ. This page covers the trade-offs and a decision guide for production deployments.

> Start free ~ Collector quickstart

Short answer

Use OTLP HTTP/protobuf for app-direct export, serverless, and anywhere your egress goes through generic HTTP infrastructure. Use OTLP gRPC between a Collector and a backend, or in high-throughput environments where a persistent connection saves real CPU. Both transports carry the same span, log, and metric records; nothing is lost by choosing one over the other.

Endpoint URLs

For Telemtra:

  • OTLP HTTP/protobuf: https://ingest.telemtra.io (the SDK appends /v1/traces, /v1/metrics, /v1/logs).
  • OTLP gRPC: ingest.telemtra.io:443 (TLS required).

The HTTP path is fixed by the OTLP spec; you cannot rename it. Telemtra terminates TLS on 443 and serves both transports there, so you point exporters at the standard HTTPS port for either one. The familiar 4317 (gRPC) and 4318 (HTTP) ports are the OTel convention for a local Collector's own receivers — they are not Telemtra's public endpoint.

Payload format

Both transports send protobuf-encoded OTLP messages. The only difference is the envelope: HTTP wraps it in an HTTP request body, gRPC wraps it in an HTTP/2 frame with gRPC framing. Some SDKs also support OTLP HTTP/JSON, but it is larger over the wire and almost never the right choice in production — stick with HTTP/protobuf.

Performance

gRPC has a small per-request overhead advantage because it multiplexes streams over a persistent HTTP/2 connection. For most apps emitting batches once per second this is negligible. The real difference shows up at high volume (tens of thousands of spans per second), where the saved TLS handshakes and connection management add up.

HTTP/protobuf with keep-alive is close enough for most production workloads that operational simplicity often wins. If your only reason to choose gRPC is "it sounds faster," HTTP/protobuf is the right default.

Proxies and load balancers

HTTP/protobuf travels through every CDN, reverse proxy, WAF, and corporate egress proxy without special configuration. gRPC requires HTTP/2 support end-to-end; many older proxies will silently break gRPC connections or terminate streams.

If your egress path includes a corporate proxy you do not control, default to HTTP/protobuf. You will save a debugging cycle.

Retries and timeouts

Both OTel SDKs implement exponential backoff with jitter for transient errors (5xx for HTTP, UNAVAILABLE for gRPC). The retry behavior is similar in both. gRPC has slightly better error semantics for streaming, but OTLP does not use streaming — every export is a unary call — so this advantage disappears.

TLS and authentication

Both transports support TLS. Telemtra requires TLS on both endpoints. Authentication is a header (x-api-key) regardless of transport. The SDK config differs slightly:

# Environment variables (apply to both transports)
OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.telemtra.io     # HTTP
# or
OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.telemtra.io:443     # gRPC

OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf      # or grpc
OTEL_EXPORTER_OTLP_HEADERS=x-api-key=YOUR_KEY

Decision guide

  • App exports directly to Telemtra → HTTP/protobuf. Simpler config, fewer surprises.
  • Serverless (Lambda, Vercel, Workers) → HTTP/protobuf. Connection reuse is unreliable; gRPC's persistent connection advantage is lost.
  • Collector sidecar → app sends HTTP, sidecar forwards gRPC. The sidecar holds the gRPC connection alive; the app pays no per-export connection cost.
  • Egress proxy in the path → HTTP/protobuf. Avoid the HTTP/2 compatibility risk.
  • Dedicated Collector-to-Collector path inside a cluster → gRPC. You control both ends and gain a real throughput advantage.

SDK examples

Python (HTTP)

pip install opentelemetry-exporter-otlp-proto-http
OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.telemtra.io \
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
OTEL_EXPORTER_OTLP_HEADERS=x-api-key=$TELEMTRA_API_KEY \
opentelemetry-instrument python app.py

Python (gRPC)

pip install opentelemetry-exporter-otlp-proto-grpc
OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.telemtra.io:443 \
OTEL_EXPORTER_OTLP_PROTOCOL=grpc \
OTEL_EXPORTER_OTLP_HEADERS=x-api-key=$TELEMTRA_API_KEY \
opentelemetry-instrument python app.py

Collector (both at once)

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

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

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp/telemtra]
    logs:
      receivers: [otlp]
      exporters: [otlphttp/telemtra]
    metrics:
      receivers: [otlp]
      exporters: [otlphttp/telemtra]

See What is OTLP? for the protocol overview and the Collector quickstart for a full pipeline. Shipping to Grafana Cloud? Its gateway is HTTP-only — see Grafana Cloud with OpenTelemetry for the endpoint and auth setup. Start a Telemtra workspace to test both transports.

Further reading