Migrate Traces from New Relic
Migrating distributed tracing from New Relic to SigNoz involves replacing New Relic APM agents with OpenTelemetry instrumentation. This guide will walk you through the process for different scenarios.
Understanding Trace Collection Differences
Before migrating, it's important to understand the key differences between New Relic and SigNoz tracing:
Feature | New Relic | SigNoz | Notes |
---|---|---|---|
Collection Method | Proprietary APM agents, OpenTelemetry support | OpenTelemetry native | SigNoz is built specifically for OpenTelemetry |
Sampling | Head-based and tail-based sampling | Head-based and tail-based sampling | Both support similar sampling approaches |
Visualization | Distributed tracing UI | Comprehensive trace analysis UI | Similar capabilities with different interfaces |
Service Maps | Available | Available | Both provide dependency visualization |
Span Attributes | Custom attributes & dimensions | OpenTelemetry attributes | Different naming conventions |
Migration Approaches
The approach for migrating traces depends on how you're currently collecting traces in New Relic.
1. For Applications Already Using OpenTelemetry with New Relic
If your applications are already instrumented with OpenTelemetry and sending data to New Relic:
- Update your OpenTelemetry configuration to point to SigNoz instead of New Relic
- Modify your exporter configuration. Here's a generic example:
# Before: New Relic OTLP endpoint
otlp:
endpoint: "https://otlp.nr-data.net:4317"
headers:
"api-key": "NEW_RELIC_LICENSE_KEY"
# After: SigNoz OTLP endpoint
otlp:
# For SigNoz Cloud
endpoint: "ingest.{region}.signoz.cloud:443"
headers:
"signoz-ingestion-key": "<your-ingestion-key>"
tls:
insecure: false
# For Self-hosted SigNoz
# endpoint: "<signoz-otel-collector>:4317"
# tls:
# insecure: true
2. Replacing New Relic APM Agents with OpenTelemetry
For applications using New Relic's proprietary APM agents:
- Remove the New Relic agent from your application
- Follow the appropriate SigNoz instrumentation guide for your programming language
- Configure the OpenTelemetry SDK to send trace data to SigNoz
SigNoz provides detailed instrumentation guides for various languages and frameworks including:
Example: Migrating from New Relic Java Agent to OpenTelemetry
Step 1: Remove the New Relic Java agent configuration from your application:
- Remove the
-javaagent:/path/to/newrelic.jar
JVM argument - Remove any New Relic configuration files (e.g.,
newrelic.yml
)
Step 2: Add the OpenTelemetry Java agent:
- Download the OpenTelemetry Java agent
- Add the agent to your JVM arguments:
java -javaagent:/path/to/opentelemetry-javaagent.jar \
-Dotel.service.name=your-service-name \
-Dotel.exporter.otlp.endpoint=http://<SigNoz endpoint>:4317 \
-jar your-application.jar
For more detailed instructions, see the SigNoz Java Instrumentation document.
Attribute Mapping
When migrating from New Relic to SigNoz, you'll need to map New Relic's span attributes to OpenTelemetry's semantic conventions. Here are some common mappings:
New Relic Attribute | OpenTelemetry Attribute |
---|---|
entity.name | service.name |
entity.type | service.namespace |
transactionName | http.route |
http.method | http.request.method |
http.url | url.full |
http.statusCode | http.response.status_code |
error.message | exception.message |
error.class | exception.type |
error.stack | exception.stacktrace |
db.statement | db.statement |
db.instance | db.name |
span.kind | span.kind |
peer.hostname | server.address |
Verifying Trace Migration
After migrating your instrumentation, verify that traces are being received correctly:
- Navigate to the APM section in SigNoz
- Look for your service in the list of services
- Check basic metrics like p99 latency, error rate, and requests per second
- Click on your service to view traces
- Verify that spans are being captured correctly with the expected attributes
Compare key metrics between New Relic and SigNoz during the migration period to ensure data consistency.
Next Steps
Once your traces are successfully migrating to SigNoz, consider:
- Creating dashboards with trace-based panels
- Setting up trace-based alerts for performance and error monitoring
- Correlating traces with logs for comprehensive troubleshooting
- Exploring the Service Map to better understand your application architecture