Distributed Tracing Without Assembling Another Stack

Yes. Netdata ingests OpenTelemetry traces over OTLP on the same agent that collects your metrics and logs. Spans are stored and indexed on your own infrastructure, and the Traces tab in Netdata Cloud gives you a duration heatmap, filters by service, span name and duration, a full waterfall for every trace, and every span attribute your instrumentation recorded.

For OpenTelemetry-instrumented services, yes: point your SDKs or Collector at a Netdata Agent over OTLP/gRPC and explore traces in Netdata Cloud, next to your metrics and logs. Netdata does not ingest the native Jaeger or Zipkin protocols, so send spans through OpenTelemetry. If your SDKs export OTLP/HTTP, switch them to gRPC or put an OpenTelemetry Collector in between; native OTLP/HTTP support is on the roadmap.

Mainly TraceQL and the metrics-generator. TraceQL lets you write structural queries across spans and attributes; Netdata filters by service, span name and minimum duration. Tempo’s metrics-generator produces span metrics and service graphs; Netdata does not build service maps or derive RED metrics or alerts from spans. If your team lives in Grafana, you also trade one UI for two. Weigh those against running one agent instead of a stack.

One agent instead of several services. Traces land on the same Netdata Agent that already collects per-second metrics from 800+ integrations and your logs, so there is no Tempo cluster, no separate metrics and logs backend to pair it with, and no Grafana data sources to wire together before a trace and its node appear in the same place. You also get a duration heatmap of every trace and AI access to traces through Netdata AI and the MCP server.

Spans are stored on the disk of the Netdata Agent that receives them, with their own retention settings by size, age and file count, separate from metrics and logs. You can optionally offload trace files to S3-compatible object storage; Netdata reads them back transparently when you query. Trace data is not stored in Netdata Cloud; Cloud brokers access to it, as it does for metrics and logs.

No. Netdata is built for point-and-click investigation: a duration heatmap to spot outliers, filters by service, span name and minimum duration, and a full waterfall with every span attribute. Netdata does not offer free-text search across spans. If your workflow depends on expressive trace queries, TraceQL is a real Tempo strength.

No. Netdata generates its own dashboards for metrics, and traces are explored in the Traces tab in Netdata Cloud, which requires a Netdata Cloud sign-in. Tempo has no UI of its own and is used through Grafana.

Not if you already use OpenTelemetry SDKs or the OpenTelemetry Collector. Change the exporter endpoint to a Netdata Agent and make sure the protocol is gRPC, for example with OTEL_EXPORTER_OTLP_PROTOCOL=grpc. Services that send Jaeger or Zipkin formats to Tempo today need to go through OpenTelemetry instead, since Netdata accepts OTLP only.

No. Every span the Agent accepts is stored. If you want to reduce volume, configure sampling in your OpenTelemetry SDK or in a Collector in front of Netdata, the same way most Tempo users do.

Traces are queried on the Agent that received them. To centralize, point your SDKs or an OpenTelemetry Collector gateway at one Netdata Agent or Parent, and every service sending to it shows up together in the Traces tab. Tempo gives you one central, multi-tenant store by design, at the cost of running it.

Yes. An OpenTelemetry Collector can export the same spans to both Tempo and a Netdata Agent, so teams can compare the two on real traffic. Many Grafana users also keep Grafana for dashboards they have already built while Netdata handles infrastructure metrics, logs and traces.

No. The Traces tab is in Netdata Cloud and needs a Netdata Cloud sign-in, even though the spans themselves stay on your agents. If you need trace exploration that works fully offline, a self-hosted Tempo and Grafana deployment fits that requirement better.

No. Netdata does distributed tracing on OpenTelemetry, with per-second infrastructure metrics and logs on the same agent. It does not build service maps, generate RED metrics or alerts from spans, or do code-level or continuous profiling. In the Grafana ecosystem those come from the Tempo metrics-generator and Pyroscope.

Netdata collects infrastructure metrics and logs and receives OpenTelemetry traces on one agent, jobs that Prometheus or Mimir, Loki and Tempo split across separate services. It adds per-second collection and ML anomaly detection on every metric, and it does not offer PromQL, LogQL or TraceQL. For a broader comparison with Grafana itself, see Netdata vs Grafana.