Introduction to PromQL, the Prometheus query language

• 4 Feb, 2020 • 12 min

PromQL is the querying language that is part of Prometheus. In addition to PromQL, Prometheus provides a scraper that fetches metrics from instances (any application providing metrics) and a time series database (TSDB), which stores these metrics over time.

This introduction to PromQL will be largely decoupled from specific tools and the non-PromQL parts of Prometheus, in order to focus on the features of the language itself.

I recommend reading Ivana Huckova’s blog post, How to explore Prometheus with easy ‘Hello World’ projects, which has useful tips and links on getting a series and a database set up together with Grafana. Also we recently introduced the Prometheus query builder in Grafana 9, which makes it easy to build simple and complex Prometheus queries — no PromQL experience required.

You can also get started with Prometheus in minutes with Grafana Cloud. We have new free and paid Grafana Cloud plans to suit every use case — sign up for free now.

As supplements to this post, check out this excellent recorded talk by Ian Billett from PromCon EU 2019: PromQL for Mere Mortals. If you’re interested in a PromQL cheat sheet check out Timber’s PromQL for Humans or PromLabs’ PromQL Cheat Sheet.

Data types

Prometheus uses three data types for metrics: the scalar, the instant vector, and the range vector. The most fundamental data type of Prometheus is the scalar — which represents a floating point value. Examples of scalars include 0, 18.12, and 1000000. All calculations in Prometheus are floating point operations.

When you group together scalars as a set of metrics in a single point in time, you get the instant vector data type. When you run a query asking for only the name of a metric, such as bicycle_distance_meters_total, the response is an instant vector. Since metrics have both names and labels (which I’ll cover a little later), a single name may contain many values, and that is why it’s a vector rather than just a scalar.

An array of vectors over time gives you the range vector. Neither Grafana nor the built-in Prometheus expression browser makes graphs out of range vectors directly, but rather uses instant vectors or scalars independently calculated for different points in time.

Because of this, range vectors are typically wrapped with a function that transforms it into an instant vector (such as rate, delta, or increase) to be plotted. Syntactically, you get a range vector when you query an instant vector and append a time selector such as [5m]. The simplest range vector query is an instant vector with a time selector, such as bicycle_distance_meters_total[1h].

Labels

Some earlier metric systems had only the metric name for distinguishing different metrics from each other. This means that you might end up with metric names such as bicycle.distance.meters.monark.7 to distinguish a 7-geared Monark bicycle from a 2-geared Brompton bicycle (bicycle.distance.meters.brompton.2). In Prometheus, we use labels for that. A label is written after the metric name in the format {label=value}.

This means that our previous two bikes are rewritten as bicycle_distance_meters_total{brand="monark",gears="7"} and bicycle_distance_meters_total{brand="brompton",gears="2"}.

When querying based on metrics, the same format is used. As such, bicycle_distance_meters_total would give us the mileage of all bikes in this example; bicycle_distance_meters_total{gears="7"} would limit the resulting set to all 7-geared bicycles. This allows us much more flexibility without having to resort to weird regex magic as with the older format.

Negation and regular expressions (in Google’s RE2-format) are supported by replacing = with either !=, !~, or =~ for not equal, not matching, and matching respectively. (When selecting multiple values for variables in Grafana, they are represented in a format compatible with =~).

The downside with labels is that the seemingly innocent query bicycle_distance_meters_total can actually return thousands of values, and it’s sometimes not intuitive which queries will end up heavy on the Prometheus server or the client from which you’re querying Prometheus.

Metric types

Prometheus conceptually has four different metric types. The metric types are all represented by one or more scalar values with some different conventions dictating how to use them and for what purpose they’re useful.

Counter and Gauge are basic metric types, both of which store a scalar. A counter always counts up (a reset to zero can happen on restart) compared to a gauge, which can go both up and down. bicycle_distance_meters_total is a counter since the number of kilometers a bike has traveled cannot decrease, whereas bicycle_speed_meters_per_second would have to be a gauge to allow for decreased speeds. By convention, counters end with _total to help the user distinguish between counters and gauges at a glance.

The third data type is Histogram, which offers a single interface for measuring three different things:

<metric>_count is a counter that stores the total number of data points.
<metric>_sum is a gauge that stores the value of all data points added together. The sum can be used as a counter for all histograms where negative values are impossible.
<metric>_bucket is a collection of counters in which a label is used to support calculating the distribution of the values. The buckets are cumulative, so all buckets that are applicable for a value are increased by one on insertion of a sample. There is a +Inf bucket, which should hold the same value as _count.

For a bicycle race, the number of cyclists finishing by the number of hours it takes them to finish could be stored in a histogram with the buckets 21600, 25200, 28800, 32400, 36000, 39600, +Inf. (Time is by convention stored in seconds; this is one bucket per hour for the range [6, 11] hours.)

If there are 2 cyclists finishing in slightly less than 7 hours, 5 in less than 8 hours, 3 in less than 10 hours, and a sole cyclist finishing two days later, the bucket would be represented something like this. (For the purpose of this example, I’ve made up the value for the sum, but of course it can be anything, depending on the values in each bucket.)

race_duration_seconds_bucket{le="21600"} 0
race_duration_seconds_bucket{le="25200"} 2
race_duration_seconds_bucket{le="28800"} 7
race_duration_seconds_bucket{le="32400"} 7
race_duration_seconds_bucket{le="36000"} 10
race_duration_seconds_bucket{le="39600"} 10
race_duration_seconds_bucket{le="+Inf"} 11
race_duration_seconds_count 11
race_duration_seconds_sum 511200

By having a common convention for how to store histograms, Prometheus can provide functions such as histogram_quantile (which calculates quantiles for a histogram – I’ll go into the details of that further down), and external tools such as Grafana can recognize the format and provide histogram features. Since histograms are “just” a collection of counters, the histograms don’t increase the complexity of Prometheus at large.

When using histograms, knowing how the buckets work and that everything above the largest bucket is simply stored as “more than the largest bucket” can help you understand what kind of accuracy you can get from histograms, and by extension, what accuracy you can expect from a calculation.

For instance, having a +Inf bucket with a significantly higher value than the largest bucket might be an indicator that your buckets are misconfigured (and that the values you’re getting from Prometheus are unreliable).

The final type of metrics is Summary. It is similar to a histogram but is defined as a quantile gauge that is calculated by the client to get a higher accuracy of a quantile. The precalculated quantiles for summaries cannot be aggregated in a meaningful way. You can study the quantiles from individual instances of your service, but you cannot aggregate them to a fleet-wide quantile.

One common use case for quantiles is as service level indicators (i.e. SLI/SLO/SLA) to know how large a portion of the incoming requests to a server is slower than say 50ms. With a histogram in which one of the buckets is <0.05 seconds, it’s possible to say with high accuracy how many of the requests were not handled within that time. Adding more buckets will make it possible to calculate quantiles, which gives you an idea of the performance. With summaries, this aggregation is not at all possible.

To summarize, histograms require you to have some level of insight into the distribution of your values to begin with to set up appropriate buckets whereas summaries lack reliable aggregation operations.

Functions and operators

Metrics can be useful by themselves, but in order to maximize their utility, some kind of manipulation is necessary, which is why Prometheus provides a number of operators and functions for manipulation.

Aggregation operators

Aggregation operators reduce one instant vector to another instant vector representing the same or fewer label sets, either by aggregating the values of different label sets or by keeping one or more distinct sets, depending on its values. The simplest form of aggregation operators would appear as avg(bicycle_speed_meters_per_second), which gives you the overall average speed of the bicycles in the set.

If you want to be able to differentiate bicycles by the labels, brand, and number of gears, you can instead use avg(bicycle_speed_meters_per_second) by (brand, gears). You can replace by with without if you want to discard a label for the new vector instead of selecting which you’d like to keep.

There are a number of aggregations available, the most prominent being the hopefully self-explanatory sum, min, max, and avg. Some of the more complex aggregators take additional parameters, such as topk(3, bicycle_speed_meters_per_second), which gives you the overall three highest speeds.

Binary operators

The arithmetic binary operators (+, -, *, /, % [modulo/clock counting], ^ [power]) can operate on a combination of instant vectors and scalars, which can lead to a bit of a world of pain if you’re trying to be mathematically sound. So I’ll summarize the different cases and how to handle the weird cases that come with doing vector arithmetics.

Scalar-to-scalar arithmetics is at its core the arithmetics from primary school. Scalar to vector arithmetics is almost as simple: For every value in the vector, apply the calculation with the scalar. (If you have the bicycle_speed_meters_per_second and want to express it in the more kilometers per hour (km/h), that is done with bicycle_speed_meters_per_second*3.6.)

Vector-to-vector arithmetics is where it becomes really interesting. There is label matching going on, and the vectors that have labels that exactly match up to each other are calculated toward each other. All other values are discarded. Example: bicycle_speed_meters_per_second / bicycle_cadence_revolutions_per_minute.

Since that’s often not what you want, you can add an on (or ignoring) operator to the right of the binary operator, and you’ll end up limiting the set of labels being used for the comparison before running it. However, all labels that are not used for the comparison are thrown away. This would be bicycle_speed_meters_per_second / on (gears) bicycle_cadence_revolutions_per_minute.

What if you want to keep those labels? Well, you can keep all labels from the left hand side by adding group_left after the on or ignoring keyword. When you do that, the value of the right-hand side will be applied on each of the left-hand side labels that match the labels from on. In practice, this looks like bicycle_speed_meters_per_second / on (gears) group_left bicycle_cadence_revolutions_per_minute. There is also a group_right, which instead groups by the right-hand side.

In addition to the arithmetic operators, there are also the comparison (==, !=, >, <, >=, <=) and set (and, or, unless) operations.

Comparison operations are defined for instant vectors and scalars. A comparison between two scalars returns either 0 for false or 1 for true and requires the bool keyword after the comparator. For instant vectors, when compared to a scalar, every data point for which the comparison is true is kept, and the others are thrown away.

When comparing two instant vectors, the logic is similar, but per set of labels, both the labels and the values are compared. When the operation returns false, or there is no metric with a matching set of labels on the opposite side, the value is thrown away; otherwise it’s kept. If you want 0 or 1 instead of keeping or tossing the value, you can add the keyword bool after the comparator.

The set operators operate on instant vectors and work by inspecting the label sets on the metrics. For and, if a label set exists on both the left-hand side and right-hand side, the value of the left-hand side is returned; otherwise, nothing. For or, all label sets for the left-hand side are returned, as are the sets for the right-hand side that don’t exist on the left-hand side. And finally, unless returns the values on the left-hand side for which the label set does not also exist on the right-hand side.

Functions

Functions in Prometheus work much like functions in programming in general, but are limited to a pre-defined set. It’s important to know that most of Prometheus’s functions are approximative and extrapolate the result – which occasionally turns what should be integer calculations into floating point values, and also means that Prometheus is really bad to use when exactness is required (for example, for billing purposes).

Some particularly useful functions are delta, increase, and rate. Each takes a range vector as input and returns an instant vector. delta operates on gauges and returns the difference between the start and end of the range. increase and rate operate on counters and return the amount the counter has increased over the specified time. increase gives the total increase over the time, and rate gives per second increase. rate(bicycle_distance_meters_total[1h]) should be the same as increase(bicycle_distance_meters_total[1h]) / 3600. Because increase and rate have logic to handle restarts when the value is reset to zero, it’s important to avoid using them with gauges that go up and down. That could end up looking like a restart to the functions, resulting in a nonsensical value.

To make sense out of the histogram buckets, the histogram_quantile function takes two arguments: first, the quantile that should be calculated, and second, the bucket’s instant vector. For our earlier race example, with a few more labels added, this could be histogram_quantile(0.95, sum(race_duration_seconds_bucket) by (le)), which returns the time in which the 95-percentile racer would finish. The reason we sum the finish time with by (le) before performing the quantile calculation is because the quantile is calculated per unique combination of labels. This allows us to graph things such as the median time per number of gears on the bike with histogram_quantile(0.5, sum(race_duration_seconds_bucket) by (le, gears)).

Feedback