Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Surveillance et débogage des tâches
Vous pouvez collecter des statistiques sur les AWS Glue offres d'emploi et les visualiser sur les AWS Glue CloudWatch consoles Amazon afin d'identifier et de résoudre les problèmes. Le profilage de vos tâches AWS Glue requiert les étapes suivantes :
1. Activation des métriques :
1. Activer l'option de **métriques de tâche** dans la définition de la tâche. Vous pouvez activer le profilage dans la console AWS Glue ou en tant que paramètre de la tâche. Pour plus d'informations, consultez [Définition des propriétés des tâches Spark](add-job.md#create-job) ou [Utilisation des paramètres des tâches dans les tâches AWS Glue](aws-glue-programming-etl-glue-arguments.md).
1. Activez l’option **Métriques d’observabilité AWS Glue** dans la définition de la tâche. Vous pouvez activer l’observabilité dans la console AWS Glue ou en tant que paramètre de la tâche. Pour de plus amples informations, veuillez consulter [Surveillance à l'aide de métriques d'observabilité AWS Glue](monitor-observability.md).
1. Vérifiez que le script de la tâche initialise un `GlueContext`. Par exemple, l'extrait de script suivant initialise un `GlueContext` et indique où le code profilé est placé dans le script. Ce format général est utilisé dans les scénarios de débogage suivants.
```
import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
import time
## @params: [JOB_NAME]
args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)
...
...
code-to-profile
...
...
job.commit()
```
1. Exécutez la tâche.
1. Visualisez les métriques :
1. Visualisez les métriques sur la console AWS Glue et identifiez les métriques anormales pour le pilote ou un exécuteur.
1. Consultez les indicateurs d'observabilité sur la page de surveillance des tâches, sur la page des détails de l'exécution des tâches ou sur Amazon CloudWatch. Pour de plus amples informations, veuillez consulter [Surveillance à l'aide de métriques d'observabilité AWS Glue](monitor-observability.md).
1. Précisez la cause première à l'aide de la métrique identifiée.
1. Confirmez éventuellement la cause première à l'aide du flux de journaux du pilote identifié ou du programme d'exécution.
**Cas d’utilisation des métriques d’observabilité AWS Glue**
+ [Débogage des exceptions OOM et des anomalies de tâches](monitor-profile-debug-oom-abnormalities.md)
+ [Débogage d'étapes exigeantes et de tâches de ralentissement](monitor-profile-debug-straggler.md)
+ [Surveillance de la progression des tâches multiples](monitor-debug-multiple.md)
+ [Surveillance de la planification des capacités de DPU](monitor-debug-capacity.md)
+ [Utilisation de l’observabilité AWS Glue pour surveiller l’utilisation des ressources afin de réduire les coûts](https://aws.amazon.com/blogs/big-data/enhance-monitoring-and-debugging-for-aws-glue-jobs-using-new-job-observability-metrics)
# Débogage des exceptions OOM et des anomalies de tâches
Vous pouvez déboguer les exceptions out-of-memory (OOM) et les anomalies de tâches dans. AWS Glue Les sections suivantes décrivent les scénarios de débogage des out-of-memory exceptions du pilote Apache Spark ou d'un exécuteur Spark.
+ [Débogage d'un pilote d'exception OOM](#monitor-profile-debug-oom-driver)
+ [Débogage d'un programme d’exécution d'exception OOM](#monitor-profile-debug-oom-executor)
## Débogage d'un pilote d'exception OOM
Dans ce scénario, une tâche Spark lit un grand nombre de petits fichiers d'Amazon Simple Storage Service (Amazon S3). Il convertit les fichiers au format Apache Parquet, puis les écrit dans Amazon S3. Le pilote Spark manque de mémoire. Les données d'entrées Amazon S3 comptent plus d'un million de fichiers dans différentes partitions Amazon S3.
Le code profilé est le suivant :
```
data = spark.read.format("json").option("inferSchema", False).load("s3://input_path")
data.write.format("parquet").save(output_path)
```
### Visualisez les métriques profilées sur la console AWS Glue
Le graphique suivant illustre l'utilisation de la mémoire sous forme de pourcentage pour le pilote et les programmes d'exécution. Cette utilisation est déterminée par un point de données qui est moyenné sur les valeurs rapportées au cours de la dernière minute. Vous pouvez voir dans le profil de la mémoire de la tâche que le [pilote de la mémoire](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.jvm.heap.usage) dépasse le seuil de sécurité de 50 % d'utilisation rapidement. D'autre part, l' [utilisation moyenne de la mémoire](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) sur l'ensemble des programmes d'exécution reste inférieure à 4 %. Ceci montre clairement l'anomalie de l'exécution du pilote dans cette tâche Spark.
![\[L' utilisation de la mémoire (en %) pour le pilote et les programmes d'exécution.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-oom-memoryprofile.png)
L'exécution de la tâche ne tarde pas à échouer et l'erreur suivante apparaît dans l'onglet **Historique** de la console AWS Glue : Command Failed with Exit Code 1. Cette chaîne d'erreur signifie que la tâche a échoué en raison d'une erreur systémique ; dans le cas présent, le pilote manque de mémoire.
![\[Le message d'erreur affiché sur la console AWS Glue.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-oom-errorstring.png)
Sur la console, cliquez sur le lien **Journaux d'erreurs** dans **l'onglet Historique** pour confirmer les conclusions relatives au pilote OOM contenues dans les CloudWatch journaux. Recherchez « **Error** » dans les journaux d'erreurs de la tâche pour vérifier que c'est bien à cause d'une exception OOM que la tâche a échoué :
```
# java.lang.OutOfMemoryError: Java heap space
# -XX:OnOutOfMemoryError="kill -9 %p"
# Executing /bin/sh -c "kill -9 12039"...
```
Dans l'onglet **Historique** de la tâche, choisissez **Journaux**. Vous pouvez trouver la trace suivante de l'exécution du pilote dans les CloudWatch journaux au début de la tâche. Le pilote Spark essaie de répertorier tous les fichiers dans tous les répertoires, il génère un `InMemoryFileIndex`et lance une tâche par fichier. Par conséquent, le pilote Spark doit conserver une grande quantité d'état en mémoire pour suivre toutes les tâches. Il met en cache une liste complète comprenant un grand nombre de fichiers pour l'index en mémoire, ce qui se traduit par un pilote OOM.
### Corriger le traitement de fichiers multiples grâce au regroupement
Vous pouvez corriger le traitement de plusieurs fichiers en utilisant la fonction de *regroupement* dans AWS Glue. Le regroupement est automatiquement activé lorsque vous utilisez des images dynamiques et lorsque l'ensemble des données d'entrée compte un grand nombre de fichiers (plus de 50 000). Le regroupement vous permet de fusionner plusieurs fichiers en un groupe, et il permet à une tâche de traiter l'ensemble du groupe plutôt qu'un seul fichier. Par conséquent, le pilote Spark stocke nettement moins d'état en mémoire pour suivre moins de tâches. Pour plus d'informations sur l'activation manuelle du regroupement pour votre ensemble de données, consultez [Lecture des fichiers en entrée dans des groupes de plus grande taille](grouping-input-files.md).
Pour consulter le profil de la mémoire de la tâche AWS Glue, profilez le code suivant avec la fonction de regroupement activée :
```
df = glueContext.create_dynamic_frame_from_options("s3", {'paths': ["s3://input_path"], "recurse":True, 'groupFiles': 'inPartition'}, format="json")
datasink = glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet", transformation_ctx = "datasink")
```
Vous pouvez surveiller le profil de la mémoire et le déplacement des données ETL dans le profil AWS Glue de la tâche.
Le pilote s'exécute sous le seuil de 50 % d'utilisation de la mémoire sur toute la durée de la tâche AWS Glue. Les programmes d'exécution diffusent des données depuis Amazon S3, les traitent et les écrivent dans Amazon S3. Par conséquent, ils consomment moins de 5 % de mémoire, quel que soit le moment.
![\[Le profil de la mémoire affichant que le problème est résolu.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-oom-memoryprofile-fixed.png)
Le profil de déplacement des données ci-dessous montre le nombre total d'octets d'Amazon S3 [lus](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) et [écrits](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) au cours de la dernière minute par tous les programmes d'exécution à mesure que la tâche progresse. Les deux suivent un modèle similaire car les données sont diffusées sur tous les programmes d'exécution. La tâche finir de traiter le million de fichiers en moins de trois heures.
![\[Le profil de déplacement des données affichant que le problème est résolu.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-oom-etlmovement.png)
## Débogage d'un programme d’exécution d'exception OOM
Dans ce scénario, vous pouvez apprendre à déboguer des exceptions OOM pouvant se produire dans les programmes d'exécution d'Apache Spark. Le code suivant utilise le lecteur MySQL Spark pour lire une grande table d'environ 34 millions de lignes dans une tramedonnées Spark. Il l'écrit ensuite sur Amazon S3 au format Parquet. Vous pouvez fournir les propriétés de connexion et utiliser les configurations Spark par défaut pour lire la table.
```
val connectionProperties = new Properties()
connectionProperties.put("user", user)
connectionProperties.put("password", password)
connectionProperties.put("Driver", "com.mysql.jdbc.Driver")
val sparkSession = glueContext.sparkSession
val dfSpark = sparkSession.read.jdbc(url, tableName, connectionProperties)
dfSpark.write.format("parquet").save(output_path)
```
### Voir les métriques profilées sur la console AWS Glue
Si la pente du graphique d'utilisation de la mémoire est positive et dépasse 50 %, si la tâche échoue avant l'émission de la métrique suivante, l'épuisement de la mémoire peut en être à l’origine. Le graphique suivant montre qu'en une minute d'exécution, l'[utilisation moyenne de la mémoire](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) sur tous les programmes d'exécution dépasse rapidement 50 %. L'utilisation peut atteindre 92 % et le conteneur qui exécute le programme d'exécution est arrêté par Apache Hadoop YARN.
![\[L'utilisation moyenne de la mémoire sur tous les programmes d'exécution.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-oom-2-memoryprofile.png)
Comme le montre le graphique suivant, un [programme d'exécution unique](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors) s'exécute toujours jusqu'à ce que la tâche échoue. En effet, un nouveau programme d'exécution est lancé pour remplacer celui qui a été arrêté. Les lectures de la source de données JDBC ne sont pas parallélisées par défaut, car cela nécessiterait le partitionnement de la table sur une colonne et d'ouvrir plusieurs connexions. Par conséquent, seul un programme d'exécution lit dans la table complète de manière séquentielle.
![\[L'exécution de la tâche montre un programme d'exécution unique jusqu'à ce que la tâche échoue.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-oom-2-execution.png)
Comme le montre le graphique suivant, Spark tente de lancer une nouvelle tâche quatre fois avant l'échec de la tâche. Vous pouvez voir le [profil de la mémoire](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.used) de trois programmes d'exécution. Chaque programme d'exécution utilise rapidement toute sa mémoire. La quatrième programme d'exécution manque de mémoire et la tâche échoue. Par conséquent, sa métrique n'est pas immédiatement reportée.
![\[Les profils de mémoire des programmes d'exécution.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-oom-2-exec-memprofile.png)
À partir de la chaîne d'erreur sur la console AWS Glue, vous pouvez vérifier que la tâche a échoué en raison d'exceptions OOM, comme le montre l'image suivante.
![\[Le message d'erreur affiché sur la console AWS Glue.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-oom-2-errorstring.png)
**Journaux de sortie des tâches :** pour confirmer la découverte d'une exception OOM de l'exécuteur, consultez les CloudWatch journaux. Lorsque vous recherchez **Error**, vous trouvez les quatre programme d'exécution arrêtés en à peu près le même temps que la fenêtre l'affiche sur le tableau de bord des métriques. Ils sont tous résiliés par YARN à mesure qu'ils excèdent les limites de mémoire.
Programme d'exécution 1
```
18/06/13 16:54:29 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 ERROR YarnClusterScheduler: Lost executor 1 on ip-10-1-2-175.ec2.internal: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 WARN TaskSetManager: Lost task 0.0 in stage 0.0 (TID 0, ip-10-1-2-175.ec2.internal, executor 1): ExecutorLostFailure (executor 1 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Programme d'exécution 2
```
18/06/13 16:55:35 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 ERROR YarnClusterScheduler: Lost executor 2 on ip-10-1-2-16.ec2.internal: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 WARN TaskSetManager: Lost task 0.1 in stage 0.0 (TID 1, ip-10-1-2-16.ec2.internal, executor 2): ExecutorLostFailure (executor 2 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Programme d'exécution 3
```
18/06/13 16:56:37 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 ERROR YarnClusterScheduler: Lost executor 3 on ip-10-1-2-189.ec2.internal: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 WARN TaskSetManager: Lost task 0.2 in stage 0.0 (TID 2, ip-10-1-2-189.ec2.internal, executor 3): ExecutorLostFailure (executor 3 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Programme d'exécution 4
```
18/06/13 16:57:18 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 ERROR YarnClusterScheduler: Lost executor 4 on ip-10-1-2-96.ec2.internal: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 WARN TaskSetManager: Lost task 0.3 in stage 0.0 (TID 3, ip-10-1-2-96.ec2.internal, executor 4): ExecutorLostFailure (executor 4 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
### Corriger le paramètre de taille d'extraction à l'aide des images dynamiques AWS Glue
Le programme d'exécution est arrivé à court de mémoire lors de la lecture de la table JDBC, car la configuration par défaut de la taille d'extraction du JDBC de Spark est zéro. Cela signifie que le pilote JDBC sur le programme d'exécution Spark tente d'extraire les 34 millions de lignes de la base de données et de les mettre en cache, même si Spark diffuse les lignes une par une. Avec Spark, vous pouvez éviter ce scénario en définissant le paramètre de taille d'extraction par une valeur autre que zéro.
Vous pouvez également résoudre ce problème en utilisant des images dynamiques AWS Glue. Par défaut, les images dynamiques utilisent une taille d'extraction de 1 000 lignes, qui est généralement une valeur suffisante. Par conséquent, le programme d'exécution n'utilise pas plus de 7 % de la mémoire totale. La tâche AWS Glue s'achève en moins de deux minutes avec un seul programme d'exécution. L'utilisation des images dynamiques AWS Glue est l'approche recommandée, mais il est également possible de définir la taille d'extraction à l'aide de la propriété Apache Spark `fetchsize`. Consultez le [guide de Spark SQL DataFrames et des ensembles de données](https://spark.apache.org/docs/2.2.0/sql-programming-guide.html#jdbc-to-other-databases).
```
val (url, database, tableName) = {
("jdbc_url", "db_name", "table_name")
}
val source = glueContext.getSource(format, sourceJson)
val df = source.getDynamicFrame
glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet", transformation_ctx = "datasink")
```
**Métriques profilées normales :** La [mémoire du programme d'exécution](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) avec les images dynamiques d'AWS Glue ne dépasse jamais le seuil de sécurité, comme le montre l'image suivante. Il diffuse dans les lignes depuis la base de données et met en cache 1 000 lignes seulement dans le pilote JDBC quel que soit le moment. Une exception de mémoire insuffisante ne se produit pas.
![\[La console AWS Glue montrant la mémoire du programme d'exécution en dessous du seuil de sécurité.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-oom-2-memoryprofile-fixed.png)
# Débogage d'étapes exigeantes et de tâches de ralentissement
Vous pouvez utiliser le profilage de tâche AWS Glue pour identifier les étapes exigeantes et les tâches de ralentissement dans vos tâches ETL (extraction, transformation et chargement). Un tâche de ralentissement prend beaucoup plus de temps que le reste des tâches dans l'étape d'une tâche AWS Glue. Par conséquent, l'étape s'effectue plus lentement, ce qui retarde aussi la durée d'exécution totale de la tâche.
## Fusion de petits fichiers d'entrée pour obtenir de plus grands fichiers de sortie
Une tâche de ralentissement a lieu lorsque la distribution du travail au sein des différentes tâches n'est pas uniforme, ou qu'une asymétrie de données entraîne un plus important traitement de données par une tâche.
Vous pouvez profiler le code suivant un modèle commun dans Apache Spark pour fusionner un grand nombre de petits fichiers en de plus grands fichiers de sortie. Pour cet exemple, l'ensemble de données d'entrée est de 32 Go de fichiers compressés Gzip JSON. L'ensemble de données de sortie a environ 190 Go de fichiers JSON décompressés.
Le code profilé est le suivant :
```
datasource0 = spark.read.format("json").load("s3://input_path")
df = datasource0.coalesce(1)
df.write.format("json").save(output_path)
```
### Voir les métriques profilées sur la console AWS Glue
Vous pouvez profiler votre tâche pour examiner quatre différents ensembles de métriques :
+ Déplacement de données ETL
+ Remaniement de données sur les programmes d'exécution
+ Exécution d’une tâche
+ Profil de mémoire
**Déplacement des données ETL** : Dans le profil du **Déplacement des données ETL**, les octets sont [lus](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) assez rapidement par tous les programmes d'exécution lors de la première étape qui se termine au cours des six premières minutes. Toutefois, la durée totale d'exécution de la tâche est d'environ une heure, et elle est principalement constituée des [écritures](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) de données.
![\[Graphique affichant le profil du déplacement des données ETL.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-straggler-1.png)
**Remaniement de données sur les programmes d'exécution :** Le nombre d'octets [lus](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleLocalBytesRead) et [écrits](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleBytesWritten) au cours du remaniement montre également un pic avant la fin de l'étape 2, comme le montrent les métriques de l'**Exécution de tâche** et du **Remaniement de données**. Suite au remaniement des données de tous les programmes d'exploitation, toutes les lectures et les écritures proviennent uniquement du programme d'exécution n°3.
![\[Les métriques pour le remaniement des données sur les programmes d'exploitation.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-straggler-2.png)
**Exécution de tâche :** Comme le montre le graphique ci-dessous, tous les autres programmes d'exécution sont inactifs et sont finalement abandonnés avant 10:09. A ce stade, le nombre total de programmes d'exécution diminue et il n'en reste qu'un. Ceci montre clairement que le programme d'exécution numéro 3 se compose de la tâche de ralentissement, dont la durée d'exécution est la plus longue, et contribue à la plus grande partie de la durée d'exécution de la tâche.
![\[Les métriques d'exécution pour les programmes d'exécution actifs.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-straggler-3.png)
**Profil de la mémoire :** Après les deux premières étapes, seul [le programme d'exécution n°3](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.used) consomme activement de la mémoire pour traiter les données. Les autres programmes d'exécution sont simplement inactifs ou ont été abandonnés peu de temps après la fin des deux premières étapes.
![\[Les métriques du profil de la mémoire après les deux premières étapes.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-straggler-4.png)
### Corriger les programmes d'exécution en retard à l'aide du regroupement
Vous pouvez éviter les programmes d'exécution en retard en utilisant la fonction de *regroupement* dans AWS Glue. Utilisez le regroupement pour répartir les données uniformément sur tous les programmes d'exécution et fusionner des fichiers en fichiers plus volumineux à l'aide de tous les programmes d'exécution disponibles sur le cluster. Pour de plus amples informations, veuillez consulter [Lecture des fichiers en entrée dans des groupes de plus grande taille](grouping-input-files.md).
Pour consulter les déplacements de données ETL dans la tâche AWS Glue, profilez le code suivant avec la fonction de regroupement activée :
```
df = glueContext.create_dynamic_frame_from_options("s3", {'paths': ["s3://input_path"], "recurse":True, 'groupFiles': 'inPartition'}, format="json")
datasink = glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "json", transformation_ctx = "datasink4")
```
**Déplacement de données ETL :** Les écritures de données sont désormais diffusées en parallèle avec les lectures de données pendant toute la durée d'exécution de la tâche. Par conséquent, la tâche est réalisée en huit minutes, soit beaucoup plus rapidement qu'avant.
![\[Les déplacements de données ETL affichant que le problème est résolu.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-straggler-5.png)
**Remaniement des données sur les programmes d'exécution :** Les données d'entrée ayant fusionné lors des lectures grâce à la fonction de regroupement, il n'y a pas de remaniement de données coûteux suite aux lectures de données.
![\[Les métriques du remaniement de données affichant que le problème est résolu.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-straggler-6.png)
**Exécution de tâche :** Les métriques d'exécution de tâche montrent que le nombre total de programmes d'exécution actifs s'exécutant et traitant des données reste relativement constant. Il n'y a pas de ralentissement dans la tâche. Tous les programmes d'exécution restent actifs et ne sont pas abandonnés tant que la tâche n'est pas terminée. Comme il n'existe pas de remaniement intermédiaire de données sur les programmes d'exécution, il n'y a qu'une seule étape dans la tâche.
![\[Les métriques du widget d'exécution de tâche montrant que la tâche ne comporte pas de ralentisseurs.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-straggler-7.png)
**Memory profile** (Profil de la mémoire) : les métriques montrent la [consommation de mémoire active](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.used) par l'ensemble des programmes d'exécution, confirmant une nouvelle fois qu'il existe une activité sur l'ensemble des programmes d'exécution. Les données étant parallèlement envoyées et reçues, l'espace mémoire total de tous les programmes d'exécution est à peu près uniforme et bien au-dessous du seuil de sécurité pour tous les programmes d'exécution.
![\[Les métriques du profil de la mémoire montrant la consommation de mémoire active sur tous les programmes d'exécution.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-straggler-8.png)
# Surveillance de la progression des tâches multiples
Vous pouvez profiler plusieurs AWS Glue tâches ensemble et surveiller le flux de données entre elles. Il s'agit d'un modèle de flux de travail courant qui nécessite la surveillance de la progression de chaque tâche, du journal de traitement des données, du retraitement des données et des signets de tâche.
**Topics**
+ [Code profilé](#monitor-debug-multiple-profile)
+ [Voir les métriques profilées sur la console AWS Glue](#monitor-debug-multiple-visualize)
+ [Corriger le traitement des fichiers](#monitor-debug-multiple-fix)
## Code profilé
Ce flux de travail comprend deux tâches : une tâche d'entrée et une tâche de sortie. La tâche d'entrée est planifiée pour s'exécuter toutes les 30 minutes au moyen d'un déclencheur périodique. La tâche de sortie est planifiée pour s'exécuter après chaque exécution réussie de la tâche d'entrée. Ces tâches planifiées sont contrôlées au moyen de déclencheurs de tâche.
![\[Capture d'écran de la console affichant les déclencheurs de tâche qui contrôlent la planification des tâches d'entrée et de sortie.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-multiple-1.png)
**Input job** (Tâche d’entrée) : cette tâche lit les données à partir d'un emplacement Amazon Simple Storage Service (Amazon S3), les transforme à l'aide d'`ApplyMapping` et les écrit à un emplacement Amazon S3 intermédiaire. Le code suivant est le code profilé pour la tâche d'entrée :
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": ["s3://input_path"], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": staging_path, "compression": "gzip"}, format = "json")
```
**Output job** (Tâche de sortie) : cette tâche lit la sortie de la tâche d'entrée à partir de l'emplacement intermédiaire dans Amazon S3, les transforme à nouveau et les écrit dans une destination :
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [staging_path], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "json")
```
## Voir les métriques profilées sur la console AWS Glue
Le tableau de bord suivant superpose la métrique d'octets Amazon S3 écrits de la tâche d'entrée sur la métrique d'octets Amazon S3 lus selon la même chronologie pour la tâche de sortie. La chronologie montre différentes exécutions de tâche des tâches d'entrée et de sortie. La tâche d'entrée (en rouge) démarre toutes les 30 minutes. La tâche de sortie (en marron) démarre lorsque la tâche d'entrée se termine, avec une simultanéité max. de 1.
![\[Graphique montrant les données lues et écrites.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-multiple-4.png)
Dans cet exemple, les [signets de tâche](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html) ne sont pas activés. Aucun contexte de transformation n'est utilisé pour activer les signets de tâche dans le code de script.
**Historique de tâche** : les tâches d'entrée et de sortie s'exécutent plusieurs fois, à partir de 12 h 00, comme le montre l'onglet **Historique**.
La tâche d'entrée sur la console AWS Glue se présente comme suit :
![\[Capture d'écran de la console affichant l'onglet Historique de la tâche d'entrée.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-multiple-2.png)
L'image suivante montre la tâche de sortie :
![\[Capture d'écran de la console affichant l'onglet Historique de la tâche de sortie.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-multiple-3.png)
**Première exécution de tâche** : comme le montre le graphique Octets de données lues et écrites ci-dessous, les premières exécutions des tâches d'entrée et de sortie entre 12 h 00 et 12 h 30 montrent à peu près la même zone sous les courbes. Ces zones représentent les octets Amazon S3 écrits par la tâche d'entrée et les octets Amazon S3 lus par la tâche de sortie. Ces données sont également confirmées par le taux d'octets Amazon S3 écrits (additionnés sur 30 minutes, la fréquence du déclencheur de tâche pour la tâche d'entrée). Le point de données pour le ratio d'exécution de la tâche d'entrée qui a commencé à 12 h 00 est également 1.
Le graphique suivant montre le taux de flux de données pour toutes les exécutions de tâches :
![\[Graphique montrant le ratio du flux de données : octets écrits et octets lus.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-multiple-5.png)
**Deuxième exécution de tâche** : dans la deuxième exécution de tâche, il existe une différence claire entre le nombre d'octets lus par la tâche de sortie et le nombre d'octets écrits par la tâche d'entrée. (Comparez la zone sous la courbe des deux exécutions de tâche de la tâche de sortie ou comparez les zones de la deuxième exécution des tâches d'entrée et de sortie.) Le ratio entre le nombre d'octets lus et écrits montre que la tâche de sortie lit environ 2,5x les données écrites par la tâche d'entrée dans la seconde période de 30 minutes, de 12 h 30 à 13 h 00. C'est parce que la tâche de sortie a retraité la sortie de la première exécution de la tâche d'entrée car les signets de tâche n'étaient pas activés. Un ratio supérieur à 1 indique qu'un backlog de données supplémentaire a été traité par la tâche de sortie.
**Troisième exécution de tâche** : la tâche d'entrée est assez cohérente quant au nombre d'octets écrits (voir la zone sous les courbes rouges). Toutefois, la troisième exécution de la tâche d'entrée a duré plus longtemps que prévu (voir la longue queue de la courbe rouge). Par conséquent, la troisième exécution de la tâche de sortie a démarré en retard. La troisième exécution de tâche n'a traité qu'une fraction des données cumulées à l'emplacement intermédiaire dans les 30 minutes restantes entre 13 h 00 et 13 h 30. Le taux de débit d'octets indique que seules 0,83 des données écrites ont été traitées par la troisième exécution de la tâche d'entrée (voir le ratio à 13 h 00).
**Chevauchement des tâches d'entrée et de sortie** : la quatrième exécution de la tâche d'entrée a démarré à 13 h 30 comme prévu, avant la fin de la troisième exécution de la tâche de sortie. Ces deux exécutions de tâche se chevauchement partiellement. Toutefois, la troisième exécution de la tâche de sortie ne capture que les fichiers répertoriés dans l'emplacement intermédiaire d'Amazon S3, lorsqu'elle a commencé vers 13:17. Cela comprend toutes les sorties de données de la première exécution de la tâche d'entrée. Le ratio réel à 13 h 30 est d'environ 2,75. La troisième exécution de la tâche de sortie a traité environ 2,75x de données écrites par la quatrième exécution de la tâche d'entrée, de 13 h 30 à 14 h 00.
Comme le montrent ces images, la tâche de sortie retraite des données de toutes les précédentes exécutions de la tâche d'entrée à partir de l'emplacement intermédiaire. Par conséquent, la quatrième exécution de la tâche de sortie est la plus longue et elle chevauche la totalité de la cinquième exécution de la tâche d'entrée.
## Corriger le traitement des fichiers
Vous devez vous assurer que la tâche de sortie ne traite les fichiers qui n'ont pas été traités par de précédentes exécutions de la tâche de sortie. Pour ce faire, activez les signets de tâche et configurez le contexte de transformation dans la tâche de sortie de la façon suivante :
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [staging_path], "useS3ListImplementation":True,"recurse":True}, format="json", transformation_ctx = "bookmark_ctx")
```
Lorsque les signets de tâche sont activés, la tâche de sortie ne retraite pas les données dans l'emplacement intermédiaire pour toutes les précédentes exécutions de la tâche d'entrée. Dans l'image suivante montrant les données lues et écrites, la zone sous la courbe marron est assez cohérente et similaire aux courbes rouges.
![\[Graphique montrant les données lues et écrites sous forme de lignes rouge et marron.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-multiple-6.png)
Le rapports du flux d'octets reste également proche de 1, car des données supplémentaires ne sont pas traitées.
![\[Graphique montrant le ratio du flux de données : octets écrits et octets lus\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-multiple-7.png)
Une exécution de la tâche de sortie démarre et capture les fichiers dans l'emplacement intermédiaire avant que la prochaine exécution de la tâche d'entrée ne commence à placer d'autres données dans l'emplacement intermédiaire. Tant que c'est le cas, elle ne traite que les fichiers capturés lors de la précédente exécution de tâche de sortie, et le ratio reste proche de 1.
![\[Graphique montrant le ratio du flux de données : octets écrits et octets lus\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-multiple-7.png)
Supposons que la tâche d'entrée dure plus longtemps que prévu et que, par conséquent, la tâche de sortie capture des fichiers dans l'emplacement intermédiaire à partir de deux exécutions de tâche d'entrée. Le ratio est supérieur à 1 pour cette exécution de tâche de sortie. Toutefois, les exécutions de tâches de sortie suivantes ne traitent aucun fichier déjà traité par les précédentes exécutions de la tâche de sortie.
# Surveillance de la planification des capacités de DPU
Vous pouvez utiliser les métriques des tâches AWS Glue pour estimer le nombre d'unités de traitement des données (DPUs) qui peuvent être utilisées pour étendre une AWS Glue tâche.
**Note**
Cette page s'applique uniquement à AWS Glue versions 0.9 et 1.0. Les versions ultérieures de AWS Glue contiennent des fonctionnalités économiques qui introduisent des considérations supplémentaires lors de la planification des capacités.
**Topics**
+ [Code profilé](#monitor-debug-capacity-profile)
+ [Voir les métriques profilées sur la console AWS Glue](#monitor-debug-capacity-visualize)
+ [Déterminer la capacité DPU optimale](#monitor-debug-capacity-fix)
## Code profilé
Le script suivant lit une partition Amazon Simple Storage Service (Amazon S3) contenant 428 fichiers JSON compressés avec gzip. Le script applique un mappage pour modifier les noms de champs, les convertit et les écrit dans Amazon S3 au format Apache Parquet. Vous DPUs en attribuez 10 par défaut et vous exécutez cette tâche.
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [input_path], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [(map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet")
```
## Voir les métriques profilées sur la console AWS Glue
**Exécution de tâche 1 :** Dans cette exécution de tâche, nous montrons comment déterminer si le cluster est sous-approvisionné DPUs . La fonctionnalité d'exécution de tâches dans AWS Glue indique le [nombre total de programmes d'exécution actifs en cours d'exécution](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors), le [nombre d'étapes terminées](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.numCompletedStages) et le [nombre maximum de programmes d'exécution nécessaires](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors).
Le nombre maximum de programmes d'exécution nécessaires est calculé en ajoutant le nombre total de tâches en cours d'exécution et de tâches en attente, puis en divisant ce nombre par le nombre de tâches par programme d'exécution. Ce résultat est une mesure du nombre total d'exécuteurs requises pour satisfaire la charge du moment.
En revanche, le nombre de programmes d'exécution actifs en cours d'exécution mesure le nombre de programmes d'exécution qui exécutent des tâches Apache Spark. À mesure que la tâche progresse, le nombre maximum de programmes d'exécution nécessaires peut varier et baisse généralement vers la fin de la tâche à mesure que diminue la file d'attente de tâches en attente.
La ligne rouge horizontale du graphique suivant indique le nombre maximum d'exécuteurs alloués, qui dépend du nombre d'exécuteurs DPUs que vous allouez à la tâche. Dans ce cas, vous allouez 10 points DPUs à l'exécution du job. Une DPU est réservée à la gestion. Neuf DPUs exécuteurs exécutent deux exécuteurs chacun et un exécuteur est réservé au pilote Spark. Le pilote Spark s'exécute dans l'application principale. Par conséquent, le nombre maximum de programmes d'exécution alloués est de 2 x 9 - 1 = 17 programmes d'exécution.
![\[Les métriques de la tâche affichant les programmes d'exécution actifs et les programmes d'exécution nécessaires maximum.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-capacity-1.png)
Comme le montre le graphique, le nombre maximum de programmes d'exécution nécessaires commence à 107 au début de la tâche, alors que le nombre de programmes d'exécution actifs reste 17. C'est le même que le nombre maximum d'exécuteurs alloués, soit 10 DPUs. Le ratio entre le nombre maximum de programmes d'exécution nécessaires et le nombre maximum de programmes d'exécution alloués (en ajoutant 1 à chacun des pilotes Spark) donne le facteur sous-alloué : 108/18 = 6x. Vous pouvez en configurer 6 (sous le ratio de provisionnement) \$19 (capacité actuelle du DPU - 1) \$1 1 DPUs = 55 DPUs pour étendre le travail afin de l'exécuter avec un parallélisme maximal et de terminer plus rapidement.
La console AWS Glue affiche le détail des métriques des tâches sous la forme d'une ligne statique qui représente le nombre maximal de programmes d'exécution alloués au départ. Pour ces métriques, la console calcule le nombre maximum de programme d'exécution alloués à partir de la définition de la tâche. En revanche, pour les métriques détaillées d'exécution des tâches, la console calcule le nombre maximum d'exécuteurs alloués à partir de la configuration d'exécution des tâches, en particulier le nombre DPUs alloué pour l'exécution des tâches. Pour afficher les métriques d'une exécution de tâche spécifique, sélectionnez l'exécution et choisissez **View run metrics (Afficher les métriques de l'exécution)**.
![\[Les métriques de la tâche montrant le déplacement de données ETL.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-capacity-2.png)
Si l'on regarde les octets Amazon S3 [lus](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) et [écrits](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes), on remarque que la tâche prend six minutes complètes pour diffuser les données à partir d’Amazon S3 et les écrire en parallèle. Tous les cœurs alloués DPUs lisent et écrivent sur Amazon S3. Le nombre maximum de programmes d'exécution nécessaires (107) correspond également au nombre de fichiers dans le chemin d'accès d'entrée Amazon S3 (428). Chaque programme d'exécution peut lancer quatre tâches Spark pour traiter quatre fichiers d'entrée (JSON compressées avec gzip).
## Déterminer la capacité DPU optimale
Sur la base des résultats de l'exécution de la tâche précédente, vous pouvez augmenter le nombre total de tâches allouées DPUs à 55 et suivre les performances de la tâche. La tâche se termine en moins de trois minutes, soit la moitié du temps auparavant nécessaire. La montée en charge de la tâche n'est pas linéaire dans ce cas, car il s'agit d'une tâche d'exécution courte. Les tâches comportant des tâches de longue durée ou un grand nombre de tâches (un grand nombre d'exécuteurs maximum nécessaires) bénéficient d'une accélération des performances du close-to-linear DPU grâce à la scale-out.
![\[Graphique montrant l'augmentation du nombre total de DPUs\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-capacity-3.png)
Comme le montre l'image ci-dessus, le nombre total de programmes d'exécution actifs atteint le nombre maximum de programmes d'exécution alloués (107). De même, le nombre maximum de programmes d'exécution nécessaires ne dépasse jamais le nombre maximum de programmes d'exécution alloués. Le nombre maximum de programmes d'exécution nécessaires est calculé à partir du nombre de tâches en cours d'exécution et en attente, il doit donc être inférieur au nombre de programmes d'exécution actifs. Ceci est dû au fait que des programmes d'exécution peuvent être partiellement ou complètement inactifs pour une courte période de temps et ne sont pas encore démagnétisés.
![\[Graphique montrant le nombre total de programmes d'exécution actifs atteignant le nombre alloué maximum.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-capacity-4.png)
Cette exécution de tâche utilise 6 fois plus de programmes d'exécution pour lire et écrire en parallèle depuis Amazon S3. Par conséquent, cette exécution de tâche utilise plus de bande passante Amazon S3 pour les lectures et les écritures, et se termine plus rapidement.
### Identifiez le surprovisionnement DPUs
Ensuite, vous pouvez déterminer si le fait d'étendre la tâche à 100 DPUs (99 \$1 2 = 198 exécuteurs) permet de poursuivre l'extension. Comme le montre le graphique suivant, la tâche se termine toujours après trois minutes. De même, la tâche ne dépasse pas 107 exécuteurs ( DPUsconfiguration 55), et les 91 exécuteurs restants sont surapprovisionnés et ne sont pas du tout utilisés. Cela montre que l'augmentation du nombre de n' DPUs améliore pas toujours les performances, comme en témoigne le nombre maximal d'exécuteurs nécessaires.
![\[Graphique montrant que les performances au travail n'augmentent pas toujours en augmentant le nombre de DPUs.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/monitor-debug-capacity-5.png)
### Comparer des différences de temps
Les trois cycles de travail présentés dans le tableau suivant résument les temps d'exécution des travaux pour 10 DPUs DPUs, 55 et 100 DPUs. Vous pouvez trouver la capacité de DPU pour améliorer la durée d'exécution de la tâche en utilisant l'estimation que vous avez réalisée en surveillant la première exécution de tâche.
| ID de tâche | Nombre de DPUs | Durée d’exécution |
| --- | --- | --- |
| jr\$1c894524c8ef5048a4d9... | 10 | 6 min. |
| jr\$11a466cf2575e7ffe6856... | 55 | 3 min. |
| jr\$134fa1ed4c6aa9ff0a814... | 100 | 3 min. |