Cómo limitar la cardinalidad de las etiquetas en las métricas de una automatización

Diseña un vocabulario cerrado antes de instrumentar

Empieza por la pregunta que debe responder el panel. Para contar fallos por etapa basta una etapa acordada y un resultado como completado, rechazado o error. Un mensaje de excepción completo no es un resultado acotado: puede incorporar rutas, referencias y fragmentos del dato que cambian en cada ejecución. Traduce los errores a categorías mantenidas y conserva una categoría desconocida que puedas revisar sin crear una etiqueta nueva por cada texto.

Prometheus advierte que cada combinación de etiquetas identifica otra serie y desaconseja dimensiones sin límite, como correos o identificadores de usuario. En un ejemplo hipotético, tres procesos, cuatro etapas y dos resultados permiten hasta 24 combinaciones de esas dimensiones para una métrica. Es una estimación del diseño, no el total de series del sistema: añade las dimensiones reales de instancia y entorno, y considera cómo exporta cada tipo de instrumento. No conviertas 24 ni otra cifra de ejemplo en un presupuesto universal.

Pon el detalle individual en el canal apropiado

La referencia de una ejecución puede ser útil en un registro o una traza con acceso restringido. No la copies como etiqueta ordinaria de todos los contadores para poder buscar un caso desde un gráfico. Tampoco añadas una etiqueta distinta por cliente sin evaluar cuántos valores habrá, cómo crecerán y si esa separación es realmente necesaria para operar el servicio.

Cambiar un correo por su hash no acota la cardinalidad: sigues teniendo potencialmente un valor por correo distinto. Además, OpenTelemetry advierte que aplicar hash no garantiza la anonimización. Conserva únicamente el detalle individual necesario, con acceso y retención acordados; trasladarlo a logs no autoriza recopilarlo todo. Inspecciona la telemetría exportada para buscar valores sensibles que añadan las bibliotecas, incluidos mensajes y URL completas. Una lista permitida de atributos ayuda, pero debes comprobar dónde actúa en tu cadena para no enviar el dato antes de filtrarlo.

Ensaya crecimiento, capacidad y pérdida de desglose

Ejecuta dos cargas de prueba con los mismos procesos y resultados: una pequeña y otra con muchas referencias sintéticas diferentes. Si esas referencias no son etiquetas, su diversidad no debería crear una serie nueva por referencia. Cuenta las series observadas por métrica y compara las etiquetas exportadas; mide también memoria del productor, volumen exportado y tiempo de las consultas operativas. Separa las diferencias causadas por nuevas instancias o por la propia infraestructura.

Acuerda un presupuesto a partir de esa carga, la capacidad disponible y los límites del destino. OpenTelemetry especifica límites de cardinalidad y una agregación de desbordamiento; comprueba qué admite tu SDK y cómo lo exporta. Ese mecanismo puede perder el desglose de las combinaciones agrupadas y no sustituye un diseño acotado. Su límite por ciclo de colección tampoco equivale a un límite global del almacén con múltiples procesos y tiempo de retención.

Prueba un valor de resultado desconocido y, en un ensayo aislado, el comportamiento al alcanzar el límite configurado. Revisa que el panel no interprete el desbordamiento como ausencia de fallos. Guarda etiquetas permitidas, capacidad observada y criterio de parada; cualquier nueva dimensión debe repetir esta evaluación antes de activarse.

Fuentes y documentación

• Prometheus — Metric and label naming — Cada combinación de etiquetas forma otra serie; advierte contra IDs de usuario, correos y otros valores sin límite.
• OpenTelemetry — Metrics SDK, cardinality limits — Define límites por ciclo de colección, filtrado de atributos y agregación de desbordamiento; debe comprobarse la implementación utilizada.
• OpenTelemetry — Handling sensitive data — Recomienda minimización de telemetría y explica límites del hash para anonimizar datos.