Skip to main content
An exporter sends telemetry data out of your application to a backend system. It’s the component that does the actual network call to Arize AX (or any other OTel-compatible backend). The exporter handles a handful of distinct concerns:
Exporter timeouts are different from Span Processor timeouts. The exporter timeout protects you from slow networks; the processor timeout protects you from slow or overloaded export pipelines. Set the processor timeout higher than the exporter timeout — see the pitfalls section below.
For the full specification, see Exporter documentation.

OTLP (OpenTelemetry Protocol)

OTLP is the standardized wire format and transport for OpenTelemetry data. Arize AX accepts spans over OTLP, and most OTel-compatible backends do too. OTLP defines three things: For the full specification, see OTLP Specification.

Transport: gRPC vs HTTP

OTLP supports two transports. They’re not identical — pick based on your environment.

OTLP/gRPC Configuration

OTLP/HTTP Configuration

Three differences worth knowing about the HTTP exporter:
  • No credentials constructor argument — TLS is automatic when the endpoint starts with https://. For client certificates, pass certificate_file, client_key_file, or client_certificate_file.
  • No insecure=True option — controlled entirely by the http:// vs https:// scheme on the endpoint.
  • No protocol constructor argument. To switch the body format between http/protobuf (default) and http/json, set OTEL_EXPORTER_OTLP_TRACES_PROTOCOL in the environment.
For the full set of constructor parameters, see the OTLP Exporter API reference.

Multiple Exporters

You can attach multiple exporters to the same Tracer Provider — useful for development (export to Arize AX and to the console) or for fan-out to multiple backends.
Each exporter gets its own span processor. They run independently — a failure in one doesn’t affect the other.

Environment Variables

You can configure the exporter entirely from the environment, which is the recommended pattern for production: The traces-only variant takes priority over the generic one when both are set. For the full reference, see OpenTelemetry environment variables.

Common Pitfalls

A few exporter failure modes worth knowing about up front:
  • Wrong OTLP port or endpoint — gRPC defaults to 4317, HTTP to 4318. Mixing them up surfaces as connection refused or 404s.
  • Wrong encoding for the transport — gRPC requires Protobuf. Trying to send JSON over gRPC will silently fail.
  • Proxies breaking gRPC — corporate proxies, service meshes, and some load balancers don’t handle HTTP/2 well. If you see flaky gRPC errors, switch to HTTP.
  • TLS mismatches — forgetting insecure=True when running against a local collector over http:// fails. So does setting insecure=False against an http:// endpoint. Match insecure to the scheme: True for http://, False (default) for https://.
  • Exporter timeout too high — if the exporter timeout exceeds the Span Processor timeout, the processor can fire a retry while the original export is still in flight, leading to queue buildup and dropped spans.
  • Spans over 4 MB hit gRPC message-size limits — very large attributes (full document text, base64 images) can blow past the gRPC default. Truncate large attributes with TraceConfig or chunk them.

Next step

The exporter sends spans. The span processor decides when and how often:

Next: Span Processor