Consigna y contexto
Los equipos utilizan diferentes bibliotecas y agentes de logging, con niveles que van desde TRACE y DEBUG hasta CRITICAL. Explica cómo mapearlos a SeverityNumber y SeverityText de OpenTelemetry, preservar la información de origen y gestionar excepciones, muestreo, consultas y migración de versiones.
Qué está evaluando el entrevistador
- Distinguir entre el SeverityNumber estandarizado, el SeverityText de origen y el cuerpo del log.
- Comprender que los rangos numéricos expresan severidad y que los niveles con el mismo nombre no necesariamente tienen significados idénticos entre sistemas.
- Combinar eventos de excepción, atributos de recursos, correlación de traza/span y transformaciones del collector.
- Considerar niveles desconocidos, sesgo de muestreo, compatibilidad de consultas, umbrales de alerta y validación mediante reproducción (replay).
Preguntas de clarificación que debes hacer
- ¿Qué significa el nivel de cada fuente, qué rango numérico utiliza y define niveles personalizados?
- ¿Se debe conservar la cadena del nivel original, la biblioteca de logging y la versión? ¿Qué campos utilizan las consultas posteriores?
- ¿Una excepción es un evento independiente o texto plano en el cuerpo, y debería vincularse a una traza, span o ID de solicitud?
- ¿El mapeo cambiará las alertas, el muestreo, el costo de almacenamiento o el cumplimiento de retención? ¿Cómo se reproducirán los logs históricos?
Una respuesta de 30 segundos
Construiría un diccionario semántico para cada fuente y luego mapearía los significados a un rango de SeverityNumber de OpenTelemetry, preservando el SeverityText original y los metadatos de la fuente. Las excepciones utilizan la semántica de excepciones estándar y la correlación de traza/span; un stack trace no debe meterse a la fuerza en el campo de nivel. El collector transforma y valida los registros, mientras que los niveles desconocidos siguen una ruta de respaldo observable. Antes del despliegue, reproduciría muestras representativas y de fallos para verificar umbrales de alertas, muestreo, consultas y costos, en lugar de redefinir silenciosamente todo el historial.
Análisis paso a paso
1. Definir los campos estándar
El OpenTelemetry Logs Data Model separa SeverityNumber y SeverityText. Number permite comparaciones dentro del modelo; Text conserva el nombre original o mostrado por el emisor. El cuerpo, los atributos, los recursos y las marcas de tiempo transportan otras semánticas. La tabla de mapeo debe registrar la fuente, el nivel original, el rango de destino y la justificación en lugar de ocultar todo en el código de conversión.
2. Mapear las fuentes a rangos semánticos
WARN, ERROR o FATAL pueden desencadenar diferentes acciones operativas en diferentes frameworks. Mapea según el significado a un rango, conserva un nivel no confirmado como indefinido o de baja confianza y coloca el valor original en SeverityText o en un atributo controlado. No compares números en bruto entre sistemas hasta que se verifiquen la documentación y las muestras de cada fuente.
3. Manejar excepciones y correlación
La semántica de excepciones de OpenTelemetry recomienda campos para el tipo de excepción, el mensaje y el stack trace, eligiendo la severidad según si la excepción causa o no una falla en la aplicación. Los logs deben llevar trace ID, span ID, servicio y versión de despliegue para que las consultas puedan distinguir los registros que pertenecen a una sola solicitud. Los stack traces son datos de diagnóstico y requieren los mismos controles de datos confidenciales y retención que los demás logs.
4. Validar la ingesta, alertas y migración
Realiza el mapeo, la validación de campos y la conversión de compatibilidad en el Collector o en un agente perimetral, registrando los valores inválidos y los motivos de descarte. Reproduce muestras históricas y fallas sintéticas para verificar umbrales de alertas, muestreo, resultados de consultas y costos de almacenamiento. Durante las actualizaciones, mantén una versión de mapeo y los campos de origen para que los consumidores puedan interpretar el historial por versión en lugar de alterar silenciosamente el significado de las alertas.
Respuesta modelo
Crearía mapeos semánticos documentados para Java, Python, Nginx y otras fuentes, apuntando a SeverityNumber de OpenTelemetry y reteniendo los nombres originales en SeverityText y atributos controlados. Los números se comparan únicamente dentro del mismo modelo; los niveles desconocidos o personalizados siguen una ruta de baja confianza con una alerta. Las excepciones utilizan los campos de excepción de OpenTelemetry y se vinculan a la traza/span y a la versión del servicio. El Collector se encarga de la transformación, la validación y las métricas. Se reproducen muestras históricas y de fallas para probar alertas, muestreo, consultas y costos. Las versiones de mapeo y los campos de origen permanecen disponibles para fines de auditabilidad.
Errores comunes
- Mapear ERROR, WARN o FATAL de cada fuente de manera unívoca (1:1) sin comprobar su semántica.
- Conservar solo SeverityNumber y descartar el nivel original y la versión de la fuente.
- Colocar los datos de la excepción en el cuerpo del log, haciendo que los stack traces sean difíciles de consultar o inseguros de retener.
- Omitir la correlación de traza/span y perder el contexto a nivel de solicitud.
- Descartar silenciosamente los mapeos fallidos o forzarlos a INFO sin generar métricas ni alertas.
- Recalcular alertas históricas después de un cambio de mapeo sin un registro de versión o de reproducción.
Preguntas de seguimiento y respuestas
¿Qué número debería utilizar un nivel desconocido?
Conserva el texto original y márcalo como desconocido o de baja confianza en lugar de forzarlo a ERROR. Si se requiere un ordenamiento comercial o de negocio, define un rango predeterminado documentado, registra la versión del mapeo, monitorea la proporción de desconocidos y corrige la semántica de la fuente.
¿Puede el muestreo cambiar la distribución de severidad?
Sí. Prioriza los registros severos y los eventos de excepción, registra la decisión de muestreo y el denominador de entrada, y compara las distribuciones antes y después del muestreo. Los recuentos muestreados no deben presentarse como la tasa de error real sin ese contexto.
¿Cómo mantienes compatibles las consultas antiguas?
Mantén los campos de origen y los alias antiguos en la capa de conversión de forma temporal, y expón vistas o funciones de consulta versionadas. Durante la migración, realiza escritura dual (dual-write) o reproduce alertas e informes hasta que se comprendan las diferencias, y luego retira los campos antiguos.