What should you do with counters that have labels?

Initializing a counter with all its potential label values to zero is a crucial best practice. When a metric with a specific label set has not yet been incremented, it is not exposed by the client library. This can cause a time series to appear suddenly, leading to incorrect calculations by functions like rate() and increase(), which rely on the continuous existence of a series to work correctly. By instantiating all possible label combinations with a zero value upon application startup, you ensure that the time series exists from the beginning, which leads to more predictable and accurate alerting and graphing.

A. This is an anti-pattern. Putting label values in the metric name makes aggregation and querying difficult, defeating the purpose of Prometheus's dimensional data model.
B. This is unnecessary and inefficient. Prometheus's query language, PromQL, is designed to perform aggregation on the fly (e.g., using sum()), making pre-aggregated metrics redundant.
D. This is an anti-pattern. Counters are expected to reset to zero on application restart. PromQL functions like rate() and increase() are specifically designed to handle these resets automatically.

1. For Correct Answer (C):

Prometheus Authors. (n.d.). Writing Exporters - Best practices. Prometheus Documentation. Retrieved from https://prometheus.io/docs/instrumenting/writingexporters/#best-practices

Reference Section: In the "Things to watch out for" subsection, the documentation states, "It is better to expose a 0 than to have a metric that appears and disappears, as the latter is harder to work with." This supports initializing metrics so they are always present.

2. For Incorrect Option (A):

Prometheus Authors. (n.d.). Metric and label naming. Prometheus Documentation. Retrieved from https://prometheus.io/docs/practices/naming/#metric-and-label-naming

Reference Section: The documentation explicitly advises, "Do not put label names in the metric name, as this introduces redundancy and will be confusing if the respective labels are aggregated away."

3. For Incorrect Option (B):

Prometheus Authors. (n.d.). When to use the Pushgateway. Prometheus Documentation. Retrieved from https://prometheus.io/docs/practices/pushing/#when-to-use-the-pushgateway

Reference Section: While discussing aggregation, the documentation notes, "Aggregation should generally be done in the Prometheus server." This principle applies broadly, discouraging pre-aggregation at the client level.

4. For Incorrect Option (D):

Prometheus Authors. (n.d.). Metric types - Counter. Prometheus Documentation. Retrieved from https://prometheus.io/docs/concepts/metrictypes/#counter

Reference Section: The documentation explains, "The rate() function automatically adjusts for counter resets." This confirms that resets are an expected behavior that the system is designed to handle, making state persistence unnecessary and incorrect.