Chris Hansen, Director of Product Management for APM, contributed to this post.  

OpenTelemetry provides community-contributed instrumentation that standardizes telemetry data collection from your applications and services, without vendor lock-in. The future of instrumentation is open, and we’re standardizing our future offerings on OpenTelemetry.

As part of our commitment, we recently shipped OpenTelemetry exporters for several programming languages, such as Java, Go, and .NET. In a recent post, we showed you how to instrument a sample Java application using OpenTelemetry SDKs and the New Relic OpenTelemetry exporter to start sending traces to New Relic One.

Don’t miss: Getting Started with OpenTelemetry for Java and New Relic

When you send your OpenTelemetry data to New Relic One, you get curated out-of-the-box experiences built on powerful visualization and analysis tools. In this post, we’ll explain how to analyze your OpenTelemetry data in our platform.

Step 1: Getting started

The best way to get started with OpenTelemetry is to try it out with your own applications and services, so that you can get value from the instrumentation right away, and you are using services with which you’re already familiar. But that may not be practical for you, or you may be using a language for which New Relic doesn’t yet have an exporter. If that’s the case for you, you can use our fork of the Online Boutique cloud-native microservices as your demo application. This application has two services instrumented with OpenTelemetry SDKs and the respective New Relic OpenTelemetry exporters: FrontEnd (in Go) and AdService (in Java). You can see these services in the examples below.

To follow along with the demo application:

  1. Obtain your Insert API key and export it to NEW_RELIC_API_KEY.
  2. Export the metric API endpoint (https://metric-api.newrelic.com/metric/v1) to NEW_RELIC_METRIC_URL.
  3. Export the trace API endpoint (https://trace-api.newrelic.com/trace/v1) to NEW_RELIC_TRACE_URL.

Then start the Online Boutique application using one of the four options specified in the README, and once it’s running, you’ll see your OpenTelemetry data in New Relic One.

Tip: If you are having trouble finding any of your OpenTelemetry data in New Relic, check out our troubleshooting steps.

Step 2: Viewing OpenTelemetry data through New Relic One

Now that your application is sending OpenTelemetry data to New Relic, let’s look at key pages that will be useful for troubleshooting.

1. Entity explorer

The entity explorer gives you a unified view of every entity (anything that reports data in your environment), so you can see everything you monitor in one place and quickly zoom into what you care about most. It’s a fast way to find out if a service or its dependencies warrants further investigation. To see a list of your OpenTelemetry instrumented services in New Relic One, use the entity explorer and filter based on the service name. In this case, you can see the AdService and FrontEnd services:

2. Summary page

Once you identify an entity of interest, the summary page provides an overview of “golden signals” for a service or application, such as response time, throughput, and error rate, so you can quickly decide if you need to dig deeper. You can also pan out to the broader view and explore more entities and use the instance-picker in the summary view to filter all the data based on a specific instance of the service.

Review a service’s “golden signals” on the summary page.

Note: For now, the data reported on the summary page is based on trace data. If you have configured OpenTelemetry to downsample, the throughput will represent the sampled traces received. At the time of this writing, the OpenTelemetry specification and implementations are not firm, so we cannot yet rely on that data. We will release metrics-based data for the summary page in the coming months once the implementations are solid and instrumentation is implemented.

3. Transactions page

If you’re on the summary page and see a spike in a service’s response time or error rate, use the APM transactions page to identify transactions that might be causing the problem. You can quickly understand the potential source of the issue by drilling down from the slow or error transaction trace to the line of code that is causing a dip in the performance, saving hours of manual analysis. If you’re already familiar with New Relic APM, this is likely a familiar workflow.

Track problematic transactions for a service on the transactions page.

Note: New Relic identifies transactions based on the root span name of your service. If you use OpenTelemetry auto-instrumentation (and you should!), the instrumentation should give your span a useful name that groups your requests. If you’re adding your own instrumentation, choose a human-readable and low-cardinality name. Refer to the OpenTelemetry specifications for guidance.

4. Distributed tracing

To effectively resolve issues in a complex system you need a complete view of all the services and its upstream and downstream dependencies. With distributed tracing, you can get an end-to-end view of a single request across your services and quickly identify slow and error traces. Drill down further into each span to see the historical performance charts and associated attributes that layer in the context you need to understand and troubleshoot issues.

Use distributed tracing to get a full view of requests traveling through your application.

5. External services page

The external services page (Externals in the New Relic One UI) captures calls to out-of-process services such as web services, resources in the cloud, and other network entities. If the downstream service is also instrumented by New Relic, you will see a breakdown of what transactions your service calls. From that, you can navigate to that service’s transaction to troubleshoot further. This is incredibly valuable for diagnosing a cascading failure from callee to caller, and helps you identify and resolve the problem faster.

Analyze transactions from external services on the externals page.

 

6. Metric explorer

Although today OpenTelemetry instrumentation of metrics isn’t as common as traces, metrics can be an incredibly valuable telemetry type to understand your systems. Whether it’s through OpenTelemetry auto-instrumentation or your own API calls, you may have metrics available today. Use the metrics explorer to view your metrics and create dashboards. You can also facet your metrics by various dimensions, view and change the New Relic Query Language (NRQL) queries to create the charts as needed.

Explore metrics and create dashboards with the metrics explorer.

Our OpenTelemetry user interface is ever-evolving

Apart from being a top contributor to the OpenTelemetry project, we’re also continuously evolving our OpenTelemetry user interface in New Relic. In the coming months, watch out for more out-of-the-box user experiences that help you quickly discover the data you need to root-cause and optimize your applications’ and services’ performance.

If you have any feedback about our OpenTelemetry user interface, hit the feedback button at the top-right corner of New Relic One, and send us your valuable suggestions.

And if you haven’t already, sign up for our free tier today and start sending your OpenTelemetry data now—you’ll get 100 GB free every month.

 

Lavanya Chockalingam is a Senior Product Marketing manager at New Relic for APM products. Lavanya started her career as an engineer and then moved on to sales and product marketing roles. Lavanya has worked both in hardware and software industries and is passionate about technology and how it can be leveraged to solve real world problems. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!