Dépannage réseau Apache Airflow avec exemples pratiques : guide de mise en œuvre

Introduction

Apache Airflow dépend de plusieurs connexions réseau : le webserver et l'API, la base de métadonnées, des brokers optionnels (pour CeleryExecutor), et parfois des collecteurs de métriques. Quand Airflow est lent ou injoignable, la cause est fréquemment liée au DNS, aux ports, à l'adresse de liaison (bind), au routage ou aux pare-feu. Ce guide vous propose des commandes sûres pour isoler rapidement les problèmes, décrit les résultats attendus afin de raisonner sur les sorties, et fournit un plan de retour arrière si un changement n'aide pas.

Le chemin le plus rapide vers la clarté consiste à tester d'abord une tranche étroite et mesurable, à vérifier localement, puis à élargir la portée. Des points de terminaison nommés et clairs pour les services Airflow réduisent les échanges et rendent les diagnostics reproductibles entre environnements. Dans cet esprit, ce guide aborde explicitement Apache Airflow networking, Apache Airflow DNS, Apache Airflow ports et Apache Airflow connectivity pour un Apache Airflow network troubleshooting efficace.

Inventaire des versions et de l'environnement

Avant tout changement, capturez ce qui tourne réellement. Cela évite de courir après le mauvais problème et offre une base de retour arrière connue.

Prérequis :

• Accès shell aux hôtes Airflow (webserver, scheduler, workers, base de données, broker).
• Possibilité d'exécuter des outils réseau de base : ss ou netstat, lsof, curl, nc (netcat), dig ou nslookup, traceroute.
• Accès en lecture à la configuration Airflow (souvent $AIRFLOW_HOME/airflow.cfg) et aux logs.

Consignez les éléments suivants sur chaque hôte pertinent :

1. Version d'Airflow et exécuteur

airflow version
airflow config get-value core executor

1. Python et OS

python --version
uname -a

1. Inventaire des processus

ps -ef | grep -E 'airflow|celery' | grep -v grep

1. Points de terminaison et ports (exemples construits)

• Webserver : http://airflow-web.example.internal:8080
• Scheduler : processus local ; pas de port entrant
• Base de métadonnées (ex. Postgres) : airflow-db.example.internal:5432
• Broker (ex. Redis ou RabbitMQ pour Celery) : redis.example.internal:6379 ou rabbitmq.example.internal:5672
• Métriques (StatsD optionnel) : statsd.example.internal:8125/udp

1. Valeurs de configuration clés

airflow config get-value webserver web_server_host
airflow config get-value webserver web_server_port
airflow config get-value webserver base_url
airflow config get-value core sql_alchemy_conn
airflow config get-value celery broker_url
airflow config get-value celery result_backend

Tableau : points de terminaison réseau Airflow courants (par défaut, adaptez à votre contexte).

Résultat attendu : une page avec versions, noms d'hôtes et ports. C'est votre source de vérité pendant le diagnostic.

Chemin de configuration sûr

Les changements réseau peuvent interrompre l'accès. Utilisez une approche réversible :

• Sauvegardez les fichiers de configuration : cp $AIRFLOW_HOME/airflow.cfg $AIRFLOW_HOME/airflow.cfg.bak.$(date +%Y%m%d%H%M%S)
• Changez une chose à la fois ; testez ; puis continuez.
• Préférez des tests temporaires (curl, nc) à des changements permanents tant que l'hypothèse n'est pas prouvée.
• Utilisez un créneau de maintenance si un redémarrage est nécessaire.

Modifications à faible risque et à périmètre réduit :

• Adresse et port d'écoute du webserver
• Si l'UI n'est accessible qu'en local : définissez l'hôte sur 0.0.0.0 pour un accès distant dans un réseau de confiance, ou sur l'IP d'interface voulue.
• Exemple (construit) : dans airflow.cfg, section [webserver] :

[webserver]
web_server_host = 0.0.0.0
web_server_port = 8080
base_url = http://airflow-web.example.internal:8080

• DNS de la base et du broker
• Remplacez temporairement un nom défaillant par une IP directe pour distinguer un souci DNS d'un problème de joignabilité.
• Si l'IP fonctionne, corrigez le DNS plutôt que de laisser l'IP en dur.

• Ouvertures de pare-feu
• Ouvrez seulement les ports nécessaires, depuis les sources qui en ont besoin. Testez avec une règle temporaire avant de la pérenniser.

Plan de retour arrière :

• Restaurez airflow.cfg depuis la sauvegarde et redémarrez uniquement le(s) service(s) concerné(s).
• Rétablissez les règles de pare-feu à partir de la liste sauvegardée puis rechargez.

Vérifications et diagnostics

Réalisez des tests simples, puis de plus en plus profonds. Arrêtez-vous dès que vous trouvez l'étape défaillante.

1. Le webserver tourne-t-il et écoute-t-il ?

# Sockets en écoute sur des ports Airflow courants
sudo ss -tulpn | grep -E ':(8080|5432|5672|6379)'

# Ou
sudo lsof -i -P -n | grep -E ':(8080|5432|5672|6379)'

Attendu : une ligne montrant python (airflow webserver) lié à 0.0.0.0:8080 ou IP:8080. S'il est lié à 127.0.0.1:8080, les clients distants ne l'atteindront pas.

1. Vérification HTTP locale depuis l'hôte

curl -sS -I http://127.0.0.1:8080/ | head -n 1
curl -sS http://127.0.0.1:8080/health || true

Attendu :

• La première commande renvoie HTTP/1.1 200 OK ou 302 Found (redirection de login). Le socket et HTTP sont OK.
• /health peut renvoyer du JSON si activé. S'il répond 404 mais que la page racine renvoie 200/302, le webserver est suffisamment sain pour servir l'UI.

1. Vérification HTTP distante depuis un client

curl -sS -I http://airflow-web.example.internal:8080/ | head -n 1

Si ceci échoue mais que le test local réussit, enquêtez DNS, routage ou pare-feu.

1. Résolution DNS

getent hosts airflow-web.example.internal
dig +short airflow-web.example.internal
nslookup airflow-web.example.internal

Attendu : IP cohérentes entre hôtes. Si la résolution diffère ou manque, corrigez d'abord le DNS.

1. Vérification de la route

# traceroute TCP vers le port web
sudo traceroute -T -p 8080 airflow-web.example.internal

Attendu : une liste de sauts stable finissant sur l'IP du webserver. Des timeouts en fin de parcours indiquent souvent un pare-feu hôte.

1. Joignabilité du port sans HTTP

# Depuis un hôte client
nc -vz airflow-web.example.internal 8080

# Pour DB et broker (exemples)
nc -vz airflow-db.example.internal 5432
nc -vz redis.example.internal 6379
nc -vz rabbitmq.example.internal 5672

Attendu : messages "succeeded" pour les ports joignables. "Connection refused" = hôte joignable mais pas de processus à l'écoute. "Timeout" = pare-feu ou trou noir de routage.

1. Connectivité base de données depuis l'hôte Airflow

# Exemple Postgres
psql "$(airflow config get-value core sql_alchemy_conn)" -c 'select 1;'

# Exemple MySQL
mysql --execute='select 1;' "$(airflow config get-value core sql_alchemy_conn)"

Attendu : une ligne avec 1. Si l'authentification échoue alors que le réseau est OK, corrigez identifiants ou paramètres SSL.

1. Connectivité broker depuis un worker (CeleryExecutor)

# Exemple Redis
redis-cli -h redis.example.internal -p 6379 PING

# Exemple RabbitMQ
openssl s_client -connect rabbitmq.example.internal:5672 -quiet < /dev/null || true

Attendu : Redis répond PONG ; pour RabbitMQ, vous validez au minimum la poignée de main TCP sauf si TLS/AMQPS est configuré.

1. Vérifications du pare-feu hôte (selon votre système)

# UFW
sudo ufw status verbose

# firewalld
sudo firewall-cmd --list-all

# iptables (héritage)
sudo iptables -S | sed -n '1,200p'

Attendu : vérifiez que 8080, 5432, 5672, 6379 sont autorisés depuis les bonnes sources.

1. Logs Airflow pour corroboration

# Remplacez par votre AIRFLOW_HOME si besoin
ls -1 $AIRFLOW_HOME/logs/

grep -iE 'connection|error|timeout|refused|dns' -R $AIRFLOW_HOME/logs/ | sed -n '1,100p'

Attendu : les erreurs réseau mentionnent timeout, refused, name or address not known, ou des échecs SSL. Alignez les horodatages avec vos tests.

Tableau : mémo diagnostic rapide.

Modes de panne et récupération

Utilisez cette cartographie pour passer des symptômes aux causes probables et aux premiers correctifs.

Tableau : pannes réseau Airflow courantes et premières actions (exemples construits).

Modèles de récupération :

1. Correction d'adresse de liaison

• Modifier [webserver] web_server_host vers 0.0.0.0 (ou IP d'interface sur réseau de confiance).
• Redémarrer uniquement le webserver.
• Revérifier curl local et distant.
• Retour arrière : restaurer airflow.cfg si l'exposition est trop large.

1. Conflit de port

• Identifier le processus en conflit :

sudo ss -tulpn | grep :8080
sudo lsof -iTCP:8080 -sTCP:LISTEN -n -P

• Option A : arrêter le processus inutile. Option B : déplacer Airflow sur un port libre (ex. 8081) et mettre à jour base_url.
• Valider avec curl ; ajuster d'éventuelles règles de pare-feu.
• Retour arrière : revenir au port d'origine si des clients y sont figés.

1. Remédiation DNS

• Prouver le chemin une fois avec une IP directe :

curl -I http://10.10.20.30:8080/

• Si l'IP fonctionne, corriger le DNS (A/CNAME, domaines de recherche). Évitez les IP en dur dans airflow.cfg.
• Vider les caches si nécessaire :

sudo resolvectl flush-caches || sudo systemd-resolve --flush-caches || true

• Retour arrière : retirer les surcharges IP temporaires.

1. Ouverture de pare-feu (exemple UFW)

# Autorisation temporaire depuis un client précis
sudo ufw allow from 192.0.2.10 to any port 8080 proto tcp
sudo ufw status numbered

• Tester avec nc et curl. Si OK, consigner et pérenniser proprement.
• Retour arrière :

sudo ufw delete <rule-number>

1. Joignabilité de la base

• Depuis l'hôte Airflow, tester le port DB et la connexion ; corriger réseau et identifiants.
• Exemple Postgres minimal :

PGURI="$(airflow config get-value core sql_alchemy_conn)"
psql "$PGURI" -c 'select 1;'

• Si SSL requis, vérifier le CA et sslmode dans la chaîne de connexion.

1. Restauration broker (CeleryExecutor)

• Redis :

redis-cli -h redis.example.internal -p 6379 PING

• RabbitMQ :

nc -vz rabbitmq.example.internal 5672

• Corriger broker_url (DNS, identifiants) ou ouvrir le port. Redémarrer les workers après validation.

1. Réglage proxy ou load balancer

• Reproduire un timeout avec curl -v pour observer le délai et d'éventuels en-têtes.
• Augmenter les timeouts et le keepalive entre proxy et webserver Airflow.
• Valider via plusieurs requêtes curl rapides ; la latence doit se stabiliser.

1. Mésalignements SSL/TLS

• Inspecter avec openssl :

openssl s_client -connect airflow-web.example.internal:8443 -servername airflow-web.example.internal -showcerts < /dev/null

• Mettre à jour certificats et aligner les versions de protocole selon la politique de sécurité.

Checklist d'exploitation

Pré-vol

• Capturer version Airflow, exécuteur et points de terminaison.
• Documenter les hôtes et ports attendus pour web, DB, broker, métriques.
• Sauvegarder airflow.cfg et toute règle de pare-feu à modifier.

Contrôle quotidien ou hebdomadaire

• ss -tulpn montre le webserver à l'écoute sur l'hôte: port visé.
• curl -I vers l'UI en local et depuis un client distant renvoie 200/302.
• getent hosts pour tous les noms d'hôtes Airflow renvoie les IP attendues.
• Pour CeleryExecutor : nc -vz vers broker et DB réussit depuis les workers.

Gestion de changement

• Modifier une variable à la fois (bind, port, DNS, pare-feu).
• Tester localement, puis à distance ; enregistrer sorties et horodatages.
• En cas d'échec, revenir immédiatement aux configs et règles sauvegardées.

Réponse incident

• Confirmer processus et écoute (ss, lsof).
• Distinguer refus vs. timeout (nc) : refused => pas d'écoute ; timeout => filtrage/routage.
• Valider la cohérence DNS entre hôtes (getent, dig).
• Tracer la route uniquement si DNS et curl local sont bons.
• Vérifier les logs pour des erreurs alignées sur vos tests.

Après-incident

• Remplacer tout contournement par IP par un DNS propre.
• Durcir les pare-feu au moindre privilège tout en maintenant les flux validés.
• Mettre à jour cette checklist avec les commandes et sorties observées.

Conclusion

Les problèmes réseau d'Airflow se ramènent à quelques questions : un processus écoute-t-il où prévu, les clients peuvent-ils le résoudre et l'atteindre, et les middleboxes autorisent-elles le flux ? En partant d'un test réduit et vérifiable, en confirmant DNS et adresses de liaison, puis en utilisant des vérifications ciblées de joignabilité, vous isolez vite les défaillances. Conservez des sauvegardes de airflow.cfg et des règles de pare-feu, changez une variable à la fois et revenez vite en arrière si nécessaire. Adoptez le mémo de diagnostics et la checklist comme base d'équipe pour transformer la validation et la récupération en réflexes.