RootTrace

RootTrace / Integrations / OpenTelemetry

APM & OpenTelemetry

Already on OpenTelemetry? Point it here.

RootTrace accepts OTLP/JSON over HTTP for traces, metrics, and logs at /v1/traces, /v1/metrics, and /v1/logs. Set one environment variable, add your collector key, and existing instrumentation lands in the same dashboards, issues, and SLOs as the native wrappers.

What RootTrace watches

Every reading is checked continuously; bad readings become grouped issues with the evidence attached. RootTrace also remembers whether it has seen the same incident before.

Warn and fail thresholds, prefilled

Sensible defaults out of the box, overridable per host with environment variables. No threshold spreadsheet required on day one.

Setup

opentelemetry setup
$ OTEL_EXPORTER_OTLP_PROTOCOL=http/json
$ OTEL_EXPORTER_OTLP_ENDPOINT=https://api.roottrace.io
$ OTEL_EXPORTER_OTLP_HEADERS="Authorization=Collector <your-key>"

Outbound HTTPS only: the wrapper aggregates in memory and posts to the API; nothing listens on your hosts and nothing touches production.

Questions, answered honestly

Which OTLP transports are supported?

OTLP/JSON over HTTP. OTLP/gRPC and protobuf-over-HTTP are not supported. Most SDKs switch with the single OTEL_EXPORTER_OTLP_PROTOCOL variable.

Is this safe to run next to production?

The collector is read-only by architecture, not by policy: there is no write path, no remediation executor, and no privileged mode to switch on. It sends short-lived outbound HTTPS requests, opens no inbound ports, and redacts credential-like evidence before anything leaves the host.

Do I need a separate agent for this?

No. One RootTrace collector per host covers every integration on this site: databases, web servers, containers, endpoints, and the Linux host itself, all from one signed package or container. You point it at targets with environment variables; there is nothing else to deploy.

Free on 5 hosts. Live in minutes.

Create a workspace, install one collector, and watch issues explain themselves.