Quelles métriques dois-je utiliser pour surveiller et résoudre les problèmes liés à Kinesis Data Streams ?
Je souhaite surveiller les données entrantes et sortantes pour Amazon Kinesis Data Streams. Quelles métriques dois-je utiliser ?
Résolution
Utilisation des métriques au niveau des flux
Vous pouvez utiliser les métriques Amazon CloudWatch pour surveiller en continu les performances de votre flux de données Amazon Kinesis et de son débit. Les métriques suivantes peuvent vous aider à surveiller les problèmes liés aux producteurs et aux consommateurs :
- GetRecords.IteratorAgeMilliseconds : mesure l'âge, en millisecondes, du dernier enregistrement du flux pour toutes les requêtes GetRecords. Une valeur égale à zéro pour cette métrique indique que les enregistrements du flux sont actuels. Une valeur inférieure est préférable. Pour surveiller les problèmes de performances, augmentez le nombre de consommateurs de votre flux afin que les données soient traitées plus rapidement. Pour optimiser votre code d'application, augmentez le nombre de consommateurs afin de réduire le délai de traitement des enregistrements.
- ReadProvisionedThroughputExceeded : mesure le nombre d'appels GetRecords qui sont limités au cours d'une période donnée, dépassant les limites de service ou de partition pour Kinesis Data Streams. Une valeur égale zéro indique que les consommateurs de données ne dépassent pas les quotas de service. Toute autre valeur indique que la limite de débit est dépassée, ce qui nécessite des partitions supplémentaires. Cette métrique confirme qu'il n'y a pas plus de cinq lectures/seconde/partition ou 2 Mo/seconde/partition dans le flux. Vous pouvez activer la surveillance améliorée pour vérifier qu'il n'y a pas de partitions à chaud dans le flux.
- WriteProvisionedThroughputExceeded : mesure le PUT ou le producteur de données (comme ReadProvisionedThroughputExceeded) pour vous aider à déterminer si le flux est limité. Cela dépasse les quotas de service pour Data Streams lors de l'écriture dans une partition. Assurez-vous que les requêtes PUT ne dépassent pas 1 Mo/seconde/partition ou 1 000 enregistrements/partition/seconde. Assurez-vous que la clé de partition est distribuée uniformément et que la surveillance améliorée est activée pour vérifier les partitions à chaud dans le flux. En fonction de la saturation des partitions, envisagez de mettre à jour le nombre de partitions dans le flux pour permettre un débit accru.
- PutRecord.Success et PutRecords.Success : mesurez le nombre d'enregistrements réussis de requêtes PutRecords sur une période donnée par les producteurs de données dans le flux. Cette métrique confirme une logique de nouvelle tentative efficace pour les enregistrements ayant échoué.
- GetRecords.Success : mesure le nombre de requêtes GetRecords réussies pendant une période donnée dans le flux. Cette métrique confirme une logique de nouvelle tentative efficace pour les enregistrements ayant échoué.
- GetRecords.Latency : mesure le temps nécessaire pour chaque opération GetRecords sur le flux pour une période donnée. Confirme les ressources physiques suffisantes ou la logique de traitement des enregistrements pour augmenter le débit du flux. Traite des lots de données plus importants pour réduire les latences réseau et autres latences en aval dans votre application. Pour Kinesis Client Library (KCL), enquêtez sur la métrique ProcessTask.Time pour surveiller le temps de traitement de l'application en retard. La métrique GetRecords.Latency confirme que le paramètre IDLE_TIME_BETWEEN_READS_IN_MILLIS est défini pour suivre le traitement des flux.
- PutRecords.Latency : mesure le temps nécessaire pour chaque opération PutRecords sur le flux pour une période spécifiée. Si la valeur PutRecords.Latency est élevée, regroupez les enregistrements dans un fichier plus volumineux pour placer les données par lots dans le flux de données Kinesis. Vous pouvez également utiliser plusieurs threads pour écrire des données. La logique de limitation et de nouvelle tentative sur l'API PutRecords peut avoir un impact sur la latence et le temps nécessaire pour chaque opération PutRecords sur le flux.
Ensuite, utilisez la statistique Average (Moyenne) pour les métriques répertoriées afin de surveiller les performances et le débit du flux.
Remarque : pour GetRecords.IteratorAgeMilliseconds, la statistique Maximum doit être utilisée pour réduire le risque de perte de données pour les consommateurs qui sont en retard par rapport aux opérations de lecture. Configurez une alarme CloudWatch pour déclencher les points de données à évaluer pour une métrique. Pour plus d'informations sur les alarmes CloudWatch, consultez Utilisation des alarmes Amazon CloudWatch.
Si vous utilisez la fonction de distribution améliorée, utilisez les métriques suivantes pour surveiller Kinesis Data Streams :
- SubscribeToShard.RateExceeded : mesure le nombre d'appels par seconde qui sont autorisés pour l'opération ou lorsqu'une tentative d'abonnement échoue car un abonnement actif existe déjà.
- SubscribeToShard.Success : vérifie si l'opération SubscribeToShard aboutit.
- SubscribeToShardEvent.Success : vérifie la publication réussie d'un événement pour un abonnement actif.
- SubscribeToShardEvent.Bytes : mesure le nombre d'octets reçus dans les partitions au cours de la période spécifiée.
- SubscribeToShardEvent.Records : mesure le nombre d'enregistrements reçus dans les partitions au cours de la période spécifiée.
- SubscribeToShardEvent.MillisBehindLatest : mesure la différence entre l'heure actuelle et le dernier enregistrement de l'événement SubscribeToShard écrit dans le flux.
Activation des métriques améliorées au niveau des partitions
Activez les métriques au niveau des partitions dans CloudWatch pour surveiller des tâches spécifiques et résoudre les problèmes liés aux producteurs et aux consommateurs de données. Par exemple, l'activation des métriques au niveau des partitions peut vous aider à identifier des problèmes tels que des distributions de charge de travail inégales.
Pour activer la surveillance améliorée, effectuez les opérations suivantes :
Remarque : vous pouvez également utiliserla requête d'API EnableEnhancedMonitoring ou l'interface de ligne AWS de commande enable-enhanced-monitoring.
1. Ouvrez la console Kinesis.
2. Choisissez une région spécifique.
3. Dans le volet de navigation, sélectionnez Data Streams(Flux de données).
4. Sous Data Stream Name (Nom du flux de données), sélectionnez votre flux de données Kinesis.
5. Sélectionnez Configuration.
6. Choisissez Edit (Modifier) sous Enhanced (shard-level) metrics (Métriques améliorées au niveau des partitions).
7. Dans le menu déroulant, sélectionnez vos métriques pour la surveillance améliorée.
8. Choisissez Save Changes (Enregistrer les modifications) pour appliquer vos paramètres de configuration.
Dépannage supplémentaire avec les appels d'API
Vous pouvez également utiliser les appels d'API suivants pour lire ou écrire des données à partir de Kinesis Data Streams :
- CreateStream : limite de cinq transactions par seconde et par compte.
- DeleteStream : limite de cinq transactions par seconde et par compte.
- ListStreams : limite de cinq transactions par seconde et par compte.
- GetShardIterator : limite de cinq transactions par seconde par compte et par partition ouverte.
- MergeShards : limite de cinq transactions par seconde et par compte.
- DescribeStream : limite de dix transactions par seconde et par compte.
- DescribeStreamSummary : limite de vingt transactions par seconde et par compte.
Lorsque vous utilisez ces appels d'API, vous pouvez surveiller n'importe quelle limitation dans les journaux AWS CloudTrail. Pour plus d'informations sur les appels d'API Kinesis Data Streams et CloudTrail, consultez Journalisation des appels d'API Amazon Kinesis Data Streams avec AWS CloudTrail.
Informations connexes
Tarification Amazon CloudWatch
Surveillance du service Amazon Kinesis Data Streams avec Amazon CloudWatch

Contenus pertinents
- demandé il y a un moislg...
- demandé il y a un moislg...
- demandé il y a un moislg...
- demandé il y a 4 moislg...
- demandé il y a un moislg...
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a 3 ans
- AWS OFFICIELA mis à jour il y a 3 ans
- AWS OFFICIELA mis à jour il y a 3 ans