There are two metric types yet to be mentioned, info and enum. They are quite recent, but the convenience they bring is very much appreciated. Metrics of the type info have their names end with _info and are regular gauges with one possible value, 1. This special kind of metric was designed to be a place where labels whose values might change over time are stored, such as versions (for example, exporter version, language version, and kernel version), assigned roles, or VM metadata information; if those labels were to be exported in every time series, were they to change, a break in continuity would happen as the metric identity (the combination of the metric name and label set) would also change. This would also pollute the labels of all the time series that were affected, since these new labels would be present in every metric. To use this type of metric, we need to combine it with the metrics we wish to augment by using the multiplication operator—since the info metric value is 1, the multiplication won't change the value of the other metric—and the group_left/group_right modifiers allow us to enrich of the resulting vector with the labels we might require.

Here's an example of a query using an info metric:

node_uname_info{instance=”10.0.2.15:9100”}

We can see the previous query result in the following snippet:

node_uname_info{domainname="(none)",endpoint="node-exporter", instance="10.0.2.15:9100",job="node-exporter-service",machine="x86_64", namespace="monitoring",nodename="minikube",pod="node-exporter-r88r6", release="4.15.0",service="node-exporter-service",sysname="Linux", version="#1 SMP Fri Dec 21 23:51:58 UTC 2018"} 1

The enum metric type is also a gauge, just like info. Its objective is to provide a way to expose anything that might need state tracking, such as the current state of a state machine. The most common use case for this type of metric is exposing the state of daemons (start, starting, stop, stopping, failed, and so on). This tracking is done by maintaining state information on a label, appropriately named state, and setting the metric value to 1 for the current state and 0 otherwise.

Here's an example of an instant vector selector query using an enum metric:

node_systemd_unit_state{name="kubelet.service"}

The previous query results in the following snippet:

node_systemd_unit_state{endpoint="node-exporter",instance="10.0.2.15:9100",job="node-exporter-service",name="kubelet.service", namespace="monitoring",pod="node-exporter-jx2c2", state="activating"} 0
node_systemd_unit_state{endpoint="node-exporter",instance="10.0.2.15:9100",job="node-exporter-service",name="kubelet.service", namespace="monitoring",pod="node-exporter-jx2c2", state="active"} 1
node_systemd_unit_state{endpoint="node-exporter",instance="10.0.2.15:9100",job="node-exporter-service",name="kubelet.service", namespace="monitoring",pod="node-exporter-jx2c2", state="deactivating"} 0
node_systemd_unit_state{endpoint="node-exporter",instance="10.0.2.15:9100",job="node-exporter-service",name="kubelet.service", namespace="monitoring",pod="node-exporter-jx2c2", state="failed"} 0
node_systemd_unit_state{endpoint="node-exporter",instance="10.0.2.15:9100",job="node-exporter-service",name="kubelet.service", namespace="monitoring",pod="node-exporter-jx2c2"", state="inactive"} 0

Now that we know the basics of PromQL, let's dive into some common patterns and avoidable pitfalls when writing expressions.