Event data retention (original pricing plan)

This is an explanation of how the number of stored events are calculated by default for an Insights Pro subscription. (Note that with flexible retention, you have more fine-grained control over the retention period.)

The events stored is calculated based on 1) total events stored over time (calculated based on the events generated per week) and 2) the weeks of data retention available. This equation can be represented like this:

events stored = (events generated per week) * (weeks of retention)

An Insights Pro subscription provides a given number of weeks of data retention as well as a given number of events over that retention period.

For example:

• (200M transactions per week) * (4 weeks of retention) = 800M events stored in Insights
• (16M transactions per week) * (50 weeks of retention) = 800M events stored in Insights

For Insights Pro subscriptions, data is purged based on retention window, not volume. It is deleted from the system once it's past the retention window.

For example: If your Insights license is for 800 million events with a 4 week retention period, your data would start being purged after it is older than four weeks. Temporary spikes in data exceeding your subscription level will still be recorded, but consistent overage should be solved by upgrading your subscription level or decreasing data collected.

For customers without an Insights Pro subscription, New Relic may throttle or downsample events to a limit of not more than than 4,000 events per host per minute.

In this example, you have an Insights Pro subscription with a license for 800 million events over 4 weeks, a rate of 200 million events per week. You have APM Pro, Browser Pro, and Mobile Enterprise. A fifth week of data is added via your subscriptions, bumping you to a total of 1 billion events stored within your plan:

• If you are using 975 million events, you are not over your retention.
• If you are using 1.25 billion events, you are over your retention.

The Insights Data summary UI page is used to see the types of events being reported. You can also use this page to enable and disable the reporting of PageView and Transaction events.

To view Data summary:

1. Go to insights.newrelic.com > Manage data.

2. Select the Summary tab.

   Note: if you disable PageView or Transaction event reporting, this can affect some New Relic UI elements. You may see some empty charts on some UI pages that rely on this data.

3. Go to insights.newrelic.com > Manage data > Summary.

4. From the Summary tab, select Configure data sources.

5. Toggle the appropriate switch on or off, then save.

   Toggling Transaction on or off will cause reporting agents to restart themselves.

   For more about configuring event reporting, see Event data retention.

To understand how standard event data retention works, first read Event data retention.

With flexible retention, you specify the data retention for applicable event namespaces across your accounts. This gives you per-event namespace control of your data. The retention that you specify for an event namespace will be shared by all the event types under that namespace. If some namespaces are not relevant to you, you can avoid collecting their event data entirely.

Your retention value can’t be lower than the included retention or higher than the default retention.

You can control data retention either in our UI or by API.

You can control data retention either using our GraphQL API or in the UI.

To do this with the UI, go to Account Settings > Usage > Data management section. Your retention changes take effect within 24 hours after updating.

When it comes to master and sub-accounts with flexible retention, be aware of the following:

To understand the terms used with flexible retention, see the following:

To list the customizable retention event names spaces for your account, go to api.newrelic.com/graphiql and run the following:

query {
 actor {
   account(id: YOUR_ACCOUNT_ID) {
     dataManagement {
       customizableRetention {
         eventNamespaces {
           namespace
         }
       }
     }
   }
 }
}

To list active rules on an account, go to api.newrelic.com/graphiql and run the following:

query {
 actor {
   account(id: YOUR_ACCOUNT_ID) {
     dataManagement {
       eventRetentionRules {
         id
         deletedAt
         deletedById
         createdAt
         createdById
         retentionInDays
         namespace
       }
     }
   }
 }
}

To show the active rule on a specific account/namespace pair, go to api.newrelic.com/graphiql and run the following:

query {
 actor {
   account(id: YOUR_ACCOUNT_ID) {
     dataManagement {
       eventRetentionRule(namespace: "APM") {
         id
         deletedById
         deletedAt
         createdById
         createdAt
         retentionInDays
         namespace
       }
     }
   }
 }
}

To create a new rule, go to api.newrelic.com/graphiql and run the following:

mutation {
 dataManagementCreateEventRetentionRule(accountId: YOUR_ACCOUNT_ID, namespace: "APM", retentionInDays: 8) {
   id
   deletedById
   deletedAt
   createdById
   createdAt
   retentionInDays
   namespace
 }
}

If you delete a rule applied to a sub-account, that sub-account will adopt the current retention value of its master account for the given namespace. If you delete a rule applied to a master account, the default retention value will re-apply for the given namespace. To delete an existing rule, go to api.newrelic.com/graphiql and run the following:

mutation {
 dataManagementDeleteEventRetentionRule(accountId: YOUR_ACCOUNT_ID, namespace: "APM") {
   id
   deletedById
   deletedAt
   createdById
   createdAt
   retentionInDays
   namespace
 }
}

You can specify a sub-account to be the template or source account, and have other destination sub-accounts adopt the same namespace retention values of the source sub-account. Note: all sub-accounts must be within the same master account. To copy an existing set of retentions, go to api.newrelic.com/graphiql and run the following:

mutation {
  dataManagementCopyRetentions(
    sourceAccountId: SOURCE_ACCOUNT_ID,
    destinationAccountIds: [DESTINATION_ACCOUNT_ID_1, DESTINATION_ACCOUNT_ID_2, DESTINATION_ACCOUNT_ID_3])
  {
    success
    failure
  }
}

Success and failure will return lists of destination account ids which were successful (or failed) in copying rules from the source account.