Día 3 (tarde) -- Sensor defectuoso inunda stream

### Miércoles, 14:30 -- La alerta de Grafana

Estas a mitad del pipeline de BMW cuando suena una alerta en el canal #data-alerts de Slack. El dashboard de Kafka en Grafana muestra un spike brutal: el topic sensors.vibration.v2 ha pasado de 1.15 MB/s a 18 MB/s en 2 minutos. El consumer lag de Spark está creciendo exponencialmente.

1[14:32] #data-alerts
2CRITICAL: kafka.topic.bytes_in_per_sec > 15 MB/s en sensors.vibration.v2
3  Valor actual: 18.3 MB/s (normal: 1.15 MB/s)
4  Duracion: 2 min 15 seg
5  Impacto: consumer lag creciendo 50K msgs/min
6
7[14:33] Kenji en #data-team:
8"Estoy mirando. Una particion tiene 16x más tráfico que las demas.
9Partition 7 (LINE-04). Algun sensor se ha vuelto loco."
10
11[14:34] Patricia en #data-team:
12"Linea 4 es la de discos de freno. Si el sensor está emitiendo basura
13podemos estar generando alertas falsas de mantenimiento. SILENCIAR
14alertas de L04 hasta que lo resolvamos."
15
16[14:35] Fernando en #data-team:
17"Resuelvan esto rápido. Si el lag de Spark sigue creciendo, las alertas
18de mantenimiento de TODA la planta se retrasan. No solo linea 4."

### Diagnóstico: qué está pasando

Investigas con Kenji. El sensor SENS-VIB-L04-M089-02 está emitiendo a 250 Hz en lugar de 5 Hz -- 50 veces más rápido de lo normal. Es un fallo de firmware: el MVM-500 entró en modo diagnóstico por un glitch eléctrico y ahora emite lecturas continuas sin respetar el sample_rate configurado. El resultado: un único sensor genera 250 eventos/segundo = 50 KB/s, cuando debería generar 5 ev/s = 1 KB/s.

El impacto cascade:

1. 01.Kafka partition 7 recibe 50x su tráfico normal (linea 4 va a partition 7 por el hash de LINE-04)
2. 02.El consumer de Spark para esa particion no puede procesar a esa velocidad -- lag crece
3. 03.Como Spark procesa todas las particiones juntas, el lag de una particion retrasa TODAS las ventanas
4. 04.Las features de mantenimiento predictivo de TODA la planta se retrasan -- alertas fuera de SLA
5. 05.Si no se resuelve en 30 minutos, el lag será irrecuperable sin intervención manual

Este es un problema clásico en sistemas IoT: un único dispositivo defectuoso puede saturar toda la infraestructura downstream. La solución: un circuit breaker que detecte anomalías de volumen por sensor y lo aísle automáticamente.

### Solución inmediata (manual) vs solución permanente (circuit breaker)

Fernando te mira: "Necesito dos cosas. Primero, resolver AHORA el incidente -- silenciar ese sensor. Segundo, que esto no vuelva a pasar. Quiero un circuit breaker automático que detecte cuando un sensor emite más de 10x su rate normal y lo ponga en cuarentena sin intervención humana. Para mañana."

Solución inmediata: Kenji añade una regla de drop en el bridge MQTT para el sensor específico. El sensor sigue emitiendo pero los mensajes se descartan en el bridge antes de llegar a Kafka. En 5 minutos el tráfico de la partición 7 vuelve a la normalidad y el lag empieza a decrecer.

Solución permanente: un componente de circuit breaker entre el bridge MQTT y Kafka que monitoriza el rate por sensor_id y aplica reglas de cuarentena automáticas. El diseño:

• ▹MONITOR: Conteo de eventos por sensor_id en ventana deslizante de 1 minuto
• ▹DETECT: Si count > 10x el rate esperado para ese tipo de sensor, marcar como anomalo
• ▹ISOLATE: Redirigir eventos del sensor anomalo a un topic de cuarentena (sensors.quarantine)
• ▹NOTIFY: Publicar alerta crítica con sensor_id, rate observado, rate esperado
• ▹RECOVER: Despues de 5 minutos, verificar si el rate volvio a la normalidad. Si si, reintegrar.
• ▹AUDIT: Loggear toda decisión del circuit breaker para post-mortem