Select Two (Multi-Select) Questions

Matrix

Why it fails: Matrix is a PromQL expression result type, not a metric type; Prometheus stores counters, gauges, histograms and summaries. It is tempting because range vectors are written with a matrix-like [1h] suffix, but that syntax denotes a query result shape, not an instrumented metric kind.

Vector

Why it fails: Vector is a PromQL expression result type, not a metric type; native metric types are counter, gauge, histogram and summary. It is tempting because instant queries return vectors, but that describes query output shape rather than how a metric is instrumented and exposed.

Scalar

Why it fails: Scalar is a PromQL expression result type, not a metric type; Prometheus instruments counters, gauges, histograms and summaries. It is tempting because numeric literals and scalar() results appear in queries, but scalars are computed values, not metric kinds exposed by instrumented targets.

Using a deployment name label.

Why it fails: A deployment name label carries a bounded set of values per workload, so it contributes low cardinality rather than high. It is tempting because deployment labels are standard practice for slicing metrics by application version, which is correct when you need per-deployment breakdowns, but that granularity stays small.

Using a cluster region label.

Why it fails: A cluster region label has only a handful of possible values, so it cannot drive high cardinality. It is tempting because region labels are legitimate for aggregating metrics across geographically distributed clusters, which is the right choice when you need per-region dashboards rather than per-object series.

Using a service name label.

Why it fails: A service name label is bounded by the number of services, typically dozens, so it produces low cardinality. It is tempting because service labels are the standard way to attribute metrics to a logical service, which is correct when you need per-service request rates rather than per-pod or per-container series.

It is a drop-in for standard scraping

Why it fails: Pushgateway is a staging buffer for batch jobs, not a drop-in replacement for scraping; it accepts pushes and exposes them for Prometheus to scrape, but does not perform service discovery or target scraping itself. It tempts because it does expose a /metrics endpoint.

It stores metrics persistently

Why it fails: Pushgateway holds pushed metrics in memory and on disk only until Prometheus scrapes them; it is not a durable time-series store. It tempts because it does persist across restarts, but that persistence is a staging buffer, not long-term storage like the TSDB.

It automatically expires metrics

Why it fails: Pushgateway retains pushed metrics indefinitely; expiry is not a feature it provides, so stale values persist until manually deleted. It is tempting because it exists to let short-lived batch jobs expose metrics for scraping, a scenario where automatic expiry would genuinely help.

>>

Why it fails: Label matchers require =, !=, =~ or !~ between the label name and value; '>>' is not a PromQL operator at all. It tempts as a plausible-looking comparison token, and would be right only if PromQL supported greater-than matching, which it does not.

==

Why it fails: '==' is not a valid matcher operator; equality matching uses a single '=' (for example job="api"). It tempts because '==' is standard equality syntax in most programming languages, so it would be correct if PromQL reused that convention rather than its own matcher grammar.

receiver

Why it fails: receiver is an Alertmanager configuration field, not a Prometheus alerting rule component; rule files define groups containing alert, expr, for, labels, and annotations. It is tempting because receivers determine where notifications are delivered, but that routing logic lives in Alertmanager, not in the rule file itself.

routing_tree

Why it fails: routing_tree is not a Prometheus alerting rule field; routing is configured in Alertmanager, not in rule files. It is tempting because alert routing is a real concept, but it belongs to Alertmanager's route configuration, whereas rule files contain groups, alert, expr, for, labels, and annotations.

median

Why it fails: PromQL has no median aggregation operator; quantile(0.5, ...) approximates it instead. It is tempting because median is a standard statistical aggregate and quantile exists, so users assume a direct median function, but only avg, sum, min, max, count, stddev, stdvar, topk, bottomk, count_values and quantile are valid.

average

Why it fails: PromQL spells the mean aggregation as avg; average is not a function, so queries using it fail to parse. It is tempting because averaging is a genuine aggregation concept and the word appears in documentation prose, but the correct operator name is avg, alongside sum, min, max and count.

Subqueries execute faster than standard instant queries because they bypass the storage engine.

Why it fails: Subqueries are evaluated by the PromQL engine over the storage engine's returned samples, adding an inner range-vector evaluation layer rather than bypassing storage. It is tempting because subqueries nest a range selector inside an instant query, which superficially suggests a shortcut around normal sample retrieval.

Subqueries can only be executed against range vectors, never instant vectors.

Why it fails: Subqueries return instant vectors, which is precisely why they exist: wrapping a range vector expression so its result can feed functions expecting instant vectors. It is tempting because the inner expression must be a range vector, so the syntax visually resembles range-vector-only evaluation.

The resolution parameter in a subquery is mandatory.

Why it fails: The resolution parameter is optional; when omitted, Prometheus defaults it to the global evaluation_interval. It is tempting because resolution appears prominently in subquery syntax and controls step alignment, so it reads as a required argument rather than an overridable default.

Adding authentication to metrics

Why it fails: Recording rules precompute PromQL expressions into new time series; they do not sit in the scrape or query path and cannot add authentication to metrics. Authentication is handled by the exporter or a reverse proxy, so this describes a security concern outside the rule-evaluation engine entirely.

Automatically increasing retention

Why it fails: Recording rules only evaluate expressions and write the resulting series; retention is governed by the storage layer's retention settings, not by rules. It is tempting because recording rules do create new stored series, but their lifetime is set by Prometheus retention flags, not by the rule itself.

Providing UI for alerts

Why it fails: Alertmanager provides the UI.

The ?= operator performs fuzzy string matching.

Why it fails: PromQL defines only =, !=, =~ and !~ as label matchers; no ?= operator exists, so this syntax is invalid. It is tempting because fuzzy or substring matching feels useful for loosely related label values, but regex matching via =~ already covers that need.

The =~ operator is used exclusively for numeric comparisons.

Why it fails: =~ performs regex matching against label values, not numeric comparison; numbers are compared with arithmetic and comparison operators outside selectors. It is tempting because regex syntax superficially resembles comparison symbols, but label matchers filter series, they do not evaluate numeric thresholds.

The == operator is valid inside label selectors for filtering.

Why it fails: Label selectors accept only =, !=, =~ and !~; == is not valid matcher syntax and causes a parse error. It is tempting because == is the equality operator in PromQL expressions and many programming languages, but inside curly braces the single = form is required.

Always set alert thresholds to zero.

Why it fails: A zero threshold fires on every observed value, producing constant alert noise and destroying signal value. Thresholds must reflect meaningful deviation from a baseline. Zeroing is tempting as a catch-all safety net, but a threshold set just above the normal operating band is the correct approach for genuine anomaly detection.

Use metrics for everything.

Why it fails: Collecting metrics for everything generates cardinality and storage cost without the traces and logs needed to explain failures, so it cannot answer why a request broke. It tempts because metrics are cheap to aggregate and good for dashboards, but it would be correct when tracking aggregate trends and alerting on thresholds.

alertmanager_host

Why it fails: alertmanager_host is a per-rule setting configured inside individual alerting rule files, not globally. It is tempting because Alertmanager endpoints are cluster-wide infrastructure, so administrators expect one global declaration; however, global configuration covers only fields such as smtp_smarthost and evaluation_interval.

storage_path

Why it fails: storage_path is a command-line flag passed at Prometheus startup, not a field in the global configuration block. It is tempting because it applies to the whole server rather than one rule, but global configuration accepts only scrape and evaluation defaults, not filesystem paths.

target_labels

Why it fails: target_labels is a field of a service discovery configuration, applied per scrape job, not a global setting. It is tempting because labels attached to every target feel cluster-wide, yet global configuration holds only fields like scrape_interval, evaluation_interval and external_labels.

group

Why it fails: group is not part of the default Prometheus ecosystem label set; those are job, instance, and (for some targets) exported labels. It tempts because grouping appears in alerting and recording rules, but that is a rule-evaluation concept, not a label attached to scraped metrics.

owner

Why it fails: owner is not a default Prometheus ecosystem label; the standard trio is job, instance, and the metric's own name. It tempts because ownership metadata is common in Kubernetes and cloud exports, but Prometheus itself does not attach it during scraping.

muted

Why it fails: Prometheus alert states are inactive, pending, and firing; muted is an Alertmanager silence concept, suppressing notifications without altering the alert's state in Prometheus. It tempts because silences do mute notifications, which is correct when you need to suppress noisy alerts during maintenance windows.

sleeping

Why it fails: Prometheus alert states are inactive, pending, and firing; sleeping is not one. It tempts because it sounds like the inactive state, but inactive means the expression returns no result, whereas sleeping is not a defined Prometheus term at all.

Log Exporter

Why it fails: Prometheus exporters surface metrics, not log streams; log shipping is handled by agents such as Promtail, Fluent Bit or Filebeat. It is tempting because logs and metrics are both telemetry, and a log exporter would be the right component when forwarding application log lines into a log aggregation platform.

Push Exporter

Why it fails: Prometheus exporters are pull-based: they expose metrics on an HTTP endpoint that the server scrapes. No push exporter type exists in that taxonomy. It is tempting because Pushgateway genuinely accepts pushed metrics from short-lived batch jobs, but that is a gateway, not an exporter category.

Trace Exporter

Why it fails: Prometheus exporters expose numeric time-series metrics; tracing uses separate instrumentation and backends such as Jaeger or Tempo. It is tempting because observability telemetry is often grouped together, and a trace exporter would be correct when shipping distributed span data to a tracing backend rather than scraping metrics.

scrape_configs

Why it fails: scrape_configs belongs to the Prometheus server configuration, not Alertmanager, which uses route, receivers, inhibit_rules and similar blocks. It is tempting because scrape_configs is a familiar top-level key, but Alertmanager never scrapes targets; Prometheus forwards alerts to it.

targets

Why it fails: Alertmanager's config blocks are route, receivers, inhibit_rules, and templates; targets belongs to Prometheus scrape_configs, not Alertmanager. It tempts because static_configs and targets define scrape endpoints, which is the correct choice when configuring Prometheus to discover and poll exporters.

rules

Why it fails: Alertmanager has no rules block; alerting and recording rules live in Prometheus rule_files, evaluated by the Prometheus server. It tempts because rules is genuinely correct when defining alert expressions and thresholds that Prometheus then forwards to Alertmanager for routing and notification.

Disk Space

Why it fails: Disk space is a resource-saturation metric, not one of the Four Golden Signals: latency, traffic, errors and saturation. It is tempting because capacity monitoring genuinely predicts outages and features in host-based dashboards, but saturation as a golden signal measures the constrained resource's utilisation, not raw free space.

Up-time

Why it fails: Up-time is an availability outcome, not a golden signal; the four are latency, traffic, errors and saturation. It is tempting because availability is what users notice and SLAs promise, so it appears on every dashboard — but the golden signals are the leading indicators that explain why availability degrades.

Histogram matrix

Why it fails: PromQL returns only instant vectors, range vectors, scalars and strings; histogram matrices are not a query return type, though native histograms appear as histogram samples inside vectors. It tempts because range vectors over histogram series resemble a matrix, and such data is genuinely queried in histogram_quantile workflows.

Log stream

Why it fails: PromQL operates solely on instant vectors, range vectors, scalars and strings; log streams belong to LogQL in Loki. A log stream is a labelled sequence of log lines, not a query result type, so it cannot be returned by any PromQL expression.

Distributed trace

Why it fails: Distributed traces are stored and queried by tracing backends such as Tempo or Jaeger, not by PromQL, which returns only vectors, scalars and strings. It tempts because exemplars link Prometheus metrics to trace IDs, making traces appear queryable through PromQL when they are merely referenced.

List

Why it fails: Prometheus supports four data types — instant vector, range vector, scalar and string — with no list type. It is tempting because lists appear in many programming languages and configuration structures, but PromQL's type system does not include them.

Set

Why it fails: Prometheus's four data types are instant vector, range vector, scalar and string; set is not among them. It is tempting because set operations appear in some query languages and label matching, but PromQL defines no set data type.

Boolean

Why it fails: Prometheus sample values are exclusively float64; there is no boolean metric type. Booleans are tempting because many monitoring systems expose up/down or healthy flags, and in Prometheus those are represented as 0 or 1 gauge values instead.

It uses a B-tree for all queries.

Why it fails: Prometheus queries resolve label matchers through inverted indexes and posting-list intersections, then scan chunks; B-trees underpin relational range lookups, not PromQL series selection. A B-tree would be the right structure for ordered key lookups in a general-purpose database, which is not this workload.

It is a relational database.

Why it fails: Prometheus TSDB is a custom append-only time-series store with per-block indexes and label-based posting lists, not a relational engine with schemas, SQL or joins. Relational databases suit structured transactional workloads; PromQL range queries over high-cardinality metrics require the inverted-index design Prometheus implements instead.

As a browser extension

Why it fails: Prometheus is a standalone server binary that scrapes and stores metrics; it cannot execute inside a browser extension's sandbox. It is tempting because browser-based dashboards exist, but those only visualise data queried from a running Prometheus server, not run Prometheus itself.

As a database engine library

Why it fails: Prometheus runs as a server process with its own TSDB, not as an embeddable database engine library invoked by applications. It is tempting because its storage layer resembles a database, but valid deployment modes are the binary, containers, or orchestrated pods, not a linked library.

As a kernel module

Why it fails: Prometheus is a userspace server process and cannot load as a kernel module. It is tempting because kernel modules can expose metrics, but Prometheus itself runs as a normal binary or container; node_exporter, not Prometheus, is what typically surfaces kernel-level metrics.