Observabilidad sin Dashboards con Notificaciones | Daniel Tinizaray

Por qué esto importa ahora

Cada pipeline de procesamiento —video, ETL, CI/CD, inferencia— emite eventos. Generalmente los ignoramos o los mandamos a un sistema externo de monitoreo con toda la parafernalia: dashboards, alertas, retention policies, equipos dedicados.

Pero hay un patrón más simple: escuchar las notificaciones que tu sistema ya publica.

No estoy hablando de reemplazar Datadog en una empresa de 500 personas. Estoy hablando del 90% de los equipos pequeños y medianos que gastan más tiempo configurando dashboards del que ahorran usándolos. Que tienen un pipeline funcionando, código que publica eventos en algún canal (un webhook, una cola, un pub/sub simple), y toda la información que necesitan ya está ahí —solo hay que leerla.

1. Tu Pipeline ya Habla. ¿Lo estás Escuchando?

Cada vez que tu sistema completa un trabajo, publica un mensaje. Generalmente incluye:

• Estado (éxito/error)
• Duración total
• Métricas específicas del proceso (tamaño del archivo, velocidad de procesamiento, cuello de botella detectado)
• Timestamps de inicio y fin
• Usuario o proyecto que lo disparó

Ese mensaje, en crudo, ya es más valioso que la mayoría de dashboards que verías después. El problema no es la falta de datos —es que esos datos se pierden en un mar de notificaciones que nadie lee.

La solución no es otro dashboard. Es un parser que lea esos mensajes, los estructure y los compare contra el histórico.

2. El Patrón: Cola de Eventos → Parser → Reporte

El ciclo es simple y aplica a cualquier pipeline:

1. Fuente: Tu pipeline publica eventos estructurados (JSON plano) en un canal pub/sub ligero —puede ser NTFY, un webhook de Slack, SQS, Redis, o simplemente un archivo de log rotado.
2. Parser: Un proceso (un hook serverless, un script cron, o un agente) consume esos mensajes, extrae las métricas relevantes y las normaliza.
3. Comparador: Compara los datos actuales con una línea base histórica guardada localmente.
4. Reporte: Si hay cambios relevantes, genera un informe. Si no, silencio.

El truco está en no procesar todo. El parser solo necesita responder una pregunta: "¿esto cambió respecto a lo que vi antes?" Si no cambió, no reportas. Si cambió, dices qué y cuánto.

3. ¿Qué Ganas?

• Cero infraestructura de monitoreo. No necesitas retención, índices, ni consultas. Tus datos son archivos JSON planos.
• Reportes en lenguaje natural, no en gráficos. Un agente analítico puede leer los datos y resumir: "subió 30% el throughput", "los jobs de ayer fueron 2s más lentos en detección".
• Contexto histórico real. No métricas de 15 minutos. Comparas contra días y semanas anteriores con consultas de segundos.
• Sin ruido. Solo reportas cuando hay un cambio que importa.

Todo esto funciona con una fuente de eventos pub/sub que ya tienes. Sin agents, sin exporters, sin sistemas externos.

4. Un Ejemplo Concreto (Abstracto)

Imagina un pipeline que procesa archivos multimedia. Cada trabajo publicado se ve así:

📁 Proyecto: Alpha
📐 clip_duration_sec: 108.11
📊 render: 3m 37s, detection: 1m 43s
🕒 Inicio: 10:15:00, Fin: 10:21:24

Un hook captura eso, lo guarda en un JSON de 300 líneas, y al final del día un agente responde:

"Hoy procesaste 7 archivos (4.9 min de contenido). El throughput subió de 0.38x a 0.51x. NVECC se mantuvo en 1."
"3 de 7 trabajos tuvieron procesamiento paralelo. El cuello de botella sigue siendo el render."

Sin abrir un solo dashboard.

5. Cuándo NO Usar Esto

Este patrón tiene límites claros:

• No reemplaza monitoreo en tiempo real para sistemas críticos (pago, salud, seguridad).
• No sirve si necesitas alertas en segundos con latencia garantizada.
• No escala a miles de eventos por minuto sin estructura adicional.

Pero para el 90% de los pipelines de procesamiento —los que corren batches, duran minutos, y generan decenas o cientos de eventos al día— es más que suficiente.

Conclusión

La obsesión con dashboards nos hizo olvidar que los datos más valiosos ya están en los eventos que nuestro sistema publica. Parsearlos directamente, compararlos con el histórico, y obtener reportes en lenguaje natural no requiere herramientas costosas. Solo requiere escuchar.