--- title: Metric normalization rules source: https://docs.newrelic.com/docs/new-relic-solutions/new-relic-one/ui-data/metric-normalization-rules --- Metric normalization rules help you to manage [Metric Grouping Issues](https://docs.newrelic.com/docs/using-new-relic/cross-product-functions/troubleshooting/metric-grouping-issues) (MGIs). This helps to ensure that application performance data remains relevant. The metric normalization applies only to [metric timeslice data](https://docs.newrelic.com/docs/data-apis/understand-data/new-relic-data-types/#timeslice-data). You can create and manage metric normalization rules to: - Group or filter out [metric timeslice data](https://docs.newrelic.com/docs/data-apis/understand-data/new-relic-data-types/#timeslice-data) - Manage the high cardinality metrics that are reported to New Relic - Prevent MGIs - Prevent automatic creation of `DENY_NEW_METRICS` rules - Reduce the number of unique metric names reported to New Relic > #### ⚠️ IMPORTANT > > Whenever MGIs with a very high number of metrics are detected, a `DENY_NEW_METRICS` rule is created automatically to protect the platform from performance degradation. This `DENY_NEW_METRICS` rule does not affect any metrics previously reported to New Relic. > #### 💡 TIP > > You can also create metric normalization rule using [NerdGraph](https://docs.newrelic.com/docs/apis/nerdgraph/examples/nerdgraph-metric-normalization-rule/). ## Agents reporting to multiple apps [#multi-app-agents] When an agent reports to multiple applications, normalization rules from all applications are applied to the metric data. Consider this scenario: - An agent reports to `app1` and `app2` - Rule `r1` is defined for `app1` - Rule `r2` is defined for `app2` Both `r1` and `r2` are applied to all metric data sent by the agent. What happens if the agent configuration is modified to only report to `app2`? In that case, only rule `r2` will be applied, since it's the only rule defined for the app the agent is reporting to. ## Manage the metric normalization [#manage-rules] You can create and manage new metric normalization rules for an entity using the **Metric normalization rules** page. **View metric normalization rules** To view the **Metric normalization rules** page, go to > **All Entities** > Select an entity > **Settings** > **Metric normalization** . ![View MGI details](https://docs.newrelic.com/images/Access_metric_rules.webp "View details") **Create a metric normalization rule** To create a metric normalization rule: 1. On the **Metric normalization rules** page, click **+ Create a new rule**. 2. Provide the following details: | Field | Description | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Time range** | Select the required time range from the drop-down menu for the rule. | | **Regular expression** | Enter a [regular expression](https://regexone.com/) pattern that matches the metrics to be normalized. This field must start with a `^` and end with a `$`. It defines a pattern to identify which metrics should be affected by the normalization rule. For example: `^WebTransaction/Uri/RESTfulExample/users/username/[a-zA-Z0-9]+$` The pattern `^[a-zA-Z0-9]+$` matches any string composed of lowercase characters `(a-z)`, uppercase characters `(A-Z)`, and numbers `(0-9)`. | | **Regular expression matches** | Preview the metrics matched by the **Regular expression** field. | | **What do you want to do with the matches?** | Select one of the following action to perform on the metrics that match the **Regular expression** field: Replace: Replace the matched metrics with value in the Replacement field. Ignore: Block any matched metrics from reporting to New Relic platform. Ignore new metrics: Prevent the creation of new metric names, while allowing existing metric names to continue reporting. | | **Replacement** | The Replacement field is required only when you select the **Replace** option in the previous field. Enter the replacement metric to replace the matched metric defined in the **Regular expression** field. | | **Order of rule in sequence** | Specify the order in which the rule is applied relative to other rules. Lower the number, higher the evaluated priority. Recommend value is `2000` | | **Terminate** | If enabled, no additional rules will be applied to the metrics after this rule successfully matches a metric. | | **Active** | Toggle to enable or disable the rule. | | **Notes** | Notes on the rule for reference. | 3. Click **Save**. **Update a metric normalization rule** ### Update a metric normalization rule [#update-rule] 1. On the **Metric normalization rules** page, select the rule, and click the icon, then select **Edit**. 2. Update the necessary details. 3. Click **Save**. ## Disable a metric normalization rule [#disable-rule] You can't delete a metric normalization rule, but you can deactivate it. The deactivated rule will not affect any metrics reporting to New Relic. You can deactivate a `DENY_NEW_METRICS` rule from the **MGI details** page, when the `Denied rate (minute)` is below the `resolution rate (minute)` of 1000. To deactivate a rule: 1. On the **Metric normalization rules** page, select the required rule, and click the icon, then click **MGI details**. 2. Click **Deactivate**. ![View MGI details](https://docs.newrelic.com/images/metric-details.webp "View details") ## MGI details page [#mgi-details] The **MGI details** page provides a comprehensive overview of the metric normalization rules applied to your metrics. It allows you to analyze the impact of these rules on your metric data and make informed decisions about managing high cardinality metrics. On the **MGI details** page, you can view the following information: - **Blocked Metrics Overview**: Displays the number of metrics affected by the `DENY_NEW_METRICS` rule, including the rate at which metrics are blocked. Similar insights are available for `REPLACE` and `IGNORE` actions. - **Time Picker Functionality**: Allows you to view metrics reporting before rule activation, broken down by metric prefix. This feature helps identify the source of metric growth. - **NRQL Query Integration**: Offers a 'view in query builder' button to see the NRQL query illustrating the metric explosion just before any rule was applied. This targets Metric Timeslice data, enabling retrospective analysis up to three months. - **Metric Pattern Identification**: Enables identification of exploding metric patterns and creation of new regex rules to manage them effectively. - **Real-Time Status Indicators**: Includes widgets showing the current status of normalization rules, with indicators changing from 'Active' to 'Mitigated' as rules manage metric growth. - **Rule Modification Capability**: Allows users to deactivate their own `DENY_NEW_METRICS` rules directly from the MGI Details page, as well as modify `REPLACE` and `IGNORE` rules without support tickets. For more information, refer to [Disable a rule](#disable-rule). ### Access the MGI details page [#access-mgi] On the **Metric normalization rules** page, select the rule and click the icon, then select **MGI details**. ![View MGI details](https://docs.newrelic.com/images/metric-details.webp "View details") ### Example use case [#example-use-case] In the above example, the MGI details page displays that 1.1 million unique metric names are blocked by the `DENY_NEW_METRICS` rule at a rate of 738 metrics per minute. The majority of this growth is traced to the namespace `WebTransaction/Uri/RESTfulExample/users/username/`. By viewing the NRQL query, you can pinpoint the source of the explosion, allowing you to create a new rule to manage the metrics effectively.