New Relic → OpenTelemetry

New Relic is a capable, all-in-one observability platform, and for a lot of teams it does the job well. Two things push teams to look at the exit anyway: the usage-based bill — priced on data ingest per GB plus billable users — that climbs as coverage grows, and the agent estate, a fleet of language APM agents and the Infrastructure agent that speak New Relic’s protocol and feed New Relic and nothing else.

Here’s the part that makes a New Relic migration unusually gentle: OpenTelemetry is not an escape you have to complete before you get any value, and New Relic natively ingests OTLP. That means you can put a vendor-neutral collection layer under your existing pipeline, keep New Relic running as one backend among several via its own OTLP endpoint, and cut the volume you pay to ingest — all before you decide anything about the backend. The broader case is in Reducing vendor lock-in with OpenTelemetry; this post is the New Relic-specific playbook.

What migrates to OpenTelemetry — and what doesn’t

OTel replaces the New Relic agents and the wire format. It does not replace New Relic’s backend, its query language, or the analytics layered on top — those are kept, rebuilt elsewhere, or dropped consciously:

New Relic capability	Move to OTel?	Notes
Infrastructure metrics	Yes	hostmetrics (+ kubeletstats) replace the Infrastructure agent’s core collection.
APM (language agents: Java, .NET, Node, Python, Go, Ruby)	Usually	OTel SDKs / auto-instrumentation replace the language agents; validate span and service naming.
Logs	Yes	filelog / journald receivers replace the log forwarders; recreate parsing as processors.
On-host integrations (nri-*)	Often	Many map to the prometheus receiver or native OTel receivers; some are New Relic-specific.
Distributed tracing	Usually	OTLP end to end; check trace context propagation and entity mapping.
Custom attributes / entity tags	Yes	Map to service.name, deployment.environment.name, and resource attributes.
NRQL queries & saved views	No	Query language is backend-specific; rebuild if you leave New Relic.
Dashboards	No	Rebuild in the new backend, or keep New Relic for them.
Alerts / NRQL conditions	No	Migrate separately to the new backend’s alerting.
Applied Intelligence / anomaly detection	No	Vendor analytics; the backend you move to provides its own, if any.
Backend storage & query (NRDB)	No	OTel is not a backend — this is where residual lock-in lives.

The rule of thumb: OTel handles collection (metrics, traces, logs) and resource attribution cleanly. New Relic-specific products — NRQL, the dashboards, alert conditions, Applied Intelligence — are not things you “migrate”; you keep them, replace them, or retire them. (For the general version, see what OpenTelemetry can and cannot replace.)

Map the New Relic pieces to their OTel equivalents

The migration is mostly a component-for-component swap. Everything the New Relic agents do has an open-standard equivalent:

New Relic	OpenTelemetry equivalent
Infrastructure agent (host metrics)	OTel Collector with hostmetrics + kubeletstats receivers
APM language agents (Java, .NET, Node, Python, …)	OTel SDKs / auto-instrumentation emitting OTLP
Log forwarding (Fluent Bit plugin, agent logs)	filelog / journald receivers
On-host integrations (nri-*)	prometheus receiver (scrape) + OTel receivers
Custom attributes / entity tags	resource / attributes processors → service.name, deployment.environment.name
New Relic backend (NRDB)	New Relic OTLP endpoint (otlphttp) — or any OTLP backend

Note the last row — it is the escape hatch, and on New Relic it’s cleaner than most. Because New Relic ingests OTLP natively, you don’t need a vendor-specific exporter at all: the Collector’s standard otlphttp exporter, pointed at New Relic’s OTLP endpoint with your license key, writes straight into NRDB. You do not have to move off New Relic to adopt OpenTelemetry — you put OTel in front of it first, keep New Relic working exactly as before, and decide about the backend later.

Two New Relic-specific details will bite if you skip them. Entity synthesis: New Relic builds entities and service maps from specific attributes; make sure service.name, service.instance.id, and host identifiers are present on the OTLP stream or your APM and infrastructure entities won’t line up the way they did under the agents. Metric shape: the language agents emit New Relic’s dimensional metrics; OTel SDKs emit OTel semantic-convention metrics. Names and units differ, so any dashboard or NRQL alert that keys on exact metric names may need updating — audit your top alerts before cutover, not after.

Step 1 — Replace the agents with a collector, still feeding New Relic

Deploy an OTel Collector alongside (or in place of) the Infrastructure agent, and point your OTLP export at New Relic. Users see no difference; the collection layer is now open. New Relic’s OTLP endpoint takes the standard otlphttp exporter — no proprietary exporter required.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  hostmetrics:
    collection_interval: 30s
    scrapers: { cpu: , memory: , disk: , network: , load: }

exporters:
  otlphttp/newrelic:
    endpoint: "https://otlp.nr-data.net"
    headers:
      api-key: "${NEW_RELIC_LICENSE_KEY}"

service:
  pipelines:
    metrics:
      receivers: [otlp, hostmetrics]
      exporters: [otlphttp/newrelic]
    traces:
      receivers: [otlp]
      exporters: [otlphttp/newrelic]

At this point nothing has changed for your users — data still lands in New Relic, on the same account — but the collection layer is now open. Every improvement from here is one you couldn’t make from inside a proprietary agent.

Step 2 — Dual-ship to New Relic and a candidate

Add a second exporter and send the same telemetry to a candidate OTLP backend. Now you can compare dashboards, alert coverage, and APM traces on live production data, with New Relic still the system of record. This is the parallel run that makes the migration safe.

exporters:
  otlphttp/newrelic:
    endpoint: "https://otlp.nr-data.net"
    headers:
      api-key: "${NEW_RELIC_LICENSE_KEY}"
  otlphttp/candidate:
    endpoint: "https://backend.internal:4318"

service:
  pipelines:
    metrics:
      receivers: [otlp, hostmetrics]
      exporters: [otlphttp/newrelic, otlphttp/candidate]

This is the move a proprietary agent simply can’t make: send one stream to two backends at once. It turns a New Relic migration into a gradual, reversible process instead of a flag day. Here’s what a configured destination looks like in LinkMesh:

Step 3 — Cut the volume you were paying to ingest

This is where the migration pays for itself. New Relic bills on data ingest per GB, so a large fraction of what you send is noise you never query but pay to store. In a proprietary agent you could tune a little; in an OTel Collector you can do a lot, in a place you control.

• Per-GB ingest. Filter debug logs, health-check spam, and chatty success events at the collector, before they’re ingested. This is the biggest, safest cut — often more than half the log volume.
• High-cardinality metrics. Every unique attribute combination is a distinct time series; one runaway label (a user ID, a request ID, a raw URL) inflates volume. Drop or aggregate it at the collector before it multiplies.
• Redundant traces. Sample high-volume, low-value spans down to a representative fraction while keeping 100% of errors.

processors:
  # Drop sub-INFO logs before they're ingested
  filter/drop_debug:
    logs:
      log_record:
        - 'severity_number < SEVERITY_NUMBER_INFO'
  # Strip a high-cardinality attribute that inflates metric volume
  attributes/drop_cardinality:
    actions:
      - key: request_id
        action: delete
  # Sample a high-volume, low-value stream
  probabilistic_sampler:
    sampling_percentage: 20

Every record dropped at the collector is a gigabyte New Relic never bills you to ingest. The full method — measure, filter, sample, route — is in how to reduce observability costs. You can also mask PII before egress, which shrinks payloads and keeps sensitive fields out of a third-party backend at the same time.

Step 4 — Manage the fleet, don’t hand-edit YAML

Here’s the catch nobody mentions: New Relic’s agents come with central configuration and Fleet Control. Raw OTel Collectors don’t — out of the box you’re hand-syncing YAML across every node, which is a step backwards in manageability from New Relic’s fleet tooling.

Don’t accept that trade. Manage the collector fleet from a control plane that speaks OpAMP. LinkMesh is a self-hosted one: point each collector at it with a token, then build sources, processors, and routes in a visual UI. It renders and validates the config and pushes it to the right nodes — with per-edge throughput so the volume you just cut is a number you can point at, not a hope. Because it’s priced per collector, not per GB, the tool managing your escape from volume pricing isn’t itself metered by volume. Telemetry flows straight from your collectors to your backend and stays on your infrastructure; the control plane only manages config, versioned and audited GitOps-style — see GitOps for collector config.

Validate parity before you cut over

Dual-shipping to New Relic and a candidate means you’re ingesting to both during the overlap, so validate briskly and keep the window short. The checklist:

• Metrics — compare key metrics and time-series counts between the agents and the OTel stream over the same window; a cardinality difference changes what you ingest.
• Traces — confirm service names, span/operation names, and trace context propagation match what your APM views and alerts key on (this is where language-agent vs OTel SDK naming differences surface).
• Logs — verify parsing, service/environment attributes, and log-to-trace correlation survived the move from New Relic log forwarding to Collector processors.
• Entity & resource metadata — check service.name, service.instance.id, host, and environment attributes are present so entity synthesis and filtering behave as before.
• Timestamps — spot-check that event and span timestamps land correctly and aren’t being rewritten to receive time.
• Alerts — re-point your highest-priority NRQL conditions at the OTel-fed data and confirm they still fire; watch for alerts that reference exact metric names.
• Dropped telemetry — check the Collector’s internal metrics for refused/dropped data, so a filter isn’t silently eating signal.
• Failure behavior — restart a collector and kill a backend connection; confirm the Collector buffers and resumes without losing data or wedging.

Have a rollback plan

Because you dual-shipped, rollback is built in — but make it explicit before you flip anything:

• Keep the New Relic agents (or the otlphttp/newrelic path) live until the candidate passes validation for an agreed period. Don’t uninstall on day one.
• Independent exporters — New Relic and the candidate are separate blocks; drop or restore either without touching the other.
• Define success thresholds — metric/trace parity, priority alerts firing, volume down by the expected amount — before you remove anything.
• Retain the ability to redirect. If the candidate misbehaves, the New Relic OTLP exporter is still in the pipeline (or one config push away) and you’re fully back.
• Decommission after an observation period, typically one to two full business cycles after cutover, not the moment parity first looks right.

Step 5 — Decide about New Relic on your terms

Here’s the important part: once you’re on OTel, you don’t have to leave New Relic at all. Because New Relic ingests OTLP natively, plenty of teams keep it for APM or a subset of critical services and route the rest — cheap-to-store logs, archival telemetry — to a second OTLP backend or object storage. The point of the migration isn’t necessarily “quit New Relic”; it’s to make staying or leaving a choice rather than a captivity.

If you do cut over, it’s an exporter change, not a re-instrumentation project. Your data is OTLP, your fleet is on OpAMP, and the next backend decision is one config block away.

The migration in five moves

1. Replace the agents — deploy OTel Collectors and SDKs exporting to New Relic over its native OTLP endpoint. Nothing changes for users.
2. Dual-ship — add a candidate OTLP backend and compare on live data.
3. Cut volume — filter logs, prune high-cardinality metrics, and sample at the collector to attack per-GB ingest directly.
4. Validate & keep rollback — work the checklist, keep the agents as a safety net.
5. Decide — keep New Relic for what it’s worth to you, route the rest elsewhere, or cut over entirely. On OTLP, it’s your call.

The New Relic agents were the collection-layer lock-in and the ingest bill was the symptom. Move collection to OpenTelemetry and both become things you control — while you keep, in New Relic, whatever analytics still earn their place.