Flujo de air despeja las tareas que no se ejecutan.

Preámbulo

Sin embargo, otras tareas de flujo de air no se ejecutan pregunta …

Todo iba más o menos bien en mi experiencia de flujo de air hasta este fin de semana cuando las cosas realmente iban cuesta abajo.

He comprobado todas las cosas estándar, por ejemplo, como se describe en esta publicación útil .

He restablecido toda la instancia varias veces intentando que funcione correctamente, pero aquí estoy perdiendo la batalla por completo.

Ambiente

  • versión: flujo de air 1.10.2
  • os: centos 7
  • python: python 3.6
  • virtualenv: si
  • ejecutor: LocalExecutor
  • db backend: mysql

El problema

Esto es lo que sucede en mi solución de problemas de bucle infinito / pesadilla recurrente.

  1. Reinicio la base de datos de metadatos (o posiblemente todo el virtualenv y la configuración, etc.) y vuelvo a ingresar la información de conexión.
  2. Las tareas se ejecutarán una vez. Pueden tener éxito. Si me perdí algo en la configuración, una tarea puede fallar.
  3. Cuando la tarea falla, pasa al estado de rebash.
  4. Arreglo el problema con (p. Ej., Se me olvidó ingresar una conexión) y borro manualmente la instancia de la tarea.
  5. Las instancias de tareas borradas no se ejecutan, solo se sientan en un estado “ninguno”
  6. Los bashs de hacer que dag vuelva a funcionar fallan.

Antes de que empezara a tener este problema, después de borrar una instancia de tarea, siempre se recogía y ejecutaba muy rápidamente.

Pero ahora, al borrar la instancia de la tarea, generalmente la instancia de la tarea se atasca en un estado de borrado. Simplemente se sienta allí.

Peor aún, si bash fallar el dag y todas las instancias, y volver a activar manualmente el dag, las instancias de la tarea se crean pero permanecen en el estado “ninguno”. Reiniciar progtwigdor no ayuda.

Otra observación

Probablemente sea una pista falsa, pero una cosa que he notado recientemente es que cuando hago clic en el icono que representa las instancias de tareas atascadas en el estado ‘ninguna’, me lleva a un filtro de vista de “instancias de tareas” que tiene el error filtrar; el filtro se establece en “cadena igual a nulo”.

Pero debe cambiarlo a “cadena vacía sí” para que realmente devuelva las instancias de tarea que están atascadas.

Supongo que esto es solo un error de UI no relacionado, una pista falsa en lo que a mí respecta, pero pensé que lo mencionaría por si acaso.

Editar 1

Estoy notando que hay un “operador nulo” en marcha: ¿Por qué mi operador es nulo? Lo miraré

Editar 2

¿Es null un valor válido para el estado de instancia de tarea? ¿O es esto un indicador de que algo está mal?

¿Es legítimo tener un estado de instancia de tarea nula?

Editar 3

Más none cosa.

Aquí hay algunos bits de la página de detalles de la instancia de tarea. Muchos atributos son none :

 Task Instance Details Dependencies Blocking Task From Getting Scheduled Dependency Reason Unknown All dependencies are met but the task instance is not running. In most cases this just means that the task will probably be scheduled soon unless: - The scheduler is down or under heavy load - The following configuration values may be limiting the number of queueable processes: parallelism, dag_concurrency, max_active_dag_runs_per_dag, non_pooled_task_slot_count - This task instance already ran and had its state changed manually (eg cleared in the UI) If this task instance does not start soon please contact your Airflow administrator for assistance. Task Instance Attributes Attribute Value duration None end_date None is_premature False job_id None operator None pid None queued_dttm None raw False run_as_user None start_date None state None 

Actualizar

Puede que finalmente esté en algo …

Después de mi sesión de resolución de problemas de pesadilla , maratón y zonas atascadas en el crepúsculo, levanté mis manos y resolví usar contenedores docker en lugar de correr de forma nativa. Era demasiado raro. Las cosas simplemente no tenían sentido. Necesitaba trasladarme a la ventana acoplable para que el entorno pudiera controlarse y reproducirse por completo.

Así que empecé a trabajar en la configuración de la ventana acoplable basada en puckel / docker-airflow. Esto tampoco fue una tarea trivial, porque decidí usar variables de entorno para todos los parámetros y conexiones. No todos los enganches analizan las URI de conexión de la misma manera, por lo que debe tener cuidado y mirar el código y hacer algunas pruebas y errores.

Así que luego hice eso, finalmente conseguí que mi configuración de la ventana acoplable funcionara localmente. Pero cuando fui a construir la imagen en mi instancia de EC2, encontré que el disco estaba lleno . Y fue en gran parte debido a los registros de flujo de air que estaba lleno.

Entonces, mi nueva teoría es que la falta de espacio en el disco puede haber tenido algo que ver con esto. No estoy seguro si podré encontrar una pistola humeante en los troncos, pero miraré.

Ok, estoy cerrando esto y marcando la presunta causa raíz ya que el servidor se quedó sin espacio.

Hubo una serie de factores contribuyentes:

  1. Mi servidor no tenía mucho almacenamiento. Sólo 10GB. No me di cuenta de que era tan bajo. Resolución: agregar más espacio
  2. Entrar en el flujo de air 1.10.2 se volvió un poco loco. Un mensaje de registro INFO Harvesting DAG parsing results cada dos o dos segundos, lo que resultó, eventualmente, en un archivo de registro grande. Resolución: Esto se solucionó en los [AIRFLOW-3911] Change Harvesting DAG parsing results to DEBUG log level (#4729) , que a la fecha de esta escritura aún no está respaldado, pero siempre se puede hacer una selección de bifurcaciones.
  3. Además, algunos de los parámetros de intervalo de mi servidor web / progtwigdor podrían haberse beneficiado de un aumento. Como resultado terminé con archivos de registro de varios GB. Creo que esto puede deberse en parte al cambio de las versiones de flujo de air sin actualizar correctamente airflow.cfg . Solución: al actualizar (o cambiar las versiones), mueva temporalmente airflow.cfg para que se airflow.cfg un cfg compatible con la versión, luego combínelos con cuidado. Otra estrategia es confiar solo en las variables de entorno, de modo que su configuración siempre debe ser una instalación nueva, y los únicos parámetros en sus variables env son las anulaciones de parámetros y, posiblemente, las conexiones.
  4. El flujo de air no puede registrar errores en ninguna parte en este caso; todo se veía bien, excepto que el progtwigdor no estaba poniendo en cola los trabajos, o haría una o dos colas y luego se detendría, sin ningún mensaje de error. Las soluciones pueden incluir (1) agregar alarmas de falta de espacio en su proveedor de computación en la nube, (2) descubrir cómo garantizar que el progtwigdor genere una excepción útil en este caso y contribuya al flujo de air.