Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 4 de 5
Observabilidad y alertas
La observabilidad combina progreso Spark, lag de fuente, calidad de datos y SLO de negocio para ofrecer alertas accionables.
30 min aprox.
04DiagnósticoObservabilidad y alertas
La observabilidad combina progreso Spark, lag de fuente, calidad de datos y SLO de negocio para ofrecer alertas accionables.
+
Observabilidad y alertas
La observabilidad combina progreso Spark, lag de fuente, calidad de datos y SLO de negocio para ofrecer alertas accionables.
El progreso de la consulta muestra duración, tasas y estado; Kafka o Auto Loader aportan backlog; las tablas silver aportan máximo event time y descartes. Una alerta de frescura debe enlazar esas señales para diferenciar fuente parada, cuello de proceso, dato inválido o sink lento.
Las métricas se escriben en una tabla con `query_id`, `batch_id`, versión y timestamp. Un dashboard sin alertas ni propietario no reduce tiempo de recuperación. Cada alarma debe incluir umbral, periodo, severidad, enlace a evidencia y primera acción segura.
import json
from pyspark.sql import Row
progress = query.lastProgress or {}
record = Row(
query_id=str(query.id),
batch_id=progress.get("batchId"),
observed_at=progress.get("timestamp"),
input_rps=progress.get("inputRowsPerSecond", 0.0),
processed_rps=progress.get("processedRowsPerSecond", 0.0),
progress_json=json.dumps(progress),
)
spark.createDataFrame([record]).write.mode("append").saveAsTable(
"main.ops.streaming_progress"
)Para una solución productiva usa un listener o monitor administrado y controla volumen/PII del JSON de progreso.
¿Qué señales distinguen una fuente parada de un consumidor lento?
Profundiza
La observabilidad útil enlaza cuatro planos: salud de la consulta, progreso de la fuente, comportamiento del estado y calidad del producto. Un dashboard que solo muestra cluster y estado `RUNNING` puede permanecer verde mientras se publican datos viejos o incompletos. Las métricas técnicas —offsets, batch duration, input rate, state rows, retries— responden cómo funciona el motor. Las métricas de negocio —máximo event time, pedidos por mercado, suma de importes, porcentaje válido— responden si entrega el producto prometido. Cada alerta debe combinar duración y severidad para evitar ruido durante microbatches vacíos o ráfagas normales, y debe señalar una primera comprobación. Logs estructurados incluyen run, query, batch, checkpoint version y correlación de la fuente; tablas de operaciones permiten tendencias y postmortems más allá de la retención de la interfaz.
Telemetría sobre ejecución, offsets, recursos, estado y fallos del motor streaming.
Localiza mecanismos operativos, pero necesita contexto de negocio para determinar impacto real.Indicadores sobre frescura, volumen, calidad y coherencia del producto de datos entregado.
Detecta pipelines técnicamente activos que producen resultados inútiles o incompletos.Regla con umbral sostenido, severidad, owner y primera hipótesis o acción segura asociada.
Reduce fatiga y transforma una señal en tiempo de diagnóstico y recuperación menor.Resumen
Puntos clave
- Una única métrica técnica rara vez explica un incumplimiento de negocio.
- Las alertas usan ventanas sostenidas para evitar ruido de un microbatch aislado.
- Versión de código y query ID permiten correlacionar regresiones con despliegues.
Evita
- Alertar por una tasa baja cuando la fuente no tiene eventos y el SLO sigue satisfecho.
- Guardar logs sin `batch_id`, versión ni owner, impidiendo correlación y respuesta.