New Relic OpenTelemetry: Ingest OTLP Spans and Metrics (2026)

New Relic’s OpenTelemetry integration doesn’t just receive your OTLP data; it actively transforms it into a richer, more actionable format using a technique you’re probably not thinking about.

Let’s see it in action. Imagine you have a simple Node.js application instrumented with OpenTelemetry.

// app.js
const { NodeSDK } = require('@opentelemetry/sdk-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-otlp-grpc');
const { OTLPMetricExporter } = require('@opentelemetry/exporter-otlp-grpc');
const { Resource } = require('@opentelemetry/resources');
const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');

const sdk = new NodeSDK({
  resource: new Resource({
    [SemanticResourceAttributes.SERVICE_NAME]: 'my-node-app',
    [SemanticResourceAttributes.SERVICE_VERSION]: '1.0.0',
  }),
  traceExporter: new OTLPTraceExporter({
    url: 'http://localhost:4318/v1/traces', // OTLP HTTP endpoint
  }),
  metricExporter: new OTLPMetricExporter({
    url: 'http://localhost:4318/v1/metrics', // OTLP HTTP endpoint
  }),
});

sdk.start();

// Simulate some work
setInterval(() => {
  console.log('Doing work...');
}, 5000);

This code sets up an OpenTelemetry SDK to export traces and metrics via OTLP over HTTP to a local collector running on localhost:4318. The Resource attributes (service.name and service.version) are crucial for identifying your application in New Relic.

When this application runs, it will generate spans for its internal operations (if instrumented with further libraries) and metrics like CPU usage, memory, etc. These are then sent to the collector. The collector, in turn, forwards them to New Relic.

The core problem New Relic’s OTLP ingest solves is bridging the gap between the standardized, often verbose, OTLP format and New Relic’s highly optimized, proprietary data model. OpenTelemetry provides a common language, but New Relic needs to understand your specific application’s context to make that data useful.

Here’s how it breaks down internally:

1. OTLP Reception: New Relic’s OTLP ingest endpoints (e.g., https://otlp.nr-data.net/v1/traces) are designed to accept data conforming to the OpenTelemetry Protocol specification. This includes Protobuf and JSON encodings for both traces and metrics.
2. Resource Attribute Enrichment: This is where the magic happens. New Relic takes the Resource attributes you send (like service.name, service.version, cloud.provider, host.name, etc.) and uses them to tag and categorize your incoming data. If you don’t send certain attributes, New Relic might infer them or use default values, but sending them explicitly is best. This is how your "my-node-app" shows up as a distinct service in the New Relic UI.
3. Data Transformation & Indexing: OTLP data is then transformed into New Relic’s internal storage format. For traces, this involves structuring them into a viewable trace graph with associated events. For metrics, it means aggregating, downsampling, and indexing them for querying. New Relic’s ingestion pipeline is optimized for high throughput and low latency, handling millions of data points per second.
4. Correlation: A key benefit is how New Relic correlates OTLP traces with metrics. Because both are tagged with the same Resource attributes (especially service.name), New Relic can automatically link them. When you look at a trace, you’ll see related metrics, and vice-versa, providing a unified view.

The specific levers you control are primarily within your OpenTelemetry SDK configuration and the data you choose to include in your Resource attributes. The more descriptive and consistent your Resource attributes are, the better New Relic can organize and display your telemetry. For example, adding deployment.environment: production or aws.region: us-east-1 makes filtering and analysis much more powerful.

The most surprising part is how New Relic uses the Resource attributes not just for identification, but also as primary keys for its internal correlation engine, allowing it to stitch together disparate telemetry signals from the same logical entity without explicit manual configuration for every link. This relational mapping is what enables the unified view across services, hosts, and environments.

Once you’ve got OTLP ingest working, the next step is exploring how to leverage New Relic’s advanced querying capabilities with your newly ingested data.