Traces Next to the Metrics and Logs That Explain 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.

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 three things. Jaeger draws a service dependency graph from your traces; Netdata does not build service maps. Jaeger lets you search by tag and trace ID and sort results; Netdata filters by service, span name and minimum duration. And Jaeger’s UI is fully self-hosted, while Netdata’s Traces tab requires a Netdata Cloud sign-in, even though the spans themselves stay on your agents. If any of those is central to how your team works today, weigh it before switching.

One less system to run. There is no Jaeger collector tier and no Cassandra, Elasticsearch or OpenSearch cluster to size and upgrade for spans. Traces land on the same Netdata Agent that already collects per-second metrics from 800+ integrations and your logs, and they appear in the same Netdata Cloud UI for the same nodes. You also get a duration heatmap of every trace, and Netdata AI and the MCP server can investigate traces alongside metrics, logs and alerts.

Not if you already use OpenTelemetry SDKs or the OpenTelemetry Collector, which is what the Jaeger project itself recommends since it retired its own client libraries. Change the exporter endpoint to a Netdata Agent and make sure the protocol is gRPC, for example with OTEL_EXPORTER_OTLP_PROTOCOL=grpc. Applications still using the legacy Jaeger clients need to move to OpenTelemetry first.

On the disk of the Netdata Agent that receives them. Traces have their own retention settings by size, age and file count, separate from metrics and logs, and can optionally be offloaded to S3-compatible object storage and read 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. 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. Jaeger, by contrast, can serve remote and adaptive sampling strategies to your SDKs and Collectors, which is useful if you rely on centrally managed sampling.

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. Jaeger gives you one central store by design, at the cost of running that store.

Yes. An OpenTelemetry Collector can export the same spans to both Jaeger and a Netdata Agent, so teams can compare the two on real traffic before switching off Jaeger’s storage. Keep Jaeger for as long as you depend on its dependency graph or tag search.

No, and it does not try to be. Jaeger is a focused, CNCF-graduated tracing backend. Its Monitor tab can show service-level request, error and latency metrics, but only when you also run a span-metrics pipeline and a Prometheus-compatible backend. Metrics, logs, alerting and infrastructure monitoring come from other tools. Netdata covers metrics, logs and traces on one agent.

No. Traces are explored in the Traces tab in Netdata Cloud and need a Netdata Cloud sign-in. The spans are stored on your agents, not in Cloud. If you need trace exploration that works fully offline or in an air-gapped network, Jaeger’s self-hosted UI is the better fit for that requirement.

Not yet. Netdata receives traces over OTLP/gRPC today, and native OTLP/HTTP support is on the roadmap. Many 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.

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 profiling. Jaeger does not do profiling either; if you need those, look at a dedicated APM suite.

Yes. Netdata AI and Netdata’s MCP server give AI assistants access to traces alongside metrics, logs and alerts, so an assistant can query and investigate traces in the same conversation as the infrastructure data.