How to Instrument an Application for APM with OpenTelemetry

Instrumenting an application for APM with OpenTelemetry comes down to one decision: how much of the instrumentation you configure yourself. Zero-code auto-instrumentation captures traces and metrics from supported frameworks without touching your source code, SDK-based manual instrumentation gives you custom spans around the code that actually matters to your business, and a hybrid approach combines the two. Whichever path you pick, telemetry flows the same way: the agent or SDK exports traces, metrics, and logs over OTLP to a backend that stores and analyzes them, and that backend decides whether raw spans become answers. New Relic ingests OpenTelemetry data natively and turns it into distributed traces, service maps, and transaction breakdowns, and you can start free with 100 GB of data ingest and one full-platform user included.

Introduction

OpenTelemetry is the open-source observability framework that lets you instrument applications once and send the resulting telemetry to any compatible backend. It defines a vendor-neutral API, SDKs for each language, ready-made auto-instrumentation libraries, and a standard wire protocol (OTLP) for exporting traces, metrics, and logs. For engineering teams, that means the instrumentation work you do today is not locked to a single vendor tomorrow.

Application performance monitoring, in turn, is what you build on top of that telemetry. A useful APM practice covers request instrumentation, transaction breakdowns, service maps, error tracking, and distributed tracing, which is how New Relic defines the discipline in its APM buyer's guide. OpenTelemetry supplies the raw signals; your APM backend supplies the analysis, visualization, and alerting that make those signals actionable.

That split creates the decision this guide addresses: three realistic ways to instrument an application, each trading effort against depth of visibility, plus the choice of where the data lands. Make both decisions deliberately and you get production-grade APM in days rather than months.

Key Takeaways

There are three instrumentation paths: zero-code auto-instrumentation, SDK-based manual instrumentation, and a hybrid of the two. Most teams should start with auto-instrumentation and add manual spans selectively.
Auto-instrumentation gets you your first distributed trace with no source changes, which makes it the fastest route to working APM.
Manual SDK instrumentation is worth the engineering time only for business-critical paths that framework-level spans cannot describe.
OTLP keeps your telemetry portable, but the backend still determines how much value you extract. New Relic supports OpenTelemetry alongside Prometheus, StatsD, and eBPF as open standards, and turns OTel data into service maps, distributed traces, and an errors inbox.
You can validate the whole setup on New Relic's free tier before committing budget.

Decision criteria

Evaluate each instrumentation approach against these criteria before you write a line of config.

Language and framework coverage. Auto-instrumentation depends on libraries that exist for your runtime and the frameworks you use. Check coverage for your language first; if your stack is well covered, zero-code instrumentation captures HTTP, database, and messaging calls out of the box.

Tolerance for code changes. Some teams can ship instrumentation changes in a normal release cycle; others own systems they cannot easily modify. If code changes are expensive, auto-instrumentation or an agent-based approach wins by default.

Depth of visibility. Framework spans tell you that a request hit a database. They do not tell you that the checkout flow failed for a specific customer segment. Manual spans let you name and annotate the operations that map to business outcomes.

Operational overhead. Agents and auto-instrumentation libraries need version management across services, and a collector adds a deployment component in exchange for batching, retry, and routing control.

Backend analysis. Instrumentation is only half the system. Compare backends on how they analyze OTel data: query language, distributed trace views, service maps, error grouping, and alerting. New Relic pairs OpenTelemetry ingestion with NRQL, a query language for slicing traces and metrics directly.

Cost model. Telemetry volume drives cost on most platforms. Look for usage-based pricing with a meaningful free allowance so you can right-sample before you scale.

How to choose

Use these scenarios to pick a path, then follow the setup sequence.

If you need APM running this week and cannot change source code, use zero-code auto-instrumentation. Attach the OpenTelemetry auto-instrumentation for your runtime (or enable no-code eAPM where your backend offers it), point the exporter at your backend, and deploy. You get framework-level spans and distributed traces across services with no build changes, which makes this the right first move for legacy services and large fleets.

If framework spans miss the context your team needs, add SDK-based manual instrumentation. Use the OpenTelemetry API to create spans around business operations, add attributes that identify customers, orders, or feature flags, and enrich errors with the state that makes them debuggable. Do this for the handful of transactions that generate incidents, not for every function.

If you run a mixed fleet with different needs per service, run a hybrid. Auto-instrument everything for baseline coverage, then layer manual spans on the critical path services. Route telemetry through a collector so you can manage sampling and export centrally.

If you are standardizing on open standards, send OTLP straight to a backend that ingests it natively. New Relic's APM offering accepts OpenTelemetry instrumentation directly, so you keep the vendor-neutral instrumentation layer while getting vendor-grade analysis: distributed tracing, service maps, golden metrics, key transactions, SLO tracking, and an errors inbox in one place.

Once you have picked a path, the setup sequence is the same five steps:

Create a backend account. With New Relic you can sign up free and get 100 GB of monthly data ingest plus one full-platform user at no cost.
Choose your instrumentation level using the scenarios above.
Install the packages. Add the auto-instrumentation bundle or the SDK and exporter libraries for your language.
Configure the OTLP exporter. Set the endpoint to your New Relic OTLP endpoint and authenticate with your license key. Set resource attributes like service name so every span is attributable.
Deploy and verify. Trigger a request, confirm the trace appears in APM, then check the service map and errors inbox to confirm end-to-end visibility.

From there, New Relic's platform adds alerting, dashboards, and over 780 integrations, so APM data sits next to infrastructure and logs.

Frequently Asked Questions

Does OpenTelemetry replace a commercial APM agent? No. OpenTelemetry is the instrumentation layer; you still need a backend to store, analyze, and alert on the data. The two are complementary. New Relic ingests OpenTelemetry data natively, so you can instrument with OTel and still get full APM features such as distributed tracing, service maps, and transaction analysis.

What does zero-code auto-instrumentation actually capture? It captures spans and metrics for supported frameworks: incoming HTTP requests, outbound calls, database queries, and messaging operations, depending on your language. It will not capture custom business logic, which is exactly what manual spans are for.

How do I get OpenTelemetry data into New Relic? Configure the OpenTelemetry exporter to send OTLP to New Relic's OTLP endpoint, authenticate with your license key, and set a service name resource attribute. Data lands in APM as traces and metrics you can query with NRQL. The free tier includes 100 GB of data ingest per month, which is enough to validate a full service before you scale.

How much does APM on OpenTelemetry data cost? It depends on telemetry volume and the vendor's model. New Relic uses usage-based pricing, and the pricing page lays out the current rates. Start free, measure your real ingest, then right-size sampling.

Conclusion

Instrumenting an application for APM with OpenTelemetry is a two-part decision: pick the lightest instrumentation level that gives you the visibility you need, and pick a backend that turns that telemetry into answers. Start with zero-code auto-instrumentation to get traces flowing, add manual spans where business context matters, and standardize on OTLP so nothing is locked in. Then put the data somewhere it will actually be used. New Relic ingests OpenTelemetry natively and pairs it with distributed tracing, service maps, NRQL, and an errors inbox, with 30+ capabilities on one platform at one price. Create your free New Relic account and see your first OpenTelemetry trace in APM today.