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.pressure ha pasado de 0.13 MB/s a 0.75 MB/s en 2 minutos, y el consumer lag de Spark está creciendo. Todo el exceso viene de un solo sensor.

1[14:32] #data-alerts
2CRITICAL: circuit_breaker -- ingest_rate_anomaly en PSR-0087
3  Ritmo actual: 200.000 eventos/min (umbral: 5.000/min)
4  Normal para un sensor: ~60 eventos/min
5  Duracion: 2 min 15 seg
6  Impacto: consumer lag creciendo ~50K msgs/min
7
8[14:33] Kenji en #data-team:
9"Estoy mirando. Casi todo el trafico extra del topic de presion
10viene de un unico sensor_id: PSR-0087, en la maquina GRD-75.
11Y lo raro: manda siempre el mismo valor, 0.0."
12
13[14:34] Patricia en #data-team:
14"PSR-0087 es el sensor de presion del sistema hidraulico de GRD-75.
15Si esta clavado en cero es que ha muerto y el firmware se ha
16quedado en bucle. SILENCIAR sus alertas: cualquier cosa que
17saque de un sensor a cero es basura."
18
19[14:35] Fernando en #data-team:
20"Resuelvan esto rápido. Si el lag de Spark sigue creciendo, las alertas
21de mantenimiento de TODA la planta se retrasan. No solo la de GRD-75."

## Diagnóstico: qué está pasando

Investigas con Kenji. El sensor PSR-0087 está emitiendo unas 3.300 lecturas por segundo en lugar de 1 por segundo -- miles de veces más de lo normal -- y todas con el mismo valor, 0.0. Es un fallo de firmware: el transductor de presión ha muerto y su electrónica se ha quedado en un bucle que reenvía la última lectura sin parar, sin respetar el sample_rate configurado. El resultado: un único sensor genera ~3.300 eventos/segundo, cuando debería generar 1 ev/s, y encima ninguno de esos eventos lleva información -- son todos el mismo cero.

El impacto cascade:

1. 01.La partición del topic de presión donde cae PSR-0087 (por el hash de su machine_id, GRD-75) recibe miles de veces su tráfico normal
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 PSR-0087. El sensor sigue emitiendo pero sus mensajes se descartan en el bridge antes de llegar a Kafka. En 5 minutos el tráfico del topic de presión 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