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 over gRPC (port 4317, listening by default) and over HTTP (port 4318, turned on in otel.yaml), on the same agent endpoints that receive OTLP metrics and logs. SDKs that export OTLP/HTTP need the HTTP listener turned on, or an OpenTelemetry Collector in between. See the OTLP ingestion docs for setup.

For OpenTelemetry-instrumented services, yes: point your SDKs or Collector at a Netdata Agent over OTLP (gRPC, or HTTP once its listener is turned on) 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.

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. Full APM suites add code-level or continuous profiling and session replay on top of tracing. 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.