Distributed Tracing

Follow Every Request Across Every Service

Q: Do I need to change my instrumentation?

No. Keep your OpenTelemetry SDKs and auto-instrumentation. Point the OTLP exporter at a Netdata Agent and set the protocol to gRPC, or send spans through an OpenTelemetry Collector that forwards OTLP/gRPC to Netdata.

Q: My SDKs export OTLP/HTTP. Will that work?

Netdata receives traces over OTLP/gRPC today. Set OTEL_EXPORTER_OTLP_PROTOCOL=grpc in your SDKs, or run an OpenTelemetry Collector that receives OTLP/HTTP from your services and exports OTLP/gRPC to Netdata. Native OTLP/HTTP support is on the roadmap. The OTLP ingestion docs cover the setup.

Q: How do I trace services running in Kubernetes?

Run an OpenTelemetry Collector as a DaemonSet or gateway in the cluster and have it forward OTLP/gRPC to a Netdata Agent or Parent. Traces are queried on the agent that received them, so sending them to one agent or Parent gives you one place to explore them.

Q: Where are the spans stored, and for how long?

On the disk of the Netdata Agent that received them. Trace data is not stored in Netdata Cloud. Traces have their own retention limits by size, age and number of files, and older trace files can be offloaded to S3-compatible object storage that Netdata reads back when you query.

Q: Do I need Netdata Cloud?

Yes. Traces are explored in the Traces tab of Netdata Cloud and need a Netdata Cloud sign-in. The spans themselves stay on your agents.

Q: Does Netdata sample traces?

No. Every span the agent accepts is stored. If you sample, you configure it in your SDK or Collector.

Q: Can I ask an AI assistant about a slow request?

Yes. Netdata AI and the Netdata MCP server give AI assistants access to traces alongside metrics, logs and alerts, so an assistant can query traces while it investigates an incident with you.

Your checkout touches a dozen services. When it gets slow, you need the one span that took the time, and the state of the node that ran it. Send your OpenTelemetry traces to Netdata and see both in one place, with the spans kept on your own infrastructure.

Start Free Trial See the Tracing Feature

Follow Every Request Across Every Service product interface

Tracing needs its own backend

A collector, a storage cluster and a query service, each to size, upgrade and keep alive.

Netdata receives traces on the agent you already run

The same agent that collects metrics and logs stores and serves your spans.

Spans carry request data you would rather keep in-house

URLs, user IDs and payload attributes end up in span attributes.

Spans stay on your own infrastructure

Trace data is stored on the receiving agent’s disk, not in Netdata Cloud.

The trace says the database call was slow

Was it the query, or a node running out of memory or disk I/O?

Per-second node metrics and logs sit in the same UI

The Metrics and Logs tabs are next to the Traces tab, for the same nodes.

Your SDKs default to OTLP/HTTP

Many OpenTelemetry SDKs export OTLP/HTTP out of the box.

Switch to gRPC or add a Collector

Set OTEL_EXPORTER_OTLP_PROTOCOL=grpc, or let a Collector convert. Native OTLP/HTTP is on the roadmap.

OTLP Ingestion

Any OpenTelemetry SDK or Collector can send traces over OTLP/gRPC to the same agent endpoint that receives OTLP metrics and logs.

Duration Heatmap

See every trace bucketed by duration over time. Error spans show as red cells, so the requests worth opening stand out.

Focused Filters

Narrow the trace list by service, span name and minimum duration, or click a heatmap cell to jump to that bucket.

Cross-Service Waterfall

Open a trace to see every span across every service, in order, with timing, span kind and error highlighting.

Every Attribute Kept

Span details show status, timing, parent span and every attribute your instrumentation recorded, all indexed.

Your Infrastructure

Spans are stored on your own agents, with their own retention limits, optional S3 offload, and TLS or mutual TLS on ingestion.

Trusted by engineering teams running microservices

A Tracing Workflow for Microservices

Point Your Services at Netdata

Keep your OpenTelemetry instrumentation as it is. Set the OTLP exporter endpoint to a Netdata Agent and the protocol to gRPC, or route spans through an OpenTelemetry Collector. In Kubernetes, a Collector DaemonSet or gateway that forwards OTLP/gRPC to a Netdata Agent or Parent gives you one place to query.

No new tracing backend

Read the OTLP ingestion docs

Spot the Slow and Failing Requests

The duration heatmap shows every trace in the window, bucketed by duration, with error spans in red. Hover a cell for its counts and click it to narrow the trace list. Switch to trace volume, error spans or p50/p95/p99 duration percentiles when you want the trend instead.

Every trace in one chart

See the Traces tab

Find the Span That Took the Time

Open a trace and the waterfall lays out every span across every service in order, with its timing and span kind. Errors are highlighted. A 138-span checkout across 12 services reads top to bottom, so the slow hop is easy to see.

Every span, every service

Explore microservices observability

Read What the Span Recorded

Click a span to see its status, timing and parent span, and every attribute your instrumentation set: HTTP method and route, database statement, request IDs. Resource, Scope, Events, Links and Raw views show the rest. Copy the trace’s deep link into the incident channel so the team looks at the same thing.

Every attribute indexed

See application performance monitoring

Check the Node Behind the Span

The Traces tab sits next to Metrics and Logs in the same Netdata Cloud UI, for the same nodes. When a span points at a service, check that pod’s or host’s per-second CPU, memory, disk and network metrics and its logs without switching tools.

Same UI as metrics and logs

Explore Kubernetes monitoring

Tracing for Microservices

Netdata vs a Standalone Tracing Stack

What changes when your traces land on the same agent as your metrics and logs, and where a dedicated APM suite still goes further.

Backend to Operate

✅ Simple
Traces handled by the existing agent

⚠️ Complex
Separate collector, storage and query tier

Instrumentation

✅ Good
OpenTelemetry SDKs or Collector over OTLP/gRPC

✅ Advanced
OpenTelemetry plus native vendor protocols

Where Spans Live

✅ Ideal
On your own agents’ disks

⚠️ Varies
Self-hosted cluster or vendor cloud

Infrastructure Context

✅ Ideal
Per-second metrics and logs, same UI

⚠️ Manual
Metrics and logs in other tools

Sampling

✅ Your Choice
Netdata stores every span it accepts

⚠️ Varies
Often sampled to control storage

Service Maps

❌ Not Available
No dependency graphs built from spans

✅ Good
Common in mature tracing and APM tools

See All Comparisons

October 5, 2026

Distributed Tracing in Netdata: OpenTelemetry Traces, Stored Where They Were Collected

Netdata now 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 explored in the new Traces tab in Netdata Cloud.

May 20, 2026

Netdata Skills: Teach Your AI Coding Agent To Monitor

Meet netdata/skills, open-source agent skills that teach Claude Code, Cursor, and Copilot to instrument and troubleshoot infrastructure. Explore them now!

May 15, 2026

OpenTelemetry and Netdata, Today

Ingest OpenTelemetry metrics and logs into Netdata via OTLP for automatic charts, ML, and alerts alongside your existing data. Read the full guide now!

Frequently Asked Questions

Does Netdata support distributed tracing?

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. See the distributed tracing feature page for details.

Do I need to change my instrumentation?

My SDKs export OTLP/HTTP. Will that work?

How do I trace services running in Kubernetes?

Can Netdata replace Jaeger or Grafana Tempo?

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.

Where are the spans stored, and for how long?

Do I need Netdata Cloud?

Does Netdata sample traces?

Can I ask an AI assistant about a slow request?

What doesn’t Netdata tracing cover?

Netdata does distributed tracing on OpenTelemetry. It does not build service maps or dependency graphs from spans, does not create metrics, alerts or anomaly detection from spans, and does not do code-level profiling or real-user monitoring. If you need those, a full APM suite goes further. Netdata’s strength is traces on the same agent as your per-second infrastructure metrics and logs, stored on your own infrastructure.

Where can I learn more?

Distributed tracing

Trace Your Microservices on Your Own Infrastructure

Send OpenTelemetry spans to the Netdata Agent you already run and follow every request next to the metrics and logs of the nodes that served it.

> Get Netdata > Watch the webinar