Promql practice questions

increase(http_requests_total[5m])

Why it fails: increase returns the total growth across the range, not a per-second rate, and it extrapolates to the range boundaries. The operator needs rate, which divides by seconds and is un-extrapolated. increase is tempting for counter growth over a window, and it would be correct when you want the absolute increment, not a rate.

rate(http_requests_total[5m])

Why it fails: rate extrapolates to the range boundaries, so it is not un-extrapolated as the stem requires. The un-extrapolated per-second function is irate, which uses only the last two samples. rate is tempting because it does return a per-second average, and it would be correct when boundary extrapolation is acceptable.

delta(http_requests_total[5m])

Why it fails: delta returns the difference between the first and last sample of a gauge range, with no per-second division and no counter handling. irate gives the un-extrapolated per-second rate. delta is tempting for measuring change over a window, and it would be correct for a gauge such as temperature.

deriv(node_disk_bytes_used[3h])

Why it fails: deriv() returns the per-second rate of change of a gauge, so it yields bytes per second, not an absolute byte total. sum_over_time() or delta() over the range gives the absolute increase. deriv() is tempting because it does operate on gauges, and it is correct when you need the instantaneous slope of a gauge.

increase(node_disk_bytes_used[3h])

Why it fails: increase() is designed for counters and extrapolates assuming monotonic growth, so applying it to a gauge such as node_disk_bytes_used gives meaningless extrapolated values. delta() or sum_over_time() returns the absolute increase for a gauge. increase() is tempting because it does compute growth, and it is correct for counter metrics.

rate(node_disk_bytes_used[3h])

Why it fails: rate() computes a per-second average rate and assumes a counter, so on a gauge it returns bytes per second rather than the absolute byte increase. delta() or sum_over_time() gives the total increase. rate() is tempting because it summarises change over a range, and it is correct for counters such as http_requests_total.

IS

Why it fails: PromQL selectors use = for exact label equality; IS is not a matcher operator and appears in no selector syntax. It tempts because SQL's IS NULL and IS NOT NULL read like equality tests, but PromQL instead provides =, !=, =~ and !~, with absent() handling missing labels.

:=

Why it fails: PromQL uses a single = for exact label equality; := is not a matcher operator and would be a syntax error in a selector. It tempts because := denotes assignment in Go and other languages, but PromQL selectors accept only =, !=, =~ and !~, so := never matches a label.

==

Why it fails: PromQL selectors use = for exact label equality, not ==; == appears only inside comparison operations in expressions. The == operator is tempting because it matches equality syntax in programming languages, but in a selector context it is a syntax error, so it cannot filter series by label value.

include_labels

Why it fails: include_labels is not a PromQL keyword; the modifier that copies labels from the 'many' side is group_left, optionally followed by a label list. It is tempting because the name describes the desired effect, but no such token exists in the language.

keep_all

Why it fails: keep_all is not a PromQL keyword; preserving labels from the many side is done with group_left plus an explicit label list. The name suggests retention of all labels, which is why it appears plausible, but the parser rejects it.

group_right

Why it fails: group_right copies labels from the right-hand 'one' side, so it cannot include labels from the many side; it also inverts which vector must be the many side. It is correct when the right vector is the many side and its labels must be carried into the result.

A range vector spanning 5 minutes.

Why it fails: rate() converts range vectors into instant vectors.

An instant vector preserving all original metric labels.

Why it fails: Unspecified aggregation drops all distinctive labels.

A scalar value representing the exact floating-point result.

Why it fails: Aggregations return instant vectors, not raw scalars, unless explicitly coerced.

The queried metric is a gauge rather than a counter, and samples do not follow monotonic rules.

Why it fails: Gauges don't cause NaN in rate, though rate on gauges is semantically incorrect.

The query is executed with an instant vector instead of a range vector.

Why it fails: Passing an instant vector directly to rate() causes a syntax error rather than returning NaN.

The counter experienced a reset during the window.

Why it fails: Counter resets are handled automatically by rate() and do not cause NaN.

Prometheus throws a fatal query evaluation runtime exception.

Why it fails: PromQL handles math errors gracefully without crashing.

The query returns NaN for all series.

Why it fails: Empty vectors are omitted entirely rather than returning NaN.

The query automatically returns infinity.

Why it fails: PromQL does not return infinity for vector division by zero; it returns empty.

It reverses the vector matching direction to evaluate from right to left.

Why it fails: Vector matching always evaluates from left to right; group_right controls cardinality expansion.

It drops all labels from the left-hand side vector.

Why it fails: group_right keeps all labels from the right side and matching labels from the left.

It ensures that the output contains only time series found exclusively on the right side.

Why it fails: It still performs an inner or outer join depending on modifiers, but specifically populates based on the right-hand side cardinality.

histogram_quantile(http_request_duration_seconds_bucket[5m], 0.99)

Why it fails: The quantile parameter must be the first argument, and the range vector must be wrapped in a rate or increase function.

quantile_over_time(0.99, http_request_duration_seconds_bucket[5m])

Why it fails: quantile_over_time calculates the quantile of raw values over time for a single series, not aggregated histogram buckets.

rate(histogram_quantile(0.99, http_request_duration_seconds_bucket[5m]))

Why it fails: histogram_quantile returns an instant vector of gauges; wrapping it in rate() is incorrect because gauges cannot be passed to rate().

sum(node_memory_Usage_bytes) drop (instance)

Why it fails: The 'drop' keyword is not a valid PromQL aggregation modifier.

sum(node_memory_Usage_bytes) by (job)

Why it fails: The 'by' clause drops all labels except 'job', meaning the 'instance' label would be discarded.

sum(node_memory_Usage_bytes) without (instance)

Why it fails: This would drop the 'instance' label and keep everything else, which is the opposite of keeping instance while grouping by job.

http_*(5m)

Why it fails: http_*(5m) is not valid PromQL syntax; wildcards are not permitted in metric names, and the trailing range only applies to range-vector selectors. It is tempting because it resembles glob matching from shell or file systems, which would be the right approach when matching filenames rather than time series.

{metric=~"http_.*"}

Why it fails: The label matcher targets a label literally named metric, which does not exist on these series, so nothing matches. It is tempting because regex label matching is the correct mechanism for name patterns, and would work if the label were __name__, as in {__name__=~"http_.*"}.

{__name__="http_*"}

Why it fails: The __name__ label is matched with the equality operator, so the asterisk is treated as a literal character and no series named http_* exists. It is tempting because __name__ is the right label to target; the correct form uses the regex operator =~ with the pattern "http_.*".

rate(http_requests_total{status="200"}[5m]) / rate(http_requests_total[5m]) ignoring(status)

Why it fails: The ignoring(status) modifier drops the status label from matching, but the denominator retains every status value, so the division produces a many-to-one vector match error rather than a single ratio. It is tempting because ignoring() is the standard tool for reconciling differing label sets between two operands.

sum(http_requests_total{status="200"}) / sum(http_requests_total)

Why it fails: Aggregating with sum() discards the per-series dimensions, collapsing both counters into single scalars and yielding one global ratio instead of per-job or per-instance results. It is tempting because sum() is the usual way to reduce a counter to a total, which suits fleet-wide dashboards rather than per-series ratios.

http_requests_total{status="200"} / http_requests_total

Why it fails: Dividing the raw counters without rate() compares cumulative totals since process start, and the denominator's extra status label values cause a many-to-one matching error. It is tempting because the metric names and label selectors look correct, and raw division works when both operands share identical label sets.

rate(http_requests_total{status='200'})

Why it fails: The rate function requires a range vector argument.

http_requests_total{status='200'}[5m]

Why it fails: This returns a range vector, not an instant vector.

http_requests_total{status='200'} offset 5m

Why it fails: The offset modifier shifts the time, but the syntax is incomplete for an expression result.

The 0.95 argument requires the 'le' label to be removed.

Why it fails: The 'le' label is required for the function to map values to buckets.

The rate function cannot be used inside histogram_quantile.

Why it fails: rate is required to convert raw buckets into a rate of events.

It is faster than calculating the quantile per instance.

Why it fails: Performance is a secondary benefit to correctness.

process_cpu_seconds_total * ignoring(job) up

Why it fails: Ignoring is usually less precise than 'on' for filtered joins.

process_cpu_seconds_total * group_left up

Why it fails: This requires an 'on' or 'ignoring' clause to match labels.

process_cpu_seconds_total and on(instance) up

Why it fails: 'and' is a set intersection operator, not an arithmetic join.

!

Why it fails: This is not a valid operator.

not

Why it fails: not is not a standalone operator.

none

Why it fails: none is not a keyword.

ns

Why it fails: Nanoseconds is not a supported duration unit.

ms

Why it fails: Milliseconds is not a supported duration unit.

merge

Why it fails: merge is not a modifier.

include

Why it fails: include is not a modifier.

Operators are evaluated strictly from left to right regardless of type.

Why it fails: PromQL applies standard mathematical precedence, so multiplication binds tighter than addition; left-to-right evaluation applies only between operators of equal precedence. It is tempting because most binary operators are left-associative, but that associativity does not override the precedence ranking between * and +.

Operators are evaluated strictly from right to left.

Why it fails: PromQL evaluates operators by precedence and left-associativity, not right-to-left; right-to-left ordering applies to nothing in standard arithmetic expressions here. It is tempting because some languages evaluate assignment or exponentiation right-associatively, but PromQL's arithmetic follows conventional precedence rules.

Addition has higher precedence than multiplication.

Why it fails: Multiplication outranks addition in PromQL, matching standard arithmetic, so addition never binds first. It is tempting because addition is written first in many expressions, but precedence is determined by operator type, not by textual position within the query.

http_requests_total{environment=~"^((?!production).)*$"}

Why it fails: Prometheus selectors match label values literally and do not evaluate regex lookaheads, so this pattern matches nothing rather than every non-production series. It is tempting because negative-lookahead regex is a familiar trick from general-purpose regex engines, and the anchored form looks like a valid way to exclude a substring.

http_requests_total{environment!~"production"}

Why it fails: The !~ operator matches series whose label value does not match the regex, but it also excludes series lacking the environment label entirely, so absent labels are dropped. It is tempting because it reads as a direct negation, yet the correct answer pairs !~ with an explicit empty-string alternative.

http_requests_total{environment!^"production"}

Why it fails: The syntax !^ does not exist in PromQL.