What's "wrong" with the myapp_filG_uploads_total{userid=,,5123",status="failed"} metric?

The primary issue with the metric myappfilGuploadstotal{userid=,,5123",status="failed"} is the use of userid as a label. User IDs are considered high-cardinality labels because they can have a vast and unbounded number of unique values (one for each user). In Prometheus, every unique combination of a metric name and its labels creates a new time series. Using high-cardinality labels like userid leads to a "cardinality explosion," which drastically increases memory consumption, storage requirements, and query latency on the Prometheus server, potentially making it unstable. Best practices strongly advise against using identifiers with high or unbounded cardinality as labels.

B. The status label is appropriate. It has low cardinality (a small, finite set of values like "success" or "failed"), which is ideal for filtering and aggregation.

C. The total suffix is a standard and recommended naming convention for counter metrics in Prometheus, clearly indicating that the metric is a cumulative count.

D. Prometheus naming conventions require underscores () as separators in metric names. Dashes (-) are invalid characters for metric names and are treated as operators in PromQL.

1. Prometheus Official Documentation, Best Practices, "Metric and label naming":

CAUTION: Remember that every unique combination of key-value label pairs represents a new time series, which can dramatically increase the amount of data stored. Do not use labels to store dimensions with high cardinality (many different label values), such as user IDs, email addresses, or other unbounded sets of values.

(Source: Prometheus Authors, "Metric and label naming," Prometheus Documentation. Accessed from: https://prometheus.io/docs/practices/naming/)

2. Prometheus Official Documentation, Concepts, "Data model":

Metric names may contain ASCII letters and digits, as well as underscores and colons. It must match the regex [a-zA-Z:][a-zA-Z0-9:].

This confirms that dashes are not permitted in metric names.

(Source: Prometheus Authors, "Data model," Prometheus Documentation. Accessed from: https://prometheus.io/docs/concepts/datamodel/#metric-names-and-labels)

3. Borg, Omega, and Kubernetes: Lessons learned from three container-management systems (Academic Publication): While discussing monitoring in large-scale systems, the principles of avoiding high-cardinality dimensions are foundational. The paper notes the importance of aggregation: "Most metrics are aggregated... losing per-task details." This aligns with the principle of not using per-instance identifiers like userid as labels.

(Source: Verma, A., Pedrosa, L., et al. (2015). Borg, Omega, and Kubernetes. ACM Queue, 13(7), Section: "Monitoring". DOI: https://doi.org/10.1145/2898442.2898444)