2.2 KiB
2.2 KiB
Runbook de operación
Objetivo operacional
Mantener la sincronización:
- FTP (archivos del mes/carpeta) → SQL Server (
URL_FTP)
con observabilidad en Kafka y alerta por webhook.
Qué esperar en una ejecución “sana”
Por cada item en INFORMATIONS se esperan, en logs de Airflow:
✅ FTP ... <N> archivos en <code_folder>✅ SQL ... <M> registros existentesℹ️ DIFF ... A insertar: <K>✅ INSERT ... Insertados: <K>(o warning de “Sin registros nuevos”)
Al final:
⏹ FINALIZADO ...
Inputs críticos (pre-flight)
- Airflow Variables existen y tienen valores válidos:
- FTP:
FTP_000oqta_SERVER,FTP_000oqta_USER,FTP_000oqta_PASSWORD - SQL:
DB_MSSQ_SERVER,DB_MSSQ_USER,DB_MSSQ_PASSWORD - Kafka:
BOOTSTRAP_SERVERS_DOCKER,KAFKA_USE_SSL - Webhook:
WEBHOOK_URL_NOTIFICATION
- FTP:
- El worker donde corre el DAG tiene:
- driver ODBC 18 instalado
- conectividad a FTP/SQL/Kafka/webhook
Procedimiento ante incidentes (rápido)
- Revisar logs del task
save_url_ftpen Airflow. - Identificar el “BD lógico” afectado (ej.
glm_pmi,IS001, etc.). - Clasificar el fallo:
- FTP (login, path, listing)
- SQL (conexión, permisos, tabla)
- INSERT (schema/constraint)
- Kafka (broker/SSL/SASL)
- Webhook (endpoint caído / 4xx/5xx)
- Ejecutar acciones según tipo (ver
08_TROUBLESHOOTING.md).
Operación programada del DAG
El DAG corre cada 2 horas (0 */2 * * *).
Si necesitas ejecución manual:
- Ejecuta el task
save_url_ftpdesde la UI de Airflow (Trigger DAG / Run Task).
Indicadores recomendados (SLOs simples)
- Frescura: últimas URLs del FTP aparecen en SQL < 2–4 horas.
- Cobertura: por cada item,
A insertartiende a 0 tras una corrida exitosa. - Errores: tasa de
FAILEDpor item debe ser baja; si sube, revisar conectividad o cambios de naming en FTP.
Mantenimiento preventivo
- Revisar que
FTP_BASE_PATH(año) sea correcto cuando cambie el año. - Verificar que las rutas/certificados SSL (si aplica) sean válidos dentro del contenedor.
- Confirmar que el naming en FTP siga el patrón esperado (contiene
_{YYYY}-{MM}eidentity_id).