OpenTelemetry Traces, Stored Where You Collect Them

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.

OTLP/gRPC, on the same agent endpoint that receives OTLP metrics and logs. Many OpenTelemetry SDKs default to OTLP/HTTP, so set OTEL_EXPORTER_OTLP_PROTOCOL=grpc, or run an OpenTelemetry Collector that receives OTLP/HTTP and exports OTLP/gRPC to Netdata. Native OTLP/HTTP support is on the roadmap. See the OTLP ingestion docs for setup.

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.

On the disk of the Netdata Agent that received them. Trace data is not stored in Netdata Cloud; Cloud brokers access to it, the same way it does for metrics and logs. If you need longer retention, older trace files can be offloaded to S3-compatible object storage, and Netdata reads them back when you query.

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; Netdata Cloud is the interface you use to query them.

No. Netdata stores every span the agent accepts. If you want sampling, configure it in your OpenTelemetry SDK or Collector.

You decide. Traces have their own retention settings by size, age and number of files, separate from the retention you set for logs and metrics. Optional offload to S3-compatible object storage extends retention without filling the agent’s local disk.

The OTLP endpoint supports TLS and mutual TLS, so only clients with trusted certificates can send spans. Multi-tenant isolation keeps one tenant’s traces separate from another’s.

Traces are queried on the agent that received them. To centralize, point your services, or an OpenTelemetry Collector gateway, at one Netdata Agent or Parent. In Kubernetes, a common pattern is a Collector DaemonSet or gateway that forwards OTLP/gRPC to a Netdata Agent.

Yes. Netdata AI and the Netdata MCP server give AI assistants access to traces alongside metrics, logs and alerts, so you can ask an assistant to investigate a slow request or a burst of errors. See Netdata MCP.

Netdata does distributed tracing on OpenTelemetry. It does not build service maps or dependency graphs from spans, does not generate metrics, alerts or anomaly detection from spans, and does not do code-level or continuous profiling. Full APM suites with service maps, code profiling, real-user monitoring or session replay go further in those areas. What Netdata adds is traces on the same agent as your per-second infrastructure metrics and logs, stored on your own infrastructure.

Watch the distributed tracing webinar recording for a walkthrough of the Traces tab, read the announcement post, or see how tracing fits a microservices workflow on the distributed tracing use case page. For how traces, metrics and logs arrive over OTLP, see the OpenTelemetry overview.