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:
Example rule-creation query:
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
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
Then, you would query it like this:
For 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 30 second time window. Normal cardinality limits on rollups will apply.
If the 50k in a 30 second window limit is exceeded, the rule is disabled and an
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 http.statusCode, 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
Requirements and recommendations
Requirements for naming a metric:
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.