New Relic drop rules don’t actually delete data; they tell New Relic to ignore data during ingestion.
Let’s see this in action. Imagine you have a noisy background job that’s flooding your New Relic account with metrics you don’t care about, like my_app.background_job.iterations for every single loop. You want to get rid of it.
Here’s how you’d set up a drop rule to ignore that specific metric:
{
"ruleType": "DATA_INGEST",
"actions": {
"drop": true
},
"condition": {
"field": "metricName",
"operator": "EQUALS",
"value": "my_app.background_job.iterations"
},
"name": "drop_background_job_iterations"
}
In the New Relic UI, you’d navigate to Data management -> Drop rules, click New drop rule, and paste this JSON.
This rule tells New Relic: if the incoming data point has metricName exactly equal to my_app.background_job.iterations, then drop: true (ignore it). The name is just for your reference.
Drop rules are powerful because they operate before data hits your retention buckets, meaning you don’t pay for storage or processing of data you discard. They are essential for managing costs and reducing noise in your dashboards and alerts.
You can filter on various fields, not just metricName. Other common fields include:
appName: To drop data from a specific application.host: To drop data from a particular server.span.kind: To drop tracing data for specific types of spans (e.g.,SPAN_KIND_INTERNAL).trace.id: To drop entire traces based on their ID.error.message: To drop events matching a specific error message.
Let’s say you want to drop all traces from a particular staging environment where you’re running performance tests and don’t want the trace data polluting your production view. You might have an environment attribute set on your spans. You could configure a rule like this:
{
"ruleType": "DATA_INGEST",
"actions": {
"drop": true
},
"condition": {
"field": "environment",
"operator": "EQUALS",
"value": "staging"
},
"name": "drop_staging_traces"
}
This rule would match any data point (metric, event, or span) that has an attribute named environment with the value staging, and then drop it.
You can also use LIKE operators for more flexible matching. For instance, if you want to drop all metrics that contain "debug" in their name:
{
"ruleType": "DATA_INGEST",
"actions": {
"drop": true
},
"condition": {
"field": "metricName",
"operator": "LIKE",
"value": "%debug%"
},
"name": "drop_debug_metrics"
}
The % acts as a wildcard.
The most surprising thing is that drop rules can be applied to different data types within a single rule. You can create a rule that drops specific metrics and events simultaneously if they meet the same criteria. For example, if you’re troubleshooting a specific issue and want to temporarily stop ingesting both the related metrics and error events:
{
"ruleType": "DATA_INGEST",
"actions": {
"drop": true
},
"condition": {
"field": "appName",
"operator": "EQUALS",
"value": "my-problematic-app"
},
"type": ["Metric", "Error"],
"name": "drop_metrics_and_errors_from_problematic_app"
}
Here, the type field specifies that this rule should only apply to Metric and Error data types. If you omit the type field, the rule applies to all data types (Metrics, Events, Traces, Logs).
When you’re designing drop rules, think about the cardinality of the fields you’re filtering on. Dropping based on a high-cardinality field (like a user ID) can be inefficient if that field appears on millions of data points. It’s generally more effective to drop based on lower-cardinality fields like appName, environment, or specific metric/event names.
After you’ve set up your drop rules, it’s crucial to monitor your data ingest volume. New Relic provides charts showing data ingest by source and type, which can help you verify that your rules are working as expected and that your ingest volume is decreasing in the areas you targeted.
The next thing you’ll likely want to explore is alert conditions and how to tune them to avoid noisy alerts, even when you’re not dropping data.