Entrevista de diseño de sistemas: ¿Cómo diseñarías una plataforma de rastreo distribuido?

Enunciado y alcance

Diseña una plataforma de rastreo distribuido multi-inquilino utilizada por equipos de backend y confiabilidad para seguir una solicitud o flujo de trabajo asíncrono a través de múltiples servicios. Las suposiciones de la entrevista son 500.000 nuevos flujos de trabajo raíz por segundo, un promedio de 15 tramos (spans) por flujo de trabajo y 700 bytes por tramo codificado antes de la compresión de almacenamiento. Una traza conservada debe poder buscarse dentro de los 30 segundos en el percentil p99. La búsqueda exacta por inquilino e ID de traza debe completarse dentro de los 2 segundos en el p99; las búsquedas comunes por servicio, operación, error, duración y ventana de tiempo deben completarse dentro de los 3 segundos en el p95. La instrumentación no debe esperar sincrónicamente a la plataforma central, y la pérdida de una zona de disponibilidad no debe impedir que las aplicaciones emitan telemetría.

La plataforma crea o recibe tramos, propaga el contexto de traza de W3C a través de los transportes compatibles, ensambla tramos que llegan tarde o desordenados, muestrea trazas completas bajo presupuestos explícitos, almacena el detalle de las trazas y admite un grafo de dependencias derivado de las trazas conservadas. Desarrollar SDKs para cada lenguaje, una interfaz de usuario de APM completa, almacenamiento de logs, almacenamiento de métricas y detección de anomalías quedan fuera del alcance. Los logs y las métricas pueden transportar IDs de traza o ejemplares (exemplars), pero continúan siendo sistemas separados.

Tres páginas independientes de preparación para entrevistas de 2026 presentan el rastreo distribuido como un ejercicio de diseño de sistemas que abarca tramos, propagación de contexto, ensamblado de trazas, muestreo y almacenamiento para consultas. Eso establece la representatividad actual sin demostrar ninguna atribución a una empresa en particular, por lo que este artículo no hace ninguna. El modelo técnico proviene de la recomendación W3C Trace Context, la especificación de OpenTelemetry y la implementación de su Collector, y el artículo Dapper de Google.

Qué evalúa el entrevistador

La primera señal es si el candidato preserva la causalidad a través de los límites de los procesos. Un trace_id no es suficiente. Cada operación necesita un span_id, relación de padre o enlaces explícitos, temporización, estado, identidad del recurso y atributos cuidadosamente acotados. El formato W3C define un traceparent interoperable y estado opcional del proveedor en tracestate; no convierte un ID de traza entrante no confiable en una credencial de autorización. Una respuesta sólida valida el contexto entrante, separa a los inquilinos en la ingesta y define el comportamiento en los límites de confianza.

La segunda señal es un modelo de muestreo honesto. El muestreo en el origen (head sampling) toma decisiones antes de que se conozca toda la traza y puede reducir el trabajo en el SDK, la red y la ingesta. No puede prometer retener cada error posterior. El muestreo al final (tail sampling) puede seleccionar una traza después de ver la mayoría de los tramos, pero primero debe recibir y almacenar temporalmente dichos tramos. Reduce el almacenamiento downstream, no el costo de recolección upstream. Si un muestreador en el origen al 2% ya descartó una traza, ningún muestreador al final podrá recuperar sus tramos con error más adelante.

La tercera señal es el ensamblado de trazas en lugar de una canalización genérica de eventos. Los tramos llegan duplicados, retrasados y desordenados; la distribución asíncrona (fan-out) o el trabajo por lotes pueden formar un grafo acíclico dirigido en lugar de un árbol perfecto. Un muestreador al final necesita que todos los tramos de una traza se enruten al mismo responsable de decisión, una regla de finalización acotada, protección de memoria y un comportamiento explícito para tramos tardíos. Este límite con estado decide si el diseño produce evidencia útil o un sesgo de muestreo silencioso.

La señal final es la operabilidad. Una buena respuesta cuantifica el volumen en bruto y el conservado, limita los índices de atributos arbitrarios, aísla a los inquilinos ruidosos, mide la propagación faltante y los tramos descartados, y evita que la ruta de telemetría se convierta en una dependencia de la aplicación. Un diagrama que termine en "escribir tramos en una base de datos" deja sin respuesta las preguntas sobre costos, corrección y fallas.

Preguntas para aclarar antes de responder

• ¿Qué flujos de trabajo requieren decisiones al final de la traza (tail decisions)? El muestreo al final completo requiere la recepción central de todos los tramos candidatos. Este diseño utiliza muestreo en el origen en la fuente para el tráfico ordinario y envía un conjunto controlado de rutas críticas al 100% hacia un grupo de muestreo al final. Si cada ruta necesita una retención consciente de errores, el flujo en bruto completo debe ajustarse al presupuesto de red y estado central.
• ¿Qué significa "traza completa"? No existe un marcador de finalización universal a través de colas y tareas desacopladas. Para solicitudes sincrónicas, un tramo raíz finalizado más un intervalo de gracia resulta útil. Los flujos de trabajo de larga duración necesitan una política más extensa o una finalización de flujo de trabajo explícita. La plataforma aún debe publicar un indicador incomplete en lugar de asumir certeza.
• ¿Qué búsquedas son contractuales? La búsqueda exacta por ID de traza y los filtros acotados por servicio, operación, estado, rango de duración y tiempo están dentro del alcance. Predicados arbitrarios de texto completo sobre cada atributo multiplicarían el costo del índice y crearían abusos de alta cardinalidad, por lo que los atributos fuera de la lista permitida permanecen disponibles solo después de recuperar la traza.
• ¿Cuánto tiempo se retienen los datos? La política asumida es de siete días de datos activos indexados y otros 23 días de datos comprimidos en almacenamiento de objetos. Una retención activa más prolongada cambia el dimensionamiento del almacenamiento y los índices; las reglas legales de eliminación también determinan si las claves de objetos y los dominios de cifrado deben ser específicos de cada inquilino.
• ¿Se permiten trazas entre inquilinos? Por defecto, no. Las puertas de enlace (gateways) asocian las credenciales autenticadas a un inquilino y sobrescriben cualquier campo de inquilino provisto en un tramo. Los flujos de trabajo aprobados entre dominios utilizan enlaces explícitos o correlación autorizada por separado, nunca un identificador de inquilino seleccionado por el cliente.
• ¿Cómo debe representarse la causalidad asíncrona? Un único padre funciona para un predecesor causal. Los consumidores de lotes y la convergencia (fan-in) pueden depender de múltiples productores, por lo que necesitan enlaces de tramos (span links). Forzar un solo padre pierde información; copiar un tramo bajo múltiples padres corrompe la contabilidad de la traza.
• ¿Qué puede perder la aplicación durante una sobrecarga? El tráfico del negocio debe continuar. Una cola local acotada puede descartar telemetría tras agotar los presupuestos de memoria y disco, pero la pérdida se contabiliza por servicio, inquilino, motivo y clase de muestreo. Si se exige cero pérdida de telemetría, el rastreo se convierte en una dependencia de la ruta de negocio y el contrato de disponibilidad debe cambiar.

Estructura de respuesta en 30 segundos

"Separaría la propagación de contexto, la recolección, las decisiones de trazas y el almacenamiento para consultas. Las bibliotecas instrumentadas crean tramos y propagan contexto W3C validado. Un agente local los procesa por lotes de forma asíncrona y utiliza un búfer en disco acotado, de modo que la plataforma central nunca bloquee la ruta de las solicitudes. Las puertas de enlace regionales autentican al inquilino, aplican esquemas y cuotas, y anexan los tramos a un flujo durable particionado por ID de traza.

Las rutas ordinarias utilizan muestreo consistente en el origen para reducir el costo upstream. Las rutas críticas ingresan a un grupo completo de muestreo al final; todos los tramos de una traza llegan a un ensamblador, que espera al nodo raíz más una ventana de gracia, aplica presupuestos de error, latencia y línea base, y registra si la traza está incompleta. Las trazas conservadas van a un almacén de objetos para el detalle canónico y a un índice activo con lista permitida para búsquedas por ID de traza y filtros acotados. Dimensionaría tanto el estado previo al muestreo como el almacenamiento conservado, degradaría descartando primero las trazas normales de baja prioridad y verificaría la propagación, los tramos tardíos, el muestreo sesgado, el aislamiento de inquilinos y la recuperación de zonas con trazas canario".

Análisis detallado paso a paso

Paso 1: Definir el contrato de tramos y la API de consultas.

Un registro de tramo contiene al menos:

Span {
  tenant_id, trace_id, span_id, parent_span_id?, links[],
  service, operation, kind, start_time, end_time, status,
  resource_attributes, span_attributes, events[],
  observed_at, schema_version, trace_flags, tracestate?
}

La puerta de enlace deriva tenant_id a partir de la autenticación. Valida las longitudes y formatos de los identificadores, rechaza registros de tamaño excesivo, normaliza los campos semánticos aprobados y limita la cantidad de atributos, longitud de valores, cantidad de eventos, cantidad de enlaces y bytes totales. Almacena tanto el tiempo del evento como observed_at: los relojes de los servicios ayudan a renderizar una línea de tiempo, mientras que el tiempo del recolector expone retrasos y problemas de desfase de reloj (clock skew). Los SDK deben medir la duración de un tramo local con un reloj monotónico, aun cuando el orden entre diferentes hosts siga requiriendo tiempo de pared y bordes causales.

Los principales contratos de consulta son:

GetTrace(tenant_id, trace_id)
SearchTraces(tenant_id, start, end, service?, operation?, status?,
             min_duration?, max_duration?, cursor?, limit?)

GetTrace devuelve tramos, enlaces, la política de muestreo y su versión, first_observed_at, last_observed_at y advertencias de completitud. SearchTraces requiere un rango de tiempo acotado y devuelve un cursor en lugar de un desplazamiento sin límites. La recuperación de detalles y la búsqueda secundaria son rutas de acceso diferentes; un registro de traza ancho no debe duplicarse en cada índice secundario.

Paso 2: Propagar el contexto sin convertirlo en confianza.

Para HTTP, el SDK extrae e inyecta W3C traceparent, transportando versión, ID de traza, ID del padre y flags; tracestate transporta estado opcional específico del proveedor. Los productores de mensajes colocan los mismos campos de propagación en los metadatos de los mensajes. Los receptores validan el formato antes de unirse a la traza. Un contexto inválido inicia una nueva traza e incrementa un contador de errores de propagación en lugar de contaminar un espacio de claves existente.

En un límite expuesto a Internet o entre inquilinos, el servicio puede iniciar deliberadamente una nueva traza y adjuntar un enlace a un contexto upstream aprobado. Esto preserva la correlación sin permitir que un cliente externo elija un padre interno o controle el muestreo. Baggage es un mecanismo separado de propagación clave-valor. Debe estar sujeto a una lista permitida, tener un tamaño acotado y estar despojado de secretos o datos personales, ya que se propaga a cada salto downstream.

Instrumenta automáticamente primero las bibliotecas comunes de HTTP, RPC, bases de datos y colas. Dapper demostró por qué la instrumentación de bibliotecas comunes mejora la cobertura con un menor esfuerzo en las aplicaciones. Los tramos personalizados siguen siendo útiles para los límites de negocio, pero la plataforma mide servicios y rutas que carecen de los tramos de servidor o cliente esperados. La calidad del rastreo es tan completa como lo sean la instrumentación y las muestras retenidas.

Paso 3: Mantener la recolección fuera de la ruta de solicitudes de la aplicación.

Los tramos finalizados ingresan a un búfer acotado en el proceso y se envían en lotes comprimidos a un agente de nodo o sidecar. El agente dispone de un búfer en disco acotado para breves caídas del recolector, reintentos exponenciales con fluctuación (jitter) y colas por prioridad. Nunca espera sincrónicamente un acuse de recibo central antes de que la aplicación pueda finalizar su respuesta. Una vez agotado el presupuesto local, descarta primero la telemetría normal de baja prioridad y exporta contadores que describen con precisión lo que se perdió.

Las puertas de enlace regionales sin estado autentican al agente, asocian al inquilino, aplican cuotas de bytes y tramos, validan el esquema y anexan los lotes aceptados a un flujo durable replicado. El acuse de recibo significa que el flujo regional ha aceptado de manera durable el lote, no que la búsqueda ya lo contenga. Los consumidores son idempotentes mediante (tenant_id, trace_id, span_id) más una versión de registro; la entrega duplicada actualiza los metadatos de observación pero no duplica un tramo.

El flujo se particiona mediante un hash estable de (tenant_id, trace_id). Eso asigna a una traza un responsable de decisión ordenado sin requerir un orden global de los tramos. Para el muestreo al final a mayor escala, una primera capa de recolectores puede balancear la carga por ID de traza hacia una segunda capa con estado. OpenTelemetry Collector documenta la misma invariante: todos los tramos de una traza deben llegar a la misma instancia de muestreo al final.

Paso 4: Hacer que cada límite de capacidad sea recalculable.

Antes del muestreo, la carga de trabajo genera:

500,000 workflows/s × 15 spans/workflow = 7,500,000 spans/s
7,500,000 spans/s × 700 bytes/span = 5.25 GB/s
5.25 GB/s × 86,400 s = 453.6 TB/day raw

Estas son suposiciones sobre la carga de trabajo, no afirmaciones de compresión medidas. Una plataforma que envíe todos los tramos en bruto a un muestreador central al final debe aprovisionar la ruta de ingesta de 5,25 GB/s antes de contabilizar la replicación, la sobrecarga de protocolo, los reintentos, el sesgo de reloj y el margen para conmutación por error (failover).

Asume que las rutas ordinarias producen el 90% de los tramos y usan un muestreo consistente en el origen del 2%. Las rutas críticas producen el 10% e ingresan al grupo de muestreo al final al 100%:

ordinary: 7.5M × 90% × 2% = 135,000 spans/s
tail pool input: 7.5M × 10% = 750,000 spans/s
collector input: 885,000 spans/s × 700 bytes = 619.5 MB/s

Si la política de muestreo al final retiene el 10% de sus tramos candidatos en promedio, el almacenamiento activo recibe 135,000 + 75,000 = 210,000 spans/s, o 147 MB/s y 12,7008 TB/día antes de compresión, replicación, índices y metadatos de objetos. Siete días activos equivalentes a datos en bruto representan 88,9056 TB. Las pruebas de rendimiento con distribuciones reales de atributos determinan la compresión y el número de nodos; la aritmética solo establece el límite inferior y muestra qué frontera de muestreo asume cada costo.

Paso 5: Tratar el muestreo al final como el cuello de botella decisivo con estado.

El ensamblador almacena el estado parcial con clave por inquilino e ID de traza: tramos únicos, inicio más temprano, fin más tardío, estado de raíz finalizada, estado de error, duración actual, recuento de bytes y última llegada. Una traza sincrónica se vuelve elegible para decisión después de que finaliza su raíz y transcurre un intervalo de gracia. También se fuerza su decisión al alcanzar una antigüedad máxima, recuento de tramos o recuento de bytes. Los flujos de trabajo prolongados utilizan una política independiente; de lo contrario, una sola traza puede retener memoria indefinidamente.

El orden de decisión reserva capacidad para flujos críticos explícitos, errores y trazas de alta latencia, y luego utiliza una línea base probabilística consistente dentro de los presupuestos por servicio y por inquilino. Una regla global de "conservar todos los errores" no es una política acotada durante un incidente, cuando los errores pueden acercarse al 100%. Cubos de tokens (token buckets) y topes estrictos de bytes limitan cada clase; la respuesta ante el agotamiento es una política degradada visible, no una caída por falta de memoria.

El muestreador registra una caché de decisiones para tramos tardíos. Un tramo tardío para una traza conservada se anexa y marca la traza como actualizada. Un tramo tardío para una traza descartada se desecha de forma consistente. Un tramo que llega después de que expire la caché se cuenta como huérfano; no debe crear una traza engañosa de un solo tramo. Cada traza almacenada incluye complete, decision_reason y contadores de tramos tardíos. Incrementar el intervalo de gracia mejora la completitud, pero aumenta la memoria, la latencia de decisión y la cantidad de trazas expuestas a una falla del muestreador.

La trampa crítica es una canalización híbrida. La lógica al final de la traza solo puede elegir entre las trazas que llegaron hasta ella. Si un muestreador en el origen al 2% descartó una traza normal antes de que ocurriera un error downstream, la etapa al final no podrá recuperarla. Por lo tanto, las rutas que requieren decisiones conscientes de errores garantizadas deben ingresar al grupo al final sin una decisión previa de descarte upstream, o usar un disparador separado aceptando que no reconstruirá el pasado.

Paso 6: Almacenar el detalle canónico por separado de los índices acotados.

Los tramos conservados se compactan en objetos inmutables y comprimidos, particionados por inquilino y tiempo, con un manifiesto para cada revisión de la traza. El directorio de IDs de traza mapea (tenant_id, trace_id) a las ubicaciones de los objetos y la última revisión. Esta ruta atiende la búsqueda exacta. Los objetos de traza recientes pueden almacenarse en caché, pero la capa de objetos es la fuente de reconstrucción para los índices derivados.

El índice de búsqueda activo almacena una fila de resumen por traza: inquilino, ID de traza, servicio y operación raíz, intervalo de inicio, duración, estado, conjunto o huellas de servicios seleccionados, motivo de muestreo, completitud y puntero al objeto. Solo los campos en la lista permitida reciben índices secundarios. Los IDs de usuario arbitrarios, texto SQL, URLs y valores de baggage permanecen en el detalle protegido o se redactan; indexarlos por defecto crea cardinalidad ilimitada, exposición de privacidad y amplificación de escritura.

Las vistas de dependencia de servicios y latencia son agregados en tiempo real (streaming aggregates) sobre las trazas conservadas y deben etiquetarse como estimaciones muestreadas. Los pesos de muestreo pueden admitir algunas estimaciones de recuento no sesgadas cuando se conoce la probabilidad, pero las muestras al final sesgadas por error y latencia no representan automáticamente las proporciones del tráfico. Las métricas siguen siendo la fuente para las tasas exactas a nivel de flota; las trazas explican las rutas causales individuales.

Paso 7: Aislar a los inquilinos y definir el comportamiento ante fallas.

Las puertas de enlace aplican límites por inquilino en bytes por segundo, tramos por segundo, trazas parciales simultáneas, concurrencia de consultas y bytes retenidos. Las claves de partición incluyen la identidad del inquilino, las políticas de cifrado pueden separar a inquilinos regulados y la autorización de consultas se valida antes de cualquier búsqueda en índices. Un inquilino con una traza gigante o un atributo de alta cardinalidad no debe expulsar el estado del muestreador de otro inquilino.

Si una puerta de enlace o zona de disponibilidad falla, los agentes reintentan contra otro endpoint regional y usan su búfer en disco. Si el flujo durable presenta lentitud, el control de admisión reduce el muestreo ordinario y rechaza los bytes excedentes antes del ensamblado con estado. Si un ensamblador falla, el flujo reproduce su partición; los puntos de control aceleran la recuperación, mientras que las claves de tramos idempotentes absorben duplicados. Durante una caída del índice, los objetos canónicos continúan escribiéndose y se acumula un registro pendiente de indexación. Las consultas exactas recién escritas pueden reportar "aceptado, indexando" en lugar de devolver un falso "no encontrado".

Si el grupo de muestreo al final se sobrecarga, reduce progresivamente la línea base probabilística, limita las trazas grandes y luego recurre a una política determinista en el origen para las rutas afectadas. Preserva las trazas canario del plano de control y cierta capacidad acotada para errores. Monitorea tramos aceptados, descartados, reintentados, expulsados prematuramente, tardíos, huérfanos e indexados por inquilino, servicio, zona y política.

Paso 8: Verificar la veracidad, no solo el rendimiento.

Las pruebas de propagación cubren encabezados válidos, faltantes, malformados y de versiones futuras; límites entre inquilinos y con Internet; límites de baggage; colas; reintentos; fan-out; fan-in; y enlaces por lotes. Las pruebas de ensamblado inyectan trazas duplicadas, desordenadas, sin padre, tardías, sobredimensionadas y que nunca finalizan. Las pruebas de muestreo demuestran la coherencia de trazas completas, topes de presupuesto, decisiones probabilísticas deterministas, políticas de error y latencia, y el hecho de que los descartes upstream en el origen siguen siendo irrecuperables.

Las pruebas de carga preservan los tamaños de trazas y el sesgo de inquilinos similares a producción. Miden la sobrecarga del SDK, pérdidas en agentes, admisión en puertas de enlace, retraso en el flujo, memoria de trazas activas, latencia de decisión, bytes conservados, retraso en índices, búsqueda de trazas y búsqueda filtrada. Las pruebas de fallas eliminan una zona, reinician un ensamblador durante una partición activa, pausan el almacenamiento de objetos, agotan la cuota de un inquilino y reconstruyen el índice activo a partir de objetos canónicos.

Emite continuamente flujos de trabajo canario sintéticos con un grafo conocido a través de cada región. Genera alertas si desaparecen tramos esperados, cambia la relación de parentesco, la frescura de búsqueda supera los 30 segundos o la búsqueda de ID de traza incumple su SLO. Un proceso recolector en buen estado no demuestra que las trazas estén completas o disponibles para búsqueda.

Ejemplo de respuesta sólida

"En primer lugar, señalaría que una traza es un grafo causal de tramos, no una bolsa de líneas de log. Cada tramo tiene un ID de traza vinculado al inquilino, ID de tramo, padre o enlaces, temporización, estado, recurso, atributos acotados, eventos y tiempo de observación. Los servicios propagan contexto W3C validado sobre HTTP o metadatos de mensajes. En un límite no confiable, iniciaría una nueva traza interna y la enlazaría, porque el contexto de traza es información de correlación, no de autorización.

Los tramos salen de la ruta de solicitudes a través de un búfer acotado en el proceso y un agente local. El agente agrupa por lotes, comprime, almacena brevemente en disco y descarta datos de baja prioridad medidos en lugar de bloquear el tráfico de negocio. Las puertas de enlace regionales autentican inquilinos, aplican esquemas y cuotas, y escriben en un flujo replicado. La partición por inquilino e ID de traza envía cada traza a un solo ensamblador y hace que los reintentos sean idempotentes por ID de tramo.

La carga de trabajo en bruto es de 7,5 millones de tramos por segundo y 5,25 GB/s. No enviaría todo eso a un muestreador al final por accidente. Las rutas ordinarias usan un muestreo consistente en el origen del 2%. El grupo controlado del 10% de rutas críticas ingresa al muestreo al final al 100%, por lo que la entrada al recolector es de 885.000 tramos/s, o 619,5 MB/s. Si el grupo al final conserva el 10%, el almacenamiento recibe 210.000 tramos/s, aproximadamente 12,7 TB/día en bruto antes de índices y réplicas. Esos límites son insumos de referencia, no resultados prometidos de compresión.

El ensamblador es la parte difícil. Mantiene trazas parciales, espera una raíz finalizada más una ventana de gracia y fuerza decisiones ante límites de antigüedad, tramos y bytes. Reserva capacidad acotada para trazas críticas, con errores y lentas, y luego cubre los presupuestos por servicio con una línea base consistente. Almacena decisiones en caché para tramos tardíos y etiqueta trazas incompletas. Un descarte en el origen upstream del 2% no se puede recuperar después, por lo que cualquier ruta que realmente necesite retención consciente de errores debe ingresar al grupo al final sin muestreo previo.

El detalle de las trazas conservadas va a un almacenamiento de objetos comprimido con un directorio de IDs de traza. Un índice activo separado almacena un resumen por traza y solo campos autorizados de servicio, operación, estado, duración y tiempo. Eso controla la cardinalidad y permite reconstruir el índice. Durante fallas, los agentes usan búferes en disco, las particiones del flujo se reproducen, las escrituras en objetos continúan si la búsqueda cae y la sobrecarga descarta la línea base normal antes que las clases protegidas. Verificaría límites de contexto, tramos duplicados y tardíos, sesgo y topes de muestreo, aislamiento de inquilinos ruidosos, pérdida de zonas, reconstrucciones y trazas canario de extremo a extremo".

Errores comunes

• Decir 'muestrear 2%, luego conservar todos los errores al final' → la primera etapa ya eliminó el 98% de las trazas candidatas, incluidos errores posteriores → envía las rutas protegidas sin muestreo al grupo de muestreo al final o flexibiliza la garantía.
• Distribuir tramos por hash entre recolectores sin el ID de traza → un muestreador al final solo ve fragmentos y toma una decisión sesgada → enruta cada tramo de (tenant, trace_id) al mismo responsable de decisión.
• Esperar indefinidamente una traza completa → el trabajo asíncrono no tiene un marcador final universal, por lo que el estado crece sin límites → usa raíz más gracia, antigüedad/tamaño máximo, políticas explícitas de flujo de trabajo y un indicador de incompleto.
• Tratar traceparent como identidad o autorización → un llamador externo puede elegir campos de correlación → autentica al inquilino de forma independiente e inicia una nueva traza enlazada en los límites de confianza.
• Colocar baggage o atributos arbitrarios en cada índice → la cardinalidad, la amplificación de escritura y la exposición de datos confidenciales se vuelven ilimitadas → define listas permitidas para campos indexados y acota o redacta valores propagados.
• Enviar tramos sincrónicamente al recolector central → una falla de telemetría eleva la latencia de la aplicación o el riesgo de disponibilidad → agrupa por lotes asincrónicamente mediante colas locales acotadas y expone la pérdida medida.
• Almacenar cada tramo omitiendo el resumen de la traza → las búsquedas por servicio, duración y error escanean enormes volúmenes de datos detallados → mantén el detalle canónico más una fila de resumen acotada y reconstruible por traza.
• Llamar a una muestra al final sesgada una distribución exacta de tráfico → las reglas de error y latencia sobrerrepresentan intencionalmente trazas inusuales → publica metadatos de muestreo y utiliza métricas para tasas agregadas exactas.
• Probar solo el tiempo de actividad del recolector → las rupturas de contexto, tramos faltantes y retrasos de índices pueden permanecer invisibles → ejecuta canarios con grafos conocidos y valida completitud, muestreo, frescura y SLOs de consulta.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: Producto ahora exige registrar cada traza con error manteniendo el mismo presupuesto central de ingesta. ¿Qué cambia?

Ambos requisitos pueden entrar en conflicto. A menudo, un error solo se conoce después de que se ejecutan los tramos downstream, por lo que un muestreador en el origen en la fuente no puede garantizar la retención. Cuantifica la tasa máxima de tramos en bruto y la capacidad del muestreo central al final. Si el presupuesto no puede recibir todas las rutas candidatas, reduce la garantía a un conjunto acotado de rutas críticas, aumenta la capacidad o agrega disparadores de errores en la aplicación que inicien un muestreo de alta tasa hacia el futuro, admitiendo que los tramos descartados en el pasado no se pueden reconstruir. "Siempre los errores" también debe tener un tope en bytes porque un incidente puede convertir casi todo el tráfico en errores.

Pregunta de seguimiento 2: Un mensaje consume eventos de 10 trazas de productores distintos. ¿Qué padre debe usar el tramo del consumidor?

Ningún padre único representa diez causas independientes. Crea un tramo de consumidor o de procesamiento por lotes en el flujo de trabajo correspondiente y adjunta enlaces a los diez contextos de productores, sujeto a un límite en la cantidad de enlaces. Si el lote en sí tiene un contexto de entrega, ese puede ser el padre mientras que las entradas individuales permanecen como enlaces. El código de consulta y visualización debe admitir un DAG y mostrar metadatos de enlaces truncados; copiar el tramo del consumidor en diez árboles distorsiona la duración y el almacenamiento.

Pregunta de seguimiento 3: El muestreador al final está expulsando trazas parciales antes de su ventana de decisión. ¿Cómo lo depuras?

Compara el recuento de trazas activas y bytes, la distribución del tamaño de trazas, el retraso de llegada, particiones calientes, antigüedad de decisión, contadores de expulsión prematura y sesgo por inquilino. Aumentar la ventana de espera puede empeorar la presión de memoria. Primero limita las trazas sobredimensionadas, aísla inquilinos ruidosos, divide particiones sin romper la afinidad de trazas y reduce la línea base normal. Luego agrega capacidad o acorta la ventana según el valor observado de los tramos tardíos. Ejecuta una política en sombra para medir cómo el cambio propuesto altera los errores retenidos, las trazas lentas y la completitud.

Pregunta de seguimiento 4: El servicio de búsqueda está caído durante dos horas, pero la ingesta y el almacenamiento de objetos funcionan correctamente. ¿Qué devuelve la API?

Continúa escribiendo objetos de trazas canónicas y el registro durable de cambios de índice. GetTrace puede usar el directorio de IDs de traza si esa ruta sigue disponible; la búsqueda secundaria reporta datos desactualizados de as_of o un estado explícito de temporalmente no disponible. No debe reportar que una traza recién aceptada no existe simplemente porque su resumen no está indexado. Tras la recuperación, reproduce de forma idempotente, compara recuentos y desfases, y reconstruye el índice a partir de los objetos si el registro de cambios se corrompió.

Pregunta de seguimiento 5: ¿Cómo demuestras que el muestreo no ha ocultado por completo un servicio de bajo volumen?

Mantén un presupuesto de línea base mínimo por servicio o por operación antes de compartir el presupuesto global restante. Registra la probabilidad y el motivo de decisión con cada traza conservada, y genera alertas sobre servicios con tráfico pero sin trazas retenidas. Los canarios sintéticos verifican la ruta completa independientemente de la probabilidad. Compara la cobertura derivada de trazas con los recuentos de solicitudes de métricas; si un servicio recibe solicitudes pero no produce tramos, distingue entre falta de instrumentación, falla de propagación, descartes por cuota, decisiones en el origen, decisiones al final y pérdidas en índices.