サンプル問題 1： What does scrape_interval configure in Prometheus?
A: It defines how frequently to scrape targets.
B: It defines how frequently to evaluate rules.
C: It defines how often to send alerts.
D: It defines how often to refresh metrics.
正解：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 C scrape_interval and Scraping Fundamentals sections.
サンプル問題 2： What is a difference between a counter and a gauge?
A: Counters change value on each scrape and gauges remain static.
B: Counters and gauges are different names for the same thing.
C: Counters have no labels while gauges can have many labels.
D: Counters are only incremented, while gauges can go up and down.
正解：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 C Metric Types section explaining Counters and Gauges definitions and usage examples.
サンプル問題 3： What's "wrong" with the myapp_filG_uploads_total{userid=,,5123",status="failed"} metric?
A: The userid should not be exposed as a label.
B: The status should not be exposed as a label.
C: The _total suffix should be omitted.
D: The metric name should consist of dashes instead of underscores.
正解：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 C Metric and Label Naming Best Practices and Writing Exporters.
