How do you configure an OTLP exporter in an OpenTelemetry SDK — gRPC versus HTTP transport and their conventional ports, the endpoint environment variables and their differing path rules, headers, compression and timeout — and what does a 'partial success' response from the receiver mean?

## What OTLP is OTLP is OpenTelemetry's own wire protocol, defined for all three signals. Its bindings: - **grpc** — protobuf over gRPC, conventionally port 4317, streaming-friendly, needs a gRPC-capable path (some proxies and load balancers are not). - **http/protobuf** — the same protobuf messages POSTed over HTTP/1.1 or HTTP/2, conventionally port 4318, at `/v1/traces`, `/v1/metrics`, `/v1/logs`. Traverses ordinary HTTP infrastructure, which is why it is often the safer default. - **http/json** — the same messages JSON-encoded; readable, larger, less uniformly supported. Default protocol choice has genuinely varied between SDKs and releases, so pin `OTEL_EXPORTER_OTLP_PROTOCOL` rather than relying on a default. ## The endpoint path rule This is the single most common configuration bug. Two families of variable exist: - Generic: `OTEL_EXPORTER_OTLP_ENDPOINT` — for HTTP the SDK **appends** the per-signal path, so `https://collector:4318` becomes `https://collector:4318/v1/traces`. - Per-signal: `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` (and the metrics/logs equivalents) — used **as-is**, so it must be the complete URL including `/v1/traces`. Set the per-signal form without the path and every export 404s. Set the generic form *with* the path and you get a doubled suffix. Per-signal values override the generic one, and the same override pattern applies to headers, timeout, compression and TLS settings. Under gRPC the endpoint is a host:port target; the path concept does not apply, and whether a scheme implies TLS is a per-SDK detail worth checking. ## Auth, compression, timeouts, TLS `OTEL_EXPORTER_OTLP_HEADERS` takes a comma-separated `key=value` list and is where vendor API keys or tenant identifiers live — which makes it a secret, to be injected like any other credential rather than baked into an image. `OTEL_EXPORTER_OTLP_COMPRESSION=gzip` trades CPU for bandwidth and is usually worth it for egress across a network boundary, less so to a collector on localhost. `OTEL_EXPORTER_OTLP_TIMEOUT` bounds one export attempt (commonly 10s); it must sit sensibly against the batching processor's own timeout and schedule delay, or a stalled backend backs the queue up. Certificate, client-certificate and client-key variables cover TLS and mTLS to a collector. ## Retries and back-pressure Exporters retry transient failures with exponential backoff and jitter on retryable conditions — a gRPC UNAVAILABLE, an HTTP 429 or 503 — and honour throttling hints where the receiver supplies them. Non-retryable failures (a 400-class rejection, a bad payload) are dropped and logged; retrying them would only burn the queue. Retrying is not free: while the exporter retries, the processor's queue keeps filling behind it, and past a point the correct outcome is to shed rather than to persist. ## Partial success OTLP responses can report **partial success**: the request was accepted, but the receiver rejected some number of spans, metric points or log records, with a human-readable message. Typical causes are payload or attribute limits, malformed or unsupported fields, and quota or cardinality rules on the receiving side. Two things matter. First, this is **not** a failure from the transport's point of view, so it does not trigger a retry — the rejected data is gone. Second, SDKs surface it only through their internal logging, so nobody notices unless someone is looking. Treat 'rejected item count greater than zero' as an alertable condition; it is one of the few forms of data loss that announces itself and is still routinely ignored. ## Metrics-specific settings Metric export also has a **temporality preference** (`OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE`: cumulative, delta, or a low-memory mix). Backends differ in what they want — pull-based ecosystems generally expect cumulative, several vendors prefer delta — and choosing wrongly produces charts that look plausible and are wrong, so it is a per-backend decision made once. ## Choosing where to send Most fleets export to a local or nearby **collector** rather than straight to a vendor: the process-side timeout is tiny, credentials and endpoints live in one place instead of in every service's environment, and retry and buffering happen outside the application. Direct-to-vendor export is reasonable for small deployments and for environments where running a collector is not possible.