Here are some limits, requirements, and recommendations when you create metrics from events, logs, or spans.
Your NRQL query must use one of the following
distribution functions to aggregate metrics:
Creates a summary metric data point for each time window (currently 1 minute). Use this if your NRQL query uses aggregator functions supported by the summary metric type, such as average, sum, min, or max.
Example rule-creation query:
SELECT summary(duration) AS 'service.responseTime' FROM Transaction WHERE appName = 'Data Points Staging' FACET name, appName, host
Example rule-creation query:
FROM Transaction SELECT uniqueCount(request.headers.userAgent) AS 'server.request.header.userAgent.uniqueCount' WHERE appName = 'Browser Monitoring Router' FACET httpResponseCode, name, appName, host
Creates a distribution metric data point for each 1-minute time window. Use this if your NRQL query uses aggregator functions such as percentile, histogram, min, max, average, sum, or count. Use only the attribute of interest as the argument, and discard the rest of the arguments from
Example of creating a
SELECT distribution(duration) AS 'service.responseTime' FROM Transaction WHERE appName = 'Data Points Staging' FACET name, appName, host
If you want a metric that's a simple count of the events, logs, or spans that match a particular
Example: If you want to create a metric named
FROM Transaction SELECT summary(1) AS 'foo.count' WHERE name = 'foo'
Then, you would query it like this:
FROM Metric SELECT sum(foo.count) SINCE 30 minutes agoFor more information about metrics, see our documentation about metric types.
These limits affect metric rules creation:
An account can have a maximum of 1,000 metric-creation rules.
|Metric rule limits||
A rule can:
|Time window limits||
50K limit on unique metric-name/attribute-value combinations for a single metric in a 24-hour time window.
If this limit is exceeded, the rule is disabled and an
|Limits on metric name and attribute value combinations||
The limit on total unique metric name/attribute value combinations in a 24-hour time window for an account is:
Rule-creation limits include limits on the number of unique combinations of metric name and attribute values. This limit exists because a large number of attributes and/or attribute values can lead to an exponential increase in the size of data reported.
Example metric creation rule that attaches five attributes:
FROM ProcessSample SELECT summary(ioTotalReadBytes) WHERE entityType = 'ComputeSample' FACET awsRegion, awsAvailabilityZone, commandName, entityName, processId
If each of the five attributes reported ten unique values within a one-minute time window, the number of unique metric-name/attribute combinations would theoretically have a maximum of 10x10x10x10x10, or 100,000. Multiple attributes with multiple unique values can lead to a large number of unique metric entries.
In practice, this isn't usually the case, because attributes are often related. For example, if one attribute is
hostname and another is
awsRegion, when you see hostname A, it will always be in AWS region B; you'd never see hostname A and other AWS region values.
This is why it's important, during the NRQL creation process, to use the
uniqueCount function to verify how many unique metric-name/attribute-value combinations your NRQL query is generating.
Multiple metrics from one rule
A rule can create up to ten metrics. There are no functional differences between metrics created one at a time and those created with a single rule. Reasons for creating multiple metrics with a single rule:
- Less likely to reach rules-per-account limit.
- Easier to add the same attributes to multiple metrics.
Example creating multiple metrics with a single rule:
FROM Transaction SELECT uniqueCount(request.headers.userAgent) AS 'server.request.header.userAgent.uniqueCount', summary(duration) AS 'server.duration', summary(totalTime) AS 'server.totalTime' WHERE appName = 'Browser Monitoring Router' FACET httpResponseCode, name, appName, host
A metric is given a name with the
AS clause, as part of the NRQL rule-creation process. In the following NRQL example, the name of the metric is
FROM ProcessSample SELECT summary(ioTotalReadBytes) AS 'io.totalread.bytes' WHERE entityType = 'ComputeSample' FACET awsRegion, awsAvailabilityZone, commandName
If there is no name assigned with the
AS clause, the metric name is the name of the queried attribute. In this example, if no name was assigned, the metric name would be
|Metric names||Requirements and recommendations|
Requirements for naming a metric:
Examples of strong metric names:
|Length and structure||
Decide on a name and structure that makes it easy for others to find, understand, and use this metric.
|Components within the name||
If you want to create components within your metric name (like the source of metrics and the thing you’re measuring), we recommend going from broad to specific (left to right):
Avoid putting attributes in your metric name. Attributes are qualities of your metric that you can use to filter or facet your data, like cluster or availability zone.
Example: If you included availability zone in your metric name, it would mean, for that metric, you wouldn’t be able to see results across all availability zones.
|Changing metric names||
If you change a metric name, historical data will not be updated to that new name. To query or chart that historical data, you will need to specify the older metric name.