• /
  • EnglishEspañolFrançais日本語한국어Português
  • Log inStart now

OpenTelemetry traces in New Relic

OpenTelemetry provides a rich tracing ecosystem, with an API for recording trace telemetry, an SDK for exporting span data, and context propagation for tracing across application boundaries.

This page describes how New Relic handles OpenTelemetry spans it receives via the New Relic OTLP endpoint. To send OpenTelemetry traces to New Relic, you'll need to configure your trace source to export data to the New Relic OpenTelemetry Collector via the OTLP endpoint. See the following pages:

OTLP span mapping

New Relic maps OTLP spans to the Span data type. The table below describes how fields from the trace proto message definitions are interpreted:

OTLP proto field

New Relic Span field

ResourceSpans.Resource.attributes

Each key/value is an attribute on the Span [1]

ScopeSpans.InstrumentationScope.name

otel.library.name

ScopeSpans.InstrumentationScope.version

otel.library.version

ScopeSpans.InstrumentationScope.attributes

Each key/value is an attribute on the Span [1]

Span.trace_id

trace.id

Span.span_id

id

Span.trace_state

w3c.tracestate

Span.parent_span_id

parent.id

Span.name

name

Span.kind

span.kind

Span.start_time_unix_nano

timestamp

Span.end_time_unix_nano

duration.ms (computed with Span.start_time_unix_nano)

Span.attributes

Each key/value is an attribute on the Span [1]

Span.dropped_attribute_count

otel.dropped_attributes_count

Span.events

Each event is recorded as a SpanEvent with span.id / trace.id referring to source span, count stored as nr.spanEventCount

Span.events[*].time_unix_nano

Stored as timestamp on SpanEvent

Span.events[*].name

Stored as name on SpanEvent

Span.events[*].attributes

Each key/value is stored as an attribute on SpanEvent

Span.events[*].dropped_attributes_count

Stored as ote.dropped_Attributes_count on SpanEvent

Span.dropped_events_count

otel.dropped_events_count

Span.status.message

otel.status_description

Span.status.code

otel.status_code

Table footnotes

[1] In case of conflict in resource attributes, scope attributes, span attributes, and top level span fields, the order of precedent (highest to lowest) is the top level Span.* fields > Span.attributes > ScopeSpans.InstrumentationScope.attributes > ResourceSpans.Resource.attributes.

See OTLP attribute types for details on New Relic OTLP endpoint supported attribute types and OTLP attribute limits for details on validation performed on attributes.

New Relic supports OpenTelemetry span links, which allow you to create causal relationships between spans that don't have a direct parent-child connection. Span links are essential for understanding distributed traces that get split across asynchronous boundaries like message queues, event streams, and batch processing systems.

When to use span links

Use span links in the following scenarios:

  • Message queue producers and consumers: Link a consuming span back to the producing span when processing messages from queues like AWS SQS, RabbitMQ, or Kafka.
  • Fan-in patterns: Link multiple producer traces to a single consumer trace that aggregates their outputs.
  • Batch processing: Link spans that process batched messages back to their individual originating traces.
  • Long-running workflows: Connect spans across workflow steps that exceed normal trace duration limits.

To implement span links in your OpenTelemetry instrumentation, you need to:

  1. Extract trace context from the incoming message or event
  2. Create a span link when starting a new span in the consumer
  3. Ensure trace context is propagated through your messaging infrastructure

The following examples show how to implement span links in different languages:

When implementing span links, follow these best practices:

  1. Always propagate trace context: Ensure W3C trace context (traceparent and tracestate headers) are included in message headers or metadata.

  2. Validate span context: Always check if the extracted span context is valid before creating a span link. Invalid contexts should not create links.

  3. Use appropriate span kinds: Set PRODUCER kind for message publishing spans and CONSUMER kind for message processing spans.

  4. Add messaging attributes: Include semantic conventions for messaging systems (like messaging.system, messaging.destination, messaging.operation) to provide context.

  5. Consider sampling: Both linked traces must be sampled to appear in New Relic. Adjust sampling strategies for critical workflows that use span links.

  6. Handle batch processing carefully: When processing batched messages, create individual span links for each message to maintain traceability.

Once you've implemented span links in your instrumentation, you can view and navigate them in the New Relic UI:

  1. Navigate to the trace details page for a trace
  2. Look for the span links badge in the filter bar showing the number of spans with links
  3. Select a span with links to see the Span links tab in the span details pane
  4. Click on linked traces to navigate between related traces

For detailed information on using span links in the UI, see Understanding span links.

Copyright © 2025 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.