Simulador de pipelines de logs: así se pierden datos

Cuando el sistema de pagos empieza a fallar, el equipo de guardia recurre a la búsqueda de logs. Filtra por ERROR, escribe “timeout del proveedor de pagos” y obtiene un solo resultado. ¿Es un timeout aislado o el único que sobrevivió al trayecto? Esa duda es clave: una búsqueda de logs muestra lo que llegó al índice, no lo que la aplicación escribió. Entre ambos puntos hay un agente, un parser, un filtro, un búfer y un clúster de búsqueda, y cada uno puede retrasar, rechazar o descartar una línea sin que la aplicación lo sepa. Por eso es fundamental entender el pipeline de agregación de logs etapa por etapa: durante un incidente, una búsqueda vacía no distingue entre un sistema sano y una evidencia que nunca llegó.

Para visualizar ese recorrido, un nuevo simulador interactivo permite observar el flujo de logs en seis etapas y romperlo de tres formas distintas. La herramienta, que se ejecuta en el navegador sin registro, mueve los logs en lotes y los contabiliza en cada etapa, en lugar de rastrear una sola línea. Está diseñada como un juego DevOps gratuito y ya está disponible para el público hispanohablante.

Seis etapas, cinco contadores y una regla de oro

El simulador representa el pipeline como seis tarjetas: Generación, Recolección, Procesamiento, Búfer, Indexación y Búsqueda. Cada paso avanza una etapa; el flujo automático avanza aproximadamente una vez por segundo. Bajo las tarjetas, cinco contadores llevan la contabilidad: Generados, En búfer, Indexados, Rechazados y Descartados. El motor conserva cada evento: lo generado está en cola, filtrado, rechazado, indexado o descartado. El ruido filtrado no tiene contador propio; la tarjeta de Procesamiento suma filtrados y rechazados en su cifra de “eliminados”.

Esa disciplina contable es la que deberías aplicar en sistemas reales: si no puedes explicar la diferencia entre “enviado” y “buscable”, no puedes confiar en una búsqueda vacía. Al hacer clic en cualquier tarjeta, el inspector de etapa muestra su “señal del operador”, el dato clave a vigilar. Para la etapa de Búsqueda, la señal es contundente: “Solo los logs indexados son buscables; los filtrados, rechazados y descartados nunca llegan aquí”.

Tres escenarios para entrenar el diagnóstico

El simulador propone tres escenarios que reproducen fallas típicas en producción. Cada uno deja una lección distinta sobre dónde mirar cuando los datos no aparecen.

1. Pico de tráfico: el búfer no salva lo que nunca llega

En el escenario “Flujo saludable”, cada ciclo genera 24 logs, el filtro de ruido elimina 4 y se indexan 20. Las colas se vacían, la insignia indica “Pipeline saludable” y las barras de fragmentos crecen de manera uniforme. Al activar el pico de tráfico, las fuentes emiten 84 logs por ciclo, pero el colector solo reenvía 38. La insignia cambia a “Se está acumulando contrapresión” en el primer paso. En el tercer ciclo, el mensaje es claro: “Las fuentes emitieron 84 logs; 26 se descartaron antes de la recolección”. Mientras tanto, el búfer está vacío. La lección: un búfer duradero no puede salvar logs que se pierden antes de llegar a él. Al final del quinto ciclo, se generaron 420 logs, se indexaron 140 y se descartaron 118. El contador “para parseo” del colector también sube 4 por ciclo: el colector envía 38, el procesador recibe 34.

2. Desajuste del parser: el peligro de mirar solo los descartes

Un despliegue cambia el formato de los logs. De 30 logs por ciclo, 4 se filtran como ruido, 11 son rechazados por el parser y solo 15 se indexan. La insignia indica “Rechazos del parser detectados” y no hay descartes, por lo que un tablero que solo vigila descartes permanece en verde. Probar el parser Grok no ayuda: solo maneja 27 de los 30 logs por ciclo, por lo que 3 más esperan en la cola del procesador cada ciclo; de esos 27, filtra 4, rechaza 10 e indexa 13. Un parser más lento que además no coincide con el formato empeora las cosas. El simulador no tiene una solución mágica para el parser; en la realidad, actualizas el parser al nuevo formato o reviertes el cambio.

3. Indexación lenta: cuando el búfer se desborda

Vuelve a seleccionar el parser JSON (el simulador conserva tu elección al cambiar de escenario). El clúster de búsqueda indexa 9 logs por ciclo mientras 32 llegan al búfer (36 arriban y el filtro de ruido elimina 4). El búfer sube 23 cada ciclo, la advertencia aparece en el tercer ciclo y en el quinto: “El búfer alcanzó su capacidad y descartó los 19 logs más antiguos”. Si desactivas “Descartar ruido de health-check” y vuelves a ejecutar, el primer descarte ocurre un ciclo antes. Filtrar el ruido antes del búfer no arregló el indexador lento, pero ganó tiempo.

Cómo usar el simulador como entrenamiento

Cada escenario puede vivirse como un simulacro de guardia. Imagina que solo tienes la pestaña de búsqueda y usa el resto de la pantalla para responder cuatro preguntas en orden. La clave está en asociar la mitigación con la señal: capacidad del colector para el pico, parser para el desajuste, capacidad de indexación o reducción de ruido para la indexación lenta.

Puedes reproducir el desajuste del parser con jq y tres líneas de log. Con jq 1.6, el primer comando imprime solo la línea de error JSON. El segundo imprime el texto plano ERROR checkout payment provider timeout after=3s. Se registraron dos timeouts y la búsqueda encuentra uno. Cuenta la segunda salida y alerta sobre ella: tienes una métrica de rechazos del parser.

Lo que las herramientas reales hacen con los rechazos

Las herramientas reales no siempre descartan un rechazo. Cuando el parseo falla en la transformación remap de Vector, “el evento original sin modificar se envía aguas abajo” por defecto, por lo que la línea llega al índice como texto sin formato, sin tus campos. Los agentes reales tienen su propia versión de los otros dos escenarios. La documentación de contrapresión de Fluent Bit explica que cuando una entrada alcanza su mem_buf_limit, Fluent Bit (con almacenamiento en memoria) “dejará de almacenar datos de ese complemento de entrada hasta que se vacíen suficientes fragmentos almacenados”, y la mayoría de los complementos registran paused (mem buf overlimit). La misma página advierte que algunas entradas pueden perder datos con almacenamiento solo en memoria y sugiere almacenamiento en sistema de archivos para evitarlo. Busca esa advertencia en los logs de tu propio agente antes de asumir que la aplicación se quedó callada. Con almacenamiento en sistema de archivos, Fluent Bit descarta los datos más antiguos, como en el escenario de indexación lenta: en storage.total_limit_size de una salida, “el fragmento más antiguo de su cola se descartará”. Los búferes de Vector bloquean por defecto.

En herramientas reales, las señales de pérdida son contadores que puedes recolectar: fluentbit_output_retries_failed_total y fluentbit_output_dropped_records_total de Fluent Bit, component_discarded_events_total de Vector, y loki_discarded_samples_total de Loki, etiquetado por motivo. La página del simulador lista las señales que deben vigilarse en conjunto: tasa de entrada, antigüedad y profundidad de la cola, tasa de rechazo del parser, utilización del búfer, eventos descartados, latencia de indexación y balance de fragmentos.

El simulador es uno de más de 60 juegos y simuladores DevOps gratuitos. Ejecuta los tres escenarios hasta que puedas predecir los números del siguiente paso, y luego repítelos como simulacros con solo la pestaña de búsqueda abierta. ¿Dónde te ha descartado líneas un pipeline de logs sin que nadie lo notara? Compártelo en los comentarios.