OTEL Metrics, Logs and Traces

An OpenTelemetry Backend Built for Scale, Not Per-Metric Billing

Q: Can Netdata receive OpenTelemetry data?

Yes. Netdata is a native OTEL backend that ingests metrics, logs and traces from any OpenTelemetry-compatible source, including OpenTelemetry Collectors, SDKs, and third-party exporters.

Q: Which OpenTelemetry signals does Netdata support?

Netdata supports OTEL metrics, logs and traces. Metrics become per-second charts with ML anomaly detection and alerting. Logs appear in the Logs tab. Traces appear in the Traces tab of Netdata Cloud, with a duration heatmap, filters by service, span name and duration, a full waterfall for every trace, and every span attribute your instrumentation recorded. See distributed tracing for details.

Q: Which OTLP protocol should my SDKs use to send traces?

Either. Netdata receives OTLP over gRPC (port 4317, listening by default) and over HTTP (port 4318, turned on in otel.yaml). SDKs that export OTLP/HTTP need the HTTP listener turned on, or an OpenTelemetry Collector in between. Setup steps are in the OTLP ingestion documentation.

Q: Can Netdata replace Jaeger or Tempo?

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.

Q: Does Netdata work with the OpenTelemetry Collector?

Yes. Configure an OTLP (gRPC) exporter in the Collector and point it at Netdata. The same pipeline can carry metrics, logs and traces. Reference pipeline configurations for DaemonSet, gateway, and Operator deployments are maintained in the netdata/otelcol-cookbook repository.

Q: Which languages are supported for OpenTelemetry instrumentation?

Netdata accepts OTEL data from any language with an OpenTelemetry SDK. The netdata/skills repository provides setup guidance for Node.js, Python, Java, Go, .NET, Ruby, and PHP.

Q: How does Netdata charge for OpenTelemetry data?

Netdata does not apply per-metric or per-series charges for OTEL metrics. Refer to the pricing page for current commercial terms; Traces are in Free Preview.

Q: Can Netdata run alongside an existing observability backend?

Yes. The OpenTelemetry Collector supports multiple exporters, allowing the same data to be sent to Netdata and an incumbent backend in parallel. This is commonly used during evaluation, or to keep feeding an existing backend while Netdata stores and analyzes the same data on your own infrastructure, with tiered long-term metric retention and configurable log and trace retention.

Q: How does Netdata's per-second granularity compare to other backends?

Most OTEL backends aggregate to 15-, 30-, or 60-second intervals. Netdata ingests at configurable intervals down to one second, which is relevant for SLO-sensitive workloads and short-duration incidents. The Real-Time at Scale page describes the underlying architecture.

Netdata is a native OTEL backend with OTLP ingestion for metrics, logs and traces, all on the same agent. Get per-second granularity, ML-based anomaly detection on every metric, a Traces tab for following requests across services, and built-in correlation with infrastructure metrics from 800+ native collectors. Data is processed and stored at the edge; only metadata reaches the cloud. No per-metric or per-series charges.

Start Free Read the Documentation

An OpenTelemetry Backend Built for Scale, Not Per-Metric Billing product interface

Native OTLP Ingestion: Metrics, Logs, and Traces

Metric Ingestion

Send OTEL metrics from any OTel Collector, SDK, or instrumented application. Incoming signals are translated into Netdata charts at configurable intervals down to one second, with automatic handling for transient services.

Application metrics land on the same dashboard as infrastructure metrics, without separate tooling, separate dashboards, or separate analysis workflows.

> Documentation

ML Anomaly Detection

Unsupervised ML models train on every metric, including OTEL signals. Anomalies are flagged automatically, without manual threshold tuning.

Alerting

Alerts on OTEL metrics use the same configuration syntax as any Netdata alert. Plain-English descriptions can be translated into alert configurations by Netdata AI.

AI-Assisted Root Cause

When an OTEL metric triggers an alert, Netdata AI correlates it with infrastructure metrics, application metrics, and logs to surface probable causes.

Infrastructure Correlation

OTEL metrics correlate automatically with data from 800+ native collectors covering node CPU, memory, disk, network, container, and service-level metrics.

Automatic Visualization

Incoming OTEL metrics render as charts on the Netdata dashboard with no manual dashboard work; organized by source and category.

Edge Storage & Retention

Metrics are stored locally in Netdata’s DBENGINE with tiered retention: per-second detail short-term, summarized data long-term. Logs and traces are stored on the same agent, each with its own retention settings.

Application Instrumentation Plus Infrastructure Coverage

Applications Instrumented With OpenTelemetry

OTEL SDKs are available for Node.js, Python, Java, Go, .NET, Ruby, and PHP, with auto-instrumentation or manual options. Data flows through an OpenTelemetry Collector (DaemonSet, gateway, or Operator) or directly from the application. Any OTel-compatible source is supported.

Vendor-neutral instrumentation. Portable across backends.

> Browse Collector pipeline recipes

Applications Instrumented With OpenTelemetry

Infrastructure Collected Natively

Netdata’s 800+ collectors cover operating systems, containers, Kubernetes, databases, message queues, and common services without additional instrumentation. Application data from OpenTelemetry and infrastructure data from native collectors share a single timeline and analysis surface.

One pane of glass. No integration glue.

> Review all 800+ integrations

Bundled With Netdata

OpenTelemetry ingestion is included in the standard Netdata distribution. No additional packages, agents, sidecars, or operators are required.

Single Configuration Surface

A single configuration file controls the OTEL endpoint. Container and Kubernetes deployments override settings through environment variables.

Secure by Default

TLS is supported on the OTEL endpoint. Authentication, certificates, and cardinality protection are first-class configuration concerns.

Side-by-Side Migration

The OpenTelemetry Collector supports multiple exporters. Run Netdata alongside an incumbent backend during evaluation, then migrate when the numbers justify it.

Kubernetes-Ready

Reference pipelines for DaemonSet, gateway, and Operator-based Collector deployments are maintained in netdata/otelcol-cookbook.

Vendor-Neutral By Design

Built on the OpenTelemetry standard. Instrumentation investments remain portable. There is no proprietary agent or SDK to commit to.

Per-Second Granularity

Most OTEL backends aggregate at 15-, 30-, or 60-second intervals. Netdata ingests at configurable intervals down to one second, which is relevant for SLO-sensitive workloads and short-duration incidents.

Predictable Per-Node Pricing

No per-metric or per-series charges for OTEL metrics. Auto-instrumentation cardinality does not translate into budget exposure or quota-driven sampling decisions.

ML Anomaly Detection on Every Metric

Unsupervised models train continuously on every metric, OTEL-ingested or otherwise. No threshold tuning is required to surface deviations from established baselines.

Infrastructure Context Included

Operating system, container, Kubernetes, database, and service metrics are collected natively by 800+ collectors. Application-to-infrastructure correlation is immediate.

Edge Processing and Data Sovereignty

Data is processed, stored, and queried at the edge. Only metadata is sent to Netdata Cloud. Metric values, log content and trace spans remain on customer infrastructure.

Open Source and Open Standard

Netdata is open source (GPL-3.0). Combined with OpenTelemetry’s vendor-neutral data model, the stack avoids the lock-in patterns common to proprietary observability platforms.

AI Agent Skills for OpenTelemetry Setup

Skills for Claude Code, Cursor, and Copilot

The open-source netdata/skills repository contains skill packs that guide AI coding agents through OTEL ingestion configuration, application instrumentation across languages, and Collector pipeline construction. Installation is a single command, and the resulting workflow reduces setup time and onboarding cost for engineering teams adopting OpenTelemetry.

Compatible with Claude Code, Cursor, GitHub Copilot, and other agents

> Review the netdata/skills repository

Skills for Claude Code, Cursor, and Copilot

Install or Update Netdata

OTEL ingestion ships with the standard Netdata distribution. No additional packages, agents, or operators are required.

Enable the Endpoint

Defaults are production-sensible. Environment variables override individual settings for container and Kubernetes deployments without rebuilding images.

Point Your Exporter at Netdata

Direct your OpenTelemetry Collector or instrumented application to Netdata. Charts, logs and traces appear in Netdata immediately.

Frequently Asked Questions

Can Netdata receive OpenTelemetry data?

Which OpenTelemetry signals does Netdata support?

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. Exploring traces requires a Netdata Cloud sign-in.

Which OTLP protocol should my SDKs use to send traces?

Can Netdata replace Jaeger or Tempo?

Does Netdata work with the OpenTelemetry Collector?

Which languages are supported for OpenTelemetry instrumentation?

How does Netdata charge for OpenTelemetry data?

Can Netdata run alongside an existing observability backend?

How does Netdata’s per-second granularity compare to other backends?

Where does OpenTelemetry data reside? Does it leave customer infrastructure?

OTEL data is processed and stored at the edge by the Netdata Agent. ML anomaly detection and alerting on metrics execute locally, and spans are stored and indexed on the agent that received them. Only metadata is transmitted to Netdata Cloud, which brokers access when you view data. Metric values, log content and trace spans remain on customer-controlled infrastructure, which simplifies compliance with data residency and sovereignty requirements.

Evaluate Netdata for OpenTelemetry

An OTEL Backend Worth Standardizing On

OTLP ingestion for metrics, logs and traces on one agent. Per-second metrics with ML anomaly detection, a Traces tab with heatmap and waterfall, edge storage for data sovereignty, and native correlation with 800+ infrastructure collectors. Deploy alongside an existing backend during evaluation. Migrate when the numbers justify it.

Start Free Talk to Sales