• Log inFree account

Performance monitoring with CodeStream

New Relic CodeStream allows developers to see how the code they're responsible for is performing in production by bringing observability into the IDE and making it part of their daily routine.

Connect CodeStream and New Relic

In order to access observability in your IDE you'll need to connect CodeStream to New Relic via your New Relic user key (learn more about New Relic user keys).

A screenshot of connecting CodeStream to New Relic with your New Relic user key

Connect CodeStream to New Relic with a user key in order to bring observability into your IDE.

Once you have your user key, click Connect to New Relic in the Observability section of CodeStream, then paste your user key and click Connect to New Relic. If you signed up for CodeStream using your New Relic user key then you'll already be connected.

Note that you must have a New Relic user type of core user or full platform user in order to use the observability features in CodeStream.

Associate repositories with New Relic entities

The telemetry data available in CodeStream is contextual, meaning that it's all related to the code you have open in your IDE. In order to do this CodeStream needs to know what entities on New Relic are built by the repositories you have open, and there are a number of ways to make these associations.

There are instances where CodeStream will prompt you to make an association if one doesn't exist. For example, if you try to view an error from New Relic in CodeStream, and the entity the error belongs to isn't associated with a repository, CodeStream will ask you to identify the appropriate repository. The Observability section of the the CodeStream pane will also prompt you take make associations for all of the repositories you have open in your IDE.

A screenshot of associating repositories in your IDE with entities.

Making these associations on the fly when prompted is a great way to get started, however we recommend one of the following methods since they require less ongoing manual effort and eliminate the possibility of end-user mistakes, such as misconfigured remote URLs. These methods have the additional benefit of allowing you to associate a repository with multiple entities. For example you might have different entities that represent different environments (e.g., production, staging) and they may all be associated with the same repository.

With any of these methods you can specify the remote URL in either the SSH or HTTPS format:

  • git@github.com:newrelic/beta-docs-site.git
  • https://github.com/newrelic/beta-docs-site.git


It's possible to add the same GitHub repository more than once, if you're using different protocols to do so. The UI warns you about this, but won't prevent you from doing so.

For example, https://github.com/tuna/repo and git@github.com:tuna/repo are the same repo, with different protocols.

Observability in the IDE

The Observability section of CodeStream allows developers to discover errors related to code that they're responsible for, right from their IDE. In addition to errors assigned to you, recent errors will be listed for each repository you have open in your IDE.

A screenshot of the observability section showing recent errors and errors assigned to you.

See recent errors related to repositories open in your IDE.

Click on any error to view the details and start collaborating.

It's possible that you may have a repository associated with mutliple entities on New Relic. In these cases a dropdown list is displayed to the right of the repository name so that you easily switch between entities.

A screenshot of the selection of the entity for which you'd like to see errors.

Select the entity for which you'd like to see errors.


If your project isn't monitored by New Relic, you can set up monitoring by clicking on the gear icon in the heading of the Observability section and then selecting Instrument my App. CodeStream has setup wizards available for Node JS, Java, and .NET projects.

Code-level metrics

Code-level metrics give you detailed insight into how your code is performing at the method level. For each method automatically instrumented by New Relic's Python APM agent, you'll see golden signals displayed via a line of text inserted above each method called a CodeLens. Response time, throughput and error rate are shown for the last 30 minutes.

A screenshot of a Python method with response time, throughput, and error rate metrics.

Code-level metrics are displayed above each instrumented method in your Python project.


Code-level metrics are only available for projects monitored by the Python APM agent implemented with a supported Python framework.

Click the CodeLens to see charts visualizing each of the golden signals. If the repository is associated with mutliple entities on New Relic you can easily switch between them. This will change the entity upon which the golden signals displayed in the editor are based.

A screenshot of an expanded code-level metrics CodeLens that shows related charts.

Click the entity name at the top of the charts to see more detailed service-level data on New Relic.

CodeLens options

You can change how CodeLenses are displayed via the CodeStream section of your IDE's settings:

  • In VS Code, go to Settings, and search for "codestream".
  • In JetBrains, go to Preferences/Settings > Tools > CodeStream
  • In Visual Studio, go to Tools > Options > CodeStream.

The default CodeLens format is:

avg duration: ${averageDuration} | throughput: ${throughput} | error rate: ${errorsPerMinute} - since ${since}

You can also turn CodeLenses off altogether by unchecking the CodeStream: Show Golden Signals In Editor setting.

Investigating errors

CodeStream will show you recent errors happening in the code you have open in your IDE, but you can see a more comprehensive list of APM errors via the errors inbox on New Relic. When you're ready to dig into the root cause of a specific error with a stack trace, click Open in IDE to go directly to the code in your IDE.

A screenshot of a stack trace error in errors inbox with the "Open in IDE button."

Collaborate on resolution

A typical collaboration session could include developers commenting on code in their IDEs, a DevOps engineer assigning errors in errors inbox, and a development manager following along in Slack. By meeting people in the tools they're already using, CodeStream shortens the amount of time between error discovery and error resolution.

Watch this short YouTube video (approx. 2:27 minutes) to see this in action.

Whether you clicked on an error in the Observability section or clicked Open in IDE from the errors inbox on New Relic, CodeStream presents all of the error's details, including the stack trace.

An animated image that shows someone commenting on a line of code associated with an error.

Navigate the stack trace to investigate the issue.

Click any frame in the stack trace to jump straight to the corresponding file and line number in your IDE. Note that frames of the stack trace that represent code that isn't part of your repository (e.g., an external library) aren't clickable.

As you navigate the stack trace, if you come across code that seems like the source of your problem, select it and click the comment icon to start a discussion. CodeStream automatically mentions the most recent person to touch that code, making it easy for you to bring the right people into the discussion.

A screenshot of a comment with the most recent code contributor automatically mentioned.

Select code in your editor to add a comment.

  • Once you've identified the problem you can assign the error, either to an existing teammate on CodeStream or to a person suggested based on the repository's Git commit history.
  • You can update the error status from unresolved to resolved or ignored.
  • Use the ... More actions menu to share the discussion on Slack or Microsoft Teams.

Associate build SHAs or release tags with errors

When viewing and error in CodeStream you may see this warning if there's no git reference, either a build SHA or release tag, associated with the error. CodeStream uses the git reference to match the specific stack trace error with the version of the code running in the environment that triggered the error. While you don't need a git reference configured to investigate the error, bear in mind that you may not be looking at the version of the code that caused it.

A screenshot of the git reference not configured warning message.

The git reference not configured warning message reads: Associate a build SHA or release tag with your errors so that CodeStream can help make sure you're looking at the right version of the code.

You can use an environment variable to let the New Relic APM agent know the commit sha associated with each build of your project. You can also use the release tag associated with the running version of your software.

For New Relic APM, the commit sha and/or release tag (tags.commit and tags.releaseTag) are added as attributes on Transaction and TransactionError events. You can use APM environment variables to set these attributes.

We recommend setting one or both of these variables as part of your build pipeline.

  • NEW_RELIC_METADATA_COMMIT - The commit sha. You can include the whole thing or only the first seven characters (e.g., 734713b).
  • NEW_RELIC_METADATA_RELEASE_TAG - A release tag (such as v0.1.209 or release-209). This has the advantage of being human readable.

For more on how to set these variables, here are specific configuration details for each language:

If you do have git references configured, CodeStream will let you know if the version of the code you're on locally doesn't contain the reference associated with the error. In this case, you may want to check out the version of the code that does contain that reference so that you can more effectively investigate and resolve the error.

A screenshot of the git reference not found warning message.

The git reference not found warning message reads: Your version of the code doesn't match the environment that triggered the error. Fetch the following reference to better investigate the error.

CodeStream will also let you know if the error doesn't have a stack trace associated with it. This happens with older errors when the stack trace has aged out on New Relic.

Dynamic logging with Pixie

Dynamic logging with Pixie allows you to debug Go applications in production without the need to instrument the source code with additional log statements, recompile, and redeploy. You can dynamically capture function arguments, return values and latency right from your IDE.


Dynamic logging is currently only available for applications written in Go, and requires a Kubernetes cluster monitored by Pixie.

To start a logging session, right-click on any method name in your Go project and select Dynamic Logging Using Pixie. After selecting your New Relic account and Kubernetes information (Cluster, Namespace, Pod), you can then start a logging session ranging anywhere from one to ten minutes in duration.

A screenshot of a dynamic logging session using Pixie.

You'll see values for all of the method's parameters start to be captured in real time.

Copyright © 2022 New Relic Inc.