Problèmes connus

Managed Airflow (3e génération) | Managed Airflow (2e génération) | Managed Airflow (ancienne 1re génération)

Cette page liste les problèmes connus liés à Managed Airflow. Pour en savoir plus sur les corrections de problèmes, consultez les notes de version.

La première exécution de DAG pour un fichier DAG importé comporte plusieurs tâches ayant échoué

Lorsque vous importez un fichier de DAG, il se peut que les premières tâches de la première exécution de DAG associée à ce fichier échouent avec l'erreur Unable to read remote log.... Ce problème est dû au fait que le fichier de DAG est synchronisé entre le bucket de votre environnement, les nœuds de calcul Airflow et les programmeurs Airflow de votre environnement. Si le programmeur obtient le fichier DAG et planifie son exécution par un nœud de calcul, et si le nœud de calcul ne dispose pas encore du fichier DAG, l'exécution de la tâche échoue.

Pour résoudre ce problème, les environnements avec Airflow 2 sont configurés pour effectuer deux nouvelles tentatives pour une tâche ayant échoué par défaut. Si une tâche échoue, elle est relancée deux fois à cinq minutes d'intervalle.

Managed Airflow ne devrait pas être affecté par la faille Apache Log4j 2 (CVE-2021-44228)

En réponse à la faille Apache Log4j 2 (CVE-2021-44228), Managed Airflow a mené une enquête détaillée et nous pensons que Managed Airflow n'est pas vulnérable à cette faille.

Il peut arriver que l'UI Airflow ne recharge pas un plug-in une fois qu'il a été modifié.

Si un plug-in se compose de nombreux fichiers qui importent d'autres modules, l'UI Airflow risque de ne pas reconnaître qu'un plug-in doit être actualisé. Dans ce cas, redémarrez le serveur Web Airflow de votre environnement.

Erreur 504 lors de l'accès à l'interface utilisateur d'Airflow

Vous pouvez obtenir l'erreur 504 Gateway Timeout lorsque vous accédez à l'UI Airflow. Cette erreur peut avoir plusieurs causes :

  • Problème de communication temporaire. Dans ce cas, essayez d'accéder à l'UI Airflow plus tard. Vous pouvez également redémarrer le serveur Web Airflow.

  • (Managed Airflow (3e génération) uniquement) Problème de connectivité. Si l'UI Airflow est indisponible de manière permanente et que des erreurs de délai d'expiration ou 504 sont générées, assurez-vous que votre environnement peut accéder à *.composer.googleusercontent.com.

  • (Managed Airflow (Gen 2) uniquement) Problème de connectivité. Si l'UI Airflow est indisponible de manière permanente et que des erreurs de délai d'expiration ou 504 sont générées, assurez-vous que votre environnement peut accéder à *.composer.cloud.google.com. Si vous utilisez l'Accès privé à Google et envoyez du trafic via des adresses IP virtuelles private.googleapis.com, ou VPC Service Controls et envoyez du trafic via des adresses IP virtuelles restricted.googleapis.com, assurez-vous que votre Cloud DNS est également configuré pour les noms de domaine *.composer.cloud.google.com.

  • Le serveur Web Airflow ne répond pas. Si l'erreur 504 persiste, mais que vous pouvez toujours accéder à l'UI Airflow à certains moments, il est possible que le serveur Web Airflow ne réponde pas, car il est surchargé. Essayez d'augmenter les paramètres d'échelle et de performances du serveur Web.

Erreur 502 lors de l'accès à l'interface utilisateur d'Airflow

L'erreur 502 Internal server exception indique que l'UI Airflow ne peut pas diffuser les requêtes entrantes. Cette erreur peut avoir plusieurs causes :

  • Problème de communication temporaire. Réessayez d'accéder à l'interface utilisateur d'Airflow plus tard.

  • Échec du démarrage du serveur Web. Pour démarrer, le serveur Web nécessite que les fichiers de configuration soient d'abord synchronisés. Recherchez dans les journaux de serveur Web des entrées de journal semblables à GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp ou GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp. Si vous rencontrez ce type d'erreur, vérifiez si les fichiers mentionnés dans les messages d'erreur sont toujours présents dans le bucket de l'environnement.

    En cas de suppression accidentelle (par exemple, en raison de la configuration d'une règle de conservation), vous pouvez les restaurer :

    1. Définissez une nouvelle variable d'environnement dans votre environnement. Vous pouvez utiliser n'importe quel nom et valeur de variable.

    2. Remplacez une option de configuration Airflow. Vous pouvez utiliser une option de configuration Airflow inexistante.

Erreur 500 lors de l'accès à l'interface utilisateur Airflow après le remplacement de [webserver]analytics_tool

Dans les environnements avec Airflow 2, si vous remplacez l'option de configuration Airflow [webserver]analytics_tool pour acheminer les données d'utilisation anonymes de l'UI Airflow vers un service d'analyse (tel que Google Analytics, Segment, MetaRouter ou Matomo), l'accès à l'UI Airflow après la mise à jour de l'environnement peut renvoyer une réponse (500) Internal Server Error, avec l'une des erreurs suivantes dans les journaux du serveur Web Airflow :

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_id] not found in config

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_url] not found in config

Lorsque [webserver]analytics_tool est défini dans Airflow 2, le serveur Web Airflow nécessite que les options d'analyse associées dans la section [webserver] soient également définies lors de l'affichage de l'UI Airflow.

Dans Airflow 3, les options de configuration [webserver]analytics_tool, [webserver]analytics_id et [webserver]analytics_url sont supprimées.

Solutions :

  • Supprimez le remplacement de l'option de configuration Airflow [webserver]analytics_tool.
  • Spécifiez toutes les options de configuration Airflow requises :
    • [webserver]analytics_tool
    • [webserver]analytics_id
    • [webserver]analytics_url (obligatoire dans Airflow 2.9 et versions ultérieures, même si votre outil d'analyse n'utilise pas d'URL personnalisée)

Le pointage sur une instance de tâche dans la vue arborescente génère une erreur TypeError non interceptée

Dans Airflow 2, il arrive que la vue arborescente de l'UI Airflow ne fonctionne pas correctement lorsqu'un fuseau horaire autre que celui par défaut est utilisé. Pour contourner ce problème, configurez explicitement le fuseau horaire dans l'interface utilisateur d'Airflow.

Dossiers vides dans Scheduler et Workers

Managed Airflow ne supprime pas activement les dossiers vides des nœuds de calcul et des programmeurs Airflow. Ces entités peuvent être créées à la suite du processus de synchronisation du bucket d'environnement lorsque ces dossiers existaient dans le bucket et ont finalement été supprimés.

Recommandation : Ajustez vos DAG afin qu'ils soient prêts à ignorer ces dossiers vides.

Ces entités sont finalement supprimées des stockages locaux des planificateurs et des nœuds de calcul Airflow lorsque ces composants sont redémarrés (par exemple, à la suite d'opérations de scaling à la baisse ou de maintenance dans le cluster de votre environnement).

Compatibilité avec Kerberos

Managed Airflow n'est pas compatible avec la configuration Kerberos d'Airflow.

Compatibilité avec les classes de calcul dans Managed Airflow (2e génération) et Managed Airflow (3e génération)

Managed Airflow (Gen 3) et Managed Airflow (Gen 2) ne sont compatibles qu'avec la classe de calcul à usage général. Cela signifie qu'il n'est pas possible d'exécuter des pods qui demandent d'autres classes de calcul (telles que Balanced ou Scale-Out).

La classe à usage général permet d'exécuter des pods demandant jusqu'à 110 Go de mémoire et jusqu'à 30 processeurs (comme décrit dans Nombre maximal de requêtes de classe de calcul).

Si vous souhaitez utiliser une architecture ARM ou si vous avez besoin de plus de processeurs et de mémoire, vous devez utiliser une autre classe de calcul, qui n'est pas compatible avec les clusters Managed Airflow (Gen 3) et Managed Airflow (Gen 2).

Recommandation : Utilisez GKEStartPodOperator pour exécuter des pods Kubernetes sur un autre cluster compatible avec la classe de calcul sélectionnée. Si vous exécutez des pods personnalisés nécessitant une classe de calcul différente, ils doivent également s'exécuter sur un cluster Managed Airflow.

Il n'est pas possible de réduire l'espace de stockage Cloud SQL

Managed Airflow utilise Cloud SQL pour exécuter la base de données Airflow. Au fil du temps, l'espace de stockage sur disque de l'instance Cloud SQL peut augmenter, car le disque est mis à l'échelle pour s'adapter aux données stockées par les opérations Cloud SQL lorsque la base de données Airflow s'agrandit.

Il n'est pas possible de réduire la taille du disque Cloud SQL.

Pour contourner ce problème, si vous souhaitez utiliser la plus petite taille de disque Cloud SQL, vous pouvez recréer des environnements Managed Airflow avec des instantanés.

La métrique d'utilisation du disque de la base de données ne diminue pas après la suppression d'enregistrements de Cloud SQL

Les bases de données relationnelles, telles que Postgres ou MySQL, ne suppriment pas physiquement les lignes lorsqu'elles sont supprimées ou mises à jour. Au lieu de cela, il les marque comme "tuples morts" pour maintenir la cohérence des données et éviter de bloquer les transactions simultanées.

MySQL et Postgres implémentent tous deux des mécanismes de récupération d'espace après la suppression d'enregistrements.

Bien qu'il soit possible de forcer la base de données à récupérer l'espace disque inutilisé, il s'agit d'une opération gourmande en ressources qui verrouille également la base de données, ce qui rend Managed Airflow indisponible. Par conséquent, il est recommandé de s'appuyer sur les mécanismes de compilation pour récupérer l'espace inutilisé.

Accès bloqué : erreur d'autorisation

Si ce problème affecte un utilisateur, la boîte de dialogue Accès bloqué : erreur d'autorisation contient le message Error 400: admin_policy_enforced.

Si l'option Contrôles des API > Applications tierces non configurées > Ne pas autoriser les utilisateurs à accéder aux applications tierces est activée dans Google Workspace et que l'application Apache Airflow dans Managed Airflow n'est pas explicitement autorisée, les utilisateurs ne peuvent pas accéder à l'UI Airflow, sauf s'ils autorisent explicitement l'application.

Pour autoriser l'accès, suivez la procédure décrite dans Autoriser l'accès à l'UI Airflow dans Google Workspace.

Boucle de connexion lors de l'accès à l'UI d'Airflow

Ce problème peut être dû aux causes suivantes :

Le dossier /data n'est pas disponible sur le serveur Web Airflow

Dans Managed Airflow (Gen 2) et Managed Airflow (Gen 3), le serveur Web Airflow est censé être un composant en lecture seule, et Managed Airflow ne synchronise pas le dossier data/ avec ce composant.

Il peut arriver que vous souhaitiez partager des fichiers communs entre tous les composants Airflow, y compris le serveur Web Airflow.

Solution :

  • Encapsulez les fichiers à partager avec le serveur Web dans un module PYPI et installez-le en tant que package PYPI standard. Une fois le module PyPI installé dans l'environnement, les fichiers sont ajoutés aux images des composants Airflow et sont disponibles pour ces composants.

  • Ajoutez des fichiers au dossier plugins/. Ce dossier est synchronisé avec le serveur Web Airflow.

Diagrammes non continus des temps d'analyse des DAG et de la taille des sacs de DAG dans la surveillance

Les diagrammes de temps d'analyse des DAG et de taille du sac de DAG non continus sur le tableau de bord de surveillance indiquent des problèmes de temps d'analyse des DAG longs (plus de cinq minutes).

Graphiques des temps d'analyse des DAG Airflow et de la taille du sac de DAG montrant une série d'intervalles non continus
Figure 1. Graphiques non continus des temps d'analyse des DAG et de la taille de sac du DAG (cliquez pour agrandir)

Solution : Nous vous recommandons de maintenir le temps d'analyse total du DAG en dessous de cinq minutes. Pour réduire le temps d'analyse des DAG, suivez les consignes d'écriture des DAG.

Les journaux de tâches s'affichent avec un certain délai

Symptôme :

  • Dans Managed Airflow (3e génération), les journaux des tâches Airflow ne s'affichent pas immédiatement et sont retardés de quelques minutes.
  • Des messages Logs not found for Cloud Logging filter peuvent s'afficher dans les journaux Airflow

Cause :

Si votre environnement exécute un grand nombre de tâches en même temps, les journaux de tâches peuvent être retardés, car la taille de l'infrastructure de l'environnement n'est pas suffisante pour traiter tous les journaux assez rapidement.

Solutions :

  • Envisagez d'augmenter la taille de l'infrastructure de l'environnement pour améliorer les performances.
  • Répartissez les exécutions de DAG dans le temps afin que les tâches ne soient pas exécutées en même temps.

Augmentation des temps de démarrage pour KubernetesPodOperator et KubernetesExecutor

Les pods créés avec KubernetesPodOperator et les tâches exécutées avec KubernetesExecutor connaissent des temps de démarrage plus longs. L'équipe Managed Airflow travaille sur une solution et annoncera quand le problème sera résolu.

Solutions :

  • Lance les pods avec plus de CPU.
  • Si possible, optimisez les images (moins de couches, taille plus petite).

L'environnement est à l'état ERREUR après la suppression ou la désactivation du compte de facturation du projet, ou la désactivation de l'API Cloud Composer

Les environnements Managed Airflow concernés par ces problèmes ne sont pas récupérables :

  • Après la suppression ou la désactivation du compte de facturation du projet, même si un autre compte a été associé ultérieurement.
  • Après la désactivation de l'API Cloud Composer dans le projet, même si elle a été activée ultérieurement.

Pour résoudre le problème, procédez comme suit :

  • Vous pouvez toujours accéder aux données stockées dans les buckets de votre environnement, mais les environnements eux-mêmes ne sont plus utilisables. Vous pouvez créer un environnement Managed Airflow, puis transférer vos DAG et vos données.

  • Si vous souhaitez effectuer l'une des opérations qui rendent vos environnements non récupérables, veillez à sauvegarder vos données, par exemple en créant un instantané de l'environnement. De cette façon, vous pouvez créer un autre environnement et transférer ses données en chargeant cet instantané.

Les journaux des tâches Airflow ne sont pas collectés si [core]execute_tasks_new_python_interpreter est défini sur "True"

Managed Airflow ne collecte pas les journaux des tâches Airflow si l'option de configuration Airflow [core]execute_tasks_new_python_interpreter est définie sur True.

Solution possible :

  • Supprimez le remplacement de cette option de configuration ou définissez sa valeur sur False.

Erreur lors de la suppression du rattachement de réseau lorsqu'un environnement est supprimé

Si plusieurs environnements partageant le même rattachement de réseau sont supprimés en même temps, certaines opérations de suppression échouent et génèrent une erreur.

Symptômes :

L'erreur suivante est générée :

Got error while removing Network Attachment: <error code>

Le code d'erreur signalé peut être Bad request: <resource> is not ready ou Precondition failed: Invalid fingerprint.

Solutions possibles :

  • Supprimez un par un les environnements qui utilisent le même rattachement de réseau.

  • Désactivez la connexion à un réseau VPC pour vos environnements avant de les supprimer. Nous recommandons cette solution pour la suppression automatisée de l'environnement.

Performances dégradées de l'environnement dans plusieurs versions du package google-api-core

Versions de 2.28.0 à 2.30.2

Les versions de package google-api-core préinstallées de 2.28.0 à 2.30.2 peuvent entraîner une dégradation des performances de l'environnement, ce qui peut allonger le temps d'exécution d'une tâche et le temps nécessaire pour faire passer une tâche de l'état "en file d'attente" à l'état "en cours d'exécution".

Builds Managed Airflow (Gen 3) concernés :

  • composer-3-airflow-3.1.7-build.0 à composer-3-airflow-3.1.7-build.5
  • composer-3-airflow-3.1.0-build.5 à composer-3-airflow-3.1.0-build.10
  • composer-3-airflow-2.11.1-build.0
  • composer-3-airflow-2.10.5-build.22 vers composer-3-airflow-2.10.5-build.33
  • composer-3-airflow-2.9.3-build.42 vers composer-3-airflow-2.9.3-build.53

Builds Managed Airflow (Gen 2) concernés :

  • composer-2.16.10-airflow-2.11.1
  • composer-2.16.0-airflow-2.10.5 vers composer-2.16.10-airflow-2.10.5
  • composer-2.16.0-airflow-2.9.3 vers composer-2.16.10-airflow-2.9.3

Mettez à niveau votre environnement vers l'un des builds suivants, qui incluent la version 2.27.0 de google-api-core préinstallée et ne sont pas concernés par ce problème :

  • composer-3-airflow-2.11.1-build.1
  • composer-3-airflow-2.10.5-build.34
  • composer-3-airflow-2.9.3-build.54
  • composer-2.16.11-airflow-2.11.1
  • composer-2.16.11-airflow-2.10.5
  • composer-2.16.11-airflow-2.9.3

Vous pouvez également passer à une image incluant google-api-core 2.43.1 ou une version ultérieure, ou installer manuellement une version compatible.

Sur Python 3.11, les versions 2.30.3 à 2.43.0 de google-api-core entraînent un problème de performances distinct à partir du 24 octobre 2026. Si votre environnement exécute Python 3.11, appliquez l'une des solutions listées dans Versions 2.30.3 à 2.43.0 sur Python 3.11.

Versions de 2.30.3 à 2.43.0 sur Python 3.11

À partir du 24 octobre 2026, les versions 2.30.3 à 2.43.0 du package google-api-core exécuteront une vérification d'obsolescence de Python 3.11 qui analysera les métadonnées des packages installés chaque fois qu'une bibliothèque cliente Google Cloud sera importée dans un nouveau sous-processus Python.

Dans les environnements Managed Airflow qui exécutent Python 3.11, ce comportement peut dégrader les performances. Ce problème est plus grave dans les environnements comportant de nombreux DAG, des tâches fréquentes de courte durée ou l'intégration de la traçabilité des données activée.

Les symptômes sont les suivants :

  • Augmentation des temps d'analyse des DAG et de l'utilisation du processeur sur les processeurs de DAG Airflow.
  • Temps d'exécution des tâches plus longs et utilisation plus élevée du processeur sur les nœuds de calcul Airflow.
  • Entrées de journal FutureWarning fréquentes de google/api_core/_python_version_support.py indiquant que la compatibilité avec Python 3.11 prendra fin le 24 octobre 2027.

Ce problème affecte tous les environnements Python 3.11 dans lesquels la version 2.30.3 à 2.43.0 de google-api-core est préinstallée ou installée manuellement, y compris les builds suivants.

Ce problème affecte les builds Managed Airflow (3e génération) suivants :

  • composer-3-airflow-3.3.1-build.0 à composer-3-airflow-3.3.1-build.5
  • composer-3-airflow-3.2.2-build.0 à composer-3-airflow-3.2.2-build.9
  • composer-3-airflow-3.1.8-build.0 à composer-3-airflow-3.1.8-build.4
  • composer-3-airflow-3.1.7-build.7 à composer-3-airflow-3.1.7-build.13
  • composer-3-airflow-2.11.1-build.3 à composer-3-airflow-2.11.1-build.22
  • composer-3-airflow-2.10.5-build.36 à composer-3-airflow-2.10.5-build.52

Builds Managed Airflow (Gen 2) concernés :

  • composer-2.17.0-airflow-2.11.1 à composer-2.17.16-airflow-2.11.1
  • composer-2.17.0-airflow-2.10.5 à composer-2.17.13-airflow-2.10.5

Solutions :

Choisissez l'une des options suivantes en fonction de la version d'image de votre environnement :

  • Option 1. Builds Managed Airflow (Gen 3) compatibles avec Airflow 3 uniquement : installez le package PyPI google-api-core avec la contrainte de version >=2.43.1.

    Builds Managed Airflow (3e génération) compatibles :

    • composer-3-airflow-3.3.1-build.0 à composer-3-airflow-3.3.1-build.5
    • composer-3-airflow-3.2.2-build.1 à composer-3-airflow-3.2.2-build.9
    • composer-3-airflow-3.1.8-build.3 vers composer-3-airflow-3.1.8-build.4

    N'utilisez pas cette option sur les builds Airflow 2 ou les builds Airflow 3 antérieurs, y compris composer-3-airflow-3.2.2-build.0 et composer-3-airflow-3.1.8-build.0 à build.2. Dans ces builds, google-api-core 2.43.1 entraîne des conflits de dépendances, car il nécessite opentelemetry-api>=1.44.0. Pour ces builds, utilisez l'option 2.

  • Option 2. Tous les builds Managed Airflow (Gen 3) et Managed Airflow (Gen 2) concernés : Appliquez un correctif d'exécution sitecustomize.py.

    1. Téléchargez sitecustomize.py depuis GitHub.

    2. Importez sitecustomize.py dans le dossier dags/patches du bucket de votre environnement.

    3. Définissez la variable d'environnement PYTHONPATH sur /home/airflow/gcs/dags/patches.

      Si PYTHONPATH est déjà défini, ajoutez /home/airflow/gcs/dags/patches: à la valeur existante. Exemple : /home/airflow/gcs/dags/patches:PREVIOUS_PYTHONPATH_VALUE

    Nettoyage après une mise à niveau : dans les prochaines versions de Managed Airflow, le package google-api-core version 2.43.1 ou ultérieure sera préinstallé. Après avoir effectué la mise à niveau vers une image avec google-api-core 2.43.1 ou version ultérieure, vous pouvez supprimer le remplacement PYTHONPATH et supprimer dags/patches/sitecustomize.py.

L'instance de tâche n'est plus en cours d'exécution, la tâche doit se terminer et des erreurs "Tâche introuvable" s'affichent dans Airflow 3

Airflow 3 présente deux problèmes liés à la perte de l'état des tâches par le programmeur lors de ses redémarrages :

  • État "409 Conflit" : une condition de concurrence dans les planificateurs entraîne la planification d'instances de tâches en double (#59378, résolu dans #60330).

    Ce problème est résolu dans Airflow 3.2.2.

  • Erreur 404 Not Found : les nœuds de calcul Airflow perdent la trace des instances de tâche lors d'un redémarrage de la boucle du programmeur standard, qui se produit une fois que le programmeur atteint [scheduler]num_runs. Cela modifie les ID d'instance de tâche existants et génère des erreurs 404 ultérieures à partir d'un nœud de calcul qui n'est pas au courant de la modification (#53140, #60330, résolu dans #61631).

    Ce problème est résolu dans Airflow 3.3.1.

Symptômes

  • 409 Conflit : l'état de nettoyage des tâches orphelines d'un planificateur redémarré marque les tâches actives comme FAILED, ce qui entraîne l'arrêt anormal des nœuds de calcul :

    Server indicated the task shouldn't be running anymore [supervisor]
detail={'detail': {'reason': 'not_running', 'message': 'TI is no longer in
the running state and task should terminate', 'current_state': 'scheduled'}} status_code=409 ti_id=UUID('...')

  • 404 Not Found : un programmeur redémarré perd les états des tâches et échoue aux vérifications d'activité des nœuds de calcul actifs :

    Server indicated the task shouldn't be running anymore [detail={'detail':
{'reason': 'not_found', 'message': 'Task Instance not found'}}]
[status_code=404] [ti_id=...]

Solution :

  • Ces deux problèmes ont été résolus dans Airflow 3.3.1 et versions ultérieures. Mettez à niveau votre environnement vers une version qui utilise Airflow 3.3.1.

Solutions possibles :

  • Il n'est pas possible de résoudre complètement le problème dans les versions d'Airflow antérieures à la version 3.3.1. Tout événement externe entraînant le redémarrage inattendu d'un seul programmeur déclenchera des erreurs 404 et 409 (dans les versions d'Airflow antérieures à la version 3.2.2). Il peut s'agir, par exemple, de mises à niveau automatiques des nœuds du cluster de votre environnement, de conditions de mémoire insuffisante dans les pods, ou d'une consommation élevée de mémoire et de processeur par les programmateurs.

  • Réduire votre environnement à un seul programmeur et définir l'option de configuration [scheduler]num_runs sur -1 permet d'atténuer la cause des conditions de concurrence dans les programmeurs.

    Pour un environnement hautement résilient (haute disponibilité), il n'est pas possible de réduire le nombre de programmeurs à un. Vous pouvez toujours définir [scheduler]num_runs sur -1.

  • Assurez-vous que la consommation de mémoire et de processeur par le programmeur respecte les limites de ressources disponibles.

Étapes suivantes