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.
# À propos de la surveillance des jobs de AWS Glue streaming
La surveillance de votre tâche de streaming est un élément essentiel de la création de votre pipeline ETL. Outre l'interface utilisateur Spark, vous pouvez également utiliser Amazon CloudWatch pour surveiller les métriques. Vous trouverez ci-dessous une liste des métriques de streaming émises par le AWS Glue framework. Pour une liste complète de toutes les AWS Glue métriques, consultez la section [Surveillance à AWS Glue l'aide CloudWatch des métriques Amazon](https://docs.aws.amazon.com/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html).
AWS Glue utilise un framework de streaming structuré pour traiter les événements d'entrée. Vous pouvez soit utiliser l’API Spark directement dans votre code, soit tirer parti du `ForEachBatch` fourni par `GlueContext`, qui publie ces métriques. Pour comprendre ces métriques, nous devons d’abord comprendre `windowSize`.
**windowSize** : `windowSize` est l’intervalle entre les microlots que vous indiquez. Si vous spécifiez une taille de fenêtre de 60 secondes, la tâche de AWS Glue diffusion attendra 60 secondes (ou plus si le lot précédent n'est pas terminé d'ici là) avant de lire les données d'un lot à partir de la source de diffusion et d'appliquer les transformations fournies dans`ForEachBatch`. Cet intervalle est également appelé intervalle de déclenchement.
Passons en revue les métriques plus en détail pour comprendre les caractéristiques de santé et de performance.
**Note**
Les métriques sont émises toutes les 30 secondes. Si votre `windowSize` est inférieure à 30 secondes, les métriques rapportées sont une agrégation. Supposons, par exemple, que votre `windowSize` soit de 10 secondes et que vous traitiez régulièrement 20 enregistrements par microlot. Dans ce scénario, la valeur métrique émise pour numRecords serait de 60.
Aucune métrique n’est émise si aucune donnée n’est disponible pour elle. De plus, dans le cas de la métrique de décalage du consommateur, vous devez activer la fonctionnalité pour obtenir des métriques correspondantes.
# Visualisation des statistiques de AWS Glue streaming
Pour tracer des métriques visuelles :
1. Accédez à **Metrics** dans la CloudWatch console Amazon, puis choisissez l'onglet **Parcourir**. Choisissez ensuite **Glue** sous « Espaces de noms personnalisés ».
![\[La capture d'écran montre l'accès aux métriques dans la CloudWatch console Amazon lors de la surveillance des jobs de AWS Glue streaming.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/streaming-monitoring-1.png)
1. Choisissez **Métriques de tâche** pour afficher les métriques de toutes vos tâches.
1. Filtrez les métriques en fonction de votre JobName =, glue-feb-monitoring puis de JobRunId =ALL. Vous pouvez cliquer sur le signe « \$1 » comme indiqué dans la figure ci-dessous pour l’ajouter au filtre de recherche.
1. Cochez la case correspondant aux métriques qui vous intéressent. Dans la figure ci-dessous, nous avons sélectionné `numberAllExecutors` et `numberMaxNeededExecutors`.
![\[La capture d’écran montre l’application d’une moyenne aux métriques lors du suivi des jobs de streaming.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/streaming-monitoring-2.png)
1. Une fois que vous avez sélectionné ces métriques, vous pouvez accéder à l’onglet **Graphique des métriques** et appliquer vos métriques.
1. Comme les métriques sont émises toutes les minutes, vous pouvez appliquer la « moyenne » sur une minute pour `batchProcessingTimeInMs` et `maxConsumerLagInMs`. Pour `numRecords`, vous pouvez appliquer la « somme » sur chaque minute.
1. Vous pouvez ajouter une annotation `windowSize` horizontale à votre graphique à l’aide de l’onglet **Options**.
![\[La capture d’écran montre l’ajout d’une annotation windowSize à votre graphique lors du suivi des tâches de streaming.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/streaming-monitoring-3.png)
1. Une fois que vous avez sélectionné vos métriques, créez un tableau de bord et ajoutez-le. Voici un exemple de tableau de bord.
![\[La capture d’écran montre un exemple de tableau de bord permettant de surveiller les tâches de streaming.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/streaming-monitoring-4.png)
# Utilisation des métriques AWS Glue de streaming
Cette section décrit chacune des métriques et la façon dont elles sont corrélées les unes avec les autres.
## Nombre d’enregistrements (métrique : streaming.numRecords)
Cette métrique indique le nombre d’enregistrements en cours de traitement.
![\[La capture d’écran montre le suivi du nombre d’enregistrements dans les tâches de streaming.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/streaming-monitoring-5numrecords.png)
Cette métrique de streaming fournit une visibilité sur le nombre d’enregistrements que vous traitez dans une fenêtre. Outre le nombre d’enregistrements en cours de traitement, cela vous aidera également à comprendre le comportement du trafic d’entrée.
+ La métrique nº 1 montre un exemple de trafic stable sans pics. Il s’agit généralement d’applications telles que des capteurs IoT qui collectent des données à intervalles réguliers et les envoient à la source de streaming.
+ La métrique nº 2 montre un exemple d’augmentation soudaine du trafic sur une charge par ailleurs stable. Cela peut se produire dans une application de flux de clics lors d’un événement marketing tel que le Black Friday et lorsque le nombre de clics augmente.
+ La métrique nº 3 montre un exemple de trafic imprévisible. Un trafic imprévisible ne signifie pas qu’il y a un problème. Il s’agit simplement de la nature des données d’entrée. Pour en revenir à l’exemple des capteurs IoT, vous pouvez imaginer des centaines de capteurs qui envoient des événements liés aux changements météorologiques à la source de streaming. Comme les changements météorologiques ne sont pas prévisibles, les données ne le sont pas non plus. Comprendre le modèle de trafic est essentiel pour dimensionner vos programmes d’exécution. Si l’entrée est sujette à des pics de trafic, vous pouvez envisager d’utiliser l’autoscaling (nous y reviendrons plus tard).
![\[La capture d'écran montre la surveillance basée sur le nombre d'enregistrements et les PutRecords mesures Kinesis dans les jobs de streaming.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/streaming-monitoring-6putrecords.png)
Vous pouvez combiner cette métrique avec la PutRecords métrique Kinesis pour vous assurer que le nombre d'événements ingérés et le nombre d'enregistrements lus sont quasiment identiques. Cette approche est utile lorsque vous essayez de comprendre le décalage. Au fur et à mesure que le taux d'ingestion augmente, le temps de `numRecords` lecture augmente également AWS Glue.
## Temps de traitement par lots (métrique : streaming). batchProcessingTimeInMs)
La métrique du temps de traitement par lots vous aide à déterminer si le cluster est sous-provisionné ou surapprovisionné.
![\[La capture d’écran montre le suivi du temps de traitement par lots dans les tâches de streaming.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/streaming-monitoring-7batchprocess.png)
Cette métrique indique le nombre de millisecondes nécessaires au traitement de chaque microlot d’enregistrements. L’objectif principal ici est de surveiller ce temps pour s’assurer qu’il est inférieur à l’intervalle `windowSize`. Ce n’est pas grave si le `batchProcessingTimeInMs` est dépassé temporairement, tant qu’il se rétablit dans l’intervalle de fenêtre suivant. La métrique nº 1 indique un temps plus ou moins stable de traitement de la tâche. Toutefois, si le nombre d’enregistrements d’entrée augmente, le temps nécessaire au traitement de la tâche augmentera, comme le montre la métrique nº 2. Si le `numRecords` n’augmente pas, mais que le temps de traitement augmente, vous devrez examiner de plus près le traitement des tâches sur les programmes d’exécution. Il est recommandé de définir un seuil et une alerte pour s’assurer que le `batchProcessingTimeInMs` ne dépasse pas 120 % pendant plus de 10 minutes. Pour plus d'informations sur le paramétrage des alarmes, consultez la section [Utilisation des CloudWatch alarmes Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
## Retard de consommation (métrique : streaming). maxConsumerLagInMs)
La métrique du décalage de consommateur vous aide à comprendre s’il existe un décalage dans le traitement des événements. Si votre décalage est trop important, vous risquez de ne pas respecter le SLA de traitement dont dépend votre activité, même si vous avez une taille de fenêtre windowSize correcte. Vous devez activer explicitement cette métrique à l’aide de l’option de connexion `emitConsumerLagMetrics`. Pour de plus amples informations, veuillez consulter [KinesisStreamingSourceOptions](https://docs.aws.amazon.com/glue/latest/webapi/API_KinesisStreamingSourceOptions.html).
![\[La capture d’écran montre le suivi du décalage dans les tâches de streaming.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/streaming-monitoring-8lag.png)
## Métriques dérivées
Pour obtenir des informations plus approfondies, vous pouvez créer des indicateurs dérivés afin d'en savoir plus sur vos jobs de streaming sur Amazon CloudWatch.
![\[La capture d’écran montre le suivi des métriques dérivées dans les tâches de streaming.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/streaming-monitoring-9derived.png)
Vous pouvez créer un graphique avec des mesures dérivées pour décider si vous devez en utiliser davantage DPUs. Bien que l’autoscaling vous aide à le faire automatiquement, vous pouvez utiliser des métriques dérivées pour déterminer si l’autoscaling fonctionne efficacement.
+ **InputRecordsPerSecond**indique la vitesse à laquelle vous obtenez des enregistrements d'entrée. Il est dérivé comme suit : nombre d'enregistrements d'entrée (Glue.Driver.Streaming.NumRecords)/. WindowSize
+ **ProcessingRecordsPerSecond**indique le rythme auquel vos enregistrements sont traités. Il est dérivé comme suit : nombre d'enregistrements d'entrée (Glue.Driver.Streaming.NumRecords)/. batchProcessingTime InMs
Si le taux d’entrée est supérieur au taux de traitement, vous devrez peut-être augmenter la capacité pour traiter votre tâche ou augmenter le parallélisme.
## Métriques d’autoscaling
Lorsque votre trafic d’entrée connaît des pics, vous devez envisager d’activer l’autoscaling et de spécifier le nombre maximal de travailleurs. Avec cela, vous obtenez deux métriques supplémentaires, `numberAllExecutors` et `numberMaxNeededExecutors`.
+ **numberAllExecutors**est le nombre d'exécuteurs de tâches en cours d'exécution active
+ **numberMaxNeededLes exécuteurs** sont le nombre maximum d'exécuteurs de tâches (en cours d'exécution et en attente) nécessaires pour satisfaire la charge actuelle.
Ces deux métriques vous aideront à déterminer si votre autoscaling fonctionne correctement.
![\[La capture d’écran montre le suivi de l’autoscaling dans les tâches de streaming.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/streaming-monitoring-10autoscaling.png)
AWS Glue surveillera la `batchProcessingTimeInMs` métrique sur quelques microlots et effectuera l'une des deux opérations suivantes. Il fera monter en puissance le nombre de programmes d’exécution, si `batchProcessingTimeInMs` est plus proche de la `windowSize`, ou mettra à l’échelle horizontale les programmes d’exécution, si `batchProcessingTimeInMs` est comparativement inférieur à `windowSize`. En outre, il utilisera un algorithme pour mettre à l’échelle les programmes d’exécution par étapes.
+ La métrique nº 1 vous montre comment les programmes d’exécution actifs augmentent pour rattraper le nombre maximal de programmes d’exécution nécessaires afin de traiter la charge.
+ La métrique nº 2 vous montre comment le nombre de programmes d’exécution actifs a été mis à l’échelle horizontale comme le `batchProcessingTimeInMs` était faible.
Vous pouvez utiliser ces métriques pour surveiller le parallélisme actuel au niveau des programmes d’exécution et ajuster le nombre maximal de travailleurs dans votre configuration d’autoscaling en conséquence.
## Comment obtenir les meilleures performances
Spark essaiera de créer une tâche par partition, à partir de laquelle lire, dans le flux Amazon Kinesis. Les données de chaque partition deviennent une partition. Il répartira ensuite ces tâches entre les programmes d’exécution/travailleurs, en fonction du nombre de cœurs de chaque travailleur (le nombre de cœurs par travailleur dépend du type de travailleur que vous sélectionnez, `G.025X`, `G.1X`, etc.). Cependant, la façon dont les tâches sont réparties n’est pas déterministe. Toutes les tâches sont exécutées en parallèle sur leurs cœurs respectifs. S’il y a plus de partitions que de cœurs de programme d’exécution disponibles, les tâches sont mises en file d’attente.
Vous pouvez utiliser une combinaison des métriques ci-dessus et du nombre de partitions pour fournir à vos programmes d’exécution une charge stable avec de la place pour les pics. Il est recommandé d’exécuter quelques itérations de votre tâche afin de déterminer le nombre approximatif de travailleurs. Pour une unstable/spiky charge de travail, vous pouvez faire de même en configurant le dimensionnement automatique et le nombre maximal de travailleurs.
Définissez la `windowSize` conformément aux exigences du SLA de votre entreprise. Par exemple, si votre entreprise exige que les données traitées ne soient pas obsolètes de plus de 120 secondes, réglez votre `windowSize` sur au moins 60 secondes afin que le décalage moyen du consommateur soit inférieur à 120 secondes (voir la section sur le décalage du consommateur ci-dessus). À partir de là, en fonction de la quantité `numRecords` et du nombre de fragments, planifiez la capacité en vous DPUs assurant que vous `batchProcessingTimeInMs` êtes inférieure à 70 % de votre capacité la `windowSize` plupart du temps.
**Note**
Les hot shards peuvent fausser les données, ce qui signifie que certains shards/partitions sont beaucoup plus gros que d'autres. Certaines tâches exécutées en parallèle peuvent donc prendre plus de temps, ce qui peut entraîner des ralentissements. Par conséquent, le lot suivant ne pourra pas démarrer tant que toutes les tâches du précédent ne seront pas terminées, ce qui aura un impact sur le `batchProcessingTimeInMillis` et le décalage maximal.