How many metric types does Prometheus text format support?
B
Explanation:
Prometheus defines four core metric types in its official exposition format, which are: Counter,
Gauge, Histogram, and Summary. These types represent the fundamental building blocks for
expressing quantitative measurements of system performance, behavior, and state.
A Counter is a cumulative metric that only increases (e.g., number of requests served).
A Gauge represents a value that can go up and down, such as memory usage or temperature.
A Histogram samples observations (e.g., request durations) and counts them in configurable buckets,
providing both counts and sum of observed values.
A Summary is similar to a histogram but provides quantile estimation over a sliding time window
along with count and sum metrics.
These four types are the only officially supported metric types in the Prometheus text exposition
format as defined by the Prometheus data model. Any additional metrics or custom naming
conventions are built on top of these core types but do not constitute new types.
Reference:
Extracted and verified from Prometheus official documentation sections on Metric Types and
Exposition Formats in the Prometheus study materials.
What does scrape_interval configure in Prometheus?
A
Explanation:
In Prometheus, the scrape_interval parameter specifies how frequently the Prometheus server
should scrape metrics from its configured targets. Each target exposes an HTTP endpoint (usually
/metrics) that Prometheus collects data from at a fixed cadence. By default, the scrape_interval is set
to 1 minute, but it can be overridden globally or per job configuration in the Prometheus YAML
configuration file.
This setting directly affects the resolution of collected time series data—a shorter interval increases
data granularity but also adds network and storage overhead, while a longer interval reduces load
but might miss short-lived metric variations.
It is important to distinguish scrape_interval from evaluation_interval, which defines how often
Prometheus evaluates recording and alerting rules. Thus, scrape_interval pertains only to data
collection frequency, not to alerting or rule evaluation.
Reference:
Extracted and verified from Prometheus documentation on Configuration File – scrape_interval and
Scraping Fundamentals sections.
What is a difference between a counter and a gauge?
D
Explanation:
The key difference between a counter and a gauge in Prometheus lies in how their values change
over time. A counter is a cumulative metric that only increases—it resets to zero only when the
process restarts. Counters are typically used for metrics like total requests served, bytes processed,
or errors encountered. You can derive rates of change from counters using functions like rate() or
increase() in PromQL.
A gauge, on the other hand, represents a metric that can go up and down. It measures values that
fluctuate, such as CPU usage, memory consumption, temperature, or active session counts. Gauges
provide a snapshot of current state rather than a cumulative total.
This distinction ensures proper interpretation of time-series trends and prevents misrepresentation
of one-time or fluctuating values as cumulative metrics.
Reference:
Extracted and verified from Prometheus official documentation – Metric Types section explaining
Counters and Gauges definitions and usage examples.
What's "wrong" with the myapp_filG_uploads_total{userid=,,5123",status="failed"} metric?
A
Explanation:
In Prometheus best practices, high-cardinality labels—especially those containing unique or user-
specific identifiers—should be avoided. The metric
myapp_filG_uploads_total{userid="5123",status="failed"} exposes the userid as a label, which is
problematic. Each distinct value of a label generates a new time series in Prometheus. If there are
thousands or millions of unique users, this would exponentially increase the number of time series,
leading to cardinality explosion, degraded performance, and high memory usage.
The _total suffix is actually correct and required for counters, as per the Prometheus naming
convention. The use of underscores in metric names is also correct, as Prometheus does not support
dashes in metric identifiers. The status label, however, is perfectly valid because it typically has a low
number of possible values (e.g., “success”, “failed”).
Reference:
Verified from Prometheus official documentation sections Instrumentation – Metric and Label
Naming Best Practices and Writing Exporters.
Which exporter would be best suited for basic HTTP probing?
B
Explanation:
The Blackbox Exporter is the Prometheus component designed specifically for probing endpoints
over various network protocols, including HTTP, HTTPS, TCP, ICMP, and DNS. It acts as a generic probe
service, allowing Prometheus to test endpoints' availability, latency, and correctness without
requiring instrumentation in the target application itself.
For basic HTTP probing, the Blackbox Exporter performs HTTP GET or POST requests to defined URLs
and exposes metrics like probe success, latency, response code, and SSL certificate validity. This
makes it ideal for uptime and availability monitoring.
By contrast, the JMX exporter is used for collecting metrics from Java applications, the Apache
exporter for Apache HTTP Server metrics, and the SNMP exporter for network devices. Thus, only the
Blackbox Exporter serves the purpose of HTTP probing.
Reference:
Verified from Prometheus documentation – Blackbox Exporter Overview and Exporter Usage
Guidelines.
How can you send metrics from your Prometheus setup to a remote system, e.g., for long-term
storage?
B
Explanation:
Prometheus provides a feature called Remote Write to transmit scraped and processed metrics to an
external system for long-term storage, aggregation, or advanced analytics. When configured,
Prometheus continuously pushes time series data to the remote endpoint defined in the
remote_write section of the configuration file.
This mechanism is often used to integrate with long-term data storage backends such as Cortex,
Thanos, Mimir, or InfluxDB, enabling durable retention and global query capabilities beyond
Prometheus’s local time series database limits.
In contrast, “scraping” refers to data collection from targets, while “federation” allows hierarchical
Prometheus setups (pulling metrics from other Prometheus instances) but does not serve as long-
term storage. Using “S3 Buckets” directly is also unsupported in native Prometheus configurations.
Reference:
Extracted and verified from Prometheus documentation – Remote Write/Read APIs and Long-Term
Storage Integrations sections.
What is api_http_requests_total in the following metric?
api_http_requests_total{method="POST", handler="/messages"}
C
Explanation:
In Prometheus, the part before the curly braces {} represents the metric name. Therefore, in the
metric api_http_requests_total{method="POST", handler="/messages"}, the term
api_http_requests_total is the metric name. Metric names describe the specific quantity being
measured — in this example, the total number of HTTP requests received by an API.
The portion within the braces defines labels, which provide additional dimensions to the metric.
Here, method="POST" and handler="/messages" are labels describing request attributes. The metric
name should follow Prometheus conventions: lowercase letters, numbers, and underscores only, and
ending in _total for counters.
This naming scheme ensures clarity and standardization across instrumented applications. The
metric type (e.g., counter, gauge) is declared separately in the exposition format, not within the
metric name itself.
Reference:
Verified from Prometheus documentation – Metric and Label Naming, Data Model, and
Instrumentation Best Practices sections.
Which of the following is a valid metric name?
C
Explanation:
According to Prometheus naming rules, metric names must match the regex [a-zA-Z_:][a-zA-Z0-9_:]*.
This means metric names must begin with a letter, underscore, or colon, and can only contain letters,
digits, and underscores thereafter.
The valid metric name among the options is go_goroutines, which follows all these rules. It starts
with a letter (g), uses underscores to separate words, and contains only allowed characters.
By contrast:
go routines is invalid because it contains a space.
go.goroutines is invalid because it contains a dot (.), which is reserved for recording rule naming
hierarchies, not metric identifiers.
99_goroutines is invalid because metric names cannot start with a number.
Following these conventions ensures compatibility with PromQL syntax and Prometheus’ internal
data model.
Reference:
Extracted from Prometheus documentation – Metric Naming Conventions and Data Model Rules
sections.
What is an example of a single-target exporter?
A
Explanation:
A single-target exporter in Prometheus is designed to expose metrics for a specific service instance
rather than multiple dynamic endpoints. The Redis Exporter is a prime example — it connects to one
Redis server instance and exports its metrics (like memory usage, keyspace hits, or command
statistics) to Prometheus.
By contrast, exporters like the SNMP Exporter and Blackbox Exporter can probe multiple targets
dynamically, making them multi-target exporters. The Node Exporter, while often deployed per host,
is considered a host-level exporter, not a true single-target one in configuration behavior.
The Redis Exporter is instrumented specifically for a single Redis endpoint per configuration, aligning
it with Prometheus’s single-target exporter definition. This design simplifies monitoring and avoids
dynamic reconfiguration.
Reference:
Verified from Prometheus documentation and official exporter guidelines – Writing Exporters,
Exporter Types, and Redis Exporter Overview sections.
How do you configure the rule evaluation interval in Prometheus?
A
Explanation:
Prometheus evaluates alerting and recording rules at a regular cadence determined by the
evaluation_interval setting. This can be defined globally in the main Prometheus configuration file
(prometheus.yml) under the global: section or overridden for specific rule groups in the rule
configuration files.
The global evaluation_interval specifies how frequently Prometheus should execute all configured
rules, while rule-specific intervals can fine-tune evaluation frequency for individual groups. For
instance:
global:
evaluation_interval: 30s
This means Prometheus evaluates rules every 30 seconds unless a rule file specifies otherwise.
This parameter is distinct from scrape_interval, which governs metric collection frequency from
targets. It has no relation to TSDB, service discovery, or command-line flags.
Reference:
Verified from Prometheus documentation – Configuration File Reference, Rule Evaluation and
Recording Rules sections.
Which of the following metrics is unsuitable for a Prometheus setup?
D
Explanation:
The metric user_last_login_timestamp_seconds{email="[email protected]"} is unsuitable for
Prometheus because it includes a high-cardinality label (email). Each unique email address would
generate a separate time series, potentially numbering in the millions, which severely impacts
Prometheus performance and memory usage.
Prometheus is optimized for low- to medium-cardinality metrics that represent system-wide
behavior rather than per-user data. High-cardinality metrics cause data explosion, complicating
queries and overwhelming the storage engine.
By contrast, the other metrics—prometheus_engine_query_log_enabled,
promhttp_metric_handler_requests_total{code="500"}, and
http_response_total{handler="static/*filepath"}—adhere to Prometheus best practices. They
represent operational or service-level metrics with limited, manageable label value sets.
Reference:
Extracted and verified from Prometheus documentation – Metric and Label Naming Best Practices,
Cardinality Management, and Anti-Patterns for Metric Design sections.
What Prometheus component would you use if targets are running behind a Firewall/NAT?
D
Explanation:
When Prometheus targets are behind firewalls or NAT and cannot be reached directly by the
Prometheus server’s pull mechanism, the recommended component to use is PushProx.
PushProx works by reversing the usual pull model. It consists of a PushProx Proxy (accessible by
Prometheus) and PushProx Clients (running alongside the targets). The clients establish outbound
connections to the proxy, which allows Prometheus to “pull” metrics indirectly. This approach
bypasses network restrictions without compromising the Prometheus data model.
Unlike the Pushgateway (which is used for short-lived batch jobs, not network-isolated targets),
PushProx maintains the Prometheus “pull” semantics while accommodating environments where
direct scraping is impossible.
Reference:
Verified from Prometheus documentation and official PushProx design notes – Monitoring Behind
NAT/Firewall, PushProx Overview, and Architecture and Usage Scenarios sections.
You’d like to monitor a short-lived batch job. What Prometheus component would you use?
B
Explanation:
Prometheus normally operates on a pull-based model, where it scrapes metrics from long-running
targets. However, short-lived batch jobs (such as cron jobs or data processing tasks) often finish
before Prometheus can scrape them. To handle this scenario, Prometheus provides the Pushgateway
component.
The Pushgateway allows ephemeral jobs to push their metrics to an intermediary gateway.
Prometheus then scrapes these metrics from the Pushgateway like any other target. This ensures
short-lived jobs have their metrics preserved even after completion.
The Pushgateway should not be used for continuously running applications because it breaks
Prometheus’s usual target lifecycle semantics. Instead, it is intended solely for transient job metrics,
like backups or CI/CD tasks.
Reference:
Verified from Prometheus documentation – Pushing Metrics – The Pushgateway and Use Cases for
Short-Lived Jobs sections.
How do you calculate the average request duration during the last 5 minutes from a histogram or
summary called http_request_duration_seconds?
A
Explanation:
In Prometheus, histograms and summaries expose metrics with _sum and _count suffixes to
represent total accumulated values and sample counts, respectively. To compute the average request
duration over a given time window (for example, 5 minutes), you divide the rate of increase of _sum
by the rate of increase of _count:
\text{Average duration} =
\frac{\text{rate(http_request_duration_seconds_sum[5m])}}{\text{rate(http_request_duration_seco
nds_count[5m])}}
Here,
http_request_duration_seconds_sum represents the total accumulated request time, and
http_request_duration_seconds_count represents the number of requests observed.
By dividing these rates, you obtain the average request duration per request over the specified time
range.
Reference:
Extracted and verified from Prometheus documentation – Querying Histograms and Summaries,
PromQL Rate Function, and Metric Naming Conventions sections.
If the vector selector foo[5m] contains 1 1 NaN, what would max_over_time(foo[5m]) return?
B
Explanation:
In PromQL, range vector functions like max_over_time() compute an aggregate value (in this case,
the maximum) over all samples within a specified time range. The function ignores NaN (Not-a-
Number) values when computing the result.
Given the range vector foo[5m] containing samples [1, 1, NaN], the maximum value among the valid
numeric samples is 1. Therefore, max_over_time(foo[5m]) returns 1.
Prometheus functions handle missing or invalid data points gracefully—ignoring NaN ensures stable
calculations even when intermittent collection issues or resets occur. The function only errors if the
selector is syntactically invalid or if no numeric samples exist at all.
Reference:
Verified from Prometheus documentation – PromQL Range Vector Functions, Aggregation Over Time
Functions, and Handling NaN Values in PromQL sections.