RootTrace

RootTrace / Integrations / Application logs

Application logs

Logs that arrive already correlated.

Logs ship through the APM wrappers you already installed or straight over OTLP. There is no separate shipper. They land searchable, faceted by level, alertable, and sitting next to the traces and issues from the same service.

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

application logs setup
# already shipping if you use an APM wrapper; for OpenTelemetry:
$ OTEL_EXPORTER_OTLP_PROTOCOL=http/json
$ OTEL_EXPORTER_OTLP_ENDPOINT=https://api.roottrace.io

Outbound HTTPS only: the wrappers and OTLP exporters post to the API; nothing listens on your hosts.

Questions, answered honestly

Do I need a log shipper like Fluentd or Vector?

No. Logs ride the APM wrapper or OTLP/JSON over HTTP. If you already run a shipper that can emit OTLP, point it at the same endpoint.

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.