English

Nunca pongas user_id en una etiqueta de métrica

Una etiqueta de métrica inocente puede multiplicar por 10 tu factura de métricas. El mecanismo tiene nombre: cardinalidad. En una base de datos de series temporales como Prometheus, cada combinación única de valores de etiqueta es una serie temporal distinta — almacenada, indexada y consultada para siempre. Si pones user_id en una métrica, no agregaste una columna; multiplicaste tu cantidad de series por la cantidad de usuarios.

Por qué una sola etiqueta hace estallar tu almacenamiento

Prometheus lo dice sin rodeos: "cada combinación única de pares clave-valor de etiquetas representa una nueva serie temporal, lo que puede aumentar drásticamente la cantidad de datos almacenados." Un solo contador con una etiqueta que toma 50.000 valores son 50.000 series. Agrega una segunda etiqueta sin límite — por ejemplo request_id — y multiplicas, no sumas.

La documentación incluso cuantifica el techo. Una métrica de cuota por usuario en 10.000 nodos y 10.000 usuarios crearía "decenas de millones" de series — "demasiado para la implementación actual de Prometheus." La recomendación: mantén la cardinalidad de una métrica por debajo de 10, y trata cualquier valor superior a 100 como un problema de diseño a corregir.

La regla: las etiquetas son para dimensiones acotadas

Una etiqueta de métrica responde "¿cuál cubeta?" — y el conjunto de cubetas debe ser pequeño, conocido y estable. Si aparecen valores nuevos cada vez que un usuario se registra o llega una petición, la dimensión es no acotada y no debe estar cerca de una métrica.

Fíjate en route, no en la URL cruda: /orders/{id} es un solo valor de etiqueta; /orders/8412, /orders/8413 … son millones. La forma con plantilla es la versión acotada de la misma idea.

A dónde van realmente los IDs de alta cardinalidad

Sigues necesitando detalle por usuario y por petición — solo que no en las métricas. La respuesta de los tres pilares:

• Logs cargan los campos no acotados. Una línea de log es barata de escribir con user_id, request_id y la URL completa; la consultas bajo demanda en vez de indexarla para siempre.
• Traces te dan la vista de una sola petición, con los IDs como atributos de span.
• Exemplars enlazan ambos: una cubeta de métrica puede adjuntar un trace ID de muestra, para saltar de "subió la tasa de 5xx" directo a un trace fallido de ejemplo — sin nunca etiquetar la métrica por petición.

Las métricas te dicen que algo anda mal y cuánto; los logs y traces te dicen qué usuario y por qué.

Movidas avanzadas

• Vigila la cardinalidad antes de que muerda. En Prometheus, topk(20, count by (__name__)({__name__=~".+"})) muestra tus métricas más pesadas; count(count by (label) (metric)) muestra cuántos valores carga una sola etiqueta. Alerta cuando una etiqueta cruce un umbral.
• Aplica plantilla a la ruta al ingerir. Normaliza /orders/8412 → /orders/{id} en tu middleware HTTP antes de que se convierta en etiqueta. La mayoría de los frameworks exponen el patrón de ruta coincidente justo para esto.
• Agrega las dimensiones que no usas. Las recording rules (o Grafana Adaptive Metrics) reducen una serie de alta cardinalidad a las etiquetas que de verdad consultas — Grafana reporta recortes de costo de métricas de ~35% en promedio solo con esto.
• Una etiqueta agregada es para siempre. Quitar una etiqueta después es un cambio disruptivo para cada dashboard y alerta construidos sobre ella. Agrega dimensiones con cautela; es mucho más barato que recuperarlas.

Recursos

• Metric and label naming — Prometheus (la advertencia de cardinalidad)
• Instrumentation: "Do not overuse labels" — Prometheus (cardinalidad por debajo de 10)
• What is high cardinality? — Grafana Labs
• How to manage high cardinality metrics in Prometheus and Kubernetes — Grafana Labs
• View exemplars: enlaza métricas con traces — Grafana