This feature is currently in preview.
Dimensional metrics are an industry standard for storing and querying metric data. All infrastructure metrics are stored as event data in New Relic, but you can also query them as dimensional metrics.
In this page you can learn:
- The benefits of dimensional metrics.
- A few examples on how and where to use them.
- Differences in querying dimensional metrics versus event data.
Why it matters
This type of metric enables you to:
- Enjoy an improved query experience for infrastructure data.
- Discover all your metrics in one place.
- Tap into more metric sources, such as Prometheus.
For example, the query to get the maximum duration of your Lambda functions is simplified:
Query with samples
Query with metrics
No agent or integration updates are required to use these metrics.
NRQL alerting based on dimensional metrics is also supported, except for data coming from cloud integrations (that is metrics from AWS polling integrations, GCP, and Azure). AWS CloudWatch Metric Streams metrics are ingested as dimensional metrics and NRQL are recommended.
Where and how to query dimensional metrics
All current NRQL query features are supported. Queries can use
FACET, and time selection functions such as
Naming conventions for metrics and attributes
All metric names and attributes for dimensional metrics follow the same naming convention in order to make them easy to find and use. Metric and attribute names are namespaced with dots: for example, the
host. prefix is used for host metrics, the
k8s. prefix is used for Kubernetes metrics, and
aws. is used for AWS metrics.
The graphic below shows how a
ProcessSample that contains three metrics (
ioTotalWriteBytes) is split into three separate metrics. Note the updated naming of the metrics and the attributes.
Dimensional metrics naming convention
Here are some examples of NQRL queries with and without dimensional metrics:
Differences in querying dimensional metrics and events
Dimensional metrics are a fundamentally different type of data than is event data. For an overview of data type differences, see New Relic data types.
Here are some notable differences when querying dimensional metrics:
Metric queries with
*do not return infrastructure sample data. For example:SELECT * FROM Metric
Metric queries with
metricName LIKEdo not return infrastructure sample data. For example:SELECT uniques(metricName) FROM Metric where metricName like 'k8%'
In order to select attributes starting with
tags.a metric name has to be provided. For example, this does not work without the
WHEREclause:SELECT uniques(tags.environment) FROM Metric WHERE metricName='aws.lambda.function.duration'
Results may not be complete if the selection criteria matches too many samples. For example, this maps to all infrastructure samples, and may return incomplete results:SELECT uniqueCount(entity.guid) FROM Metric
Initially there is no support for the newly introduced metric wildcarding feature, for example:SELECT average(host.swap%Bytes) FROM Metric
Functions used on multiple metrics may fail or return incorrect results, for example:FROM Metric SELECT latest(metricNameA + metricNameB)
When you include
RAWin a query, the request transforms internally and prints equivalent, aggregated event data. It won't print raw data. Refer to the example query to see this behavior:SELECT max(host.cpuPercent) FROM Metric TIMESERIES 1 MINUTE SINCE 60 MINUTES AGO RAW
We don't support using
TIMESERIESand doing so will return an error. See the example below:FROM Metric SELECT keyset() WHERE instrumentation.provider = 'infrastructure' TIMESERIES