Master LF PCA: Your Gateway to Prometheus Excellence

Correct : A

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.

Verified from Prometheus documentation -- Configuration File Reference, Rule Evaluation and Recording Rules sections.

Correct : D

Prometheus metric naming best practices require that every metric name include a unit suffix that indicates the measurement type, where applicable. The unit should follow the base name, separated by an underscore, and must use base SI units (for example, _seconds, _bytes, _total, etc.).

In the case of http_requests_total, while the metric correctly includes the _total suffix---indicating it is a counter---it lacks a base unit of measurement (such as time, bytes, or duration). However, for event counters, _total is itself considered the unit, representing ''total occurrences'' of an event. Thus, the naming would be acceptable in strict Prometheus terms, but if this metric were measuring something like duration, size, or latency, then including a specific unit would be mandatory.

However, since the question implies that the missing unit is the issue and not the label schema, the expected answer aligns with ensuring metric names convey measurable units when applicable.

Prometheus documentation -- Metric and Label Naming Conventions, Instrumentation Best Practices, and Metric Type Naming (Counters, Gauges, and Units) sections.

Correct : A

Following Prometheus's metric naming conventions, every metric should indicate:

What it measures (the quantity or event).

The unit of measurement in base SI units as a suffix.

Since the metric measures response size, the base unit is bytes. Therefore, the correct and compliant metric name is:

grpc_response_size_bytes

This clearly communicates that it measures gRPC response payload sizes expressed in bytes.

The _bytes suffix is the Prometheus-recommended unit indicator for data sizes. The other options violate naming rules:

_total is reserved for counters.

_sum is used internally by histograms or summaries.

Omitting the unit (grpc_response_size) is discouraged, as it reduces clarity.

Extracted and verified from Prometheus documentation -- Metric Naming Conventions, Instrumentation Best Practices, and Standard Units for Size and Time Measurements.

Correct : D

According to Prometheus metric naming conventions, a metric name must clearly describe what is being measured and include a unit suffix that specifies the base unit of measurement, following SI standards. For durations, the suffix _seconds is mandatory.

Therefore, the correct and standards-compliant name for a metric tracking HTTP request duration is:

http_request_duration_seconds

This name communicates:

http_request the subject being measured (HTTP requests),

duration the aspect being measured (the latency or time taken),

_seconds the unit of measurement (seconds).

This metric name typically corresponds to a histogram or summary, exposing submetrics such as _count, _sum, and _bucket. These represent the number of observations, total duration, and distribution across time buckets respectively.

Options A, B, and C fail to fully comply with Prometheus naming standards --- they either omit the http_ prefix, use invalid separators (dots), or lack the required unit suffix.

Verified from Prometheus documentation -- Metric and Label Naming Conventions, Instrumentation Best Practices, and Histogram and Summary Metric Naming Patterns.

Correct : A

The correct way to expose a timestamp from an application in Prometheus is to use a gauge metric where the timestamp value (in Unix time, seconds since epoch) is stored as the metric's value. This approach aligns with the Prometheus data model, which discourages embedding timestamps as labels or metadata.

Example:

app_last_successful_backup_timestamp_seconds 1.696358e+09

In this example, the gauge represents the timestamp of the last successful backup. The _seconds suffix indicates the unit of measurement, making the metric self-descriptive. Prometheus automatically assigns timestamps to scraped samples, so the metric's value is treated purely as data, not as a Prometheus sample time.

Options B and D are incorrect because Prometheus does not allow arbitrary timestamps or labels for time values. Option C is incorrect since counters are monotonically increasing and not suited for discrete timestamp values.

Verified from Prometheus documentation -- Instrumentation Best Practices (Exposing Timestamps), Gauge Metric Semantics, and Metric Naming Conventions -- _seconds suffix.