Surveiller Apache Hop et déclencher des alertes : guide pratique avec exemples

Intro

Cette version française explique Apache Hop monitoring and alerts with practical examples avec le même objectif pratique que l article source : aider le lecteur à comprendre le contexte, les décisions à prendre et les points à vérifier avant de passer à l action.

Apache Hop déplace des données via des pipelines et des workflows. Lorsqu'une exécution échoue ou ralentit, il faut un retour rapide et précis pour corriger en toute sécurité ou revenir en arrière. Ce guide propose une approche de Apache Hop monitoring à faible risque : partir des logs sur fichiers, extraire quelques Apache Hop metrics à fort signal, câbler des Apache Hop alerts simples, construire un Apache Hop dashboard compact et vérifier le tout avec des tests contrôlés. Vous y trouverez des commandes, des exemples construits et des étapes de reprise que vous pouvez adapter à votre environnement pour une Apache Hop incident response efficace.

Principes clés à appliquer :

• Démarrer par un pilote simple et mesurable, vérifiable localement avant de l'étendre.
• Séparer configuration, collecte et alerte pour rendre chaque changement réversible.
• Surveiller d'abord la correction (succès/échec), la ponctualité (durée et horaire) et la pression de ressources (débit de lignes, retries, indices mémoire) avant d'ajouter des métriques exotiques.

Inventaire des versions et de l'environnement

Avant tout changement, établissez une base commune de discussion.

Prérequis

• Être capable d'exécuter les pipelines/workflows Hop depuis l'interface Hop GUI ou la ligne de commande sur l'hôte cible.
• Disposer d'un accès shell et d'un accès en lecture au répertoire de logs.
• Pouvoir créer un répertoire pour les artefacts de monitoring (scripts, métriques parsées, logs de test).

Enregistrez versions et topologie

• Version d'Apache Hop et source d'installation (archive tar, paquet système, etc.).
• Version de la JVM sur l'hôte d'exécution.
• Système d'exploitation et version.
• Topologie d'exécution (hôte local, multiples hôtes avec ordonnanceur, Hop Server).
• Emplacement des logs utilisés par vos exécutions ou wrappers de service.

Exemples de commandes (à adapter) :

# Version Java (exemple construit)
java -version

# Détails OS (exemple construit)
uname -a

# Créer les répertoires d'artefacts
sudo mkdir -p /var/log/hop
sudo mkdir -p /opt/hop-monitoring/bin /opt/hop-monitoring/state
sudo chown -R "$USER" /opt/hop-monitoring

Définir le périmètre pilote

• Choisissez un pipeline quotidien critique et un workflow de support. C'est suffisant pour valider l'approche et régler les seuils.
• Décidez où stocker les métriques parsées (par exemple, un CSV local dans /opt/hop-monitoring/state) pour les alimenter ensuite dans l'outil de dashboard de votre choix.

Que surveiller dans Apache Hop

Inutile de multiplier les métriques au départ. Concentrez-vous sur un petit ensemble à fort signal.

Note sur les lignes traitées : si un pipeline traite parfois 0 ligne (pas de nouvelles données), documentez une fenêtre d'exception (p. ex. week-ends).

Chemin de configuration sûr

1. Piloter seulement deux exécutables

• Sélectionnez un pipeline (ex. daily_load.hpl) et un workflow (ex. nightly_compact.hwf) avec leurs noms/chemins réels.

1. Utiliser d'abord des logs sur fichiers

• Assurez-vous que chaque exécution ajoute à un fichier daté dans /var/log/hop via redirection stdout/stderr. Conservez 14 jours de logs.

1. Capturer quelques champs

• Par exécution : statut (succès/échec), horodatages début/fin, durée en secondes, lignes lues/écrites par transform clé, compteur de lignes ERROR et compte de retries (si présent dans le texte de log).

1. Seuils conservateurs

• Démarrez large et resserrez après une semaine de données.

1. Changements réversibles

• Chaque règle vit dans son propre fichier ou bloc clairement désactivable.

1. Valider localement, puis planifier

• Testez les scripts manuellement, confirmez les métriques parsées, puis branchez-les à votre ordonnanceur ou wrapper.

Collecte et alertes : exemples pratiques

Motifs de logs à parser (exemples construits)

2026/08/01 02:15:30 - pipeline - Pipeline daily_load started
2026/08/01 02:16:40 - transform OrdersInput - read: 120345 written: 120345
2026/08/01 02:16:50 - transform FilterBadRows - read: 120345 written: 120200 rejected: 145
2026/08/01 02:17:07 - pipeline - Pipeline daily_load finished (duration: 97 s)

Échec (exemple construit) :

2026/08/01 02:15:30 - pipeline - Pipeline daily_load started
2026/08/01 02:17:07 - transform OrdersOutput - ERROR: failed to write batch: timeout
2026/08/01 02:17:07 - pipeline - ERROR: Pipeline failed after 97 s (1 errors)

Parser les signaux essentiels avec des outils shell

Utilisez des outils portables pour prouver le concept, remplaçables plus tard par votre collecteur préféré.

#!/usr/bin/env bash
# /opt/hop-monitoring/bin/parse_hop_log.sh
# Usage: parse_hop_log.sh /var/log/hop/daily_load_2026-08-01.log

set -euo pipefail
LOG_FILE="$1"
NAME=$(basename "$LOG_FILE" .log)
START_TS=$(grep -m1 -E "Pipeline .* started|Workflow .* started" "$LOG_FILE" | awk '{print $1" "$2}')
END_OK=$(grep -m1 -E "Pipeline .* finished|Workflow .* finished" "$LOG_FILE" || true)
END_ERR=$(grep -m1 -E "ERROR: Pipeline failed|ERROR: Workflow failed" "$LOG_FILE" || true)
ERROR_COUNT=$(grep -E " ERROR: " "$LOG_FILE" | wc -l | tr -d ' ')
DURATION_SEC=$(grep -m1 -E "duration: [0-9]+ s|after [0-9]+ s" "$LOG_FILE" | grep -oE "[0-9]+" | head -1)

STATUS="unknown"
if [ -n "$END_ERR" ]; then STATUS="failed"; fi
if [ -n "$END_OK" ]; then STATUS="success"; fi

# Indice simple de lignes traitées depuis un transform clé si présent
ROWS=$(grep -E "transform .* - read: [0-9]+" "$LOG_FILE" | tail -1 | grep -oE "read: [0-9]+" | awk '{print $2}')
: "${ROWS:=0}"

# Émettre une ligne CSV pour les tableaux de bord
OUT="$(date +%Y-%m-%dT%H:%M:%S%z),$NAME,$STATUS,${DURATION_SEC:-0},$ERROR_COUNT,$ROWS"
echo "$OUT" | tee -a /opt/hop-monitoring/state/hop_runs.csv

# Émettre des alertes via codes de sortie et stdout (consommés par l'ordonnanceur)
if [ "$STATUS" = "failed" ]; then
  echo "ALERT: $NAME failed in ${DURATION_SEC:-0}s with $ERROR_COUNT error lines"
  exit 2
fi
if [ "${DURATION_SEC:-0}" -gt 900 ]; then
  echo "ALERT: $NAME duration ${DURATION_SEC}s exceeds 15m threshold"
  exit 3
fi
if [ "$ROWS" = "0" ]; then
  echo "WARN: $NAME processed 0 rows"
  exit 0
fi

Notes

• Les motifs utilisent un phrasé générique issu des exemples construits. Adaptez au format réel de vos logs.
• Le script ajoute au CSV /opt/hop-monitoring/state/hop_runs.csv et imprime des messages d'alerte consommables par votre ordonnanceur.
• Les codes de sortie peuvent être mappés à des sévérités.

Brancher le parseur à vos exécutions

Si vous utilisez déjà un wrapper, ajoutez une étape de parsing après chaque run :

#!/usr/bin/env bash
# /usr/local/bin/run_daily_load.sh (exemple construit)
set -euo pipefail
LOG="/var/log/hop/daily_load_$(date +%F).log"

# Exécuter Hop (remplacez par votre invocation réelle)
# Assurez l'écriture dans "$LOG" et un retour non-zéro en cas d'échec
/path/to/hop-run.sh \
  --file=/opt/hop/projects/pipelines/daily_load.hpl \
  --logFile="$LOG" --logLevel=Detailed || true

# Parser et émettre les alertes
/opt/hop-monitoring/bin/parse_hop_log.sh "$LOG"

Pour un ordonnanceur avec hooks post-run, appelez le parseur dans ce hook avec le chemin de log spécifique.

Règles d'alerte efficaces dès le jour 1

Catégories de départ :

• Correction : tout run en échec.
• Ponctualité : run dépassant un seuil fixe ou le P95 récent de 25%.
• Complétude : run avec 0 ligne quand ce n'est pas attendu.

Astuce : appliquez un rate limit (ex. 30 min) aux doublons pendant un incident prolongé.

Tableaux de bord et KPI

Parce que le parseur écrit un CSV, vous pouvez grapher dans l'outil de votre choix.

Panneaux recommandés

• Taux de succès (7 et 30 jours) par pipeline/workflow.
• Tendance de durée par exécution, avec lignes de référence médiane et P95.
• Lignes traitées par run, surlignant les valeurs sous le plancher.
• Comptage d'alertes par type dans le temps (échec, lent, zéro ligne).

Options en maturant

• Comptes lu/écrit par transform pour les 3 plus volumineux.
• Retries/backoff par système cible (entrepôt, objet, API).
• Respect d'horaire : nuage de points heure prévue vs réelle.

Guides KPI (chiffres construits, à ajuster après 1 semaine)

• Taux de succès : >= 99% pour les runs critiques quotidiens.
• Durée : médiane dans ±10% semaine sur semaine; alerte à > 25% au-dessus du P95.
• Tolérance zéro-ligne : 0 en semaine pour sources critiques; exceptions documentées le week-end.

Vérification et diagnostics

Vérifiez avant de dépendre du dispositif.

1. Chemin heureux

• Lancer le pipeline pilote une fois. Confirmer :
• Un nouveau log apparaît dans /var/log/hop.
• Le parseur ajoute une ligne CSV dans /opt/hop-monitoring/state/hop_runs.csv.
• Aucune alerte pour un run réussi et rapide.

1. Chemin échec (contrôlé)

• Injecter une panne (ex. destination temporairement invalide) et relancer. Confirmer :
• Le log contient une ligne ERROR.
• Le parseur imprime ALERT et sort avec code 2.
• L'ordonnanceur route correctement l'alerte.

1. Chemin lent

• Ajouter un sleep artificiel pour dépasser 15 min. Confirmer :
• Alerte de durée imprimée, code 3.

1. Chemin complétude

• Filtre d'entrée retournant 0 ligne. Confirmer :
• WARN avec ROWS==0.

1. Diagnostic si échec des vérifications

• CSV vide : vérifier permissions /opt/hop-monitoring/state et chemin du parseur.
• Logs manquants : confirmer l'écriture dans le fichier attendu et le dossier.
• Durées nulles : adapter la regex aux tournures réelles des logs.

Modes de panne et reprise

1. Alertes bruyantes

• Causes possibles : retries courts, règles sur erreurs transitoires, seuils trop serrés.
• Reprise : rate limit 30 min, élargir les seuils de 20%, désactiver temporairement la règle la plus bruyante.

1. Dérive de parsing

• Cause : changement de phrasé après upgrade Hop.
• Reprise : capturer un log frais, mettre à jour les regex dans parse_hop_log.sh, garder une sauvegarde pour rollback.

1. Logs manquants ou tournants

• Cause : chemin changé, rotation trop agressive.
• Reprise : aligner le parseur, parser à la fin d'exécution, porter la rétention à 14 jours, vérifier droits.

1. Runs longs ou bloqués

• Cause : lenteur amont, deadlock, attente d'entrée.
• Reprise : alerte de runtime max (ex. 2× P95), inspecter les dernières lignes de log, mettre en pause les dépendants, redémarrer au dernier point idempotent si sûr.

1. Pression de ressources

• Cause : contention hôte, mémoire JVM insuffisante, limites de descripteurs.
• Reprise : décaler les runs lourds, augmenter la mémoire prudemment et tester, relever les ulimits, ajouter du backoff entre transforms lourds.

1. Mauvais paramètres ou horaires

• Cause : date erronée, désalignement avec la disponibilité source.
• Reprise : recouper les paramètres logués, aligner le schedule, ajouter une garde pour éviter un run quand la source est connue vide.

Rollback

• Parseur : conserver la version précédente et un symlink. En cas de régression, repointer et relancer les vérifications.
• Règles d'alerte : stocker chaque seuil séparément pour une désactivation unitaire, avec valeurs de base et date de changement.
• Pipelines : maintenir des versions; si un déploiement crée du bruit ou des échecs, revenir au dernier bon connu et revalider.

Conclusion

Vous disposez maintenant d'une méthode pragmatique pour surveiller Apache Hop :

• Un pilote étroit avec logs sur fichiers et un petit nombre de métriques à fort signal.
• Un parseur simple qui extrait statut, durée, erreurs et lignes.
• Des règles d'alerte de base pour correction, ponctualité et complétude.
• Des tableaux de bord qui tracent taux de succès, durées et volumes.
• Des étapes de vérification et des playbooks de reprise pour les pannes courantes.

Faites évoluer prudemment : intégrez vos plateformes d'alerting et de visualisation, ajoutez des métriques par transform sur les parcours critiques et ne resserrez les seuils qu'après avoir collecté des tendances. Gardez chaque changement réversible, validez d'abord en local et documentez les exceptions pour que les équipes réagissent rapidement et avec confiance.