Running the TracePath OTel Agent as Your Collector: A Practical Guide
Where the tracepath-otel-agent fits in your pipeline, how to configure it for batch-and-forward, and when you should put a full OpenTelemetry Collector in front of it instead.
Why a collector at all
OpenTelemetry SDKs speak OTLP over HTTP or gRPC, but shipping every span directly from your app to your observability backend couples your app's lifecycle to your observability stack's uptime. A collector in between gives you buffering, retries, and one place to redact attributes.
The one-binary path
tracepath-otel-agent is our fork of a minimal collector tuned for the
TracePath ingest API. It ships as a single static binary with sensible
defaults: OTLP HTTP receiver on 4318, batch processor, forward to
https://<your-tracepath-host>/api/otel/v1/* with your project token.
TODO-content: TODO-content: walk through the actual setup: 1. install: curl -fsSL https://get.tracepath.dev/otel-agent | sh (verify real URL before publishing) 2. minimal config.yaml: receivers (otlp), processors (batch, memory_limiter), exporters (otlphttp with Authorization header from TRACEPATH_TOKEN env) 3. run as systemd unit; health check endpoint 4. verify first arrival in the TracePath UI ("Waiting for events" -> installed) Then a section "when you outgrow the agent": tail sampling, multi-tenant routing, and the full upstream opentelemetry-collector-contrib with the same OTLPHTTP exporter pointed at TracePath. Include a real config snippet for tail-sampling with a 10% default policy + keep-all-errors. Link docs /client/otel.