Supported data ingestion methods

Uptrace supports multiple ingestion methods to collect traces, metrics, and logs from your applications and infrastructure. This guide helps you choose the right approach for your use case.

Quick decision guide

Starting fresh with observability?
Use the OpenTelemetry SDK for your programming language. It provides traces, metrics, and logs with full control over instrumentation.

Need zero-code instrumentation?
Use OpenTelemetry eBPF to automatically capture HTTP, gRPC, SQL, and other traffic without code changes.

Already using Prometheus or Grafana?
Use Prometheus remote write to forward metrics while keeping PromQL compatibility.

Collecting infrastructure metrics?
Use the OpenTelemetry Collector to monitor host metrics, databases, and other systems.

Forwarding logs from files or systems?
Use Vector or FluentBit for high-performance log collection.

Migrating from Sentry?
Use the Sentry SDK integration to send error tracking data to Uptrace.

OpenTelemetry native

These methods use OpenTelemetry Protocol (OTLP) natively and provide the most complete observability.

Method	Signals	Best for
OpenTelemetry SDK	Traces, Metrics, Logs	Applications with code access. Configure SDKs for Go, Python, Java, JavaScript, Ruby, PHP, .NET, Rust, and more.
OpenTelemetry Collector	Traces, Metrics, Logs	Infrastructure monitoring, data transformation, and routing. Acts as a central hub for telemetry.
OTel Arrow	Traces, Metrics, Logs	High-volume deployments. Uses Apache Arrow for 50-70% bandwidth reduction compared to standard OTLP.
OpenTelemetry eBPF	Traces, Metrics	Zero-code instrumentation. Captures HTTP, gRPC, SQL at the kernel level for any language.

Metrics collection

These methods focus on collecting metrics from various sources.

Method	Description
Prometheus	Forward Prometheus metrics via remote write or Collector receivers. Keeps PromQL queries compatible.
AWS CloudWatch	Ship AWS CloudWatch metrics and logs via Data Firehose or YACE exporter.
Telegraf	Output Telegraf metrics through the OpenTelemetry plugin.

Log forwarding

These methods specialize in collecting and forwarding logs to Uptrace.

Method	Description
Vector	High-performance log collection with VRL transforms. Blazingly fast and memory efficient.
FluentBit	Lightweight log processor with OpenTelemetry output. Great for containerized environments.
Loki	Bridge Promtail or Grafana Agent logs via the Collector's Loki receiver.
Heroku	Collect Heroku platform logs using Logplex and Vector.

Error tracking and legacy protocols

Method	Signals	Description
Sentry SDK	Traces, Errors	Use existing Sentry SDKs with Uptrace. Good for JavaScript browser apps and error tracking.
Jaeger	Traces	Accept spans from existing Jaeger agents via Collector receiver.

Summary table

Method	Traces	Metrics	Logs	Code changes
OpenTelemetry SDK	✅	✅	✅	Required
OpenTelemetry Collector	✅	✅	✅	None
OTel Arrow	✅	✅	✅	None
OpenTelemetry eBPF	✅	✅		None
Prometheus		✅		None
AWS CloudWatch		✅	✅	None
Telegraf		✅		None
Vector			✅	None
FluentBit			✅	None
Loki			✅	None
Heroku			✅	None
Sentry SDK	✅			Minimal
Jaeger	✅			None

Limits and retries

These rules apply to every ingestion method above.

Authentication. Pass the project DSN in the uptrace-dsn header (gRPC metadata or HTTP). Over HTTP, Uptrace also accepts Authorization: Bearer <dsn> and a ?dsn=<dsn> query parameter, which helps with clients that cannot set custom headers.

Compression. HTTP endpoints accept request bodies with Content-Encoding set to gzip, zstd, deflate, zlib, lz4, or s2.

Overload. Each Uptrace instance reads a bounded number of request bodies at the same time. When no read slot frees up within ingest.read_queue_timeout (5s by default), the request is rejected with a retry hint:

HTTP: 429 Too Many Requests with a Retry-After header.
gRPC: ResourceExhausted with a RetryInfo detail.

OpenTelemetry SDK and Collector exporters retry these responses automatically. OTel Arrow is the exception: its rejections carry no retry hint.

Metric attributes. Uptrace checks each metric datapoint as it arrives:

Limit	Default	When exceeded
Attributes per datapoint	128	The datapoint is dropped.
Attribute key length	256 bytes	The datapoint is dropped.
Attribute value length	1000 bytes	The value is truncated and kept.

For OTLP, the attribute count includes resource and scope attributes. On self-hosted Uptrace, you can change these limits with pipelines.metrics.max_attrs, max_attr_key_len, and max_attr_value_len.