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

In Prometheus best practices,high-cardinality labels—especially those containing unique or user-specific identifiers—should beavoided. 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 tocardinality explosion, degraded performance, and high memory usage.

The _total suffix is actuallycorrect and requiredfor 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”).