Entrevista de diseño de sistemas: Diseñar un sistema centralizado de registro de logs

Problema y alcance

Diseñe un sistema centralizado de registro de logs compartido por múltiples equipos de ingeniería. Cien mil instancias de servicios, contenedores y trabajos por lotes producen 1 millón de eventos por segundo en estado estable, con un promedio de 600 bytes de datos sin procesar por evento. Un incidente importante puede sostener 3 millones de eventos por segundo durante 15 minutos porque las solicitudes fallidas, los reintentos y los stack traces aumentan todos al mismo tiempo. El objetivo p99 desde la creación del evento hasta la visibilidad en búsquedas es de 30 segundos. Las consultas comunes sobre los últimos 15 minutos, con filtros por tenant, tiempo, servicio, entorno y severidad, deben completarse en menos de 2 segundos en el p95.

Los usuarios necesitan filtros por tiempo, servicio, host, severidad y traceId, además de búsqueda de texto completo acotada, descargas y alertas. Las clases de logs tienen diferentes requisitos de retención y confiabilidad. Los logs de depuración (debug) pueden tener una retención corta y pueden muestrearse durante una emergencia. Los errores operativos necesitan una retención durable. Los logs de auditoría de seguridad no pueden usar la política de degradación ordinaria. El sistema también necesita cuotas por tenant, redacción de campos, auditoría de accesos, gestión del ciclo de vida y restauración histórica.

La escala, la latencia, la retención y los objetivos de confiabilidad son premisas de la entrevista, no compromisos públicos de un proveedor de registro de logs. El alcance no incluye implementar un motor de búsqueda completo ni reescribir un message broker durante la entrevista. Tampoco requiere copiar la arquitectura interna de una empresa. Los ejercicios públicos de diseño de sistemas para 2026 siguen pidiendo a los candidatos que diseñen sistemas centralizados de registro de logs con manejo de ráfagas, búsqueda, retención y aislamiento de tenants. El modelo de datos de logs estable de OpenTelemetry, su guía de resolución de problemas de Collector y la documentación de Elastic sobre niveles de datos (data tiers) y explosión de mapeos (mapping explosion) proporcionan evidencia fundamental para los límites de ingeniería importantes.

Qué evalúa el entrevistador

Primero, ¿puede el candidato separar la aceptación durable de la visibilidad inmediata en búsquedas? El gateway puede confirmar la recepción de un evento después de confirmarlo en un flujo durable replicado. El índice de búsqueda puede retrasarse decenas de segundos. Si el éxito requiere una escritura en el clúster de búsqueda, el mantenimiento y escalado del índice aplicarán contrapresión directamente a cada productor.

Segundo, ¿reconoce el candidato las fallas correlacionadas durante un incidente? El momento en que los logs son más valiosos es también cuando los errores de la aplicación, las tormentas de reintentos y la presión en el clúster de búsqueda suelen aumentar juntos. Una respuesta completa incluye almacenamiento en búfer en disco local, una cola central durable, contrapresión, capacidad finita, descarte basado en prioridades y recuentos de descarte medibles. Decir únicamente “añadir Kafka y Elasticsearch” no cubre la ruta de fallo.

Tercero, ¿el plan de indexación comprende el costo y la cardinalidad? Indexar dinámicamente cada atributo JSON arbitrario permite que los campos de alta cardinalidad generen mapeos, diccionarios y sobrecarga de shards. Un diseño sólido indexa campos estables, consultados frecuentemente y con tipos bien definidos. Otros atributos pueden almacenarse sin necesidad de indexarse de forma predeterminada.

Cuarto, ¿el aislamiento de tenants cubre tanto la ingesta como las consultas? La identidad del tenant debe provenir de credenciales autenticadas, no de un tenantId proporcionado dentro del cuerpo del log. Un solo tenant con alto volumen, una expresión regular amplia o una explosión de campos no deben agotar las colas compartidas, los hilos de indexación, los cachés o la concurrencia de consultas.

Por último, ¿forman la capacidad, la semántica de entrega, la seguridad y la validación un único sistema coherente? El candidato debe calcular el rendimiento bruto y el backlog por ráfagas, admitir que la entrega de al menos una vez genera duplicados, explicar por qué los logs de auditoría y de depuración necesitan políticas diferentes, y utilizar canarios de extremo a extremo para demostrar que las pérdidas nunca son silenciosas.

Preguntas de aclaración antes de responder

• ¿Qué logs no deben perderse bajo ninguna circunstancia? Los eventos de auditoría y seguridad requieren retención durable. Los logs de depuración pueden muestrearse o

descartarse bajo una política de degradación explícita.

• ¿Dónde se encuentra el límite de éxito? El gateway central confirma la recepción tras confirmar el evento en un flujo durable

replicado entre zonas de disponibilidad, sin esperar a que el índice de búsqueda se actualice.

• ¿Puede el registro de logs bloquear al productor? Los logs ordinarios de la aplicación no deben bloquear sincrónicamente las solicitudes de negocio. Un agente de

nodo utiliza lotes asincrónicos y un disco local finito.

• ¿Cuáles son los patrones de consulta principales? Filtros estructurados con tenant y rango de tiempo, búsqueda exacta por traceId y

búsqueda de texto completo en una ventana acotada.

• ¿Se requiere un orden global? No. Se preserva el orden aproximado dentro de una misma instancia de origen y se utilizan las marcas de tiempo del

evento y las observadas para ayudar a ordenar los eventos entre orígenes.

• ¿Cuáles son los supuestos de retención? Los logs de depuración tienen 24 horas en el índice activo (hot) y 7 días en archivos sin procesar.

Los logs operativos tienen 7 días en hot y 90 días archivados. Los logs de auditoría tienen 30 días con capacidad de búsqueda y 365 días en archivos inmutables.

• ¿Necesitamos escrituras activas entre regiones? El diseño principal recolecta en una canalización regional. Un plano de control

unificado y consultas de recuperación ante desastres pueden leer los archivos.

• ¿Indexamos todos los campos? No. Los campos estables de nivel superior y los atributos en listas de permitidos pueden indexarse. Los atributos

arbitrarios de alta cardinalidad solo se almacenan de forma predeterminada.

• ¿Cómo se manejan los valores sensibles? Los SDKs y los agentes de nodo los previenen o redactan primero, y los procesadores centrales los

verifican nuevamente. Los secretos y tokens no deben entrar a los logs.

• ¿Qué tan amplia puede ser una consulta? Requiere un rango de tiempo, paginación por cursor, presupuestos de escaneo, límites de concurrencia y

cancelación. Las exportaciones históricas grandes utilizan trabajos asincrónicos.

Estructura de respuesta en 30 segundos

“Las aplicaciones escriben en stdout o mediante un SDK asincrónico. Un agente de nodo agrupa en lotes, redacta y utiliza una cola en disco finito. Un gateway regional autentica la carga de trabajo, vincula el tenant, aplica cuotas y valida el formato antes de escribir en un flujo durable replicado entre zonas de disponibilidad. Esa confirmación es el límite de confirmación de recepción. Los procesadores normalizan los eventos, escriben registros sin procesar en almacenamiento de objetos y escriben campos aprobados más texto seleccionado en un índice de búsqueda activo (hot). El servicio de consultas requiere predicados de tenant y tiempo, y enruta ventanas entre almacenamiento hot, warm y de archivo. El tráfico bruto en estado estable es de unos 600 MB/s o 51.84 TB/día. Una ráfaga de 3x durante 15 minutos genera un backlog de aproximadamente 1.08 TB por encima del procesamiento en estado estable. La entrega es de al menos una vez con deduplicación por eventId. Durante una sobrecarga, se preservan primero los logs de auditoría y de error, se muestrean primero los logs de depuración y se expone cada descarte como una métrica alertable.”

Análisis detallado paso a paso

Comience con seis invariantes:

1. Una solicitud de negocio ordinaria no debe depender sincrónicamente de la plataforma remota de registro de logs.
2. El sistema central confirma la recepción de un evento solo después de que este llega al almacenamiento en búfer durable y replicado.
3. La identidad del tenant proviene de la autenticación, y la ingesta, el almacenamiento, la búsqueda y la exportación no pueden cruzar los límites del tenant.
4. Los logs de auditoría no utilizan la política de muestreo y descarte de los logs de depuración.
5. Los atributos de usuario arbitrarios no se indexan dinámicamente de forma predeterminada, evitando que los campos de alta cardinalidad aumenten el esquema

sin límite.

1. Los descartes, retrasos, fallas de procesamiento sintáctico y fallas de redacción son medibles y nunca silenciosos.

Paso 1: Definir la ruta de recolección y el límite de confirmación de recepción.

Application stdout / asynchronous SDK
  -> node agent or sidecar: batch, compress, redact, local disk spool
  -> regional ingestion gateway: authenticate, bind tenant, quota, mandatory redaction, format and size limits
  -> durable stream replicated across availability zones
  -> normalization and routing processors
       -> raw object-storage archive
       -> hot search index
       -> alerts and streaming subscriptions
  -> query coordinator -> hot / warm / archive readers

Las aplicaciones normalmente escriben en stdout para que el agente del nodo permanezca desacoplado de los procesos de negocio. Un SDK asincrónico es razonable para eventos explícitamente estructurados, pero aun así escribe en una cola en memoria o en un agente local. El agente agrupa en lotes por bytes y tiempo, limita el tamaño de cada evento, persiste su posición y utiliza una cola en disco finito durante fallas de red. Cuando el disco se llena, sigue una política por clase de log en lugar de bloquear indefinidamente o consumir disco sin límite.

El gateway regional deriva el tenant, el servicio y el entorno a partir de la identidad mTLS, la identidad de la carga de trabajo o credenciales de corta duración, sobrescribiendo cualquier campo falso en el cuerpo. Aplica límites de tasa, descomprime datos, realiza verificaciones básicas de esquema, impone un tamaño máximo por evento y aplica la redacción obligatoria de secretos y tokens antes de que los datos ingresen al búfer durable central. Confirma la recepción solo después de que el evento se haya replicado en un flujo durable entre zonas de disponibilidad. La búsqueda, los archivos y las alertas son consumidores separados, por lo que un consumidor fallido no se convierte en una dependencia directa de cada productor.

Paso 2: Utilizar un modelo de datos común con puntos de extensión controlados.

LogEvent(
  eventId, timestamp, observedTimestamp,
  tenantId, service, environment, instance,
  severityNumber, severityText, body,
  traceId, spanId, schemaVersion,
  attributes, sensitivityClass
)

timestamp es cuando ocurrió el evento, mientras que observedTimestamp es cuando el sistema de recolección lo vio por primera vez. Si los relojes de origen se desvían, este último sigue exponiendo el orden y el retraso de ingesta. traceId y spanId conectan los logs con los trazos distribuidos. severityNumber permite comparaciones normalizadas mientras que severityText preserva la redacción original del productor. schemaVersion permite a los procesadores actualizar las reglas de procesamiento sintáctico de manera segura.

Los campos estables de nivel superior tienen tipos e índices explícitos. attributes retiene datos estructurados adicionales, pero solo los campos registrados en la lista de permitidos pueden ingresar a los mapeos del índice. Los atributos desconocidos pueden usar un objeto aplanado, una columna de clave-valor o el cuerpo sin procesar. Si el mismo campo cambia de número a objeto, el procesador lo pone en cuarentena como un error de procesamiento sintáctico o escribe un campo versionado. Un despliegue defectuoso no debe romper un índice compartido completo.

El agente puede generar eventId a partir de la instancia de origen, el epoch de arranque y la secuencia local. La entrega es de al menos una vez, por lo que un agente reintenta cuando no recibe una confirmación. Los consumidores y las escrituras en el índice utilizan eventId de forma idempotente. Las ventanas de deduplicación son finitas y los archivos pueden conservar duplicados. Las consultas y agregaciones deben entender esta semántica en lugar de pretender una entrega de exactamente una vez de extremo a extremo, costosa y frágil.

Paso 3: Planificar el particionamiento y el aislamiento de tenants.

El flujo durable escala mediante particiones virtuales. Una clave de enrutamiento puede calcular el hash de (tenantId, sourceInstance), preservando el orden aproximado para un origen y distribuyendo al mismo tiempo a un tenant en múltiples particiones. Particionar únicamente por tenantId convierte a un tenant grande en un punto caliente (hotspot). Un particionamiento puramente aleatorio pierde el orden local del origen. Los tenants grandes pueden recibir grupos dedicados de particiones mientras que los pequeños comparten un grupo, y el plano de control puede rebalancear la asignación sin modificar el formato del evento.

Cada tenant tiene cuotas de bytes de ingesta, tasa de eventos, tokens de ráfaga, backlog local y central, recuento de campos indexados, almacenamiento hot, concurrencia de consultas, bytes escaneados y trabajos de exportación. Los rechazos y la degradación se registran por tenant. Durante una sobrecarga del sistema, el orden de prioridad puede ser:

1. Preservar eventos de auditoría y seguridad.
2. Preservar errores y eventos operativos críticos.
3. Muestrear advertencias repetitivas, logs informativos y logs de depuración según la política declarada.
4. Rechazar nuevas consultas amplias y exportaciones de baja prioridad.

Un índice hot compartido funciona para tenants pequeños, pero cada documento, clave de caché y plan de consulta debe incluir un tenantId de confianza. Los tenants grandes o con regulaciones estrictas pueden usar índices aislados y límites de cifrado. El diseño no debe crear muchos shards diarios vacíos para cada tenant pequeño ni colocar a todos los tenants en un único índice compartido sin límites.

Paso 4: Separar el archivo sin procesar del índice de búsqueda.

El almacenamiento de objetos guarda eventos sin procesar normalizados en archivos columnares comprimidos de gran tamaño particionados por región, tenant, fecha, hora y opcionalmente servicio. Es la fuente de bajo costo y a largo plazo para exportaciones de cumplimiento, escaneos históricos y para reconstruir un índice hot dañado. Los escritores agrupan los eventos en objetos de tamaño adecuado en lugar de crear un objeto por cada línea de log.

El índice de búsqueda activo (hot) almacena únicamente datos recientes sobre los que se puedan realizar búsquedas. Los campos estables utilizan índices invertidos o columnares, mientras que la indexación de texto completo del cuerpo puede variar según la clase de log. Los ID de solicitud, ID de usuario o etiquetas arbitrarias de alta cardinalidad permanecen como campos solo almacenados cuando no se consultan con frecuencia. traceId también tiene alta cardinalidad, pero cuenta con un caso de uso claro de búsqueda exacta, por lo que puede utilizar un campo exacto dedicado con retención acotada sin sentar un precedente para todos los campos dinámicos.

Un controlador de ciclo de vida traslada los datos por clase desde los niveles hot a warm, cold, frozen o de archivo. El almacenamiento hot cuenta con más cómputo y réplicas para escrituras y búsquedas de baja latencia. Los datos más antiguos cuestan menos y admiten un acceso más lento. La eliminación por retención debe abarcar índices, archivos, cachés, exportaciones y retenciones legales (legal holds). Borrar un solo índice de búsqueda no constituye un flujo de trabajo de eliminación completo.

Paso 5: Construir una ruta de consulta controlada.

La API de consultas deriva el tenantId a partir de la sesión y requiere de forma predeterminada startTime, endTime y un servicio u otra condición selectiva. El coordinador examina el rango de tiempo y la clase de log, y luego enruta la solicitud a índices hot, almacenamiento warm o un escaneo asincrónico de archivos. A continuación se muestran interfaces de ejemplo:

POST /logs/search
  { startTime, endTime, services, severities, traceId, query, cursor, limit }
  -> { events[], nextCursor, partial, scannedBytes }

POST /logs/exports
  { startTime, endTime, filters }
  -> { jobId }

Los resultados utilizan la clave de ordenamiento estable (timestamp, eventId) y paginación por cursor en lugar de desplazamientos (offsets) profundos. Las consultas interactivas tienen límites de bytes escaneados, filas devueltas, tiempo de ejecución y concurrencia. Cuando se alcanza un límite, la respuesta devuelve un marcador explícito partial en lugar de omitir datos silenciosamente. Las expresiones regulares amplias, las búsquedas de texto completo de 90 días y las exportaciones grandes entran en una cola asincrónica y pueden cancelarse. Los metadatos de los filtros comunes pueden almacenarse en caché, pero los resultados de las consultas no pueden reutilizarse entre tenants sin un aislamiento total.

El objetivo p95 por debajo de 2 segundos aplica a consultas filtradas selectivas sobre los últimos 15 minutos en un clúster en buen estado. Un escaneo de texto completo sin límites sobre todos los datos retenidos no comparte ese SLO. Definir clases de consulta resulta más creíble que prometer que todas las consultas serán rápidas.

Paso 6: Calcular la capacidad.

El rendimiento bruto en estado estable es:

1,000,000 events/s × 600 bytes = 600 MB/s
600 MB/s × 86,400 s = 51.84 TB/day

El tráfico aumenta de 1 millón a 3 millones de eventos por segundo durante 15 minutos. Si el procesamiento posterior solo puede sostener la tasa de estado estable, debe absorber este backlog adicional:

(3,000,000 - 1,000,000) × 600 bytes × 900 s = 1.08 TB

La ráfaga produce 1.62 TB en total durante esos 15 minutos, pero 0.54 TB corresponden a la línea base que el procesamiento en estado estable maneja al mismo tiempo. El almacenamiento en búfer real también requiere replicación, sobrecarga por lotes, capacidad de recuperación y margen de seguridad, por lo que 1.08 TB no es una cifra final para adquisición de hardware.

Si solo el 20% de los logs ingresa a un índice hot estructurado o de texto completo y permanece allí durante 7 días, el volumen bruto antes de la sobrecarga de indexación sigue siendo:

51.84 TB/day × 20% × 7 = 72.576 TB

El tamaño real del índice depende de los campos, la compresión, los shards y las réplicas, y debe medirse mediante pruebas de carga. Noventa días de archivos sin procesar equivalen a 51.84 TB × 90 = 4.6656 PB, o aproximadamente 4.67 PB antes de la compresión. Esta escala hace que la división en niveles (tiering), la retención basada en clases, la compresión y la eliminación de logs de bajo valor sean más importantes que simplemente agrandar el clúster de búsqueda.

Deduzca la cantidad de particiones a partir de los bytes sostenidos por partición, los eventos por partición y la velocidad de reproducción requerida. Las pruebas de capacidad deben combinar la pérdida de una zona de disponibilidad, la recuperación de consumidores atrasados y una ráfaga de 3x, asegurando que la antigüedad del mensaje más antiguo termine recuperándose. Contar únicamente los eventos es insuficiente porque los stack traces pueden cambiar drásticamente el tamaño promedio.

Paso 7: Manejar contrapresión, tormentas de logs y caídas de servicios posteriores.

Cada capa tiene una capacidad finita: memoria del SDK, disco del agente, conexiones del gateway, retención del flujo, concurrencia de procesadores, colas de escritura en índices e hilos de consulta. El sistema propaga la presión mediante retry-after, lotes más pequeños, consumidores pausados y colas de prioridad. Cuando el disco del agente se acerca a su límite, muestrea primero los logs de depuración según la política y registra contadores locales por clase descartada. Los eventos de auditoría utilizan un grupo reservado independiente o activan una política explícita de fallo de negocio.

La guía de resolución de problemas de OpenTelemetry Collector señala que tanto un destino no disponible como un Collector subdimensionado pueden provocar descartes. Las colas de envío y los reintentos cubren fallas temporales, pero una cola sobredimensionada también puede crear presión en la memoria. Por lo tanto, “habilitar reintentos” no es en sí mismo un plan de confiabilidad. Monitoree la utilización de colas, la antigüedad del evento más antiguo, los rechazos, los fallos permanentes y la memoria del proceso, y active alertas antes de que se agote la capacidad.

Si el clúster de índices no está disponible, el flujo durable continúa aceptando datos, y los consumidores del archivo sin procesar y del índice avanzan de forma independiente. Durante la recuperación, los consumidores del índice se ponen al día aplicando equidad entre tenants y límites de reproducción para no sobrecargar nuevamente el clúster recién restaurado. Cuando la indexación se retrasa, la interfaz de usuario muestra la marca de agua de frescura de búsqueda y el intervalo faltante. Los usuarios no deben interpretar “sin resultados de búsqueda” como “el log no existe”.

Paso 8: Cerrar el ciclo de seguridad, privacidad y eliminación.

El mejor control para datos sensibles es evitar generar el valor. Los SDKs ofrecen listas de permitidos para campos estructurados. Los agentes redactan patrones comunes de tokens, contraseñas, cookies y datos personales. El gateway aplica reglas obligatorias antes del flujo durable central, y los procesadores posteriores realizan una redacción semántica basada en el esquema y enrutan los eventos fallidos a cuarentena. Un cuerpo sin procesar no puede eludir la seguridad simplemente porque se destine únicamente a un archivo.

El transporte utiliza mTLS o identidades de carga de trabajo de corta duración, y los datos se cifran en reposo con límites de claves según el entorno o el tenant regulado. RBAC restringe tenant, entorno, servicio, campos y rangos de tiempo. Las consultas, exportaciones, cambios de retención y retenciones legales generan eventos inmutables de auditoría de acceso. Los campos altamente sensibles pueden utilizar cifrado a nivel de campo o ser eliminados por completo; ocultarlos en la interfaz de usuario no es suficiente.

La eliminación es un flujo de trabajo trazable a través de índices hot, niveles warm, particiones de objetos, cachés y copias de exportación. Cuando la retención de auditoría entra en conflicto con una solicitud de eliminación por privacidad, las políticas de producto y legales deben definir la precedencia, las excepciones y las retenciones legales. El sistema ejecuta esa política explícita; no puede escudarse en que “los logs son inmutables” para eludir una obligación de eliminación.

Paso 9: Validar el sistema con métricas e inyección de fallas.

Las métricas principales incluyen p50/p95/p99 desde la creación hasta el gateway, desde el gateway hasta el flujo durable, desde el flujo hasta el archivo y desde el flujo hasta la visibilidad en búsquedas; utilización de colas, antigüedad del evento más antiguo, reintentos y descartes en cada etapa; ingesta, limitación (throttling), cardinalidad de campos y costo por tenant; rechazos de índices, crecimiento de mapeos, bytes escaneados, tiempos de espera de consultas, cancelaciones y aciertos en caché; fallas de redacción, denegaciones de autorización y éxito en la restauración de archivos.

Un canario de extremo a extremo escribe cada minuto un evento estructurado con un ID único desde cada región y verifica la aceptación durable, la visibilidad en búsquedas, la presencia en el archivo de objetos y la eventual eliminación por retención. La conciliación de recuentos compara los totales de enviados por el agente, aceptados por el gateway, confirmados en el flujo, escritos en el archivo y exitosos en el índice. Se permiten duplicados justificados. Las diferencias no atribuidas no se permiten.

Las pruebas de fallas incluyen una tormenta de logs de 3x durante 15 minutos, una caída de búsqueda de 30 minutos, limitación (throttling) en el almacenamiento de objetos, pérdida de una zona de disponibilidad, un tenant caliente, un ataque de campos de alta cardinalidad, un esquema inválido, desfase en los relojes de origen, inyección de datos sensibles, agotamiento del disco del agente, lotes duplicados, reproducción de flujos y reconstrucción de un índice hot a partir de archivos. Las afirmaciones críticas son que los eventos de auditoría sigan siendo recuperables según la política, que cada descarte de log ordinario cuente con evidencia de tenant, clase, tiempo y recuento, y que los usuarios y las alertas puedan visualizar la degradación en la frescura de búsqueda.

Respuesta de ejemplo de alta calidad

“Comenzaría separando la aceptación durable de la visibilidad en búsquedas. Las aplicaciones escriben en stdout o a través de un SDK asincrónico, y un agente de nodo gestiona la agrupación en lotes, la redacción y el almacenamiento en búfer en disco finito, de modo que una caída en el registro de logs no bloquee sincrónicamente las solicitudes ordinarias del negocio. El gateway regional deriva el tenant a partir de la identidad de la carga de trabajo, aplica cuotas y reglas de formato, y luego confirma el lote en un flujo durable replicado entre zonas de disponibilidad. Ese es el punto de aceptación central. Los índices de búsqueda y los archivos de objetos consumen de forma asincrónica.

Los eventos cuentan con campos estables de nivel superior para tiempo del evento, tiempo observado, tenant, servicio, entorno, instancia, severidad, cuerpo, traceId, spanId, versión de esquema y sensibilidad. Los atributos arbitrarios se almacenan de forma predeterminada. Solo los campos estables, con tipos bien definidos y con valor real de consulta ingresan al índice, evitando que los atributos de alta cardinalidad provoquen un crecimiento en los mapeos y en el índice. La entrega es de al menos una vez. El agente reintenta con un eventId estable, y las escrituras en el índice son idempotentes, aunque los archivos pueden conservar duplicados identificables.

El almacenamiento de objetos guarda registros sin procesar a largo plazo que pueden reproducirse, mientras que el nivel de búsqueda activo (hot) mantiene solo los datos recientes y consultables. Las consultas requieren un tenant y un rango de tiempo confiables, se enrutan a través de los niveles hot, warm y de archivo, y limitan los bytes escaneados, la concurrencia y el tamaño de los resultados. Las búsquedas de texto completo históricas y amplias, así como las exportaciones, se convierten en trabajos asincrónicos. Los tenants pequeños comparten índices y los tenants grandes pueden estar aislados, pero las cuotas de ingesta, backlog, campos y consultas siempre se aplican por tenant.

En estado estable, la ingesta bruta es de 600 MB/s o 51.84 TB/día. Una ráfaga de 3x durante 15 minutos añade aproximadamente 1.08 TB de backlog si el procesamiento posterior permanece en su capacidad estable. Indexar solo el 20% durante 7 días sigue produciendo unos 72.6 TB antes de la sobrecarga del índice, mientras que 90 días de archivos sin procesar representan unos 4.67 PB antes de la compresión. Por lo tanto, la indexación selectiva, la retención basada en clases y la división en niveles son obligatorias.

Durante una falla, el flujo durable absorbe el backlog temporal y los consumidores de archivo e índice se recuperan de forma independiente. Cada búfer es finito. El sistema preserva primero los eventos de auditoría y error, muestrea primero los eventos de depuración y expone los descartes, la antigüedad del mensaje más antiguo y la marca de agua de frescura de búsqueda a la monitorización y a la UI. Finalmente, ejecutaría un canario único a través del productor, el flujo, el índice y el archivo, e inyectaría tráfico 3x, caídas en servicios posteriores, campos de alta cardinalidad y agotamiento de disco para demostrar que no hay pérdidas silenciosas y que los índices pueden reconstruirse a partir de los archivos.”

Errores comunes

• Llamar sincrónicamente a una API de logs remota desde la aplicación → una caída en los logs perjudica las solicitudes de negocio

→ escribir a un agente asincrónico local con búfer finito y degradación explícita.

• Confirmar la recepción solo después de escribir en el clúster de búsqueda → el mantenimiento del índice genera contrapresión sobre todos los productores

→ confirmar la recepción tras escribir en el flujo durable replicado.

• Indexar dinámicamente cada campo JSON → la alta cardinalidad provoca explosión de mapeos y costos incontrolados

→ indexar únicamente campos estables en listas de permitidos.

• Usar una partición de flujo por ID de tenant → un tenant grande se convierte en un punto caliente (hotspot) en una sola partición

→ usar particiones virtuales basadas en tenant y origen, con grupos dedicados cuando esté justificado.

• Afirmar orden global tras un particionamiento aleatorio → los relojes y los orígenes paralelos no pueden proporcionarlo

→ preservar el orden local del origen y mantener una marca de tiempo observada.

• Usar “exactamente una vez” para ocultar duplicados → las respuestas perdidas y las reproducciones siguen ocurriendo

→ usar entrega de al menos una vez, eventId estable y escrituras idempotentes.

• Asumir que una cola ilimitada previene pérdidas → el disco, la memoria y la retención eventualmente se llenan

→ establecer límites de capacidad, monitorear la antigüedad máxima, priorizar clases y conservar evidencia de descartes.

• Muestrear todos los logs de forma uniforme durante una tormenta → la evidencia de auditoría también se descarta

→ definir la confiabilidad y la degradación por separado para cada clase de log.

• Prometer que cada consulta finalizará en 2 segundos → un escaneo de texto completo de 90 días perjudica al clúster interactivo

→ separar las consultas selectivas hot de los escaneos históricos asincrónicos.

• Tratar un resultado vacío en la UI como prueba de que no existen logs → el retraso en el índice oculta evidencia del incidente

→ mostrar marcas de agua, resultados parciales y ventanas faltantes.

• Eliminar solo el índice hot → los archivos, cachés y exportaciones aún contienen valores sensibles

→ utilizar un flujo de trabajo de eliminación auditable a través de todas las copias.

• Monitorear únicamente si el proceso del Collector está activo → un proceso en buen estado aún puede descartar datos

→ conciliar recuentos entre etapas y monitorear colas, rechazos y fallos permanentes.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Por qué no permitir que los agentes escriban directamente en el clúster de búsqueda?

Eso es razonable para una herramienta interna pequeña porque tiene menos componentes y ofrece frescura de búsqueda directa. A esta escala, los cambios de shards en la búsqueda, los fallos de mapeo y los rechazos de escritura se propagarían a 100,000 orígenes. Un flujo durable crea un límite de confirmación de recepción, absorbe ráfagas, permite que los consumidores se recuperen de forma independiente y admite la reproducción. Implica costos operativos adicionales, duplicados y retraso asincrónico. Si la escala medida es pequeña, elija la ruta directa en lugar de añadir un broker solo para el diagrama.

Pregunta de seguimiento 2: ¿Qué sucede si un campo de repente tiene millones de valores distintos?

El registro de esquemas guarda los campos indexables, tipos, equipos propietarios y presupuestos de cardinalidad. Los procesadores utilizan recuentos aproximados de valores distintos para supervisar la cardinalidad. Cuando un campo supera su límite, dejan de crear nuevas estructuras de índice, conservan el valor como un atributo no indexado y notifican al tenant. Si la explosión de mapeos ya ocurrió, primero bloquee los nuevos campos y corrija el formato upstream, luego reconstruya los campos válidos en un nuevo índice. Dividir el mismo conjunto de campos ilimitados en más índices no resuelve su crecimiento.

Pregunta de seguimiento 3: ¿Qué sucede cuando tanto el flujo durable como la cola local en disco están llenos?

Un sistema finito no puede garantizar una ráfaga infinita. El agente reserva capacidad por clase de log: los eventos de auditoría utilizan el canal más robusto, los errores tienen prioridad sobre los eventos informativos y los logs de depuración se muestrean o descartan primero. Cada descarte se cuenta localmente y se reporta tras la recuperación. Si una operación de negocio requiere que un evento de auditoría específico sea durable, la operación puede fallar explícitamente o usar un transactional outbox local. Una llamada de depuración ordinaria no debe bloquear toda la aplicación indefinidamente.

Pregunta de seguimiento 4: ¿Cómo se reconstruye el índice de búsqueda a partir del almacenamiento de objetos?

Los objetos archivados incluyen la versión del esquema, la partición de tiempo, el tenant, la suma de verificación y un manifiesto. Un trabajo de reconstrucción selecciona un tenant y una ventana, lee y verifica los manifiestos, transforma los registros con el mapeo actual y escribe en un nuevo índice de forma idempotente mediante eventId. Compara recuentos, límites de tiempo y canarios antes de cambiar atómicamente un alias o una ruta. El tráfico de reconstrucción tiene una cuota separada para no privar de recursos a la indexación en tiempo real.

Pregunta de seguimiento 5: ¿Cómo evita que la consulta de un tenant perjudique a los demás?

El planificador mantiene depósitos de tokens (token buckets) por tenant para concurrencia, tiempo de CPU, bytes escaneados y filas devueltas, y utiliza colas equitativas ponderadas (weighted fair queuing). Las consultas interactivas tienen prioridad sobre las exportaciones, y las tareas costosas pueden cancelarse o moverse a segundo plano de forma asincrónica. Las claves de caché compartidas incluyen resúmenes de tenant y permisos. Los tenants grandes o altamente regulados pueden recibir grupos de índices aislados, pero aísle solo después de medir el cuello de botella para evitar que los tenants pequeños generen una cantidad excesiva de shards diminutos.

Pregunta de seguimiento 6: ¿Por qué los logs de auditoría necesitan una política separada?

Los logs de auditoría existen para demostrar quién hizo qué y cuándo. El muestreo, el contenido mutable y la eliminación administrativa ordinaria anularían ese propósito. Necesitan esquemas más estrictos, procedencia autenticada, verificaciones de integridad, archivos inmutables, consultas restringidas y auditoría de accesos. Aun así, siguen las políticas de eliminación por privacidad y retención legal, por lo que “inmutable” significa que las rutas ordinarias no pueden alterarlos, no que un flujo de trabajo de cumplimiento autorizado nunca pueda intervenir.

Pregunta de seguimiento 7: ¿Cómo extendería el diseño a múltiples regiones?

Cada región escribe primero los eventos locales en un flujo durable y archivo locales para que las solicitudes de negocio no esperen a través de los continentes. Los eventos llevan IDs de región y de tenant global, y el plano de control distribuye esquemas, cuotas y reglas de retención. Un coordinador global de consultas distribuye la solicitud por tiempo y región y marca resultados parciales cuando una región no está disponible. Si las regulaciones exigen residencia de datos, los logs sin procesar permanecen locales y solo los índices o agregados aprobados cruzan entre regiones. La recuperación ante desastres se restaura a partir de archivos de objetos locales o replicados de forma conforme.

Pregunta de seguimiento 8: ¿Cómo demuestra que el sistema no está perdiendo logs de forma silenciosa?

Cada lote registra el recuento de origen y la suma de verificación. Cada etapa emite recuentos de aceptados, duplicados, rechazados, fallidos permanentemente y exitosos. Un canario único atraviesa continuamente el agente, el gateway, el flujo durable, el índice y el archivo. La conciliación permite duplicados justificados por eventId y descartes justificados por una política explícita de cuotas. Cualquier diferencia no atribuida se considera un incidente. Luego, detenga la indexación durante 30 minutos y recupérela, verificando que la antigüedad del mensaje disminuya, que los canarios cubran el intervalo y que la marca de agua de frescura en la UI se restablezca, en lugar de limitarse a comprobar que el proceso simplemente se reinició.