Instrumentation And Exporters practice questions

Gauge

Why it fails: A gauge records an instantaneous value that rises and falls, so it cannot accumulate the count and sum of observations that server-side quantile estimation requires. Gauges suit current values like temperature or queue depth, where no distribution across a window is needed.

Counter

Why it fails: A counter only increases monotonically, so it cannot capture the per-observation values needed to estimate quantiles; it tracks totals such as request counts. Counters are correct for rates and totals, not for the distribution of individual query durations.

Summary

Why it fails: Summaries compute quantiles client-side, making them less ideal for aggregation across instances.

tcp_connect

Why it fails: TCP connect does not validate TLS certificates.

ssl_check

Why it fails: There is no built-in module named ssl_check.

cert_monitor

Why it fails: This is not a standard module.

None of the above

Why it fails: A custom exporter that parses the log file and exposes metrics on an HTTP endpoint is required, so dismissing all options leaves the scenario unsolved. It tempts candidates who believe no Prometheus mechanism can read file-based logs, yet "none of the above" is only right when every listed option genuinely fails.

Use a blackbox exporter

Why it fails: Blackbox exporter probes endpoints over HTTP, DNS, TCP or ICMP from outside, returning synthetic reachability metrics; it cannot parse a log file's contents into application metrics. It is the right choice for measuring external availability and latency of a service, not for extracting counters a legacy application writes only to disk.

Use Pushgateway

Why it fails: Pushgateway accepts pushed metrics from short-lived batch jobs, but the legacy application does not push anything; it only writes a file. It would be correct for a cron job that cannot be scraped, not for extracting metrics from log lines via a parser.

Use a custom exporter

Why it fails: A custom exporter is exactly the mechanism for parsing a file and exposing metrics, so this is the correct answer rather than an incorrect one. It is tempting only because writing a parser seems heavier than reusing an existing exporter, yet no off-the-shelf exporter reads this application's bespoke log format.

_total

Why it fails: _total is a reserved suffix appended automatically to Counter metric names, not a unit suffix; units belong in the metric name itself, such as _seconds, _bytes or _requests. It is tempting because _total appears in nearly every Counter series, making it look like a naming convention rather than a type marker.

_sum

Why it fails: _sum is a generated sample suffix on Summary and Histogram series, not a unit suffix; Prometheus appends it to expose the running total alongside _count. It is tempting because it looks like a naming convention, but it is produced by the client library rather than chosen by the metric author.

_count

Why it fails: _count is a generated sample suffix on Summary and Histogram series, not a unit suffix; Prometheus appends it to expose the observation count. It is tempting because it appears in every histogram series and resembles a deliberate naming convention, but it is emitted automatically rather than authored.

Snapshot

Why it fails: Snapshot is not a standard Prometheus metric type.

Set

Why it fails: Set is not a standard Prometheus metric type.

The total number of instances scraping the metric.

Why it fails: Scraping frequency does not change the internal quantile calculation of a summary.

The CPU architecture of the client host.

Why it fails: CPU architecture does not influence metric accuracy.

The number of buckets defined in the configuration.

Why it fails: Buckets are specific to Histograms, not Summaries.

Prometheus API

Why it fails: The Prometheus API queries already-collected time series; it cannot ingest metrics from a job that has already exited. It is tempting because the API is the standard interface for retrieving Prometheus data, but that role belongs to the Pushgateway, which lets short-lived jobs push metrics before terminating.

Alertmanager

Why it fails: Alertmanager only routes and deduplicates alerts generated from existing Prometheus metrics; it stores no time series and cannot capture a batch job's metrics. It is tempting because it is a core Prometheus component, but the Pushgateway is the component designed for short-lived jobs that finish before scraping.

node_exporter

Why it fails: node_exporter exposes host-level metrics such as CPU and memory for scraping; it does not accept pushed metrics from batch jobs. It is tempting because it is a standard Prometheus exporter, but exporters are scraped, whereas the Pushgateway receives pushed metrics from short-lived jobs that exit before a scrape.

Summary

Why it fails: A Summary records pre-computed quantiles and a _sum/_count pair, not a running tally you increment per request. It is tempting because its _count does increase, but Summary suits latency distribution tracking, whereas a Counter is the correct type for monotonically increasing request totals.

Gauge

Why it fails: A Gauge represents a value that can rise and fall, such as temperature or queue depth, and lacks the monotonic guarantee a request tally needs. It is tempting because gauges can be incremented, but they are correct for current-state measurements rather than cumulative counts.

Histogram

Why it fails: A Histogram buckets observations into ranges and exposes _bucket, _sum and _count, designed for distributions like request duration. It is tempting because _count rises with requests, but Histogram is correct when you need latency percentiles, not a simple running total.

Using static labels

Why it fails: Static labels fix a value at write time, so a metric cannot later distinguish dimensions such as response code or region, defeating the purpose of labels. They are tempting because constant metadata like environment or service name genuinely belongs in a label, but only when that value never varies per data point.

Adding job labels

Why it fails: Job labels are added automatically by Prometheus during scraping, so manually defining them creates duplicate or conflicting label sets that break metric queries. It is tempting because job labels appear in every metric, but they are reserved for scrape configuration, not custom metric definitions.

Adding instance labels

Why it fails: Instance labels attach a unique value per host or process, creating unbounded cardinality that inflates storage and query cost. They are tempting because per-instance attribution is useful for debugging a single node, but that belongs in logs or traces, not in a metric label set.

JSON

Why it fails: Prometheus expects the line-oriented text exposition format, where each metric appears as name{labels} value; generic JSON is not parsed by the scraper. JSON suits API responses or the HTTP SD endpoint, but a custom exporter must render metrics in the text format Prometheus understands.

XML

Why it fails: Prometheus scrapes its text-based exposition format, or Protocol Buffers for efficiency; XML parsing is not implemented by the scrape endpoint. XML is tempting because it is a common structured interchange format, and would suit integrations with SOAP APIs or configuration files, but it cannot satisfy the scrape contract.

Binary Protobuf

Why it fails: Prometheus scrapes its plain-text exposition format over HTTP; binary Protobuf is not parsed by the scrape loop and is used only in the remote-write protocol for pushing samples. A custom exporter must emit text/plain metrics with HELP and TYPE lines, not serialised binary payloads.

dns_query

Why it fails: DNS query probes resolve names against a server and return record data, never issuing an HTTP request, so no status code exists to check. It is tempting for validating resolution and record correctness, but the stem requires inspecting the HTTP response itself.

tcp_connect

Why it fails: A TCP connect probe only completes the three-way handshake, confirming the port is listening without sending an HTTP request, so no status code is returned. It suits simple port-availability checks, but the stem needs the HTTP response code, which requires an http module.

icmp_ping

Why it fails: ICMP echo probes test reachability and round-trip latency, never parsing HTTP responses, so no status code is ever observed. It is tempting because ping-style checks suit host liveness monitoring where only reachability matters, but the stem requires inspecting the HTTP reply itself.

Counter

Why it fails: Counter only ever increases or resets, so it cannot report a fluctuating value like current memory usage; it is designed for cumulative counts such as requests or errors. Gauges capture an instantaneous measurement, making them correct here. The developer needs a snapshot, not an accumulating total.

Summary

Why it fails: Summary aggregates observations over a time window and reports count and sum, so it cannot represent an instantaneous gauge such as current memory usage. It suits request counts or latency totals, where pre-aggregated quantiles and totals are wanted. A gauge is required here, since memory rises and falls and must be sampled at a point in time.

Histogram

Why it fails: A histogram aggregates many observations into configurable buckets, so it cannot report a single instantaneous value such as current memory usage; the stem requires a gauge, which holds one current reading that can rise or fall. Histograms suit distributions, for example request-duration percentiles, where you deliberately record repeated measurements over time.

mysqld_exporter

Why it fails: mysqld_exporter exposes MySQL server statistics such as connections, queries and replication lag. It reads no /proc or /sys data, so CPU, memory and filesystem metrics are absent; node_exporter is the exporter that collects those host hardware and OS metrics.

blackbox_exporter

Why it fails: blackbox_exporter probes endpoints externally, measuring reachability, latency and certificate expiry over HTTP, TCP, ICMP or DNS. It reports on the target from outside rather than reading local /proc and /sys counters, so it cannot expose the server's own CPU usage; node_exporter does that.

pushgateway

Why it fails: pushgateway accepts metrics pushed by short-lived batch jobs that Prometheus cannot scrape before they exit. It stores whatever is pushed and collects nothing itself, so it exposes no CPU or OS counters; node_exporter is the agent that reads those from the host.

9115

Why it fails: Port 9115 belongs to the Blackbox exporter, which probes endpoints externally rather than exposing host metrics. node_exporter listens on 9100, so scraping 9115 would return probe results or nothing. It is tempting because both are Prometheus exporters with similar default port ranges.

9090

Why it fails: Port 9090 is Prometheus's own web interface and API port, not an exporter's. node_exporter defaults to 9100, so scraping 9090 would query Prometheus itself. It is tempting because 9090 is the most familiar Prometheus port and is often seen in configuration examples.

8080

Why it fails: Port 8080 is a generic HTTP alternative used by many web applications and some exporters, but node_exporter defaults to 9100. Scraping 8080 would hit whatever else listens there. It is tempting because 8080 is a common fallback for web services when 80 is unavailable.

collector.textfile=false

Why it fails: node_exporter reads collector toggles from command-line flags, not from a collector.textfile=false configuration key. The form is tempting because it resembles Prometheus configuration syntax, but it would be correct only for a component that parses key-value config files, which node_exporter does not.

exclude=textfile

Why it fails: node_exporter has no exclude flag; collectors are toggled with --no-collector.<name> or --collector.<name>. The exclude= form resembles Prometheus scrape config or blackbox exporter syntax, which is why it tempts. Filtering scraped metrics happens in relabel_configs, not in the exporter's own command line.

--disable-textfile

Why it fails: The flag syntax requires --no-collector.<name>.

prometheus.Enable()

Why it fails: No prometheus.Enable() function exists in the client_golang library, so the call fails to compile. It is tempting because enabling sounds like setup, but the correct registration path is prometheus.MustRegister() or prometheus.NewRegistry(), which actually adds collectors to the default registry.

prometheus.Set()

Why it fails: prometheus.Set() is not part of the client_golang API, so the code will not compile. It is tempting because Set() exists on Gauge and other metric objects for assigning values, but registration itself is performed by prometheus.MustRegister(), not a package-level Set function.

prometheus.Add()

Why it fails: prometheus.Add() does not exist in the Go client library; metrics are registered via prometheus.MustRegister() or promauto constructors, which bind the collector to the default registry. The name resembles generic instrumentation APIs, so it tempts those expecting a simple add call, but no such function is exported.

None

Why it fails: Histogram buckets are cumulative: every bucket whose upper bound is greater than or equal to the observed value is incremented. With 0.7 seconds, the 1 and 5 buckets both increase, so at least two buckets change and none is a valid answer.

0.1, 0.5

Why it fails: Cumulative buckets increment whenever the upper bound is greater than or equal to the observation. A 0.7-second request exceeds 0.1 and 0.5, so those two buckets stay unchanged; the 1 and 5 buckets are the ones that increment.

Only 1

Why it fails: Histogram buckets are cumulative upper bounds, so 0.7 falls into every bucket whose bound is at least 0.7, incrementing 1, 5 and the +Inf bucket, not only 1. Incrementing only 1 would be correct if buckets were exclusive ranges rather than Prometheus-style cumulative counters.

It improves performance

Why it fails: Client-side quantiles cannot be aggregated across instances, and Summary metrics expose them without server-side computation, so performance is not improved. It is tempting because Summary metrics do reduce server-side quantile calculation, which is correct when you need pre-computed quantiles per instance without aggregation.

It allows cross-instance aggregation

Why it fails: Client-side quantiles are computed per instance and exported as pre-aggregated values, so summing or averaging them across instances produces statistically meaningless results; the Summary type cannot be aggregated server-side. It is tempting because aggregation works for Counter and Gauge metrics, and Summary's quantile output superficially resembles a numeric sample.

It doubles the scrape time

Why it fails: Scrape duration depends on the exporter's response time and the number of series returned, not on the metric type; Summary quantiles are computed in the client during collection, adding negligible overhead. It is tempting because client-side quantile calculation does consume CPU on the instrumented application, which can slow the exporter's own request handling.

Writing to a file

Why it fails: Writing metrics to a file gives Prometheus nothing to scrape; the textfile collector expects that format only via node_exporter. Custom exporters expose metrics over HTTP, typically by starting an HTTP server and returning the Prometheus text format on /metrics, which is the standard integration path.

Using a message queue

Why it fails: A message queue decouples producers from consumers but does not expose metrics for Prometheus to scrape, so no HTTP endpoint or text exposition format exists for collection. Queues suit asynchronous buffering between services, such as streaming events to a remote sink, not the pull-based scraping model that custom Python exporters must implement.

Using a database connection

Why it fails: A database connection cannot expose metrics for scraping; Prometheus exporters must serve an HTTP endpoint returning text in the exposition format. Databases suit long-term metric storage, queried by Grafana or PromQL, so this would fit a persistence layer behind the exporter rather than the exposure mechanism itself.

Latency estimate

Why it fails: The 'le' label means 'less than or equal to' and holds each bucket's upper inclusive bound, not a latency estimate. A latency estimate would come from histogram_quantile() over the bucket counters, which is the query you would use when you actually need a percentile value.

Logarithmic exponent

Why it fails: 'le' denotes 'less than or equal to', the cumulative bucket boundary, not a logarithmic exponent. Prometheus histograms use linear or custom bucket boundaries; exponential bucketing appears in native histograms, which is the scenario where an exponent-style boundary would be relevant.

Last entry

Why it fails: 'le' abbreviates 'less than or equal to', marking each bucket's inclusive upper bound, not the last entry. The final bucket is the +Inf one, which captures all remaining observations; 'last entry' describes no Prometheus label semantics at all.