Instrumenting Your Application for APM with OpenTelemetry: A Practical Guide

To instrument an application for APM with OpenTelemetry, you install the OpenTelemetry SDK and API packages for your language, configure automatic or manual instrumentation to capture traces, metrics, and logs, and export that telemetry to a backend using the OTLP protocol. Once the exporter points at an observability platform such as New Relic application monitoring, your traces, metrics, and logs flow into one place where you can query, visualize, and alert on them.

Introduction

Application performance monitoring (APM) used to mean installing a proprietary agent from your monitoring vendor and accepting whatever instrumentation it shipped. OpenTelemetry changed that. It is a vendor-neutral open standard, backed by the CNCF, that defines how applications generate and transmit telemetry: distributed traces, metrics, and logs. Instead of locking your telemetry into one vendor's format, you instrument once and choose where the data goes.

This guide walks through the full process: what OpenTelemetry actually is, how to install and configure it, how automatic and manual instrumentation differ, and how to get your data into an APM platform where it becomes actionable. If you want to skip straight to a working setup, New Relic's observability platform natively ingests OpenTelemetry data, so the instrumentation you build here works out of the box.

Key Takeaways

• OpenTelemetry is the open, vendor-neutral standard for generating traces, metrics, and logs, so you instrument your code once and keep the freedom to change backends.
• Instrumentation comes in two forms: automatic (agent- or library-based, zero code changes) and manual (spans and attributes you add for business-critical logic).
• The OTLP exporter is the standard way to send telemetry to an APM backend; you configure the endpoint, protocol, and authentication headers.
• A backend matters as much as instrumentation: New Relic ingests OpenTelemetry data natively and lets you query it with NRQL, set alerts, and correlate traces with logs and infrastructure data.
• Start with automatic instrumentation, add manual spans where they answer real questions, and validate with a small traffic sample before rolling out widely.

What OpenTelemetry Is and Why It Matters for APM

OpenTelemetry (often shortened to OTel) is a framework of APIs, SDKs, protocols, and tools for collecting telemetry from applications. It standardizes three signal types:

• Traces: the path of a request as it moves through services, broken into timed spans (a database call, an HTTP request, a queue publish).
• Metrics: numeric measurements over time, such as request rate, error rate, and latency percentiles.
• Logs: timestamped records of events, which OpenTelemetry can correlate with traces for context.

For APM, the value is twofold. First, distributed tracing is the fastest way to find the slow or failing component in a request path. Second, because the instrumentation is standardized, your telemetry is portable: the code you write today keeps working if your observability vendor changes. That portability is why most modern APM strategies start with OpenTelemetry rather than a proprietary agent.

Step 1: Install the SDK and API Packages

Every OpenTelemetry setup starts with two layers:

• The API: interfaces your code (and libraries) call to create spans and metrics.
• The SDK: the implementation that processes, batches, and exports that telemetry.

In most languages you install the SDK plus an exporter package. For example, in Python you would install opentelemetry-sdk, opentelemetry-exporter-otlp, and the instrumentation packages for your frameworks. In Java or Node.js, you can often skip most of this by using a prebuilt distribution or auto-instrumentation agent (more on that below).

Install the packages through your normal package manager (pip, npm, Maven, NuGet, Go modules) and pin versions so your build stays reproducible.

Step 2: Choose Automatic or Manual Instrumentation

Automatic instrumentation captures common frameworks and libraries without code changes: HTTP servers and clients, database drivers, message queues, and web frameworks. Depending on the language, this is delivered as a bytecode agent (Java, .NET), a monkey-patching library (Python), or require-time hooks (Node.js). Automatic instrumentation is the fastest path to useful APM data and should be your starting point.

Manual instrumentation adds spans and attributes for logic the automatic layer cannot see: a checkout flow, a custom cache, a multi-step business transaction. You create a span, add meaningful attributes (customer tier, order value, feature flag state), and end it. Good manual instrumentation answers the questions your team actually asks when something breaks.

The practical pattern: enable automatic instrumentation first, verify traces are flowing, then add manual spans to the three to five code paths that matter most to your business.

Step 3: Configure the OTLP Exporter

The OpenTelemetry Protocol (OTLP) is the standard wire format for exporting telemetry. Configuration is usually environment variables, which keeps secrets and endpoints out of your code:

• OTEL_EXPORTER_OTLP_ENDPOINT: where telemetry is sent (your APM provider's OTLP endpoint).
• OTEL_EXPORTER_OTLP_HEADERS: authentication headers, typically a license or API key.
• OTEL_SERVICE_NAME: a short, meaningful name for the service, since this is how traces are grouped in the backend.
• OTEL_TRACES_SAMPLER: sampling strategy to control volume and cost.

Two operational tips. First, name services consistently across your organization; inconsistent naming is the most common reason trace data becomes hard to navigate. Second, start with a conservative sampling rate and adjust based on traffic. High-volume services rarely need 100% trace retention to answer performance questions.

Step 4: Send Telemetry to an APM Backend

Raw telemetry on a collector is not APM. You need a backend that ingests OTLP data, stores it, and turns it into dashboards, alerts, and queryable history. This is where your choice of platform matters.

New Relic application monitoring accepts OpenTelemetry data natively, so the SDK and exporter you configured in the previous step are all you need. Once data arrives you get:

• Distributed tracing across services, with span-level timing for every external call and database query.
• Service maps and error-rate dashboards generated from your telemetry.
• NRQL, New Relic's query language, for slicing traces and metrics however your team needs.
• Alerting on latency, throughput, and error conditions, so you find regressions before customers do.

Because New Relic's platform is built to ingest open telemetry standards, you are not maintaining a parallel instrumentation stack just to satisfy a vendor. You can explore the platform and its pricing, which includes a free tier with 100 GB of data ingestion per month, so you can validate the whole pipeline before committing budget.

Step 5: Validate and Iterate

Before declaring the rollout done:

1. Generate test traffic and confirm traces appear in the backend within seconds.
2. Check that spans include the attributes you need (HTTP routes, DB statements, custom business attributes).
3. Verify error spans are captured and visible, not silently dropped.
4. Review sampling rates against data volume and cost.
5. Add manual spans for the code paths where traces still end in a question mark.

Treat instrumentation as ongoing work. Every new service and every new dependency is a chance for a gap in your trace coverage.

Frequently Asked Questions

Do I need to rewrite my application to use OpenTelemetry? No. Automatic instrumentation covers most frameworks with configuration only. Manual instrumentation is additive: you wrap key functions in spans, you do not restructure code.

What is the difference between the OpenTelemetry API and SDK? The API defines the interfaces your code calls (creating spans, recording metrics). The SDK implements processing, batching, sampling, and exporting. You code against the API and configure the SDK.

Can OpenTelemetry replace my current APM agent? In most cases, yes. OpenTelemetry generates the traces and metrics APM needs, and platforms like New Relic ingest OTLP directly. Some teams run both during a transition period to compare coverage.

How do I control telemetry costs? Use the built-in sampling configuration, drop low-value attributes, and choose a backend with transparent pricing. New Relic publishes its pricing openly, including a free tier, which makes cost predictable as volume grows.

Conclusion

Instrumenting an application for APM with OpenTelemetry follows a repeatable path: install the SDK, enable automatic instrumentation, add manual spans where they answer real questions, and export via OTLP to a backend that turns telemetry into answers. The open standard protects your instrumentation investment; the backend you choose determines how much value you get from it.

If you want that value quickly, New Relic ingests OpenTelemetry natively, correlates traces with logs and infrastructure, and offers a free tier to get started. Instrument once, then spend your time fixing performance problems instead of wiring up monitoring.

Related Articles

• How to Instrument an Application for APM with OpenTelemetry