Saltar a contenido

RUNBOOK — job-monitor-adf

Dato L23 adf_pipelines_monitor L24 adf_monitor_ir_nodes
Programacion 0 7 * * * 5 * * * *
Comando .venv/bin/python -m monitor_adf pipelines .venv/bin/python -m monitor_adf ir-nodes
Auditoria (ATHENAS.ods.tbl_control_procesos) ID08 - PY_ADF_PIPELINES_MONITOR (con --desde: ..._MANUAL) ID08 - PY_ADF_PIPELINES_MONITOR_IR_NODES
Logs /var/log/dabra/adf_pipelines_monitor/ /var/log/dabra/adf_monitor_ir_nodes/
Datos tablas ods.adf_monitor_* (no deja archivos) ods.adf_monitor_IntegrationRuntimeNodes

Duracion esperada: sin medir. Tolerancia 120 min en ambos (decision del responsable del proyecto; ajustar mas adelante). Timeouts propuestos: 120 min (L23; el backfill de las Copy puede pasar de 1 h) y 10 min (L24). Auditoria de 7 columnas; estados Success / Error.

Codigo Significado Accion
0 Todo bien —
1 Fallo de Azure, de la BD o no se pudo auditar Ver el log; reejecutar
2 Configuracion o argumentos invalidos Revisar .env / la fecha de --desde

Comandos

python -m monitor_adf pipelines --dry-run              # consulta Azure y calcula; no crea tablas, no escribe, no audita
python -m monitor_adf pipelines                        # produccion (backfill 30 dias si la tabla esta vacia)
python -m monitor_adf pipelines --desde 2026-09-01     # recarga desde esa fecha (UTC); auditoria ..._MANUAL
python -m monitor_adf ir-nodes --dry-run               # lee los nodos; no escribe, no avisa por Telegram, no audita
python -m monitor_adf ir-nodes                         # produccion

Reproceso

  • L23 es reejecutable: borra la ventana solapada de PipelineRuns, TriggerRuns y CopyActivityRunStats y la vuelve a insertar (en una transaccion por tabla). Las demas tablas (Estadisticas, Detalle, SP, Copy, IR) se insertan completas en cada corrida, como el original: se acumulan por FechaEjecucion.
  • Si el job estuvo caido, continua desde el ultimo RunStart (maximo 30 dias atras): no hace falta --desde. Usar --desde solo para rehacer un rango.
  • L24 guarda una foto por corrida y la compara con la anterior (leida de la propia tabla, sin archivos): avisa por Telegram solo cuando un nodo cae o se recupera. Mientras sigue caido deja un WARNING por corrida en el log (visible en el panel) pero no vuelve a avisar. Repetir el job no repite el aviso.

Rollback

No hay. Una carga mala de L23 se corrige reejecutando con --desde anterior a la ventana afectada.

Problemas conocidos

  • HTTP 429 de Azure: se reintenta con espera creciente; si persiste, bajar ROWS_MAX_WORKERS.
  • La consulta de estadisticas de Copy puede tardar mas de una hora en un backfill; el token se renueva solo.
  • Sin TELEGRAM_TOKEN/TELEGRAM_CHAT_ID L24 guarda los nodos pero no avisa (WARNING en el log).
  • Si Telegram falla justo al caer un nodo, ese aviso se pierde (la corrida siguiente ya ve el nodo como "sigue caido"). El fallo queda en el log; el nodo caido se sigue viendo como WARNING en cada corrida.
  • Un fallo del job (exit 1) se ve en el panel por el codigo de salida y la auditoria Error; no se envia correo (decision del responsable del proyecto).
  • Un IR que devuelve error en getStatus se registra con ErrorMessage en L23 y se salta (WARNING) en L24.

Fuente: repositorio job-monitor-adf, versión a3d350b. Página generada con tools/publicar_docs.py.