Query and alert on usage data

To help you understand your New Relic usage and billing, we provide a usage UI for understanding your billing-related usage. Also, you can run custom NRQL queries to get additional detail, and you can create alert notifications for when your usage has reached certain levels.

Keep the following in mind when using the usage UI or making consumption queries:

• The results are approximate and don't correspond exactly to the values used to calculate your invoice amount.
• Use these tools to find and track your areas of high usage.
• Use queries to create alerts so you know if you're approaching a limit.

Data ingest usage queries

The usage UI displays your data ingest over time. If you need more detail than the UI provides, you can use a variety of NRQL queries. The examples below include two data types:

• NrConsumption: Use this to dive deep into the details of your usage hour-by-hour. It's less helpful as a proxy for your bill.
• NrMTDConsumption: Use this to see a good approximation of your monthly aggregated usage.

FROM NrConsumption SELECT sum(GigabytesIngested) 
WHERE productLine = 'DataPlatform' 
SINCE 3 months ago TIMESERIES 1 day

FROM NrConsumption SELECT sum(GigabytesIngested) 
WHERE productLine = 'DataPlatform' SINCE 3 months ago 
FACET usageMetric TIMESERIES 1 day

FROM Metric SELECT bytecountestimate()/10e8 AS 'GB Estimate' 
SINCE 24 hours ago
FACET metricName LIMIT 10 TIMESERIES 1 hour

FROM NrMTDConsumption SELECT latest(GigabytesIngested) 
WHERE productLine = 'DataPlatform'

Data ingest and query limits

For information about data ingest limits and query limits, see New Relic data limits.

User count queries

For a display of your user count, see the usage UI. If you need more detail than that, you can use the example NRQL queries below. For details about how users are calculated, see Billable user calculations.

Most New Relic organization have the ability to add core users. This section includes queries that will work for those organizations. If you're in an older organization that hasn't opted in to unlock core users, see Queries for organizations without core users.

Here are some rules for querying your users:

• Use only the NrMTDConsumption event.
• The attributes used for querying users are CoreUsersBillable and FullPlatformUsersBillable.

Here are some example NRQL queries for determining user count:

Month-to-date full platform users

This query shows the billable full platform users for the month. In other words, it shows how much you'd be billed for your full platform users for that month if you were billed right now.

FROM NrMTDConsumption 
SELECT latest(FullPlatformUsersBillable) 
SINCE 3 hours ago

Month-to-date core users

This query shows the number of core users you'd be billed for if you were billed right now:

FROM NrMTDConsumption 
SELECT latest(CoreUsersBillable)
SINCE 3 hours ago

Estimated cost

Here's a query for getting the current month's cost for your full platform users. Note that you'll have to know your organization's full platform user cost.

FROM NrMTDConsumption 
SELECT latest(FullPlatformUsersBillable) * YOUR_PER_FULL_PLATFORM_USER_COST
SINCE 3 hours ago

User queries for organizations without core users

These queries apply for some older New Relic organizations that have only two user types available: basic users and full platform users.

Synthetics usage

There are a certain number of synthetics checks included for free with each edition. For details on that, see Synthetics limits.

The NrMTDConsumption event powers the usage UI and should be used for usage alerting.

The NrDailyUsage event can help you further break down synthetics usage, but results may not match the usage UI and NrMTDConsumption event. It's generated once per day. Usage timestamps correspond to the time that New Relic receives and processes a synthetic check. This may introduce a slight difference in usage data compared to the time the synthetic check was executed.

By using FACET with the NrDailyUsage event, you can break your consumption into multiple categories, including account, location, monitor type, and monitor name. If you have a parent account structure, ensure you run queries in a parent account to see the aggregated usage for that parent and its child accounts.

Both successful and failed checks contribute to overall synthetics consumption. Below are sample queries to view and facet your synthetics consumption, using both event types as appropriate:

SELECT latest(freeConsumption) AS 'Included checks', latest(billableConsumption) AS 'Extra checks'
FROM NrMTDConsumption
WHERE metric='SyntheticChecks'
SINCE this month

SELECT latest(freeConsumption) AS 'Included checks', latest(billableConsumption) AS 'Extra checks'
FROM NrMTDConsumption
WHERE metric='SyntheticChecks'
SINCE 6 months ago 
FACET monthOf(timestamp)

SELECT (sum(syntheticsFailedCheckCount) + sum(syntheticsSuccessCheckCount)) 
AS 'Total Checks' 
FROM NrDailyUsage 
WHERE syntheticsTypeLabel != 'Ping' 
SINCE 1 month ago 
FACET consumingAccountName

SELECT (sum(syntheticsFailedCheckCount) + sum(syntheticsSuccessCheckCount)) 
AS 'Total Checks' 
FROM NrDailyUsage 
WHERE syntheticsTypeLabel != 'Ping' 
SINCE 1 month ago 
FACET syntheticsTypeLabel

SELECT (sum(syntheticsFailedCheckCount) + sum(syntheticsSuccessCheckCount)) 
AS 'Total Checks' 
FROM NrDailyUsage 
WHERE syntheticsTypeLabel != 'Ping' 
SINCE 1 month ago 
FACET syntheticsMonitorName

SELECT (sum(syntheticsFailedCheckCount) + sum(syntheticsSuccessCheckCount)) 
AS 'Total Checks' 
FROM NrDailyUsage 
WHERE syntheticsTypeLabel != 'Ping' 
SINCE 1 month ago 
FACET syntheticsLocationLabel

Cost-related queries

Here are some query recommendations for helping you understand the estimated cost for the current month.

FROM NrMTDConsumption 
SELECT latest(GigabytesIngestedBillable) * YOUR_PER_GB_COST

FROM NrMTDConsumption 
SELECT latest(GigabytesIngestedBillable) * .35

Set usage alerts

To help manage your billing, you can set alerts to notify you of unexpected increases in data ingest or user count.

Before building usage-related alert conditions, here are some tips:

• For basics about how to set up alerts, see NRQL alert conditions.
• The event timer aggregation method is recommended because it works best for infrequent data.

Here are some NRQL alert condition examples.

FROM NrConsumption 
SELECT sum(GigabytesIngested) 
WHERE productLine = 'DataPlatform'

FROM NrConsumption 
SELECT sum(GigabytesIngested) 
WHERE productLine = 'DataPlatform' 
AND consumingAccountId = YOUR_CHILD_ACCOUNT_ID

FROM NrMTDConsumption 
SELECT latest(GigabytesIngested) 
WHERE productLine = 'DataPlatform'

FROM NrMTDConsumption 
SELECT latest(FullPlatformUsersBillable)

FROM NrMTDConsumption 
SELECT latest(GigabytesIngestedBillable) * YOUR_PER_GB_COST

For setting up alerts related to data ingest limits and query limits, see Set alerts for hitting data limits.

Query changes to your account

To see changes made to your account (for example, changes related to managing users), you can query NrAuditEvent.

Usage-related events and attributes

These are the primary events to query for understanding your usage:

• NrConsumption records usage every hour, and is the equivalent of "real-time" usage. Use this event to observe usage trends over time.
• NrMTDConsumption generates aggregate values from the NrConsumption event. Use this event to see usage by monthly billing period. This is the best event for querying user count.

Here are some of the most important attributes attached to usage-related events.

Byte count estimate

One tool you can use to learn more about your usage is the function bytecountestimate() (for example, see this query that uses it).

Some important points to know about using bytecountestimate():

• Because it returns all data it finds, and some of that data doesn't count towards your ingest and billing, it's only an estimate of your actual usage. For that reason, it's mostly useful for researching the data reported by various sources, or for understanding the upper ceiling of data reported.
• We recommend using it mainly for querying time ranges under 24 hours, and, if desired, using that to extrapolate. This is because it's a function that requires querying a lot of data, and because it won't find data that passes retention boundaries.

For more about estimating usage, see our blog post about estimating usage.

Here are some technical details about how bytecountestimate() works:

• There are several types of data that don't count towards ingest but that is returned by the bytecountestimate() function. This means that this function sometimes shows more data than actually is counted towards your usage. It may rarely show a lower amount but, if it does, it will be only slightly lower.
• Some telemetry data reported from an entity shares common attributes (for example, attributes about your New Relic account). We don't count the duplicated attributes towards your ingest, but bytecountestimate() does count those attributes. This can sometimes result in a large discrepency between a bytecountestimate() query and your actual usage.
• Our APM, browser monitoring, and mobile monitoring report a type of data known as metric timeslice data. This data isn't stored in NRDB like our other data types are, and so trying to use bytecountestimate() on this data can result in confusing results. When querying this data, we recommend faceting by application name, and not by the metric name.