Problèmes connus

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

Cette page liste les problèmes connus de Managed Airflow. Pour en savoir plus sur les correctifs, consultez les notes de version.

La première exécution du DAG pour un fichier de 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 de DAG et planifie son exécution par un nœud de calcul alors que ce nœud de calcul ne dispose pas encore du fichier de DAG, l'exécution de la tâche échoue.

Pour atténuer ce problème, les environnements avec Airflow 2 sont configurés pour effectuer par défaut deux tentatives pour chaque tâche ayant échoué. Si une tâche échoue, elle est relancée deux fois avec un intervalle de cinq minutes.

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 approfondie et nous pensons que Managed Airflow n'est pas vulnérable à cette exploitation.

L'interface utilisateur d'Airflow peut parfois ne pas recharger un plug-in une fois qu'il a été modifié

Si un plug-in comporte de nombreux fichiers qui importent d'autres modules, l'interface utilisateur d'Airflow peut ne pas être en mesure de reconnaître qu'un plug-in doit être rechargé. Dans ce cas, redémarrez le serveur Web Airflow de votre environnement.

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

L'erreur 504 Gateway Timeout peut s'afficher lorsque vous accédez à l'interface utilisateur d'Airflow. Cette erreur peut avoir plusieurs causes :

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

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

  • (Managed Airflow (2e génération) uniquement) Problème de connectivité. Si l'interface utilisateur d'Airflow est définitivement indisponible et que des erreurs de délai d'attente 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 que vous envoyez du trafic via des adresses IP virtuelles private.googleapis.com, ou si vous utilisez VPC Service Controls et que vous 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.

  • Serveur Web Airflow ne répondant pas. Si l'erreur 504 persiste, mais que vous pouvez toujours accéder à l'interface utilisateur d'Airflow à certains moments, le serveur Web Airflow peut ne pas répondre, car il est surchargé. Essayez d'augmenter les paramètres de scaling 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'interface utilisateur d'Airflow ne peut pas traiter les requêtes entrantes. Cette erreur peut avoir plusieurs causes :

  • Problème de communication temporaire. Essayez d'accéder à l'interface utilisateur d'Airflow ultérieurement.

  • Échec du démarrage du serveur Web. Pour démarrer, le serveur Web doit d'abord synchroniser les fichiers de configuration. Recherchez dans les journaux du 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 ces erreurs s'affichent, 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.

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

Dans Airflow 2, la vue arborescente de l'interface utilisateur d'Airflow peut parfois ne pas fonctionner correctement lorsqu'un fuseau horaire non défini par défaut est utilisé. Pour contourner ce problème, configurez explicitement le fuseau horaire dans l'interface utilisateur d'Airflow.

Dossiers vides dans le programmeur et les nœuds de calcul

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 espaces de stockage locaux des programmeurs et des nœuds de calcul Airflow lorsque ces composants sont redémarrés (par exemple, à la suite d'une réduction de la taille ou d'opérations de maintenance dans le cluster de votre environnement).

Compatibilité avec Kerberos

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

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

Managed Airflow (3e génération) et Managed Airflow (2e génération) 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 Équilibré 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 Requêtes maximales de la classe de calcul.

Si vous souhaitez utiliser une architecture basée sur 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 (3e génération) et Managed Airflow (2e génération).

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 autre classe de calcul, ils doivent également s'exécuter sur un cluster non 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 augmente.

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, elles les marquent comme "tuples morts" pour maintenir la cohérence des données et éviter de bloquer les transactions simultanées.

MySQL et Postgres implémentent 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 en plus la base de données, ce qui rend Managed Airflow indisponible. Il est donc recommandé de s'appuyer sur les mécanismes de création 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 de l'API > Applications tierces non configurées > N'autoriser les utilisateurs à accéder à aucune application tierce 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'interface utilisateur d'Airflow, sauf s'ils autorisent explicitement l'application.

Pour autoriser l'accès, suivez les étapes décrites dans Autoriser l'accès à l'interface utilisateur d'Airflow dans Google Workspace.

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

Ce problème peut avoir les causes suivantes :

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

Dans Managed Airflow (2e génération) et Managed Airflow (3e génération), le serveur Web Airflow est principalement un composant en lecture seule, et Managed Airflow ne synchronise pas le dossier data/ avec ce composant.

Parfois, vous pouvez 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 eux.

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

Diagrammes de durée d'analyse des DAG non continue et de taille du sac de DAG dans la surveillance

Les diagrammes de durée d'analyse des DAG non continue et de taille du sac de DAG sur le tableau de bord de surveillance indiquent des problèmes liés à des durées d'analyse des DAG longues (plus de cinq minutes).

Graphiques des temps d&#39;analyse des DAG Airflow et de la taille du DAG bag montrant une série d&#39;intervalles non continus
Figure 1. Graphiques de durée d'analyse des DAG non continue et de taille du sac de DAG (cliquez pour agrandir)

Solution : Nous vous recommandons de maintenir la durée d'analyse totale des DAG en dessous de cinq minutes. Pour réduire la durée d'analyse des DAG, suivez les consignes de rédaction des DAG.

Les journaux des tâches s'affichent avec des retards

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.
  • Vous pouvez trouver des messages Logs not found for Cloud Logging filter dans les journaux Airflow.

Cause :

Si votre environnement exécute un grand nombre de tâches en même temps, les journaux des 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 durées de démarrage pour KubernetesPodOperator et KubernetesExecutor

Les pods créés avec KubernetesPodOperator et les tâches exécutées avec KubernetesExecutor connaissent des durées de démarrage plus longues. L'équipe Managed Airflow travaille sur une solution et annoncera la résolution du problème.

Solutions :

  • Lancez des pods avec plus de processeurs.
  • Si possible, optimisez les images (moins de calques, taille plus petite).

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

Les environnements Managed Airflow affecté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 ceux-ci 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. Vous pouvez ainsi 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 d'un rattachement de réseau lorsqu'un environnement est supprimé

Si plusieurs environnements qui partagent le même rattachement de réseau sont supprimés en même temps, certaines opérations de suppression échouent avec 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 les environnements qui utilisent le même rattachement de réseau un par un.

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

Dégradation des performances de l'environnement dans plusieurs versions du package google-api-core

Les versions du package préinstallé google-api-core comprises entre 2.28.0 et 2.30.2 peuvent entraîner une dégradation des performances de l'environnement, ce qui peut entraîner des durées d'exécution plus longues pour une tâche et des durées plus longues pour passer une tâche de l'état "En file d'attente" à l'état "En cours d'exécution".

Builds Managed Airflow (3e génération) 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 à composer-3-airflow-2.10.5-build.33
  • composer-3-airflow-2.9.3-build.42 à composer-3-airflow-2.9.3-build.53

Builds Managed Airflow (2e génération) concernés :

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

Nous vous recommandons de mettre à niveau votre environnement vers les versions suivantes, qui contiennent une version du package où le problème est résolu ou n'est pas présent :

  • composer-3-airflow-3.1.7-build.7 et versions ultérieures
  • composer-3-airflow-2.11.1-build.3 et versions ultérieures
  • composer-3-airflow-2.10.5-build.36 et versions ultérieures
  • composer-3-airflow-2.9.3-build.54 (contient 2.27.0)
  • composer-2.17.0-airflow-2.11.1 et versions ultérieures
  • composer-2.17.0-airflow-2.10.5 et versions ultérieures
  • composer-2.16.11-airflow-2.11.1 (contient 2.27.0)
  • composer-2.16.11-airflow-2.10.5 (contient 2.27.0)
  • composer-2.16.11-airflow-2.9.3 (contient 2.27.0)

Pour contourner ce problème, vous pouvez installer manuellement une version ultérieure du google-api-core package dans un environnement affecté en spécifiant >=2.30.3 comme version requise.

Étape suivante