Consigna y contexto
Un servicio está adoptando OpenTelemetry y el equipo desea incluir userid, requestid y URLs completas como atributos de métricas. Diseña un presupuesto de cardinalidad, explica qué se conserva, qué ocurre al alcanzar el límite y cómo demuestras que las alertas siguen siendo útiles.
Las métricas de OpenTelemetry crean series temporales a partir de combinaciones de atributos. Un límite de cardinalidad del SDK es un tope estricto en los puntos métricos rastreados para una métrica durante un ciclo de recolección. Los campos de alta cardinalidad multiplican los costos de memoria, exportación, almacenamiento y consulta, por lo que un presupuesto debe proteger tanto el costo como el valor de diagnóstico.
Qué evalúa el entrevistador
El entrevistador está evaluando si separas las dimensiones de métricas, registros y trazas, entiendes las combinaciones en lugar de los conteos de campos individuales, diseñas límites estrictos y degradación, y haces operativas las restricciones de grafos de servicios, alertas, muestreo y privacidad.
Preguntas para clarificar
Confirma el propósito de las métricas, la ventana de consulta, la latencia de las alertas, la cantidad de inquilinos, la cantidad de endpoints, el intervalo de recolección, la retención en el backend y el presupuesto. Pregunta si ya existen campos de correlación de trazas o registros, qué campos de identidad son sensibles a la privacidad y si el límite debería favorecer valores nuevos, valores antiguos o la precisión agregada.
Respuesta de 30 segundos
“Definiría las dimensiones permitidas según el propósito de la métrica en lugar de colocar todo el contexto en las métricas. Mantendría campos estables y de baja cardinalidad que respalden alertas agrupadas, como service, region, plantilla de ruta y clase de estado; colocaría userid, requestid y URLs sin procesar en trazas o registros. Establecería un límite de cardinalidad, una alerta de costos y una señal de saturación por métrica, con una política explícita de agregación o descarte. Finalmente, reproduciría tráfico histórico para medir la recuperación de alertas, falsos positivos, costo de consulta y privacidad.”
Respuesta detallada
Paso 1: Definir la pregunta de la métrica
Escribe la pregunta: ¿Está aumentando la tasa de errores, qué ruta se ve afectada, qué región está degradada o qué sucedió en una solicitud de usuario específica? Los primeros casos se ajustan a las métricas; el último pertenece a trazas o registros.
Paso 2: Estimar la cardinalidad de las combinaciones
La cardinalidad es el conjunto único de combinaciones de atributos, no la suma de valores de cada campo. Estima el producto de service, region, plantilla de ruta, estado, método y nivel de inquilino, y luego corrígelo con distribuciones reales, colas largas y ráfagas.
Paso 3: Estratificar los campos
Conserva campos estables y agregables; coloca usuarios, solicitudes y URLs completas en trazas o registros. Para identificadores de inquilinos de alta cardinalidad, utiliza agrupación en contenedores (bucketing), hashing o muestreo solo cuando las necesidades de control de acceso e investigación sigan satisfechas. Nunca crees series sin límites a partir de parámetros de ruta sin procesar.
Paso 4: Configurar presupuestos en el SDK y el backend
Establece presupuestos en el SDK, el Collector, el backend de series temporales y la capa de consultas en lugar de truncar únicamente al final. El límite de cardinalidad de métricas de OpenTelemetry es un tope estricto, y el conjunto de atributos retenidos debe ser observable en la implementación y en las alertas.
Paso 5: Definir el comportamiento en el límite
Especifica qué combinaciones sobreviven, si se utiliza un contenedor de desbordamiento (overflow bucket), si se descartan nuevos conjuntos y cómo se contabiliza la decisión. La política debe ser estable y explicable, con una señal de saturación; la pérdida silenciosa no es aceptable.
Paso 6: Colocar la correlación en la señal correcta
Utiliza traceid para una solicitud, registros para una URL sin procesar o userid, y ejemplares (exemplars) o enlaces para saltar de una métrica a una muestra. Las métricas proporcionan tendencias y alertas; no reemplazan el diagnóstico por solicitud.
Paso 7: Presupuestar grafos de servicios y costos
Los grafos de servicios y la autoinstrumentación pueden crear muchas familias de métricas. Establece presupuestos separados para aristas, clientes, servidores y estados de error, y controla la frecuencia de exportación, la retención y los atributos de alta cardinalidad. Atribuye los informes de costos a servicios y métricas en lugar de observar únicamente el total.
Paso 8: Validar la calidad de las alertas y la privacidad
Reproduce tráfico e inyecta fallas para comparar la recuperación, los falsos positivos, la latencia y el costo de consulta con y sin el presupuesto. Verifica la ofuscación de datos, el control de acceso, las solicitudes de eliminación y el aislamiento de inquilinos, y haz que la saturación, los cambios de configuración y la pérdida de datos sean rastreables.
Respuesta modelo
Separaría las alertas de tendencias de la investigación de solicitudes individuales. Service, region, plantilla de ruta, método y clase de estado suelen ser atributos de métricas estables y de baja cardinalidad; userid, requestid y URLs parametrizadas pertenecen a trazas, registros y ejemplares. Estimaría el producto de las combinaciones de atributos y lo corregiría con el tráfico de cola larga, para luego configurar presupuestos de cardinalidad y costos en el SDK, el Collector y el backend. Al alcanzar el límite, utilizaría una política explícita de desbordamiento o descarte y registraría la saturación en lugar de fallar silenciosamente. Presupuestaría las aristas del grafo de servicios, clientes y estados de error de forma independiente, controlando la recolección y la retención. Antes del lanzamiento, reproduciría tráfico e inyectaría casos de alta cardinalidad y fallas, comparando la recuperación de alertas, falsos positivos, costo de consulta, privacidad y aislamiento de inquilinos.
Errores comunes
Contar cada campo de forma independiente
Las series provienen de combinaciones. Varios campos de cardinalidad media pueden multiplicarse en una explosión, por lo que se deben estimar combinaciones, colas largas y ráfagas.
Incluir user_id en cada métrica
La investigación a nivel de usuario pertenece a trazas y registros. Las dimensiones de identidad en las métricas añaden costos, riesgos de privacidad y ruido en las consultas.
Descartar datos silenciosamente al alcanzar el límite
La pérdida silenciosa hace que las alertas parezcan saludables. Registra la saturación, las reglas de retención y la versión de configuración, y luego prueba el diagnóstico degradado.
Preguntas de seguimiento y respuestas
¿En qué deben diferenciarse las plantillas de rutas de las URLs completas?
Las métricas utilizan plantillas de rutas normalizadas para que los parámetros de ruta no creen nuevas series. Las URLs completas van a registros o trazas controlados con ofuscación por privacidad.
¿Debería un límite preservar conjuntos de atributos antiguos o nuevos?
Depende de la alerta y del agregador, pero la regla debe ser fija, explicable y observable. Cuenta el desbordamiento para que las instancias no se comporten de manera inconsistente.
¿Cómo correlacionas métricas, trazas y registros?
Utiliza traceid, spanid o ejemplares para vincular muestras. Mantén dimensiones estables en las métricas, contexto de solicitud en registros y trazas, y aplica el límite de acceso al navegar.
¿Por qué necesita un grafo de servicios su propio presupuesto?
Las aristas, clientes y dimensiones de error generados automáticamente multiplican las series. Divide el presupuesto por tipo de arista, frecuencia de recolección y retención para que el grafo no desplace a las métricas de negocio.
¿Cómo demuestras que el presupuesto no está ocultando fallas?
Reproduce tráfico real e inyecta alta cardinalidad, picos de errores y colas largas de inquilinos. Compara la recuperación, falsos positivos, latencia y resultados de consultas antes y después del presupuesto mientras observas los eventos de saturación.
¿Cuándo deberías agregar registros en lugar de métricas?
Cuando la pregunta requiera una solicitud individual, entrada sin procesar o contexto de usuario, utiliza registros o trazas controlados. Las métricas deben contener tendencias agregables y dimensiones de alerta.