Consigna y alcance
Una empresa emite registros de texto de aplicaciones, stdout de contenedores y eventos JSON legacy con diferentes nombres de campos, precisión temporal y convenciones de severidad. Desea adoptar el OpenTelemetry Logs Data Model preservando las búsquedas históricas y evitando enlaces de TraceId engañosos. Diseña un plan de backfill offline junto con una escritura dual (dual-write) en tiempo real.
OpenTelemetry separa Timestamp, ObservedTimestamp, TraceId, SpanId, SeverityNumber, Body, Resource y Attributes. La migración es un contrato de datos trazable, no una decisión de colocar cada línea dentro de Body. Una respuesta sólida gestiona fallos del analizador (parser), zonas horarias, duplicados, campos sensibles y marcas de agua de reproducción.
Qué evalúa el entrevistador
- Distinguir el tiempo del evento, el tiempo de observación, los atributos de recursos y los atributos de eventos.
- Diseñar mapeos de esquemas, versiones, retención de campos desconocidos y rutas para fallos de análisis sintáctico.
- Preservar la veracidad y opcionalidad de TraceId, SpanId e identificadores de solicitud.
- Gestionar el aislamiento de inquilinos, la ofuscación, los duplicados, el reordenamiento y el costo del backfill.
- Proponer compuertas de calidad reproducibles y reconciliables en lugar de simplemente nombrar una herramienta ETL.
Preguntas para clarificar
- ¿Las marcas de tiempo legacy son locales, UTC o mixtas, y tienen precisión de milisegundos o nanosegundos?
- ¿Qué fuentes tienen esquemas estables y cuáles requieren expresiones regulares o análisis basado en muestras?
- ¿TraceId, SpanId y los ID de solicitud son producidos por las aplicaciones o inferidos por los recolectores?
- ¿Se deben retener las cargas útiles (payloads) sin procesar, por cuánto tiempo y quién puede leerlas?
- ¿El backfill y la escritura dual comparten almacenamiento e índices, y cuánta divergencia en las consultas es aceptable?
Respuesta en 30 segundos
Crearía contratos de mapeo versionados y conservaría los payloads sin procesar con su estado de análisis. Timestamp es el tiempo del evento y ObservedTimestamp es el tiempo de observación; Resource almacena hechos estables del origen como servicio, host e inquilino, Attributes almacena campos del evento y Body mantiene el contenido estructurado del negocio. Poblaría TraceId y SpanId únicamente a partir de contexto de confianza. El backfill se ejecuta junto con la escritura dual, la reconciliación utiliza particiones de origen y tiempo, y los fallos van a colas de mensajes no entregados (dead letters) reproducibles. Las compuertas cubren el éxito del análisis, la completitud de campos, el desfase temporal, los duplicados, las coincidencias de ofuscación y la equivalencia de consultas.
Solución paso a paso
1. Fijar primero el contrato de datos
Define la versión del analizador, campos obligatorios, valores predeterminados y la política de campos desconocidos para cada fuente. Genera un ID de evento estable y registra la fuente, el offset de archivo o la posición del mensaje. Los campos desconocidos pueden permanecer en Attributes o en el payload sin procesar, pero no deben desaparecer en silencio; los cambios semánticos requieren un incremento en la versión del mapeo.
{
"timestamp": "2026-08-02T02:00:00.123Z",
"observedTimestamp": "2026-08-02T02:00:00.800Z",
"severityNumber": 17,
"severityText": "ERROR",
"body": {"message": "payment declined", "code": "CARD_DECLINED"},
"resource": {"service.name": "checkout", "tenant.id": "t-7"},
"attributes": {"region": "us-east-1"}
}2. Preservar la semántica del tiempo
Normaliza las marcas de tiempo con información de zona horaria y conserva la cadena original y el estado del análisis. Timestamp es cuando ocurrió el evento; ObservedTimestamp es cuando el recolector lo observó. Si falta el tiempo del evento, usa el tiempo de observación únicamente como una alternativa explícita (fallback) y márcalo, para que la demora de recolección no se confunda con la latencia del negocio. Valida tiempos futuros, antigüedad excesiva y truncamiento de precisión.
3. Mapear Resource, Attributes y Body
Resource describe la entidad que produce los registros, como servicio, versión, host, clúster e inquilino. Attributes describe una instancia del evento, como región, tipo de solicitud o grupo de experimento. Body contiene contenido estructurado o un mensaje no analizado. Ubicar mal los campos cambia la agregación, la indexación y los costos, por lo que los mapeos deben registrar los motivos y los consumidores posteriores.
4. Mapear severidad y contexto
Mapea los niveles numéricos y legacy WARN y ERR a SeverityNumber mientras conservas el SeverityText original. Acepta TraceId, SpanId y TraceFlags solo cuando el formato y el punto de inyección sean de confianza. Mantén el contexto faltante vacío con un motivo; nunca inventes un ID de traza. Un ID de solicitud puede ser un Attribute ordinario, pero no debe presentarse como TraceId.
5. Diseñar la escritura dual y el backfill
La ruta en tiempo real escribe en el almacenamiento antiguo y en el nuevo con el mismo ID de evento. La ruta offline segmenta archivos, particiones o posiciones de mensajes y registra puntos de control (checkpoints). Ambas rutas comparten analizadores y reglas de ofuscación, pero pueden usar diferentes tamaños de lote. Después del backfill, reconcilia por fuente, ventana temporal e ID de evento, y luego traslada gradualmente las consultas al nuevo modelo.
6. Gestionar fallos, duplicados y reordenamiento
Escribe los fallos de análisis en dead letters que contengan los datos sin procesar, el código de error y la versión del analizador; reprodúcelos desde un punto de control después de aplicar una corrección. Deduplica con el ID de evento más la posición de origen y el hash del contenido. No reescribas el tiempo del evento porque los registros lleguen fuera de orden; permite que los índices soporten el tiempo de evento y el de observación por separado. Si la identidad es incierta, márcala en lugar de sobrescribir silenciosamente.
7. Aislamiento, ofuscación y costos
Obtén el ID de inquilino de un atributo de Resource confiable, no de una entrada arbitraria del cliente. Ofusca secretos, tokens y datos personales antes de la persistencia, registrando la versión de ofuscación y la cantidad de coincidencias. Cifra los payloads sin procesar por separado con acceso restringido y retención más corta. Presupuesta los índices para Attributes de alta cardinalidad para que un modelo normalizado no genere costos descontrolados.
8. Compuertas de calidad y reversión (rollback)
Muestrea consultas antiguas y nuevas y compara el recuento de eventos, la distribución de severidad, el desfase temporal y los campos críticos. Establece compuertas sobre el éxito del análisis, la completitud de campos obligatorios, duplicados, desfase temporal, omisiones de ofuscación y equivalencia de consultas. Mantén las escrituras antiguas durante la fase canary; ante desviación de campos o fuga entre inquilinos, detén las escrituras nuevas y redirige las consultas hacia atrás usando puntos de control sin eliminar datos sin procesar reproducibles.
Ejemplo de respuesta sólida
Separaría la migración en contrato, análisis, escritura dual, backfill, reconciliación y transición (cutover). Cada fuente recibe un analizador versionado y un ID de evento estable. Timestamp es el tiempo del evento y ObservedTimestamp es el tiempo de recolección. Resource almacena hechos estables de servicio, host e inquilino; Attributes almacena campos del evento; Body mantiene el contenido estructurado; SeverityNumber mapea niveles antiguos; TraceId se acepta solo desde un contexto de confianza.
Durante la fase activa, los almacenes antiguos y nuevos reciben los mismos eventos. El backfill se ejecuta por posición y los fallos van a dead letters con datos sin procesar y códigos de error. Reconcilia por ID de evento y posición mientras rastreas tasas de reordenamiento y duplicados. Ofusca antes de persistir y aísla los payloads sin procesar. Haz pruebas canary sobre recuentos de eventos, completitud, desfase temporal y resultados de consultas; las compuertas fallidas detienen el nuevo escritor y restauran las consultas antiguas.
Errores comunes
- Poner todo en Body → los consumidores posteriores pierden la semántica de recursos y atributos → mapea campos según el modelo de datos y conserva los desconocidos.
- Reemplazar el tiempo del evento con el tiempo de recolección → la latencia del negocio se vuelve inmedible → conserva tanto Timestamp como ObservedTimestamp.
- Inventar TraceId cuando falta contexto → genera trazas falsas → mantenlo vacío y registra el motivo.
- Escritura dual sin reconciliación → no se puede demostrar que el historial y los resultados en vivo sean equivalentes → reconcilia por posición, ID de evento y ventana temporal.
- Descartar fallos de análisis → las correcciones del analizador no pueden reparar el historial → utiliza dead letters reproducibles.
- Persistir antes de ofuscar → los datos sin procesar tienen una ventana de exposición mayor → ofusca en un ingreso controlado y aísla los originales.
Preguntas de seguimiento y respuestas
¿Qué pasa si no hay una marca de tiempo del evento?
Usa ObservedTimestamp como alternativa explícita con un marcador de tiempo faltante. No lo presentes como tiempo de negocio; repórtalo por separado en las métricas de calidad.
¿Cómo demuestras que TraceId no fue inventado?
Confía únicamente en el contexto del SDK de la aplicación o de un proxy controlado, valida el formato y el alcance, y trata un campo de cliente con el mismo nombre como un Attribute ordinario.
¿Cómo manejas los duplicados provenientes de la escritura dual?
Genera un ID de evento estable y utiliza la posición de origen más el hash de contenido para escrituras idempotentes. Si la identidad sigue siendo incierta, conserva un marcador de duplicado y explícalo al momento de la consulta.
¿Qué pasa si el significado de un campo cambia durante la migración?
Incrementa las versiones del analizador y del esquema, conserva los mapeos antiguos y los metadatos de versión, permite una ventana de compatibilidad y prueba las consultas posteriores contra ambas versiones.
¿Por qué retener payloads sin procesar?
Permiten correcciones del analizador, resolución de disputas y reproducción. Cífralos y restríngelos, audita el acceso, acorta la retención y mantenlos separados de los índices normalizados.