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 99.5% of queries across the 7.8 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.

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.

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 query 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 time series 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 time series aggregations. For more information, see our NRQL reference and sliding windows deep dive.

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

Query range and data scraping intervals

• The range of your query in PromQL must be larger than the duration of the step size of the query to avoid the error "TIMESERIES bucket size is larger than the current time window".
• We inspect data up to one minute old when servicing instant queries. If your scrape interval is greater than 1 minute, some queries may result in No data found. Avoid this by sending data at least once per minute.
• If the time series unit for your NRQL query is less than the scrape interval for your application, some periods will lack data, and the resulting graph may be jagged or contain peaks and valleys. In general, set the step size to your scrape interval, or higher.