Fix Missing Transactions in New Relic: Resolving Metric Grouping Issues (MGIs)

Introduction

If your team is experiencing difficulties locating specific transactions in New Relic’s Transactions UI, even though they appear in NRQL query results, the issue may stem from Metric Grouping Issues (MGIs) or active Deny_New_Metrics rules. These challenges can reduce confidence in your observability data, making it harder to monitor and diagnose critical application transactions.

This post provides a structured approach to diagnosing and resolving these gaps, helping you restore visibility and ensure accurate monitoring in New Relic.

One common reason for missing transactions is incomplete or improperly configured event storage. To ensure that you're capturing all the necessary data, consider extending browser event storage. You can learn how to implement this in our article on extending browser event storage with New Relic.

Understanding the Issue

Objective: Determine why certain transactions appear in NRQL query results but are missing from the Transactions section of the New Relic UI.

Context: Transactions might be recorded and visible in query results but fail to show up under the Transactions section in your application’s APM entity. This discrepancy usually indicates a problem with metric grouping or blocked metrics.

Initial Steps:

1. Confirm Query Results: Validate that the transactions are being captured by New Relic using an NRQL query like this:

   FROM Transaction SELECT count(*) WHERE appName = 'myAppName' AND name = 'MyTransaction/MyApp/Search/GetResponse/{dynamicPart}'

   • If this query returns results, it confirms that the transactions themselves are being recorded but may just be blocked from appearing in the Transactions UI often due to Metrics Grouping Issues (MGIs).

Diagnosing Metric Grouping Issues (MGIs)

Objective: Identify if a Deny_New_Metrics rule is blocking the display of transaction metrics.

Context: MGIs occur when dynamic transaction names create too many unique metrics, exceeding the threshold (e.g., 1,000 unique metrics per minute). This triggers a Deny_New_Metrics rule, which blocks new metrics from being displayed to maintain system performance.

Steps to Diagnose:

1. Access MGI Details:

   • Navigate to Metric Normalization in New Relic’s UI.

   • Select your application entity, then choose Metric Normalization to view active Deny_New_Metrics rules.

2. Monitor Unique Metrics:

   • Check if the number of unique metrics exceeds the threshold.

   • Once the unique metric count drops below the threshold, the rule will deactivate, allowing transactions to display.

Addressing Deny_New_Metrics Rules

Objective: Resolve MGIs and reduce excessive unique metrics to restore visibility.

Objective: Resolve MGIs and reduce excessive unique metrics by normalizing dynamic transaction names. There are two primary approaches: (1) using RegEx normalization rules for a code-free solution, and (2) implementing in-code changes for greater control and flexibility.

Approach 1: RegEx Normalization Rules

If modifying your application’s code is not an option, you can use RegEx normalization rules within New Relic to manage dynamic transaction names and reduce unique metrics.

1. Identify Problematic Patterns:

   • Analyze transaction names that include dynamic parts, such as unique identifiers, timestamps, or user-specific data. Examples:

     • Apdex/MyApp/Service/{dynamicPart}

     • WebTransaction/MyApp/Service/{uniqueID}

     • WebTransactionTotalTime/MyApp/Task/{timestamp}

2. Create RegEx Rules in New Relic:

   • Navigate to the Metric Normalization section in the New Relic UI for your application.

   • Define RegEx patterns to match dynamic parts of transaction names and normalize them into consistent formats.

   Example RegEx Replacement:

   • Dynamic Metric: WebTransaction/MyApp/Service/unique-id-12345

   • RegEx Pattern: ^(Apdex|WebTransaction|WebTransactionTotalTime)/MyApp/Service/[a-z0-9-]+$

   • Replacement String: \1/MyApp/Service/*

3. Test and Monitor Results:

   • After applying the rules, monitor your application's metrics in the Metric Normalization section to confirm that the number of unique metrics has decreased. This should help deactivate the Deny_New_Metrics rule

     and restore transaction visibility.

Approach 2: In-Code Normalization

For applications where you can make changes to the codebase, using New Relic’s SetTransactionName() method offers precise control over how transactions are reported.

1. Modify Transaction Naming Logic:

   • Replace dynamic parts of transaction names with consistent values in your application code.

   • Use the SetTransactionName()method provided by New Relic agents to override transaction names programmatically.

   Implementation Example:

   // Original dynamic transaction name string transactionName = $"WebTransaction/MyApp/Service/{dynamicPart}"; // Normalized transaction name string normalizedTransactionName = "WebTransaction/MyApp/Service"; // Set the normalized name NewRelic.Api.Agent.NewRelic.SetTransactionName(normalizedTransactionName);

2. Focus on Consistency:

   • Ensure that dynamic parts, such as user IDs, timestamps, or unique identifiers, are removed or replaced with static placeholders. For instance:

     • Dynamic Name: WebTransaction/MyApp/Service/{dynamicPart}

     • Consistent Name: WebTransaction/MyApp/Service

3. Test and Deploy:

   • Test the changes in a development or staging environment to ensure the new transaction names are correctly captured in New Relic.

   • Once verified, deploy the changes to production and monitor the updated metrics.

Viewing Transactions in the New Relic UI

Objective: Ensure that previously missing transactions are now visible.

Steps:

1. Access APM Monitoring:

   • Log in to the New Relic dashboard and select your application from the APM section.

2. View Transactions:

   • Open the Transactions tab, select “View All,” and search for the relevant transactions.

   • Confirm that dynamic naming issues and Deny_New_Metrics rules are resolved.

3. Use Distributed Tracing:

   • Filter by transaction names or IDs in Distributed Tracing to verify that transactions are being captured and displayed correctly.

Key Considerations

• Metric Grouping and Performance: Address MGIs promptly to avoid blocked transactions and ensure accurate monitoring.

• Consistent Transaction Naming: Use meaningful and standardized naming to prevent MGIs and improve traceability.

• Team Communication: Share findings with your team to align on how transactions are being tracked and displayed.

Conclusion

Missing transactions in New Relic’s UI are often caused by Metric Grouping Issues (MGIs) and Deny_New_Metrics rules. By diagnosing and resolving these issues through consistent naming, RegEx normalization, and monitoring metric thresholds, you can restore visibility to critical transactions.

To avoid missing transactions in the future, it's also important to expand your event storage while at the same time managing costs. By doing so, you ensure more comprehensive tracking across your system. For a complete guide on extending browser event storage, see our article on extending browser event storage.

For additional information, explore the New Relic Metric Normalization Documentation.

Ready to optimize your observability strategy?

Learn more about how our services can help transform your New Relic implementation into measurable business outcomes.