Monitorización, Event Log, métricas y costes

1. Las cinco métricas que debes monitorizar

No basta con saber que el pipeline aparece en verde.

Para una plataforma con Kafka, Bronze, Silver y Power BI, vigilaría especialmente la freshness de extremo a extremo.

Un pipeline puede estar funcionando perfectamente y aun así mostrar datos de hace dos horas porque la fuente está retrasada.

2. El Event Log: tu principal herramienta

Lakeflow genera un Event Log con información sobre ejecuciones, flows, errores, calidad y progreso.

Puedes consultarlo directamente con SQL:

SELECT
    timestamp,
    event_type,
    origin.flow_name,
    message
FROM event_log('<pipeline-id>')
ORDER BY timestamp DESC
LIMIT 20;

Sustituye <pipeline-id> por el ID real de tu pipeline.

Por ejemplo, para ver los registros procesados:

SELECT
    timestamp,
    origin.flow_name AS flow,
    details:flow_progress:metrics
        :num_output_rows::BIGINT AS rows_written
FROM event_log('<pipeline-id>')
WHERE event_type = 'flow_progress'
ORDER BY timestamp DESC;

num_output_rows informa sobre filas de salida cuando esa métrica está disponible; no es necesariamente igual a los eventos consumidos ni aparece en todos los flows. Databricks on AWS

3. Cómo medir la latencia real

Imagina esta situación:

Aunque Bronze solo tarde 4 minutos, el usuario del dashboard ve información con 15 minutos de retraso.

Consulta SQL de freshness

Si conservas kafka_timestamp en Bronze:

SELECT
    MAX(kafka_timestamp) AS latest_event,
    CURRENT_TIMESTAMP() AS checked_at,
    TIMESTAMPDIFF(
        MINUTE,
        MAX(kafka_timestamp),
        CURRENT_TIMESTAMP()
    ) AS freshness_minutes
FROM bronze_tickets;

Esta consulta mide la antigüedad del evento más reciente disponible, no el backlog real de Kafka. Si no se han producido eventos nuevos, la cifra aumenta aunque el pipeline esté al día. Para detectar retrasos de consumo necesitamos también métricas de progreso y backlog.

4. Simulador: ¿cuándo lanzamos una alerta?

En producción evitaría alertar por una única medición aislada. Por ejemplo, exigiría dos comprobaciones consecutivas fuera del SLA para reducir falsos positivos.

5. ¿Cómo monitorizar el coste real?

Databricks publica el consumo en system.billing.usage.

Podemos consultar cuántas DBUs ha utilizado un pipeline durante los últimos 7 días:

SELECT
    usage_date,
    sku_name,
    ROUND(SUM(usage_quantity), 2) AS total_dbus
FROM system.billing.usage
WHERE usage_metadata.dlt_pipeline_id = '<pipeline-id>'
  AND usage_unit = 'DBU'
  AND usage_date >= CURRENT_DATE() - INTERVAL 7 DAYS
GROUP BY usage_date, sku_name
ORDER BY usage_date;

Esta consulta nos dice cuánto compute hemos consumido, pero DBUs no es lo mismo que euros.

Para calcular el coste necesitaríamos aplicar las tarifas correspondientes, por ejemplo utilizando system.billing.list_prices o los precios efectivos de vuestro contrato.

Microsoft Learn+1

Los KPIs de eficiencia que utilizaría

Una subida de DBUs no siempre significa que el pipeline sea menos eficiente: quizá está procesando muchos más eventos.

Por eso conviene relacionar coste y volumen procesado.

6. Configurar las alertas

Hay varios mecanismos de alerta:

• Notificaciones de Jobs/Pipelines: ejecuciones fallidas o eventos de ejecución.

• Databricks SQL Alerts: una consulta detecta que un KPI supera un umbral.

• Event hooks: permiten desarrollar integraciones personalizadas para determinados eventos.

Databricks documenta estas opciones para monitorización de pipelines.

Databricks on AWS+1

Para una primera versión de producción configuraría:

Los umbrales deben ajustarse según el SLA y el comportamiento real de cada país y fuente.

7. Mini ejercicio

Qué debes recordar:

• El Event Log es la fuente principal de observabilidad técnica.

• Freshness no es lo mismo que estado del pipeline.

• Backlog, throughput y calidad aportan contexto para investigar problemas.

• system.billing.usage permite controlar DBUs y analizar costes.

• La monitorización debe orientarse al SLA de negocio, no solo al éxito técnico de las ejecuciones.

Nos quedan 3 lecciones: arquitectura completa, CDC vs CDF con recálculo incremental de KPIs históricos, y Lakeflow vs dbt.