Aller au contenu principal

Détail d'une exécution

Cliquer sur un run dans la liste des exécutions ouvre son détail (/monitoring/<uuid>) : l'état complet du run, ses logs en direct, ses métriques de ressources et le déroulé de ses étapes.

Le détail d&#39;une exécution L'en-tête de statut, les onglets Logs / Métriques / Lineage et le panneau latéral (étapes, contexte, détails).

L'en-tête​

La carte d'en-tête résume le run :

  • statut (icône colorée + badge) : Succès, Terminé avec avertissements, Erreur, En cours, Arrêté ;
  • identité : nom du pipeline et identifiant court du run (#a1b2c3d4) ;
  • méta : runner, heures de début et fin, durée (qui défile en direct tant que le run tourne), date, origine et version du pipeline exécutée ;
  • navigation : flèches vers le run précédent et suivant du même pipeline.

Actions​

  • Exporter : télécharge les logs du run en CSV (horodatage, niveau, brique, message), indépendamment du filtre de niveau actif ;
  • Arrêter (run en cours) : demande l'arrêt au runner ;
  • Relancer (run terminé) : démarre une nouvelle exécution du même pipeline sur le même runner, et ouvre son détail ;
  • le menu ⋮ : copier l'URL du run, voir le pipeline source, voir le runner.

Onglet Logs​

Les logs arrivent en temps réel (WebSocket) pendant le run, puis restent consultables ensuite. La barre d'outils propose :

  • un filtre par niveau : ALL, INFO, WARN, ERROR ;
  • une recherche en texte libre (message et nom de brique) ;
  • une case Auto-scroll : la vue suit la dernière ligne ; décochez-la pour lire tranquillement pendant que le run continue.

Si la connexion se coupe​

Le flux temps réel passe par un socket, et un socket se perd : veille de la machine, coupure réseau, redéploiement du serveur. L'écran se réabonne tout seul dès que la liaison revient, puis recharge le journal — les lignes passées pendant la coupure reprennent leur place, elles n'ont pas disparu.

C'est vrai dans le Studio comme ici. Il n'y a plus à actualiser la page.

Journal tronqué​

Pendant qu'un run tourne, ses lignes sont gardées en mémoire par le serveur, dans une fenêtre glissante de 10 000 lignes par défaut. Un flux très bavard la dépasse : les plus anciennes tombent, et ce sont celles du début du run.

Quand c'est arrivé, un bandeau le dit en tête du journal, avec le nombre de lignes perdues. Le plafond se relève par la variable d'environnement MONITORING_LOG_BUFFER_MAX_LINES côté serveur — au prix de la mémoire du pod.

Une fois le run terminé

Le journal complet est écrit dans un fichier et n'est plus soumis à ce plafond : la troncature ne concerne que la lecture pendant l'exécution.

Onglet Métriques​

L'onglet Métriques agrège la télémétrie rapportée par le runner :

  • six cartes : Lignes lues, Lignes sorties, CPU moy., CPU peak, RAM moy., RAM peak ;
  • deux courbes temporelles CPU et RAM sur la durée du run (dès que la télémétrie contient plusieurs échantillons) ;
  • un tableau par brique : statut, durée et consommation CPU/RAM attribuée à chaque brique du pipeline.
remarque

Ces valeurs affichent « — » pour les runs exécutés par un runner qui ne rapporte pas encore la télémétrie. Pendant un run, la télémétrie se rafraîchit toutes les 5 secondes.

Onglet Lineage​

Le lineage représente le flux d'exécution des briques, de gauche à droite : chaque nœud porte son numéro d'étape, son statut (succès, erreur, en cours) et sa durée. Le résumé en tête compte les étapes terminées, en cours et en erreur.

Le panneau latéral​

La timeline des étapes La carte Étapes : un mini-gantt du déroulé, chaque barre positionnée sur la durée totale du run.

  • Erreur (runs en échec) : le premier message d'erreur et la brique fautive, avec un raccourci de relance ;
  • Étapes : la timeline des briques exécutées ; chaque étape est positionnée et dimensionnée proportionnellement à la durée totale ; un lien bascule vers l'onglet Lineage ;
  • Contexte : les connexions et variables résolues au moment du run, telles que fournies par l'environnement du projet (les valeurs secrètes sont exclues) ;
  • Détails : les informations techniques du run.
astuce

La carte Contexte est le bon réflexe quand un run se comporte différemment entre deux environnements : elle montre exactement quelles valeurs de configuration le run a utilisées.

Et ensuite ?​