Prometheus Certified Associate (PCA, CNCF/Linux Foundation) (PCA) (PCA) — Questions 226–265

Labelling a counter by 'user_id' creates one time series per distinct user, so cardinality scales with your user base. Prometheus holds every active series in memory, and each unique label combination multiplies storage and index overhead, exhausting RAM and degrading queries. This directly satisfies the stem's operational risk: unbounded cardinality from a high-churn identifier.

Retaining logs gives responders the granular, timestamped detail needed to reconstruct an incident's sequence and root cause. This satisfies the requirement for recommended observability practise by ensuring sufficient telemetry depth exists before an incident occurs, enabling precise analysis instead of relying on aggregated metrics alone.

High-cardinality labels, such as unique user IDs or timestamps, create unbounded time series that inflate storage costs and slow PromQL queries. The stem asks what to avoid, and this directly violates the cardinality constraint that keeps custom metrics performant and cost-effective in Prometheus.

Gauge is a valid Prometheus metric type representing a value that can rise or fall arbitrarily, such as temperature or memory usage. It is one of the four core types alongside counter, histogram and summary, and supports functions like delta() and predict_linear().

Recording rules precompute the expensive PromQL expression and persist the result as a new time series, so dashboards read a cheap, already-aggregated metric instead of re-evaluating the complex query on every refresh, directly cutting dashboard query latency.

scrape_interval is set in the global block of the Prometheus configuration file, establishing the default collection frequency for every scrape job. Individual jobs may override it, but the global value applies cluster-wide unless explicitly superseded.

Prometheus service discovery queries platform APIs to automatically detect scrape targets as containers and instances appear or disappear, so configuration stays accurate without manual edits. This satisfies the stem's dynamic-environment requirement, where static target lists become stale immediately after scaling events.

Traces record the full path of a single request as it crosses service boundaries, capturing per-span timing, parent-child relationships and errors. This satisfies the stem's distinction from metrics, which are aggregated numeric measurements over time rather than individual request lifecycles.

A Counter only increases (or resets to zero on restart), making it the natural fit for a cumulative total of requests received. PromQL rate() and increase() then derive request rates from this monotonically increasing series.

Pushgateway stores pushed metrics in a keyed grouping identified by job and instance labels. Pushing a metric with an identical name and label set replaces the previously stored value for that key rather than appending a new series.

A custom HTTP exporter pushes metrics or traces directly to a collector endpoint over HTTP, satisfying the requirement for a valid instrumentation approach. Unlike agents or auto-instrumentation libraries, it gives explicit control over payload format and destination, letting applications emit telemetry without depending on vendor-specific SDKs.

Exponentiation (^) binds tighter than multiplication, division, addition and subtraction, and also tighter than comparison and logical operators, so it evaluates first in any PromQL expression. This right-associative operator sits at the top of the precedence table.

A recording rule precomputes the rate expression and stores the result as a new time series, so dashboards read a small precalculated series instead of evaluating the full underlying expression at render time. This reduces query latency on dashboards, satisfying the stated preference.

Node_exporter listens on TCP port 9100 by default, exposing Prometheus-format metrics at the /metrics endpoint. This satisfies the stem's requirement for the standard default port without any command-line override, so scrapes configured against port 9100 succeed immediately after installation.

The `route` block defines Alertmanager's routing tree, matching alerts to receivers by label. It satisfies the requirement to direct Slack notifications, since child routes inherit and override parent settings, with `receiver: slack` specified at the appropriate node. Without `route`, no alert reaches the Slack receiver.

PromQL parses metric names as identifiers, so characters such as hyphens or spaces would break query syntax. Restricting names to alphanumerics, underscores and colons keeps them valid tokens, letting the expression engine resolve selectors without quoting or escaping.

keep_firing_for holds an alert in firing state for a set duration after its condition stops being true, preventing rapid transitions between firing and resolved. This directly addresses flapping, which the stem identifies as the concern.

Prometheus reads its main configuration from a YAML file, conventionally `prometheus.yml`, parsed at startup and on reload. This satisfies the stem's requirement for the native format of the primary config file, where scrape jobs, rule files and service discovery targets are declared.

A counter is monotonically increasing, so each received request increments it and never resets except on process restart. This satisfies the stem's request-counting requirement, letting rate() or increase() derive requests per second across any window.

A range selector returns a range vector: every sample value with its timestamp falling inside the specified window, rather than a single instant value. Applying [5m] to a gauge therefore yields all points from the preceding five minutes.

The le label is attached by Prometheus when recording histogram buckets, encoding each bucket's upper bound. It forms part of the default ecosystem label set alongside job and instance, so it satisfies the stem's requirement for a standard ecosystem label.

The `on(...)` modifier restricts matching to the labels you list, so vectors with differing label sets still pair up on that shared subset. Without it, Prometheus requires identical label sets for vector-to-vector binary operations, returning no results. This directly satisfies the stem's constraint of matching on common labels only.

The 'description' annotation is used to provide details about the alert.

An alert enters the inactive state when its expression evaluates to false, meaning no alert instance exists for that series. This satisfies the stem's requirement for a genuine Prometheus alert state, alongside pending and firing, as defined by the Prometheus alerting lifecycle.

The `for` field sets a pending duration, during which the alert must remain continuously firing before Alertmanager receives it. Configuring `for: 5m` satisfies the stem's requirement to delay notification until the condition has persisted five minutes, filtering transient spikes that would otherwise trigger premature alerts.

Metrics are numeric time-series suited to aggregation and rate calculations, so request rate per second is computed cheaply and stored at low cardinality. Logs would require parsing each entry to derive the same count, making metrics the efficient choice for this high-volume, continuously changing measurement.

The `!~` operator is a valid PromQL label matcher, selecting time series whose label value does not match a given regular expression. It satisfies the stem's requirement by providing the negated regex-matching axis, complementing `=~`, `!=` and `=` as the fourth supported matcher type.

A Silence matches alerts by label set and suppresses notifications for a defined time window, which maps directly onto a scheduled maintenance period. Unlike inhibition, which depends on another firing alert, a Silence is time-bounded and configured in advance, satisfying the maintenance-window constraint.

Prometheus TSDB persists time-series samples in immutable `chunks` segment files, which hold compressed sample data for a fixed time window before being compacted. This satisfies the stem's requirement for a valid TSDB file type, since chunks are written directly by the head block and queried during reads.

Prometheus synthesises the up metric per scrape target, recording 1 when the scrape succeeds and 0 when it fails. It therefore reports reachability of each configured target, satisfying the stem's requirement to detect whether a target can be scraped.

A recording rule referencing a non-existent metric produces no output series, because the expression evaluates against an empty vector and yields nothing. This satisfies the stem's impact directly: no data is written, so dependent dashboards and alerts querying that recorded series return empty results rather than errors.

The resolution parameter sets the step interval at which the inner range-vector expression is evaluated across the subquery's window, producing a series that the outer max_over_time() then aggregates over. It is not the lookback delta nor the outer range.

Prometheus scrapes metrics endpoints expecting the Prometheus Text Format, a line-based exposition syntax of metric name, optional labels and a sample value. A custom exporter emitting JSON, CSV or XML cannot be parsed by the scrape pipeline, so the text format satisfies the stem's scraping requirement.

route is a top-level Alertmanager block defining the routing tree that matches alerts by label and dispatches them to child routes or receivers. It is required for alert delivery, making it a valid configuration block.

Alertmanager receives alerts pushed from Prometheus and handles deduplication, grouping, silencing and routing to receivers such as email or Slack. It satisfies the stem's routing requirement, sitting downstream of Prometheus rather than performing the metric evaluation itself.

If node_exporter is not running or bound to a different interface, Prometheus scrapes will fail silently, so confirming the listener and port reachability isolates the fault before investigating scrape configuration or firewall rules. This directly tests the stem's missing-metrics symptom at its source.

absent() returns an empty vector when the given instant vector has samples, and returns a single-element vector with value 1 when the selector matches nothing, letting alerting rules fire on missing metrics such as a target that stopped reporting.

Prometheus TSDB maintains an inverted index mapping label pairs to posting lists of series IDs, enabling rapid label-based lookups without scanning every series. This satisfies the requirement for fast searching across high-cardinality metrics, as queries resolve matching series directly from the index before reading chunks.

Running Prometheus as a container satisfies the portability constraint, packaging the server and its dependencies into a single image deployable via Docker or Kubernetes. Configuration and time-series data persist through mounted volumes, so the TSDB survives restarts. This decouples Prometheus from the host, enabling consistent deployment across environments.

Both functions return per-second rates, but the axis of difference is the sample window: rate() divides the counter increase across the whole range vector, smoothing spikes, whereas irate() uses only the final two samples, giving the instantaneous rate.