Fallas y reproceso

4 tareas · 40 min · Principiante

Una tubería falla: cae un recolector, un mensaje llega mal formado, el destino rechaza un lote. Lo que distingue una tubería madura es lo que pasa con esos eventos después. Una cola de mensajes muertos los aparta para revisarlos, un plan de reproceso los reenvía y una regla de unicidad evita que lo reenviado cuente dos veces. En Textiles Quebrada Dorada lees la cola de muertos de una noche y calculas qué duplicaría un reproceso mal planeado.

0 de 4 · 0%

Objetivo de la sala

La mayoría de las tuberías prometen entregar al menos una vez: reintentan hasta que el destino confirma, y por eso un evento puede llegar repetido. Prometer exactamente una vez es mucho más caro y casi nunca se logra de extremo a extremo. Lo habitual es aceptar duplicados y eliminarlos al final, con un identificador estable de cada evento.

Responde para continuar

¿Qué hay que hacer para que una entrega repetida no cuente dos veces en una regla?

Dar a cada evento un identificador estable y descartar al llegar los ya recibidos Reducir los reintentos a uno, de modo que ningún evento se envíe nunca dos veces Contar los eventos por hora de ingesta, que es única para cada evento que llega al SIEM

Un mensaje que no se pudo entregar tras sus reintentos no se pierde: va a una cola de mensajes muertos, con el motivo del fallo. Allí se revisa. Un motivo repetido es un error de la configuración, no del mensaje; el motivo campo_obligatorio_ausente indica que un paso anterior quitó o no encontró un campo que el destino exige.

Responde para continuar

Escribe cuántos mensajes de la cola de muertos fallaron por un campo obligatorio ausente.

Ver pista de ayuda

Cuenta las filas de `cola_de_muertos` con ese motivo.

El recolector cayó de las 02:10 a las 03:40. Para recuperar lo que faltó, el plan (tabla plan_de_reproceso) reenvía el archivo desde las 02:05, con unos minutos de margen. Pero entre las 02:05 y las 02:09 el SIEM sí recibió eventos, y los eventos del archivo carecen de identificador estable, así que se contarían dos veces. Suma lo ya entregado en esos cinco minutos con entregas_antes_de_la_caida.

Responde para continuar

Escribe cuántos eventos quedarían duplicados por el reproceso.

Ver pista de ayuda

Suma `eventos_entregados` de las 02:05 a las 02:09, ambas incluidas.

El margen de cinco minutos es una buena idea, porque un reproceso que empieza justo en el límite puede perder el evento de la frontera. La condición es que el destino distinga el repetido. Sin identificador, el margen cambia pérdida por duplicados, y las reglas de umbral cuentan cualquiera de los dos como un falso resultado.

Responde para continuar

¿Qué debe resolverse antes de lanzar el reproceso?

Pedir a las fuentes que envíen otra vez toda su actividad de la noche completa por su cuenta Elegir una hora de inicio más tardía, que deje fuera todo lo entregado antes de la caída Añadir un identificador estable a los eventos o una marca que permita descartar repetidos

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 Al menos una vez

2 La cola de muertos Lab

3 Cuánto duplicaría el reproceso Lab

4 Antes de reprocesar

Whoami-Labs Pro utiliza cookies