Planteamiento y alcance
Un entrevistador puede preguntar: “Diseña una canalización de logs en OpenTelemetry que admita correlación de trazas. Explica el modelo de datos, la contrapresión, el aislamiento de inquilinos y la recuperación”.
La señal evaluada es si puedes convertir los eventos de las aplicaciones en telemetría gobernada. El modelo de datos de logs de OpenTelemetry separa Timestamp, TraceId, SpanId, SeverityNumber, Body, Resource y Attributes; OTLP permite que los logs viajen salto a salto a través de agentes, Collectors y backends. El desafío reside en preservar la semántica, la capacidad y los límites de seguridad, no en limitarse a trazar una simple línea con Kafka.
Lo que evalúa el entrevistador
- Si separas adecuadamente las responsabilidades de Resource, Attributes, Body y Trace Context.
- Si puedes diseñar una ruta confiable a través de aplicaciones, agentes, Collectors, colas y backends.
- Si sabes gestionar la contrapresión ante picos, el procesamiento por lotes, los reintentos, los descartes por prioridad y el almacenamiento en búfer en disco.
- Si previenes la exposición entre inquilinos y redactas secretos y datos personales.
- Si explicas los duplicados, el ordenamiento, el muestreo y la experiencia de consulta cuando falta TraceId.
Preguntas de clarificación
- ¿Las fuentes son SDK, archivos existentes, el stdout de contenedores o una mezcla?
- ¿Cuáles son los objetivos en cuanto a cantidad de inquilinos, rendimiento (throughput), retención y latencia de consulta?
- ¿La aplicación inyecta TraceId de manera consistente y se permite una clave de correlación cuando no está presente?
- ¿Qué campos contienen datos personales, secretos o contenido sensible para el negocio, y en qué punto debe realizarse la redacción?
- Durante una falla del backend, ¿qué niveles se pueden descartar y cuánto volumen de reproducción (replay) se requiere tras la recuperación?
Respuesta en 30 segundos
Puedes decir:
Utilizaría una ruta por capas desde los receptores de aplicaciones o archivos hacia un Collector local, luego hacia una cola y al backend. Cada registro conserva el tiempo, la severidad, Body, Resource y Attributes, e incluye TraceId y SpanId cuando existe contexto. Los Collectors procesan por lotes, limitan la tasa, redactan y enrutan; una cola y un búfer en disco absorben la fluctuación (jitter) del backend. La identidad del inquilino ingresa mediante atributos de Resource confiables e índices de autorización. Durante una sobrecarga, se descarta o muestrea debug en primer lugar, para luego gestionar los reintentos, los duplicados y las lecturas de recuperación.
Razonamiento paso a paso
Definir un contrato de registro único
No hagas de una línea no estructurada el único contrato. Un registro lógico puede verse así:
{
"timestamp": "2026-08-01T10:00:00Z",
"traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
"spanId": "00f067aa0ba902b7",
"severityNumber": 17,
"severityText": "ERROR",
"body": {"message": "payment declined", "code": "CARD_DECLINED"},
"resource": {"service.name": "checkout", "tenant.id": "t-7"},
"attributes": {"region": "us-east-1"}
}Resource describe la entidad emisora, Attributes describe la ocurrencia de un evento y Body preserva el contenido estructurado. Compara la severidad con SeverityNumber mientras retienes el SeverityText de origen para su visualización.
Diseñar la recolección y el transporte
Un SDK o un receptor de archivos convierte los registros a OTLP. Un agente de nodo procesa por lotes y aplica límites iniciales; un Collector analiza, enriquece los datos de Resource, redacta, enruta y exporta. OTLP admite Collectors intermedios, por lo que las rutas largas necesitan tiempos de espera (timeouts), autenticación y compresión explícitos. Una cola es opcional, pero puede proporcionar almacenamiento en búfer duradero y un límite de cuota por inquilino cuando el rendimiento del backend es inestable.
Gestionar la contrapresión y las clases de datos
Establece límites de tasa, lotes, memoria y disco por inquilino y por servicio. Cuando el backend se ralentice, pausa las exportaciones de baja prioridad mientras preservas eventos de error, auditoría y seguridad; muestrea o descarta debug. Los reintentos necesitan un retroceso exponencial (exponential backoff) y un tiempo máximo de retención para evitar tormentas de reintentos. Registra los rangos de lotes fallidos para su reproducción y utiliza idempotencia o deduplicación en el backend para reducir los duplicados.
Asegurar, aislar y correlacionar consultas
Elimina secretos, tokens y datos personales de forma temprana en el borde o en el Collector. Inyecta la identidad del inquilino desde una fuente de Resource confiable; no aceptes sobrescrituras arbitrarias del cliente. Particiona los índices por inquilino y tiempo, con índices de correlación opcionales por TraceId y SpanId. Los logs sin TraceId permanecen consultables por servicio, tiempo e identificador de solicitud; nunca inventes un TraceId plausible.
Respuesta modelo de alta calidad
Dividiría el diseño en capas de contrato de registro, recolección, almacenamiento en búfer, procesamiento y consulta. Los registros siguen el modelo de datos de logs de OpenTelemetry para tiempo, severidad, Body, Resource y Attributes, agregando TraceId y SpanId cuando la aplicación tiene contexto. Un SDK o un receptor filelog envía a un Collector de nodo; el Collector procesa por lotes, redacta, aplica cuotas de inquilinos y enruta mediante OTLP, utilizando una cola duradera por inquilino cuando sea necesario. La fluctuación del backend es absorbida por búferes de memoria y disco; cuando se exceden los presupuestos asignados, se descarta en el orden de debug, info, error y audit mientras se mide la tasa de descarte y la antigüedad del registro más antiguo. Los índices de consulta están aislados por inquilino y tiempo, y la correlación por TraceId acelera la investigación sin fabricar contexto. La recuperación utiliza rangos de lotes, retroceso y deduplicación idempotente; los logs de auditoría y seguridad cuentan con políticas de retención y acceso independientes.
Errores comunes
- Colocar todos los campos en Body y perder la semántica de Resource, Attributes y Trace Context.
- Trazar únicamente una línea entre la aplicación y el backend sin un agente, Collector, cola o búfer en disco.
- Reintentar indefinidamente durante una falla del backend hasta agotar la memoria y provocar una caída en cascada.
- Permitir que los clientes envíen directamente atributos de inquilino y contaminen los índices entre inquilinos.
- Generar identificadores de traza aleatorios para logs que carecen de contexto, desorientando la investigación.
- Discutir el rendimiento sin incluir métricas de descarte por prioridad, redacción, duplicados y recuperación.
Preguntas de seguimiento y respuestas
1. ¿Qué haces cuando falta TraceId?
Conserva el log original y marca el contexto como faltante. Utiliza identificadores verificables de servicio, tiempo y solicitud para la correlación. Completa TraceId solo cuando la aplicación o un proxy confiable lo suministren; nunca fabriques uno.
2. ¿Cómo evitas la filtración de secretos?
Aplica reglas por campo y redacción por patrones de forma temprana en el SDK, agente o Collector, rechaza formatos obvios de secretos y haz cumplir el acceso al backend a nivel de inquilino. Cualquier retención de datos crudos muestreados requiere un aislamiento y una auditoría más estrictos.
3. ¿Cuándo es aceptable descartar logs?
Define primero las clases de negocio: seguridad, auditoría y errores críticos generalmente se preservan; debug y campos de diagnóstico de alta cardinalidad se pueden muestrear. Registra el motivo, el inquilino, el rango de tiempo y el conteo para cada descarte, de modo que la presión de capacidad sea explicable y permita generar alertas.