New Relic’s error correlation feature is less about finding errors and more about finding the root cause of errors by linking them directly to the specific transactions that produced them.
Let’s see this in action. Imagine you’re running a typical web application, and New Relic is instrumenting it.
# In your Rails controller
def create
@user = User.new(user_params)
if @user.save
# This is a successful path
redirect_to @user, notice: 'User was successfully created.'
else
# This is where an error might occur if validation fails
render :new, status: :unprocessable_entity
end
end
# In your New Relic configuration (newrelic.yml)
common: &common
app_name: MyRailsApp
license_key: YOUR_LICENSE_KEY
development:
<<: *common
monitor_mode: true
production:
<<: *common
monitor_mode: false # Errors are still reported in production
When a user submits a form that violates a User model’s validation (e.g., missing email), the else block in the controller will execute. New Relic, by default, captures this as an "error" and associates it with the POST /users transaction. The magic happens when you navigate to the "Errors" page in New Relic. Instead of just seeing a list of error messages, you’ll see each error instance, and crucially, a link to the trace of the transaction that generated it.
This isn’t just about seeing the error message; it’s about seeing the entire journey of that specific request. You can click on the error, and then click on the "View transaction trace" link. This takes you to the trace details page, showing you a breakdown of every method call, database query, and external service call that occurred during that particular POST /users request. You can see exactly which line of code in @user.save triggered the validation failure, how long each part of the transaction took, and if any other services were involved.
The problem this solves is the classic "I got an error, now what?" scenario. Before robust error correlation, you’d see an error in your logs or an error monitoring tool, and you’d have to manually sift through application logs, transaction metrics, and potentially database logs to piece together what happened. Error correlation collapses this investigative process. It provides a direct, actionable link between the symptom (the error) and the system’s behavior at the moment the symptom occurred (the transaction trace).
Internally, New Relic achieves this by instrumenting your application’s code. When an exception is caught and reported by the New Relic agent, the agent attaches context from the current transaction. This context includes the transaction’s unique ID, its name (e.g., WebTransaction/Action/UsersController#create), and other metadata. When you view errors in the UI, New Relic queries its data store for errors and uses the stored transaction IDs to link back to the corresponding traces. The specific levers you control are primarily through the New Relic agent’s configuration and how your application is structured. Ensuring transactions are named predictably (e.g., using standard Rails routing) makes correlation much easier.
The one thing most people don’t realize is that New Relic’s error correlation isn’t limited to just uncaught exceptions. If your application explicitly catches an exception and then passes it to NewRelic::Agent.notice_error(exception), that error will also be correlated with the current transaction’s trace. This means you can proactively signal specific error conditions within your code, even if they don’t halt execution, and have them linked for investigation.
The next step in understanding error analysis is exploring how to create custom attributes on errors for even finer-grained filtering and analysis.