Liste de contrôle des opérations en production Apache Airflow avec exemples pratiques (Airflow 2.7+ et 3.x)

Introduction

Traitez Apache Airflow comme tout service critique : configurez-le avec intention, observez-le en continu et entraînez-vous à le restaurer. Cette liste de contrôle axée opérateurs couvre Airflow 2.7+ et 3.x (3.3 comme référence actuelle). Elle précise quoi inventorier, comment vérifier l’état des composants, quoi mesurer, et comment sauvegarder, mettre à niveau et récupérer sans risque. SQLite et les modes standalone ou quick-start ne sont pas des déploiements de production; utilisez une base de métadonnées PostgreSQL ou MySQL-compatible externe et des exécuteurs prêts pour la production.

1) Faites d’abord l’inventaire de votre déploiement

Avant d’optimiser ou de dépanner, capturez une source de vérité unique.

Exécutez ces commandes depuis un ordonnanceur ou un pod/hôte utilitaire.
Remplacez les espaces réservés comme <scheduler-pod> et <database-host> par vos valeurs.

Tableau 1 : Inventaire des versions et du déploiement

Élément	Commande ou source	Exemple de valeur	Étape de vérification
Version d’Airflow	`airflow version`	3.3.0	Confirmez majeure.mineure et notez les différences 2.x vs 3.x.
Méthode de déploiement	docs/runbook	Publication Helm Kubernetes `<release-name>`	Faites correspondre au manifeste CI/CD et aux empreintes des images.
Exécuteur	`airflow config get-value core executor`	KubernetesExecutor	Assurez-vous que l’exécuteur est aligné avec la topologie des processus d’exécution.
Base de métadonnées	`airflow config get-value database sql_alchemy_conn`	`postgresql+psycopg2://...@<database-host>:5432/airflow`	Confirmez un Postgres ou MySQL externe, pas SQLite.
Distribution des DAG	docs/runbook	Sidecar Git-sync vers `/opt/airflow/dags`	Vérifiez le chemin et la révision de mise à jour des DAG.
Journalisation distante	`airflow config get-value logging remote_logging`	True	Confirmez que `remote_base_log_folder` est accessible.
Secrets backend	`airflow config get-value secrets backend`	`airflow.providers.hashicorp.vault.secrets.vault.VaultBackend`	Validez l’accès en lecture avec une connexion de test.
Providers	`python -m pip list`	`apache-airflow-providers-amazon 9.x`	Vérifiez les versions des providers selon les contraintes.
Gestionnaire d’authentification	`airflow config get-value webserver auth_backend`	`airflow.api.auth.backend.session`	Validez le flux de connexion et les rôles.
Architecture (2 vs 3)	docs/runbook	Airflow 3 avec API server et DAG processor externe	Assurez-vous que les composants sont déployés en conséquence.

2) Composants et contrôles de santé

Connaissez le rôle de chaque composant et comment le vérifier :

API server (Airflow 3) ou webserver (Airflow 2) : sert l’UI et les requêtes API.
Ordonnanceur : crée les DagRuns et TaskInstances; place les tâches dans les files.
DAG processor : analyse le code des DAG. Processus indépendant dans Airflow 3.
Triggerer : exécute les opérateurs et capteurs différables (deferrable).
Processus d’exécution (workers) : exécutent les tâches sous la direction de l’exécuteur (Celery, Kubernetes, Local).
Base de métadonnées : registre des états d’Airflow.
Stockage des journaux distant : conservation des logs de tâches (S3, GCS, Azure, etc.).

Points de terminaison d’état et vérifications CLI (copiables) :

Santé de l’API server Airflow 3.x

curl -sSf http://<api-host>/api/v2/monitor/health

Attendez-vous à un HTTP 200 et un JSON avec des statuts par composant; un 200 seul n’est pas suffisant.

Santé du webserver Airflow 2.x

curl -sSf http://<webserver-host>/health

Attendez-vous à un HTTP 200 et un JSON indiquant les composants sains.

Vivacité de l’ordonnanceur (2.7+ et 3.x)

airflow jobs check --job-type SchedulerJob --hostname <scheduler-hostname>

Un code de sortie 0 indique que le signal de présence (heartbeat) de l’ordonnanceur est récent.

Serveur d’état de l’ordonnanceur (si activé dans airflow.cfg)

curl -sSf http://<scheduler-host>:8974/health

Attendez-vous à un HTTP 200 avec un corps de statut minimal.

Processus du DAG processor (Airflow 3.x) et arriéré

ps aux | grep airflow | grep dag-processor

Attendez-vous à au moins un processus actif; vérifiez les journaux pour les délais d’analyse et les erreurs d’import.

Triggerer

airflow jobs check --job-type TriggererJob --hostname <triggerer-hostname>

Un code de sortie 0 indique que le triggerer envoie son signal de présence.

Connectivité base de données (exemple Postgres)

psql "host=<database-host> dbname=airflow user=<user>" -c "select 1;"

Attendez un seul enregistrement avec 1; investiguez la latence et les connexions si c’est lent.

Tableau 2 : Santé des composants et premières actions

Composant ou symptôme	Causes probables	Première vérification sûre	Commande exemple	Résultat attendu
API server ou UI lente	Saturation de la base de données, latence du backend d’authentification, CPU hôte	Vérifiez connexions base de données et CPU	`psql ... -c "select count(*) from pg_stat_activity;"`	Connexions dans les limites configurées.
Signal de présence de l’ordonnanceur à l’arrêt	Panne de base de données, interblocage, pression mémoire, crash loop	Utilisez jobs check et inspectez les journaux de l’ordonnanceur	`airflow jobs check --job-type SchedulerJob`	Sortie 0 si sain; journaux avec signaux de présence stables.
Arriéré d’analyse des DAG	Imports coûteux, trop peu de processus d’analyse	Inspectez journaux et métriques du dag-processor	`grep -i "processing" $AIRFLOW_HOME/logs/dag_processor/*`	Durée d’analyse stable et sous la cible.
ge des tâches en file qui augmente	Capacité de l’exécuteur, saturation de pools, plantages des processus d’exécution	Vérifiez pools et concurrence des processus d’exécution	`airflow pools list`	Pool utilisé sous la limite ou ajustez au besoin.
Saturation des processus d’exécution	Trop de tâches parallèles, limites hôte	Comparez créneaux des processus d’exécution vs limites pod/VM	`kubectl get pods -l component=worker`	Nombre désiré en exécution et prêt.
Retard du triggerer	Beaucoup de tâches différables, triggerer à l’arrêt	Vérifiez le job triggerer et ses journaux	`airflow jobs check --job-type TriggererJob`	Sortie 0 et faible arriéré.
Erreurs de base de données dans l’UI	Changement d’ACL réseau, souci de certificat TLS	Testez la connectivité directe à la base de données	`psql ... -c "select 1;"`	Requête réussie avec faible latence.
Échecs de logs distants	Mauvais IAM, politique de bucket, identifiants temporaires expirés	Suivez les journaux de tâches pour erreurs d’upload	`grep -i "failed to upload" <task-log>`	Absence d’erreurs après rafraîchissement des identifiants.

3) Observabilité pour éviter les surprises

Suivez les symptômes corrélés aux incidents pour trier rapidement. Les seuils ci-dessous sont illustratifs : établissez d’abord votre référence.

Signal de présence et délai de l’ordonnanceur : alertez s’ils manquent plusieurs intervalles.
Temps d’analyse des DAG et erreurs d’import : des hausses durables signalent des goulots.
ge des tâches en file et en cours : des âges longs indiquent un manque de capacité ou des pools saturés.
Échecs et retries des tâches : des pics pointent des incidents aval ou des régressions de code.
Détection de zombies : enquêtez les tâches sans signal de présence mais marquées running.
Saturation des pools : une utilisation proche de la limite bloque le travail critique.
Capacité exécuteur/processus d’exécution : surveillez la longueur des files par queue.
Latence et connexions de la base de données : requêtes lentes persistantes ou pics de connexions.
Santé du triggerer : arriéré de tâches différables, CPU/mémoire du triggerer.
Erreurs et taux API : hausse des 5xx ou des échecs d’authentification = problèmes amont.
Erreurs d’upload des journaux distants : assurez des journaux complets et à temps.
Saturation hôte/conteneur : pression CPU, mémoire, disque provoque de l’instabilité.

4) Configuration opérationnelle et capacité

Évitez les chiffres universels; réglez à partir des mesures et d’essais de charge.

Capacité dépendante de l’exécuteur : faites correspondre les créneaux de parallélisme des processus d’exécution aux limites des systèmes aval. Utilisez des pools pour plafonner les cibles partagées.

# Exemple : plafonner l’entrepôt de données à 5 tâches concurrentes
airflow pools set dw_pool 5 "Concurrence entrepôt de données"
# Vérifiez
airflow pools list
# Assurez-vous que les tâches déclarent pool="dw_pool"

Concurrence et parsing (illustratif)

airflow config get-value core parallelism
airflow config get-value core max_active_tasks_per_dag
airflow config get-value scheduler parsing_processes

Ajustez progressivement en surveillant la charge de la base de données et le délai de l’ordonnanceur.

Journalisation distante et variables d’environnement : définissez logging.remote_logging=True et fournissez un remote_base_log_folder stable. Gardez les identifiants hors d’airflow.cfg via un secrets backend. Validez en exécutant une petite tâche et en vérifiant l’apparition des journaux distants en quelques minutes.

N’utilisez pas SQLite ni les modes standalone/quick-start en production. Préférez des services gérés PostgreSQL ou MySQL-compatibles avec sauvegardes, limites de connexions et TLS.

5) Modèles de fiabilité pour les DAG

Tâches idempotentes et sûres en retry : concevez pour éviter les effets de bord en cas de retry. Préférez upserts, écritures partitionnées, ou transactions externes.
Intervalles de données stables : utilisez data intervals et logical dates plutôt que l’horloge; évitez la logique horaire dans les opérateurs.
Retries et délais bornés : définissez retries, retry_delay et execution_timeout avec des pools pour éviter le travail incontrôlé.
Tests d’import : interceptez les échecs au moment de l’analyse avant déploiement.

# Détecter les erreurs d’import sans exécuter les tâches
airflow dags list-import-errors

Attendez-vous à aucune erreur listée. S’il y en a, corrigez puis relancez avant d’activer le DAG.

6) Essentiels de sécurité

Moindre privilège : limitez au strict nécessaire l’accès à la base de données, au stockage d’objets et aux providers.
Secrets backends : stockez connexions et variables dans Vault, AWS Secrets Manager, GCP Secret Manager ou Azure Key Vault. Effectuez des rotations régulières.
Chiffrement : définissez une clé Fernet valide; utilisez TLS pour l’UI et les transports vers la base de données.
Authentification et autorisation : activez le RBAC avec des rôles alignés aux responsabilités opérationnelles. Pour Airflow 3, validez votre gestionnaire d’authentification avec l’API server.
Frontières réseau : isolez l’UI et la base de métadonnées dans des réseaux de confiance.
Auditabilité : conservez les journaux d’actions UI et l’historique des changements des providers; vérifiez la provenance et les empreintes des images et des packages providers.
Évitez les secrets partagés entre composants qui n’en ont pas besoin.

7) Sauvegarde et restauration

Sauvegardez des actifs que vous pouvez réellement restaurer. Les exercices de restauration doivent être scriptés et répétables.

Tableau 3 : Matrice de sauvegarde, restauration et validation

Actif	À sauvegarder	Approche de restauration	Étape de validation	Notes
Base de métadonnées	Sauvegarde complète quotidienne et incrémentales fréquentes	Provisionnez une nouvelle base de données, restezorez un instantané, repointez Airflow	Airflow démarre, DAG et connexions visibles	Ne considérez pas les pods/conteneurs actifs comme une sauvegarde.
Source des DAG ou bundles	Dépôt Git et artefacts construits	Redéployez depuis un commit tagué ou un artefact	L’analyse des DAG réussit et les calendriers correspondent	Gardez des builds reproductibles.
Configuration-as-code	airflow.cfg, environnement, valeurs Helm	Réappliquez la configuration dans un nouvel environnement	Les contrôles de santé réussissent	Excluez les secrets des dépôts; référencez des backends.
Références de secrets	Chemins de secrets et politiques d’accès	Recréez rôles ou comptes de service	Un DAG de connexion de test réussit	N’exportez jamais de secrets bruts dans les sauvegardes.
Plugins, providers, images custom	Registre d’images et jeu de versions épinglées des providers	Retaguez et redéployez les versions d’images	Les tests d’import passent	Vérifiez la correspondance des empreintes des images.
Journaux distants	Chemin de stockage objet et règles de cycle de vie	Repointez le nouvel Airflow vers le même bucket	Les journaux historiques des tâches sont accessibles	Durée de rétention selon besoins.
Définitions d’infra	Terraform ou modèles cloud	Recréez l’infrastructure de base et le réseau	Le nouvel environnement passe les tests de fumée	Documentez les différences par région.

Exercice minimal de restauration (illustratif) :

Démarrez un environnement vide avec la même version d’Airflow et les mêmes exécuteurs.
Restaurez la base de métadonnées sur une nouvelle instance; repointez Airflow vers celle-ci.
Déployez les mêmes DAG et images/providers.
Exécutez un DAG de vérification en lecture seule qui liste les connexions et vérifie une exécution historique par DAG critique.
Documentez les écarts; mettez à jour les runbooks. La reprise est bornée par le point de restauration de la base de données et la rétention des journaux.

8) Des mises à niveau fiables

Planifiez les mises à niveau comme des changements contrôlés avec des retours arrière testés. Pour Airflow 2.7+ et 3.x, la commande base de données est airflow db migrate.

Tableau 4 : Étapes, jalons et retours arrière de mise à niveau

Étape	Actions opérateur	Jalon pour continuer	Retour arrière si échec	Notes de version
Plan et contraintes	Lisez notes de version et contraintes, épinglez les providers	Matrice de compatibilité revue	Différez la mise à niveau et ouvrez des tickets	En 3.x, confirmez compatibilité auth et plugins.
Build en environnement de préproduction	Reconstruisez l’image, mettez à jour providers, appliquez la configuration	Import des DAG et exécutions basiques OK	Revenez au tag d’image et aux versions épinglées des providers	Utilisez le même exécuteur et moteur de base de données que la production.
Répétition de la migration de la base de données	Stoppez les ordonnanceurs, lancez `airflow db migrate` en environnement de préproduction	Migrations sans erreurs	Restaurez la base de données depuis un instantané et réessayez	N’utilisez pas `airflow db upgrade`.
Déploiement progressif ou arrêt bref	Stratégie selon exécuteur et orchestration	Runbook approuvé	Abandonnez et conservez la production actuelle	Le rolling est limité selon les exécuteurs.
Migration en production	Sauvegarde, arrêt des ordonnanceurs, `airflow db migrate`	Airflow démarre et contrôles de santé OK	Restaurez base de données et images précédentes	Validez immédiatement `jobs check` et l’état de l’API.
Vérification post-upgrade	Lancez des DAG représentatifs et passez en revue les métriques	Aucune régression sur la fenêtre convenue	Restaurez image et instantané de la base de données	Gardez un plan de retour valide pendant la fenêtre.

Changements Airflow 3 pertinents pour les opérateurs :

L’API server remplace le webserver RBAC 2.x pour les opérations API.
Le DAG processor tourne indépendamment; mettez à l’échelle l’analyse séparément de la planification.
Le Task SDK et les frontières de sécurité durcissent les imports et l’exécution; validez opérateurs et plugins personnalisés.
Les vérifications de migration de configuration au démarrage peuvent bloquer des clés héritées invalides; examinez les journaux.
Les interfaces d’authentification et de plugins peuvent nécessiter des mises à jour; mettez en préproduction et testez à fond.

9) Séquence d’incident courte : perte de signal de présence de l’ordonnanceur ou hausse de l’âge des tâches en file

Observation : alerte pour signal de présence manquant de l’ordonnanceur ou âge des tâches en file au-delà du seuil.
Cadrage : identifiez les DAG, pools et queues affectés; vérifiez si le triggerer ou l’API server est aussi dégradé.
Préservez les éléments factuels : capturez journaux ordonnanceur/processus d’exécution, comptez les connexions à la base de données, relevez la version d’Airflow et les empreintes des images.
Dépendances : vérifiez l’état de la base de données, la disponibilité du stockage objet et les événements d’autoscaling du cluster.
Intervention la moins risquée : redémarrez uniquement le composant affecté (par ex. un seul pod d’ordonnanceur), évitez les clears larges ou redémarrages massifs.
Vérifiez le rétablissement : confirmez que airflow jobs check renvoie 0, que l’âge en file diminue et que de nouvelles tâches sont planifiées.
Suivi : créez un ticket de cause racine avec métriques, journaux et recommandations de configuration/capacité.

Si vous envisagez airflow tasks clear, cadrez-le précisément, faites un essai préalable d’abord et comprenez les effets aval.

# Essai préalable d’un clear ciblé pour une seule TaskInstance
airflow tasks clear -s 2024-07-01 -e 2024-07-01 <dag-id> <task-id> --dry-run
# Puis confirmez le périmètre et, si sûr, relancez sans --dry-run

Vérifiez que l’instance effacée est replanifiée et se termine; contrôlez les déclenchements aval non souhaités.

10) Opérations de routine

Installez des habitudes prévisibles au quotidien, chaque semaine, chaque mois et au moment des releases.

Tableau 5 : Liste de contrôle des opérations quotidiennes, hebdomadaires, mensuelles et à la release

Cadence	Actions	Vérification	Notes
Quotidien	Revue du délai de l’ordonnanceur, âge en file, principaux DAG en échec	Tableaux de bord stables ou en amélioration	Ajustez pools ou concurrence selon les éléments observés.
Hebdomadaire	Purgez anciens XComs et journaux d’échecs selon la politique	Croissance stockage dans le budget	Utilisez un DAG de maintenance pour un nettoyage prévisible.
Mensuel	Rotation des clés, audit des rôles, vacuum/analyze de la base de données	Contrôles d’accès et performances OK	Coordonnez avec les équipes sécurité et base de données.
À la release	Préproduction, migration avec `airflow db migrate`, vérification des DAG	Contrôles de santé et smoke tests OK	Gardez plan de rollback et instantané prêts.

Conclusion

Un Airflow prêt pour la production résulte d’un inventaire discipliné, de contrôles de santé explicites, d’une observabilité ciblée, d’une configuration prudente et d’exercices de restauration répétés. Utilisez cette liste de contrôle bornée par version pour déployer et opérer Airflow 2.7+ et 3.x avec confiance : vérifiez chaque composant, mesurez les symptômes qui comptent, sauvegardez des actifs restaurables, mettez à niveau avec des jalons et des retours arrière, et répondez aux incidents avec les actions les moins risquées qui rétablissent le service. Adaptez chaque exemple illustratif à vos mesures, et maintenez vos runbooks à jour au rythme de votre environnement.