Utiliser l'interface de surveillance de Cloud Dataflow

Lorsque vous exécutez votre pipeline à l'aide du service géré Cloud Dataflow, vous pouvez afficher la tâche correspondante et toute autre tâche au moyen de l'interface Web de surveillance de Cloud Dataflow. Elle vous permet de voir vos tâches Cloud Dataflow et d'interagir avec elles.

Vous pouvez accéder à l'interface de surveillance de Cloud Dataflow à l'aide de la console Google Cloud Platform. L'interface de surveillance peut vous montrer :

  • une liste de toutes les tâches Cloud Dataflow en cours d'exécution et des tâches précédemment exécutées au cours des 30 derniers jours ;
  • une représentation graphique de chaque pipeline ;
  • des détails relatifs à l'état, à l'exécution et à la version du SDK de votre tâche ;
  • des liens vers des informations sur les services Google Cloud Platform exécutant votre pipeline (tels que Compute Engine et Cloud Storage) ;
  • toute erreur ou avertissement survenus au cours d'une tâche.

Accéder à l'interface de surveillance de Cloud Dataflow

Pour accéder à l'interface de surveillance de Cloud Dataflow :

  1. Connectez-vous à la console GCP.
  2. Sélectionnez votre projet GCP.
  3. Cliquez sur le menu dans le coin supérieur gauche.
  4. Accédez à la section Big Data et cliquez sur Dataflow.

Une liste des tâches Cloud Dataflow ainsi que leur état respectif apparaissent. Si vous ne voyez aucune tâche, vous devez en exécuter une nouvelle. Pour découvrir comment exécuter une tâche, consultez les guides de démarrage rapide de Cloud Dataflow.

Liste de tâches Cloud Dataflow dans les états en cours, ayant échoué et ayant réussi.
Figure 1 : Liste de tâches Cloud Dataflow dans la console GCP, présentant des tâches dans les états "Running" (En cours d'exécution), "Failed" (Échec) et "Succeeded" (Réussie).

Une tâche peut présenter les états suivants :

  •  : l'interface de surveillance n'a pas encore reçu d'information d'état de la part du service Cloud Dataflow.
  • Running (en cours d'exécution) : la tâche est en cours d'exécution.
  • Not started (pas démarrée) : la tâche est créée, mais le système a besoin d'un certain temps pour se préparer avant de la lancer.
  • Queued (en file d'attente) : une tâche FlexRS est en file d'attente.
  • Cancelling... (en cours d'annulation) : la tâche est en cours d'annulation.
  • Cancelled (annulée) : la tâche a été annulée par l'utilisateur.
  • Draining... (drainage en cours) : la tâche est en cours de drainage.
  • Drained (drainée) : l'utilisateur a drainé la tâche.
  • Updating... (en cours de mise à jour) : la tâche est en cours de mise à jour.
  • Updated (mise à jour) : l'utilisateur a mis à jour la tâche.
  • Succeeded (réussie) : la tâche s'est terminée avec succès.
  • Failed (échec) : la tâche n'a pas abouti.

Pour plus d'informations sur un pipeline donné, sélectionnez la tâche correspondante.

Afficher un pipeline

Lorsque vous sélectionnez une tâche Cloud Dataflow donnée, l'interface de surveillance affiche des informations détaillées sur le pipeline associé à cette tâche. Ces informations incluent une représentation graphique de votre pipeline tel qu'il est exécuté sur le service Cloud Dataflow, ainsi qu'un résumé de la tâche, le journal associé, et des informations détaillées sur chaque étape du pipeline.

Tâche de pipeline individuelle dans l'interface de surveillance de Cloud Dataflow.
Figure 2 : Une tâche de pipeline individuelle dans l'interface de surveillance de Cloud Dataflow.

L'interface de surveillance Cloud Dataflow offre une représentation graphique de votre pipeline : le graphique d'exécution. Sur le graphique d'exécution d'un pipeline, chaque transformation est représentée sous la forme d'une case. Chaque case contient le nom de la transformation et certaines informations sur son état, par exemple :

  • Running (en cours d'exécution) : l'étape est en cours d'exécution.
  • Queued (en file d'attente) : l'étape d'une tâche FlexRS est en file d'attente.
  • Succeeded (réussie) : l'étape s'est terminée avec succès.
  • Stopped (arrêtée) : l'étape a été arrêtée car la tâche s'est arrêtée.
  • Unknown (état inconnu) : l'étape n'a pas abouti.
  • Failed (échec) : l'étape n'a pas abouti.

Graphique d'exécution de base

Code du pipeline :

Java : SDK 2.x


  // Read the lines of the input text.
  p.apply("ReadLines", TextIO.read().from(options.getInputFile()))
     // Count the words.
     .apply(new CountWords())
     // Write the formatted word counts to output.
     .apply("WriteCounts", TextIO.write().to(options.getOutput()))
         .to(options.getOutput()));

Python


(p
 # Read the lines of the input text.
 | 'ReadLines' >> beam.io.ReadFromText(options.input)
 # Count the words.
 | CountWords()
 # Write the formatted word counts to output.
 | 'WriteCounts' >> beam.io.WriteToText(options.output))

Java : SDK 1.x


  // Read the lines of the input text.
  p.apply(TextIO.Read.named("ReadLines").from(options.getInput()))
     // Count the words.
     .apply(new CountWords())
     // Write the formatted word counts to output.
     .apply(TextIO.Write.named("WriteCounts")
         .to(options.getOutput())
         .withNumShards(options.getNumShards()));
Graphique d'exécution :

Le graphique d'exécution d'un pipeline WordCount tel qu'affiché dans l'interface de surveillance de Cloud Dataflow.

Figure 3 : Code du pipeline WordCount affiché côte à côte avec le graphique d'exécution obtenu dans l'interface de surveillance de Cloud Dataflow.

Transformations composites

Dans le graphique d'exécution, vous pouvez développer les transformations composites (qui contiennent plusieurs sous-transformations imbriquées). Les transformations composites que vous pouvez développer sont identifiées par une flèche. Cliquez sur cette flèche pour développer la transformation et afficher les sous-transformations qu'elle contient.

Code du pipeline :

Java : SDK 2.x


  // The CountWords Composite Transform
  // inside the WordCount pipeline.

  public static class CountWords
    extends PTransform<PCollection<String>, PCollection<String>> {

    @Override
    public PCollection<String> apply(PCollection<String> lines) {

      // Convert lines of text into individual words.
      PCollection<String> words = lines.apply(
        ParDo.of(new ExtractWordsFn()));

      // Count the number of times each word occurs.
      PCollection<KV<String, Long>> wordCounts =
        words.apply(Count.<String>perElement());

      return wordCounts;
    }
  }

Remarque : Dans l'image à droite, FormatCounts n'est pas pertinent pour ce SDK.

Python


# The CountWords Composite Transform inside the WordCount pipeline.
class CountWords(beam.PTransform):

  def expand(self, pcoll):
    return (pcoll
            # Convert lines of text into individual words.
            | 'ExtractWords' >> beam.ParDo(ExtractWordsFn())
            # Count the number of times each word occurs.
            | beam.combiners.Count.PerElement()
            # Format each word and count into a printable string.
            | 'FormatCounts' >> beam.ParDo(FormatCountsFn()))

Java : SDK 1.x


  // The CountWords Composite Transform
  // inside the WordCount pipeline.

  public static class CountWords
    extends PTransform<PCollection<String>, PCollection<String>> {

    @Override
    public PCollection<String> apply(PCollection<String> lines) {

      // Convert lines of text into individual words.
      PCollection<String> words = lines.apply(
        ParDo.of(new ExtractWordsFn()));

      // Count the number of times each word occurs.
      PCollection<KV<String, Long>> wordCounts =
        words.apply(Count.<String>perElement());

      // Format each word and count into a printable string.
      PCollection<String> results = wordCounts.apply(
        ParDo.of(new FormatCountsFn()));

      return results;
    }
  }
Graphique d'exécution :

Le graphique d'exécution d'un pipeline WordCount, avec la transformation CountWords développée pour afficher les transformations qui la constituent.

Figure 4 : Code du pipeline correspondant aux sous-étapes de la transformation CountWords, affiché côte à côte avec le graphique d'exécution déployé pour l'ensemble du pipeline.

Noms de transformation

Cloud Dataflow propose plusieurs solutions pour obtenir le nom de la transformation apparaissant dans le graphique d'exécution de l'interface de surveillance :

Java : SDK 2.x

  • Cloud Dataflow peut utiliser un nom que vous attribuez lorsque vous appliquez votre transformation. Le premier argument que vous fournissez à la méthode apply sert de nom à votre transformation.
  • Cloud Dataflow peut déduire le nom de la transformation soit du nom de la classe (si vous avez créé une transformation personnalisée), soit du nom de votre objet fonction DoFn (si vous utilisez une transformation de base telle que ParDo).

Python

  • Cloud Dataflow peut utiliser un nom que vous attribuez lorsque vous appliquez votre transformation. Vous pouvez définir le nom de la transformation en renseignant l'argument label de la transformation.
  • Cloud Dataflow peut déduire le nom de la transformation soit du nom de la classe (si vous avez créé une transformation personnalisée), soit du nom de votre objet fonction DoFn (si vous utilisez une transformation de base telle que ParDo).

Java : SDK 1.x

  • Cloud Dataflow peut utiliser un nom que vous attribuez lorsque vous appliquez votre transformation. Le premier argument que vous fournissez à la méthode apply sert de nom à votre transformation.
  • Cloud Dataflow peut déduire le nom de la transformation soit du nom de la classe (si vous avez créé une transformation personnalisée), soit du nom de votre objet fonction DoFn (si vous utilisez une transformation de base telle que ParDo).

Durée d'exécution

Lorsque vous cliquez sur une étape, la métrique Wall time (Durée d'exécution) s’affiche. Cette durée d'exécution fournit une approximation du temps total passé sur l'ensemble des threads et la totalité des nœuds de calcul pour les actions suivantes :

  • Initialisation de l'étape
  • Traitement des données
  • Mélange des données
  • Conclusion de l'étape

Pour les étapes composites, il s'agit de la durée cumulée des étapes des composants. Cette estimation peut vous aider à identifier les étapes particulièrement lentes et à déterminer quelles parties de votre pipeline prennent plus de temps qu'elle ne le devraient.

Vous pouvez afficher le temps nécessaire à l'exécution d'une étape de votre pipeline.
Figure 5 : La métrique Wall time (Durée d'exécution) peut vous aider à vérifier que votre pipeline fonctionne efficacement.

Reportez-vous à la rubrique Comprendre la gestion du temps dans les pipelines Cloud Dataflow qui comporte un exemple utilisant la métrique durée d'exécution (précédemment appelée Temps total d'exécution) pour déterminer la cause de la lenteur d'exécution d'un pipeline.

Métriques des entrées secondaires

Les métriques des entrées secondaires vous montrent comment les modèles et algorithmes d'accès aux entrées secondaires affectent les performances de votre pipeline. Lorsque votre pipeline utilise une entrée secondaire, Cloud Dataflow écrit la collection sur une couche persistante (telle qu'un disque) et vos transformations lisent les données à partir de cette collection persistante. Ces lectures et écritures affectent le temps d'exécution de votre tâche.

L'interface de surveillance de Cloud Dataflow affiche les métriques des entrées secondaires lorsque vous sélectionnez une transformation qui crée ou absorbe une collection d'entrées secondaires. Vous pouvez consulter les métriques dans la section Side Input Metrics (Métriques des entrées secondaires) de l'onglet Step (Étape).

Transformations créant une entrée secondaire

Si la transformation sélectionnée crée une collection de l'entrée secondaire, la section Side Input Metrics (Métriques des entrées secondaires) affiche le nom de la collection, ainsi que les métriques suivantes :

  • Time spent writing (Durée de l'écriture) : temps d'exécution passé à écrire la collection de l'entrée secondaire.
  • Bytes written (Octets écrits) : nombre total d'octets écrits dans la collection de l'entrée secondaire.
  • Time & bytes read from side input (Durée de la lecture et octets lus à partir des entrées secondaires) : tableau contenant des métriques supplémentaires pour toutes les transformations absorbant la collection de l'entrée secondaire (appelées side input consumers (consommateurs de l'entrée secondaire)).

Le tableau Time & bytes read from side input (Durée de la lecture et octets lus à partir des entrées secondaires) contient les informations suivantes pour chaque consommateur de l'entrée secondaire :

  • Side input consumer (Consommateur de l'entrée secondaire) : nom de la transformation consommant l'entrée secondaire.
  • Time spent reading (Durée de la lecture) : temps passé par ce consommateur à lire la collection de l'entrée secondaire.
  • Bytes read (Octets lus) : nombre d'octets lus par ce consommateur à partir de la collection de l'entrée secondaire.

Si votre pipeline comporte une transformation composite qui crée une entrée secondaire, déployez la transformation composite jusqu'à voir la sous-transformation spécifique qui crée l'entrée secondaire. Ensuite, sélectionnez cette sous-transformation pour afficher la section Side Input Metrics (Métriques des entrées secondaires).

La figure 6 illustre les métriques des entrées secondaires pour une transformation créant une collection en entrée secondaire.

Vous pouvez sélectionner la sous-transformation, ses métriques d'entrées secondaires sont alors visibles dans l'onglet "Step" (Étape).
Figure 6 : Le graphique d'exécution comporte une transformation composite développée (MakeMapView). La sous-transformation créant l'entrée secondaire (CreateDataflowView) est sélectionnée et les métriques des entrées secondaires sont visibles dans l'onglet Step (Étape).

Transformations consommant une ou plusieurs entrées secondaires

Si la transformation sélectionnée consomme une ou plusieurs collections de l'entrée secondaire, la section Side Input Metrics (Métriques des entrées secondaires) affiche le tableau Time & bytes read from side input (Durée de la lecture et octets lus à partir des entrées secondaires). Ce tableau contient les informations suivantes pour chaque collection de l'entrée secondaire :

  • Side input collection (Collection de l'entrée secondaire) : nom de la collection de l'entrée secondaire.
  • Time spent reading (Durée de la lecture) : temps passé par la transformation à lire cette collection de l'entrée secondaire.
  • Bytes read (Octets lus) : nombre d'octets lus par la transformation dans la collection de l'entrée secondaire.

Si votre pipeline comporte une transformation composite qui lit une entrée secondaire, déployez la transformation composite jusqu'à voir la sous-transformation spécifique qui lit l'entrée secondaire. Ensuite, sélectionnez cette sous-transformation pour afficher la section Side Input Metrics (Métriques des entrées secondaires).

La figure 7 illustre les métriques des entrées secondaires pour une transformation lisant une collection en entrée secondaire.

Vous pouvez sélectionner la transformation, ses métriques d'entrées secondaires sont alors visibles dans l'onglet "Step" (Étape).
Figure 7 : La transformation JoinBothCollections lit des données à partir d'une collection de l'entrée secondaire. JoinBothCollections est sélectionnée dans le graphique d'exécution et les métriques des entrées secondaires sont visibles dans l'onglet Step (Étape).

Identifier les problèmes de performance des entrées secondaires

La réitération est un problème de performances courant lié aux entrées secondaires. Si votre PCollection d'entrée secondaire est trop volumineuse, les nœuds de calcul ne peuvent pas mettre en cache l'intégralité de la collection. Par conséquent, les nœuds de calcul doivent régulièrement lire les données depuis le stockage persistant de la collection de l'entrée secondaire.

Dans la figure 8, les métriques des entrées secondaires montrent que le nombre total d'octets lus dans la collection de l'entrée secondaire est bien supérieur à la taille de la collection (nombre total d'octets écrits).

Vous pouvez sélectionner la transformation, ses métriques d'entrées secondaires sont alors visibles dans l'onglet "Step" (Étape).
Figure 8 : Exemple de réitération. La collection de l'entrée secondaire a une taille de 563 Mo, et la somme des octets lus par les transformations consommatrices atteint pratiquement 12 Go.

Pour améliorer les performances de ce pipeline, modifiez votre algorithme pour éviter les itérations ou la récupération répétée des données de l'entrée secondaires. Dans cet exemple, le pipeline calcule le produit cartésien de deux collections. Pour chaque élément de la collection principale, l'algorithme parcourt l'ensemble de la collection de l'entrée secondaire. Vous pouvez améliorer le modèle d'accès du pipeline en regroupant plusieurs éléments de la collection principale. Cette modification réduit le nombre de lectures de la collection de l'entrée secondaire requises par les nœuds de calcul.

Un autre problème de performances courant peut survenir si votre pipeline effectue une jointure en appliquant une fonction ParDo sur une ou plusieurs entrées secondaires volumineuses. Dans ce cas, les nœuds de calcul consacrent une large proportion du temps d'exécution de la jointure simplement à lire les données des collections de l'entrée secondaire.

La figure 9 illustre des exemples de métriques des entrées secondaires dans ce type de contexte :

Vous pouvez sélectionner la transformation, ses métriques d'entrées secondaires sont alors visibles dans l'onglet "Step" (Étape).
Figure 9 : La transformation JoinBothCollections a un temps total d'exécution de 18 min 31 s. Les nœuds de calcul passent la majeure partie du temps d'exécution (10 min 3 s) à lire les données dans la collection de l'entrée secondaire, d'une taille de 10 Go.

Pour améliorer les performances de ce pipeline, utilisez CoGroupByKey au lieu des entrées secondaires.

Latence du système et fraîcheur des données

Le panneau Job summary (Résumé de la tâche) vous permet de consulter des graphes illustrant les métriques de latence du système et de fraîcheur des données pour les six dernières heures.

  • La latence système représente le délai d'attente maximal pour le traitement d'un élément de données, exprimé en secondes. Les données sont échantillonnées toutes les 60 secondes. Après échantillonnage, les données ne sont pas visibles pendant un délai pouvant atteindre 180 secondes.

  • La fraîcheur des données est l'âge (durée écoulée depuis l'horodatage de l'événement) du dernier élément de données entièrement traité par le pipeline. Les données sont échantillonnées toutes les 60 secondes. Après échantillonnage, les données ne sont pas visibles pendant un délai pouvant atteindre 180 secondes.

Un clic sur le lien Create alerting (Créer des alertes), situé sous les graphiques, permet d'ouvrir la page Créer une règle d'alerte du tableau de bord Stackdriver Monitoring.

Afficher les graphes des métriques de latence du système et de fraîcheur des données.
Figure 10 : Afficher les graphes des métriques de latence du système et de fraîcheur des données.

Autoscaling

Le panneau Job summary (Résumé de la tâche) vous permet de consulter des informations relatives à votre tâche en autoscaling. Le service Cloud Dataflow détermine automatiquement le nombre d'instances de calcul requises pour exécuter votre tâche en autoscaling. Le nombre d'instances de calcul peut changer au fil du temps en fonction des besoins de votre tâche.

Vous pouvez afficher le nombre d'instances de calcul utilisées par votre pipeline en autoscaling ainsi que d'autres informations dans l'onglet "Summary" (Résumé).

Pour voir l'historique des modifications de l'autoscaling, cliquez sur le lien See More History (Afficher plus d'entrées d'historique). Cela ouvre une fenêtre contenant des informations sur l'historique du nombre de nœuds de calcul assignés à votre pipeline.

Pour voir l'historique des modifications de l'autoscaling, cliquez sur le lien "See More History" (Afficher plus d'entrées d'historique).

Remarque : Vous pouvez afficher les détails relatifs à l'autoscaling pour les pipelines de flux continu exécutés ou mis à jour depuis le 12 décembre 2016. Si votre pipeline a été lancé avant cette date et n'a pas été mis à jour depuis, vous ne pourrez consulter les détails relatifs à l'autoscaling qu'après avoir mis à jour votre pipeline.

Error Reporting

L'interface Stackdriver Error Reporting rassemble et présente les erreurs générées dans vos pipelines.

Le rapport d'erreurs comprend :

  • Une liste des erreurs avec les messages d'erreurs correspondants.
  • Le nombre d'occurrences de chaque erreur.
  • Un histogramme indiquant quand est survenue chaque erreur.
  • L'heure à laquelle l'erreur s'est produite pour la dernière fois.

Pour afficher le rapport d'erreurs relatif à votre pipeline, cliquez sur le menu Logs (Journaux) situé au-dessus du graphique du pipeline, puis sur l'onglet Stack Traces (Traces de piles) visible en-dessous du graphique. Dans l'interface de surveillance de Cloud Dataflow, vous verrez un résumé de chaque erreur consignée et le nombre d'occurrences de cette erreur.

Récapitulatif de chaque erreur consignée et de son nombre d'occurrences.

Pour afficher plus d'informations sur les erreurs, cliquez sur le résumé d'une erreur. Vous êtes alors dirigé vers l'interface de Stackdriver Error Reporting.

Plus d'informations sur les erreurs dans l'interface Stackdriver Error Reporting

L'interface Stackdriver Error Reporting offre des fonctionnalités supplémentaires. Pour plus d'informations sur les erreurs générées par vos pipelines, consultez la page Afficher les erreurs.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Besoin d'aide ? Consultez notre page d'assistance.