Dépannage réseau Apache Hop avec exemples pratiques

Introduction

Apache Hop est une puissante plateforme d'orchestration de données qui communique fréquemment avec des systèmes externes : bases de données, partages de fichiers, files de messages et services cloud. Lorsqu'un pipeline échoue en raison d'un problème réseau, la cause première est rarement évidente. S'agit-il d'une mauvaise configuration DNS ? D'un pare-feu qui bloque silencieusement les paquets ? D'une entrée de table de routage qui dirige le trafic dans la mauvaise direction ? Sans approche systématique, le dépannage peut prendre des heures et conduire à des modifications de configuration dangereuses.

Ce guide fournit des procédures pratiques, étape par étape, pour diagnostiquer et résoudre les problèmes de réseau dans les environnements Apache Hop. Nous couvrons l'inventaire de l'environnement, les pratiques de configuration sûres, les commandes de vérification, les modes de défaillance courants avec les étapes de récupération et une liste de contrôle opérationnelle. Tous les exemples sont concrets et prêts à être adaptés à votre infrastructure.

Inventaire des versions et de l'environnement

Avant d'apporter des modifications, documentez votre environnement actuel. Cela évite les erreurs et vous donne une vision claire de ce qui pourrait être affecté. Enregistrez au minimum :

• Version d'Apache Hop (par exemple, 1.2.0)
• Système d'exploitation et version (par exemple, Ubuntu 20.04, Windows Server 2019)
• Version de Java (Hop nécessite Java 11 ou ultérieur)
• Topologie réseau : sur site, cloud, hybride ou conteneurisé (par exemple, Docker, Kubernetes)
• Services externes auxquels Hop se connecte : bases de données (PostgreSQL, MySQL, Oracle), API, partages de fichiers (SMB, NFS), files de messages (RabbitMQ, Kafka), stockage cloud (S3, Azure Blob)
• Règles de pare-feu et politiques de sécurité réseau en place (pare-feu locaux, groupes de sécurité cloud, listes de contrôle d'accès réseau)
• Adresse IP et nom d'hôte du serveur Hop

Exemple de tableau d'inventaire pour un déploiement typique :

Gardez cet inventaire à jour et accessible à toute personne susceptible de faire du dépannage. En équipe, désignez une personne (par exemple, l'ingénieur plateforme de données) pour le maintenir et le réviser mensuellement.

Chemin de configuration sûr

Préférez toujours des modifications étroites et réversibles à des modifications larges. Par exemple, si une connexion à une base de données échoue, testez d'abord la connectivité depuis le serveur Hop vers la base de données à l'aide d'outils en ligne de commande avant de modifier les paramètres de connexion Hop. Cette approche isole le problème et réduit le risque d'introduire de nouveaux problèmes.

Suivez cette procédure de configuration sûre :

1. Isolez la connexion défaillante : identifiez exactement quelle transformation ou étape de pipeline Hop échoue et quelle ressource externe elle utilise.
2. Testez la connexion réseau sous-jacente : utilisez telnet, nc, ping ou curl depuis le serveur Hop pour vérifier la connectivité vers l'hôte et le port cibles.
3. Vérifiez la résolution DNS : assurez-vous que le nom d'hôte se résout en la bonne adresse IP en utilisant nslookup ou dig.
4. Examinez les règles de pare-feu : confirmez que le port requis est ouvert entre la source et la destination, à la fois localement et dans tout pare-feu intermédiaire ou groupe de sécurité.
5. Apportez une modification à la fois : mettez à jour la configuration, puis refaites le test avant de poursuivre.
6. Documentez les modifications : tenez un journal de ce qui a été changé, pourquoi et comment revenir en arrière.

Exemple : test de connectivité à la base de données avec nc :

nc -vz 10.0.1.50 5432

Sortie attendue en cas de succès :

Connection to 10.0.1.50 5432 port [tcp/postgresql] succeeded!

Si cela échoue, vous verrez un délai d'attente ou « Connection refused ». Cela indique un problème de réseau ou de pare-feu, pas un problème de configuration Hop.

Vérification et diagnostics

Après avoir apporté une modification, vérifiez qu'elle a résolu le problème. Utilisez plusieurs outils de diagnostic pour confirmer la connectivité et le bon fonctionnement. Les sous-sections suivantes couvrent les vérifications les plus importantes.

Vérifications de la résolution DNS

Si un nom d'hôte ne se résout pas, utilisez nslookup ou dig :

nslookup database.internal

Sortie attendue :

Server:         192.168.1.1
Address:        192.168.1.1#53

Name:   database.internal
Address: 10.0.1.50

Si cela échoue, vérifiez le fichier hosts local (/etc/hosts sous Linux, C:\Windows\System32\drivers\etc\hosts sous Windows) pour les entrées manuelles, et examinez la configuration du serveur DNS (/etc/resolv.conf sous Linux, paramètres de la carte réseau sous Windows).

Pour plus de détails, utilisez dig :

dig database.internal

Recherchez la section ANSWER SECTION pour confirmer l'adresse IP et le TTL. Une section de réponse manquante ou un statut SERVFAIL indique un problème DNS.

Test de connectivité des ports

Utilisez curl pour les points de terminaison HTTP(S), y compris les API REST et les services cloud. Par exemple, pour tester AWS S3 :

curl -I https://s3.us-east-1.amazonaws.com

Sortie attendue (HTTP 200 ou 403 est courant ; 403 signifie que le chemin réseau fonctionne mais que l'accès est refusé) :

HTTP/1.1 403 Forbidden
...

Pour les services non HTTP, utilisez nc ou telnet. Exemple avec telnet :

telnet 10.0.1.50 5432

Si le port est ouvert, vous verrez un message de connexion ou un écran vide (vous pouvez quitter avec Ctrl+]). Si cela échoue, vous obtiendrez un délai d'attente ou « Connection refused ».

Vérifications du routage et du pare-feu

Vérifiez la route vers la destination :

traceroute 10.0.1.50

Sous Windows, utilisez tracert. Cela montre chaque saut. Si cela s'arrête à un certain point, il peut y avoir un problème de routage ou un pare-feu qui bloque. Notez que certains routeurs peuvent ne pas répondre aux sondes traceroute, interprétez donc les résultats avec prudence.

Sous Linux, vérifiez la table de routage :

ip route show

Vérifiez que la passerelle par défaut et les routes spécifiques sont correctes. Pour ajouter une route temporaire (pour test), utilisez :

sudo ip route add 10.0.1.0/24 via 192.168.10.1

Vérifiez les règles de pare-feu locales :

• Linux avec ufw : sudo ufw status numbered
• Linux avec iptables : sudo iptables -L -n -v
• Windows : netsh advfirewall firewall show rule name=all

Dans les environnements cloud, examinez les règles entrantes et sortantes du groupe de sécurité pour le serveur Hop et le service cible. Assurez-vous que l'IP source (IP publique ou privée du serveur Hop) est autorisée sur le port requis.

Test depuis Apache Hop

Une fois la connectivité externe confirmée, testez depuis Hop lui-même. Créez un pipeline simple avec une transformation qui se connecte à la ressource externe, comme une étape « Table Input » pour une base de données. Exécutez le pipeline et vérifiez les journaux Hop.

Les journaux Hop se trouvent généralement dans le fichier logs/hop.log ou sont affichés dans la console GUI de Hop. Recherchez des messages comme Connection refused, Unknown host ou timeout.

Exemple d'extrait de journal Hop indiquant une défaillance DNS :

2023-01-15 10:00:00 - Table input.0 - ERROR: Could not connect to database: Unknown host 'database.internal'

Cela confirme que Hop ne peut pas résoudre le nom d'hôte, même si le système d'exploitation le peut. Cela peut indiquer que Hop utilise un résolveur DNS différent ou que le cache DNS de Java est obsolète. Pour vider le cache DNS de Java, redémarrez Hop ou définissez la propriété JVM -Dsun.net.inetaddr.ttl=0 temporairement.

Pour les erreurs SSL/TLS, vous pourriez voir :

2023-01-15 10:05:00 - REST Client.0 - ERROR: SSLHandshakeException: PKIX path building failed

Cela indique un problème de confiance de certificat, couvert dans la section des modes de défaillance.

Modes de défaillance et récupération

Les modes de défaillance courants, leurs symptômes et les étapes de récupération sont détaillés ci-dessous. Testez toujours la connectivité après chaque action de récupération.

Défaillance 1 : Mauvaise configuration DNS

Symptômes : Erreurs « Unknown host » dans les journaux Hop, échecs intermittents si plusieurs serveurs DNS sont configurés et que l'un est en panne.

Récupération :

1. Vérifiez avec nslookup ou dig depuis le serveur Hop.
2. Si le serveur DNS est incorrect ou injoignable, mettez à jour /etc/resolv.conf (Linux) ou les paramètres réseau (Windows).
3. Comme solution temporaire, ajoutez une entrée au fichier hosts : /etc/hosts (Linux) ou C:\Windows\System32\drivers\etc\hosts (Windows). Par exemple :

   10.0.1.50    database.internal

1. Videz le cache DNS sur le serveur Hop :

• Linux : sudo systemd-resolve --flush-caches ou sudo service nscd restart
• Windows : ipconfig /flushdns

1. Videz le cache DNS de Java en redémarrant Hop ou en définissant -Dsun.net.inetaddr.ttl=0 dans le script de démarrage Hop (pour test uniquement).

Défaillance 2 : Pare-feu bloquant le port

Symptômes : Délai d'attente de connexion (pas de réponse) lors de l'utilisation de nc, telnet ou des tentatives Hop.

Récupération :

1. Confirmez le blocage en testant depuis le serveur Hop vers le port cible avec nc ou telnet.
2. Vérifiez le pare-feu local sur le serveur Hop : sudo ufw status ou sudo iptables -L.
3. Ouvrez le port requis s'il est bloqué localement. Par exemple, pour autoriser PostgreSQL depuis votre sous-réseau :

   sudo ufw allow from 192.168.10.0/24 to any port 5432 proto tcp

1. Vérifiez les pare-feu intermédiaires et les groupes de sécurité cloud. Ajoutez une règle autorisant le trafic depuis l'IP du serveur Hop vers le port du service.
2. Vérifiez à nouveau avec nc.

Défaillance 3 : Routage incorrect

Symptômes : Le trafic va vers la mauvaise interface ou est abandonné ; traceroute montre des sauts inattendus ou s'arrête à mi-chemin.

Récupération :

1. Inspectez la table de routage : ip route show (Linux) ou route print (Windows).
2. Recherchez des routes manquantes ou une passerelle par défaut incorrecte.
3. Si une route spécifique est manquante, ajoutez-la (temporaire) :

   sudo ip route add 10.0.2.0/24 via 192.168.10.1 dev eth0

Pour une route permanente, modifiez la configuration réseau (par exemple, netplan sur Ubuntu, /etc/network/interfaces sur les anciens systèmes, ou la commande route add Windows avec -p).

1. Si la passerelle par défaut est incorrecte, corrigez-la et assurez-vous que l'interface est active.
2. Testez avec ping et traceroute pour confirmer le chemin.

Défaillance 4 : Échec de la poignée de main SSL/TLS

Symptômes : SSLHandshakeException dans les journaux Hop, en particulier pour les points de terminaison HTTPS ou les connexions de base de données avec SSL requis.

Récupération :

1. Obtenez le certificat du serveur. Vous pouvez utiliser un navigateur pour l'exporter ou openssl :

   openssl s_client -connect database.internal:5432 -showcerts

1. Assurez-vous que le certificat est approuvé. Pour Hop basé sur Java, importez le certificat dans le keystore Java utilisé par Hop :

   keytool -import -alias databasecert -keystore $JAVA_HOME/lib/security/cacerts -file cert.pem

Le mot de passe par défaut du keystore cacerts est changeit (changez-le si ce n'est pas déjà fait).

1. Redémarrez Hop et testez la connexion.
2. Si vous utilisez un certificat auto-signé, envisagez de l'ajouter au truststore ou de configurer Hop pour faire confiance à tous les certificats pour les tests (non recommandé en production).

Conseils de retour en arrière

Gardez toujours une sauvegarde des fichiers de configuration avant de les modifier. Les fichiers Hop pertinents incluent :

• hop-config.json (configuration globale)
• Définitions de connexion dans les métadonnées Hop (souvent stockées dans le projet ou shared.xml)
• Variables d'environnement et scripts de démarrage
• Toute option JVM personnalisée

Pour les bases de données, utilisez un système de contrôle de version pour toute modification manuelle. Si une modification provoque de nouveaux problèmes, revenez à la sauvegarde et refaites le test. Documentez la procédure de retour en arrière dans votre manuel d'exploitation.

Pièges courants et comment les éviter

1. Ne pas tester depuis le serveur Hop lui-même. D'autres machines peuvent avoir un accès réseau différent. Exécutez toujours les commandes de diagnostic sur le même hôte où Hop s'exécute.
2. Supposer que le DNS est correct lorsque ping fonctionne. ping peut utiliser un chemin de résolution de noms différent (par exemple, le fichier hosts) que les applications Java. Vérifiez toujours avec nslookup et testez la connexion réelle.
3. Ouvrir trop de ports de pare-feu. Évitez les règles globales comme « autoriser tout depuis 0.0.0.0/0 ». Limitez plutôt aux IP sources ou sous-réseaux spécifiques et aux ports requis.
4. Négliger le cache DNS de Java. Java met en cache les recherches DNS. Après avoir modifié le DNS, vous devrez peut-être redémarrer Hop ou ajuster le TTL de la JVM.
5. Ignorer la différence entre délai d'attente et connexion refusée. Un délai d'attente suggère un pare-feu qui bloque silencieusement les paquets, tandis qu'une connexion refusée signifie que le port est fermé ou que le service n'écoute pas. Cette distinction aide à cerner la cause.
6. Ne pas vérifier les groupes de sécurité cloud. Dans les environnements cloud, le pare-feu de l'instance et le groupe de sécurité doivent autoriser le trafic. Le groupe de sécurité est souvent le coupable.
7. Modifier la configuration Hop avant de tester la connectivité de base. Testez d'abord avec les outils du système d'exploitation ; si nc échoue, le problème n'est pas dans Hop.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour les vérifications de santé réseau de routine et après tout changement lié au réseau. Attribuez un responsable (par exemple, l'administrateur réseau ou l'ingénieur plateforme de données) pour effectuer ces vérifications mensuellement ou après chaque changement d'infrastructure.

Conclusion

Le dépannage des problèmes réseau d'Apache Hop nécessite une approche méthodique. Commencez par documenter votre environnement, puis testez la connectivité au niveau du système d'exploitation avant de plonger dans la configuration Hop. Utilisez des outils comme nc, nslookup et curl pour isoler les problèmes de DNS, de pare-feu ou de routage. Apportez une modification à la fois et vérifiez son effet. Gardez un plan de retour en arrière et maintenez une liste de contrôle opérationnelle pour les vérifications de santé continues.

En suivant les exemples pratiques de ce guide, vous pouvez réduire les temps d'arrêt et maintenir la fiabilité de vos pipelines de données. N'oubliez pas : un test étroit et mesurable révèle souvent la cause première plus rapidement que de deviner les modifications de configuration.