Supported PromQL Features

New Relic supports PromQL-style queries, and our query builder offers a PromQL-style query mode that translates PromQL syntax queries into the closest NRQL approximation. Although the method of approximation means that a handful of edge cases are not fully supported, it provides coverage for an overwhelming majority of queries, supporting over 97% of queries across the 7 million top Grafana dashboard downloads.

Read on to learn about how we work with PromQL queries, as well as differences between standard PromQL and our PromQL-like query language we want you to be aware of.

For general information about Prometheus queries and operators, see the Prometheus.io documentation.

Supported features

We support the following aggregation, arithmetic, mathematical, and rate-like functions. As we continue to expand support for Prometheus and PromQL, this list will be updated.

Aggregation operators and functions
Arithmetic binary operators
Logical operators
Date/time functions
Mathematical functions
Rate-like functions
Predictive functions
Time-series selectors

We offer support for PromQL time-series selectors including the following:

We only support offset queries if every vector in the query has the same offset value.

PromQL troubleshooting

This section describes differences in behavior between PromQL and our PromQL-style query behavior and how to work with and around these differences. This is particularly relevant if you want to use advanced queries and our PromQL-style mode in the chart builder.

Metric types

Prometheus recommendations note that you should only use some functions, like delta(), on gauges, and only use others like rate() and increase() on counters, but queries in Prometheus still work most of the time even if they don’t follow those instructions.

However, because NRDB converts PromQL-style accumulating counters to delta counters, our implementation is unforgiving when using these functions on the wrong data type and will produce different or incorrect answers.

For this reason, it's best to follow all Prometheus recommendations when working with our PromQL-style queries, even if you don't follow these recommendations in Prometheus.

Limits

  • In order to ensure the stability and performance of our system for all users, we place some limits on what queries can be run. In all cases, we enforce a limit of 366 steps in range queries. We also default to only returning 100 timeseries from queries by default.
  • If you want to see more (or fewer), you need to explicitly add a topk() to your query. (Note that the topk() implementation in our PromQL-style query is different from that of Prometheus.)
  • We limit the total memory a query can use. This means that requests for large numbers of time steps or large numbers of time series may be rejected, particularly if they are combined with an aggregation like unique count or quantile which require significantly more memory to compute than simple arithmetic aggregations.

Range vector selectors (sliding windows and smoothing behavior)

We provide support for sliding window timeseries aggregations. For more information, see our NRQL syntax, clauses, and functions resource and our sliding windows deep dive.

For information on translating between NRQL and our PromQL-style language, see Translate PromQL queries to NRQL.

For more help

If you need more help, check out these support and learning resources: