Airflow frente a cron: trabajos, logs y reintentos

Cron sirve para tareas sueltas; Airflow agrega dependencias, estado, logs y reintentos. Cómo armar una pila mínima con PostgreSQL, permisos y prueba de salida.

ULTIMA MILLA · Técnico · 4 de jun de 2026 · 4 min de lectura

¿Qué tarea crítica corre los domingos aunque nadie mire la consola? Cron sirve para scripts sueltos, pero una pyme qué carga ventas, limpia CSV y manda reportes necesita estado, dependencias, logs y reintentos. Apache Airflow ordena esos trabajos sobre una base de metadatos. Esta guía explica cuándo conviene usarlo, dónde vive cada dato y cómo probar que una falla no queda escondida.

Dónde aparece el costo del crontab sin dueño

El problema operativo aparece cuando una tarea automática deja de ser una línea aislada. Un script descarga datos, otro transforma columnas, otro manda un reporte y otro borra temporales. Si uno falla, cron sabe que ejecutó un comando; el negocio necesita saber qué dato quedó incompleto, quién recibió alerta y qué reintento funciónó. La documentación de Airflow 3.2.2 recomienda PostgreSQL o MySQL para una prueba real y lista soporte para PostgreSQL 13, 14, 15, 16 y 17. La cifra global da contexto: Stack Overflow 2024 ubicó PostgreSQL en 49% de uso entre desarrolladores. Para una cámara empresaria de San Martín, eso vuelve razonable guardar estados, ejecuciones y usuarios en una base que el equipo ya puede auditar. La factura recurrente del proveedor de reportes aparece cuando cada automatización vive en un servicio distinto. En la oficina, el objeto que contaba la historia era un almanaque de pared con marcas verdes en los cierres mensuales. El almanaque mostraba fechas; no mostraba qué tarea había fallado.

Cómo funciona por dentro

El flujo empieza con un DAG, que describe tareas y dependencias en código. El scheduler lee el DAG, decide qué tarea puede correr y crea ejecuciones. El worker toma la tarea, ejecuta el comando o función y devuelve estado. PostgreSQL guarda metadatos: DAG, ejecución, tarea, intento, usuario, variable, conexión y evento. Los logs guardan salida técnica de cada intento. Airflow muestra vista por DAG, tarea, duración, error y reintento. Keycloak o el proxy de identidad separan roles para administrar conexiones, leer ejecuciones o disparar una corrida manual. El backup copia la base de metadatos, configuración y definición versionada de DAGs; la prueba restaura un flujo mensual y confirma que la tarea fallida conserva log y estado. El tablero útil marca cuatro señales: tarea atrasada, tarea fallida, reintento agotado y dato de salida ausente. Si el reporte mensual depende de tres pasos, Airflow debe impedir que el envío final corra con un CSV incompleto. El cierre de datos necesita una convención escrita. Cada DAG tiene responsable, fuente, salida esperada, horario, tolerancia de atraso y contacto de guardia. Las variables guardan rutas y límites; las credenciales quedan en conexiones con permisos. Cuando una tarea produce un archivo, el hash y la cantidad de filas se registran antes del envío. Esa marca permite detectar un reporte vacío antes de que llegue a gerencia.

Qué se instala o configura primero

La pila mínima usa Airflow 3.2.2, PostgreSQL 17, repositorio Git para DAGs, executor local o Celery según carga, proxy HTTPS, roles y backup. En una pyme con 10 a 30 flujos livianos, el costo mensual puede quedar entre USD 120 y USD 260 si incluye servidor, copia externa y monitoreo. Con dólar vendedor oficial consultado de ARS 1.458, el rango mensual va de ARS 174.960 a ARS 379.080. El primer entregable verificable es chico: un DAG que toma un CSV, valida columnas, carga PostgreSQL, genera un reporte y manda alerta. La implementación inicial suele llevar 35 a 65 horas, según cantidad de tareas, credenciales y fuentes. La salida debe incluir DAGs versionados, variables documentadas, roles, respaldo y prueba de restauración. UMSA puede entrar cuando el equipo ya tiene identificadas las tareas repetidas. El trabajo técnico consiste en pasar de comandos dispersos a flujos con dueño, horario, dependencia, log y recuperación. Gerencia no necesita leer el código; necesita saber qué proceso corrió, qué dato produjo y quién recibió aviso.

Dónde se rompe y cómo probarlo

El primer riesgo es la credencial compartida. La señal aparece cuando varios DAGs usan el mismo usuario para sistemas distintos. La prueba crea conexiones separadas, revoca una y confirma que sólo falla el flujo afectado. El segundo riesgo es el reintento que duplica datos. La señal aparece cuando una tarea vuelve a correr y carga dos veces la misma fila. La prueba ejecuta dos intentos con el mismo archivo y exige una clave única o una marca de idempotencia. El tercer riesgo es el log perdido. La señal aparece cuando la tarea falla y sólo queda un estado rojo sin detalle. La prueba rompe una entrada, revisa el log y verifica que el error tenga archivo, columna y timestamp. El cuarto riesgo es restaurar la base sin los DAGs. La señal aparece cuando Airflow vuelve, pero no sabe qué código ejecutaba. La prueba restaura PostgreSQL, DAGs y variables en un entorno limpio, corre un flujo y compara salida. Una automatización sirve cuando el lunes muestra qué pasó el domingo.