Le pipeline se termine en vert, sans une seule erreur, et le fichier de sortie contient quarante mille lignes au lieu de trente-huit mille. Ou bien il s’exécutait en douze secondes la semaine dernière et il en met maintenant quatre minutes. Dans les deux cas, le réflexe le plus répandu consiste à semer des transforms Write to log un peu partout, à relancer, puis à tout commenter avant de livrer.
Apache Hop propose beaucoup mieux. Entre les métriques par transform, le mode Preview & debug avec condition d’arrêt, les niveaux de log gradués et la perspective Execution Information, vous disposez d’un véritable outillage d’observation, en développement comme en production.
Prérequis
- Apache Hop 2.19.0, publiée le 17 août 2026, ou une version proche.
- Un runtime Java 21 64 bits. La documentation valide Oracle Java Runtime, Microsoft OpenJDK et OpenJDK, et signale qu’Adoptium pose problème avec Hop.
- Un pipeline qui produit déjà des lignes, même imparfaitement, et une configuration d’exécution de type moteur local — l’installation par défaut en fournit une.
1. Commencer par les métriques, pas par les logs
Après chaque exécution dans Hop GUI, le panneau Execution Results s’ouvre en bas de la fenêtre avec deux onglets : Transform Metrics et Logging. La plupart des développeurs vont directement au second. C’est une erreur de méthode : le premier répond bien plus vite à la question « où le compte de lignes dérape-t-il ? ».
| Métrique | Signification |
|---|---|
| Input | Lignes lues depuis une source externe |
| Read | Lignes reçues du transform précédent |
| Written | Lignes envoyées au transform suivant |
| Output | Lignes écrites vers une cible externe |
| Rejected | Lignes détournées vers un transform de gestion d’erreurs |
| Errors | Erreurs non détournées, signalées par un triangle rouge |
| Duration | Durée d’exécution du transform |
| Speed | Lignes par seconde, soit les lignes traitées divisées par la durée |
Deux lectures sont particulièrement utiles. Comparez d’abord Read et Written transform par transform : l’endroit où le nombre de lignes gonfle brutalement est presque toujours une jointure ou un lookup qui ramène plusieurs correspondances là où vous en attendiez une seule. Repérez ensuite le transform le plus lent via Speed et Duration : c’est le goulot d’étranglement, et le seul qu’il soit rentable d’optimiser.
Le panneau propose aussi Buffers Input et Buffers Output, supérieures à zéro uniquement pendant l’exécution. Un tampon de sortie constamment plein devant un transform signifie que celui-ci n’absorbe pas le débit de son prédécesseur : c’est l’indicateur le plus direct de la cause d’un ralentissement. Le moteur local affiche ces métriques en temps réel, ce que les autres moteurs ne font pas nécessairement.
2. S’arrêter exactement sur la ligne fautive
Quand les métriques ont désigné le transform suspect, il faut regarder les données. C’est le rôle du mode Preview & debug, accessible depuis l’icône de preview de la barre d’outils, par le menu Run puis Preview & debug, ou par l’entrée Preview & debug output du menu contextuel d’un transform.
Dans la boîte de dialogue, vous sélectionnez le transform à observer puis renseignez Retrieve first rows, le nombre de lignes à collecter. L’option décisive se trouve juste en dessous : Pause on breakpoint, assortie d’une condition. Le pipeline s’interrompt dès qu’une ligne satisfait cette condition, et les lignes collectées s’affichent dans la fenêtre de preview. Quick Launch démarre l’inspection, Configure permet de changer de configuration d’exécution au préalable.
C’est toute la différence entre « j’inspecte les cent premières lignes en espérant y trouver le problème » et « je m’arrête sur la ligne dont le code client est vide ». Sur plusieurs millions de lignes où l’anomalie concerne trois enregistrements, cette option fait gagner des heures.
3. Doser le niveau de log
Les logs restent indispensables, à condition de choisir le bon niveau. Hop en définit sept, du moins au plus verbeux : NOTHING, ERROR, MINIMAL, BASIC, DETAILED, DEBUG, ROWLEVEL. BASIC est le niveau standard, concis et informatif ; DETAILED expose ce qui se passe en coulisses ; DEBUG ajoute les valeurs précises ; ROWLEVEL rapporte les valeurs pour chaque ligne.
La règle pratique : DETAILED pour comprendre un comportement d’ensemble, ROWLEVEL uniquement sur un échantillon réduit, jamais sur un pipeline de production complet. En ligne de commande, le niveau se passe à hop-run avec l’option -l (forme longue --level) :
./hop-run.sh \
--project=mon-projet \
--environment=dev \
--runconfig=local \
--file='${PROJECT_HOME}/pipelines/chargement-ventes.hpl' \
--parameters=DATE_DEBUT=2026-10-01,DATE_FIN=2026-10-19 \
--level=DETAILED \
--logfile=/var/log/hop/chargement-ventes.logL’option -lf / --logfile indique le fichier dans lequel Hop Run écrit le log console : préférez-la à une redirection shell, elle survit aux changements d’orchestrateur. Pensez aussi à -o / --printoptions, qui affiche les options réellement prises en compte, précieux quand un paramètre semble ignoré. Un détail de vocabulaire : la documentation de hop-run liste DEBUG là où l’interface graphique affiche Debugging — c’est le même niveau.
4. Garder la trace de ce qui s’est exécuté
Les outils précédents sont interactifs : ils supposent que vous soyez devant l’écran au moment du problème. Pour les exécutions planifiées, Hop propose le type de métadonnées Execution Information Location, qui indique où envoyer les informations d’exécution. Celles-ci sont ensuite consultables dans la perspective Execution Information.
Une location se configure avec un Name, une Description et trois paramètres de cadence : Data logging delay (ms) (2000 par défaut), Data logging interval (ms) (5000) et Data logging size (rows) (1000). Le champ Location type choisit le plugin d’écriture :
- File location : écrit dans un dossier du système de fichiers (Root folder, Create folder?). Le plus simple pour commencer.
- Caching File Location : regroupe les informations par pipeline ou workflow dans des fichiers JSON de premier niveau et les conserve en mémoire avant écriture, ce qui réduit la charge disque au prix de davantage de mémoire.
- Remote location : envoie les informations à un Hop Server.
- Caching Database location : stocke un document JSON par exécution dans une table relationnelle,
hop_executionspar défaut, avec des colonnes de filtrage pour que la perspective interroge efficacement.
Pour le type base de données, l’option Show table and indexes DDL génère les instructions CREATE TABLE et CREATE INDEX adaptées à votre dialecte sans les exécuter : vous devez les lancer vous-même avant d’écrire des données.
Une location s’attache ensuite à une configuration d’exécution de pipeline, dont les options comprennent Execution information location et Execution data profile aux côtés de Engine Type. Vous pouvez donc avoir une configuration de développement sans location et une configuration de production qui archive son historique.
5. Profiler les données, pas seulement l’exécution
Le type de métadonnées Execution Data Profile construit des profils de données au fil de leur passage dans les pipelines. Vous y sélectionnez un ou plusieurs Data Samplers to use :
- Data profile output rows : profilage de base des lignes en sortie, avec Sample size (25 par défaut), Last transforms only (vrai), Minima, Maxima, Count nulls, Count non-nulls, Min length et Max length.
- First output rows et Last output rows : échantillonnent les premières ou les dernières lignes (Sample size 100).
- Random output rows : échantillonnage par réservoir des lignes de sortie.
L’intérêt est considérable pour une anomalie intermittente : chaque exécution archive le nombre de valeurs nulles et les bornes de chaque champ, et vous comparez le profil de l’exécution fautive avec celui de la veille. Attention, Last transforms only est actif par défaut et limite le profilage aux transforms terminaux : désactivez-le pour profiler des étapes intermédiaires.
6. Observer un pipeline sans le modifier
Reste un cas délicat : surveiller en continu la sortie d’un pipeline sans y toucher. Le type de métadonnées Pipeline Probe envoie les lignes de sortie d’un pipeline vers un autre pipeline, qui peut alors les traiter pour du contrôle qualité, du profilage ou de la traçabilité. Quatre champs suffisent : Name, Enabled (vrai par défaut), Pipeline executed to capture logging — le pipeline récepteur, qui commence par un transform Pipeline Data Probe — et Capture output of the following transforms.
Aucune modification du pipeline surveillé n’est nécessaire : vous ajoutez une surveillance qualité à un pipeline déjà livré, puis la retirez en basculant Enabled, sans toucher au fichier .hpl ni repasser par la chaîne d’intégration. Le projet samples fourni avec Hop contient un exemple complet autour de la métadonnée pipeline-probe-example.
Ce que vous avez gagné
Vous disposez d’une démarche en quatre temps plutôt que d’un réflexe unique. Les métriques par transform localisent le problème sans lire une ligne de log. Preview & debug avec condition d’arrêt vous amène sur la donnée fautive. Les niveaux de log et les options de hop-run rendent les exécutions non interactives analysables après coup. Enfin, Execution Information Location, Execution Data Profile et Pipeline Probe transforment chaque exécution planifiée en trace exploitable, sans ajouter un seul transform de débogage. Le gain réel n’est pas de corriger plus vite : c’est de ne plus avoir à reproduire un incident pour le comprendre.