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.

Résoudre les problèmes des utilisateurs de Kinesis Data Streams

Erreur de compilation avec le LeaseManagementConfig constructeur

Lors de la mise à niveau vers Kinesis Client Library (KCL) version 3.x ou ultérieure, vous pouvez rencontrer une erreur de compilation liée au constructeur. LeaseManagementConfig Si vous créez directement un LeaseManagementConfig objet pour définir des configurations au lieu de l'utiliser ConfigsBuilder dans KCL les versions 3.x ou ultérieures, le message d'erreur suivant peut s'afficher lors de la compilation du code de votre KCL application.

Cannot resolve constructor 'LeaseManagementConfig(String, DynamoDbAsyncClient, KinesisAsyncClient, String)'

KCLavec les versions 3.x ou ultérieures, vous devez ajouter un paramètre supplémentaire, applicationName (type : String), après le tableName paramètre.

Au lieu de créer directement un LeaseManagementConfig objet, nous vous recommandons de l'utiliser ConfigsBuilder pour définir des configurations dans les versions KCL 3.x et ultérieures. ConfigsBuilderfournit une méthode plus flexible et plus facile à gérer pour configurer votre KCL application.

Voici un exemple d'utilisation ConfigsBuilder pour définir des KCL configurations.

ConfigsBuilder configsBuilder = new ConfigsBuilder(
    streamName,
    applicationName,
    kinesisClient,
    dynamoClient,
    cloudWatchClient,
    UUID.randomUUID().toString(),
    new SampleRecordProcessorFactory()
);

Scheduler scheduler = new Scheduler(
    configsBuilder.checkpointConfig(),
    configsBuilder.coordinatorConfig(),
    configsBuilder.leaseManagementConfig()
    .failoverTimeMillis(60000), // this is an example
    configsBuilder.lifecycleConfig(),
    configsBuilder.metricsConfig(),
    configsBuilder.processorConfig(),
    configsBuilder.retrievalConfig()
);

Certains enregistrements Kinesis Data Streams sont ignorés lors de l'utilisation de la bibliothèque cliente Kinesis

La cause la plus courante des enregistrements ignorés est une exception non gérée émise par processRecords. La bibliothèque cliente Kinesis (KCL) s'appuie sur votre processRecords code pour gérer les exceptions liées au traitement des enregistrements de données. Toute exception émise par processRecords est absorbée par leKCL. Pour éviter un nombre infini de tentatives en cas d'échec récurrent, le lot d'enregistrements traité au moment de l'exception KCL n'est pas renvoyé. Il appelle KCL processRecords ensuite le lot d'enregistrements de données suivant sans redémarrer le processeur d'enregistrements. Il en résulte que des enregistrements sont ignorés dans les applications consommateur. Pour éviter d'avoir des enregistrements ignorés, gérez toutes les exceptions dans processRecords de manière appropriée.

Les enregistrements appartenant à la même partition sont traités simultanément par différents processeurs d'enregistrements.

Pour toute application Kinesis Client Library (KCL) en cours d'exécution, une partition n'a qu'un seul propriétaire. Toutefois, plusieurs processeurs d'enregistrements peuvent traiter temporairement la même partition. Dans le cas d'une instance de travail qui perd sa connectivité réseau, elle KCL suppose que le travailleur inaccessible ne traite plus les enregistrements, une fois le délai de basculement expiré, et demande aux autres instances de travail de prendre le relais. Pendant une courte période, les nouveaux processeurs d'enregistrements et ceux de l'application de travail inaccessible peuvent traiter les données depuis la même partition.

Vous devez définir un délai de basculement qui est approprié pour votre application. Pour les applications à faible latence, la valeur par défaut de 10 secondes peut représenter l'intervalle de temps maximal pendant lequel vous voulez attendre. Cependant, dans les cas où vous prévoyez des problèmes de connectivité liés, par exemple lorsque les appels sont effectués dans des zones géographiques où la connectivité peut être perdue plus fréquemment, ce nombre peut être trop faible.

Votre application doit anticiper et gérer ce scénario, sachant notamment que la connectivité réseau est généralement restaurée pour l'application de travail précédemment inaccessible. Si un processeur d'enregistrements se voit prendre ses partitions par un autre processeur d'enregistrements, il doit gérer les deux cas suivants pour effectuer un arrêt approprié :

Pour de plus amples informations, veuillez consulter Gérer les enregistrements dupliqués.

L'application destinée au consommateur lit plus lentement que prévu

Les raisons principales les plus courantes liées au débit de lecture plus lent que prévu sont les suivantes :

Si vous n'avez qu'une seule application consommateur, il est toujours possible de lire au moins deux fois plus vite que la vitesse de placement. En effet, vous pouvez écrire jusqu'à 1 000 enregistrements par seconde pour les écritures, jusqu'à une vitesse d'écriture totale des données maximale de 1 Mo par seconde (y compris les clés de partition). Chaque partition ouverte peut prendre en charge jusqu'à 5 transactions par seconde pour la lecture, jusqu'à une vitesse de lecture totale des données maximale de 2 Mo par seconde. Notez que chaque lecture (appel de GetRecords) extrait un lot d'enregistrements. La taille des données renvoyées par appel de GetRecords varie en fonction de l'utilisation de la partition. La taille maximale des données que GetRecords peut renvoyer est de 10 Mo. Si un appel retourne cette valeur limite, les appels suivants effectués dans les 5 secondes suivantes lèvent l'exception ProvisionedThroughputExceededException.

GetRecords renvoie un tableau d'enregistrements vide même s'il y a des données dans le flux

L'utilisation ou l'obtention d'enregistrements est un modèle d'extraction. Les développeurs sont tenus d'effectuer GetRecordsdes appels en boucle continue, sans interruption. Chaque appel de GetRecords renvoie également une valeur ShardIterator, qui doit être utilisée dans la prochaine itération de la boucle.

L'opération GetRecords ne se bloque pas. Elle renvoie immédiatement un résultat : des enregistrements de données appropriés ou un élément Records vide. Un élément Records vide est renvoyé dans deux conditions :

Cette dernière condition est subtile, mais constitue un compromis de conception nécessaire pour éviter un temps de recherche illimité (latence)lors de l'extraction des enregistrements. Ainsi, l'application qui utilise le flux doit être exécutée en boucle et appeler GetRecords, en traitant les enregistrements vides comme une évidence.

Dans un scénario de production, la seule fois où la boucle continue doit être fermée est lorsque la valeur NextShardIterator est NULL. Lorsque NextShardIterator est NULL, cela signifie que la partition actuelle a été fermée et que la valeur ShardIterator pointerait autrement après le dernier enregistrement. Si l'application consommateur n'appelle jamais SplitShard ou MergeShards, la partition reste ouverte et les appels de GetRecords ne renvoient jamais de valeur NextShardIterator égale à NULL.

Si vous utilisez la bibliothèque cliente Kinesis (KCL), le modèle de consommation ci-dessus est résumé pour vous. Cela inclut la gestion automatique d'un ensemble de partitions qui changent dynamiquement. Avec leKCL, le développeur fournit uniquement la logique pour traiter les enregistrements entrants. Cela est rendu possible par le fait que la bibliothèque effectue des appels continus de GetRecords à votre place.

L'utérateur de partition expire de façon inattendue

Un nouvel itérateur de partition est renvoyé par chaque demande de GetRecords (en tant que NextShardIterator), que vous utilisez ensuite dans la demande GetRecords suivante (en tant que ShardIterator). En règle générale, cet itérateur de partition n'expire pas avant d'être utilisé. Cependant, vous pouvez constater que les itérateurs de partition expirent lorsque vous n'avez pas appelé GetRecords pendant plus de 5 minutes ou que vous avez redémarré votre application consommateur.

Si l'itérateur de partition expire immédiatement avant d'être utilisé, cela peut indiquer que la table DynamoDB utilisée par Kinesis n'a pas suffisamment de capacité pour stocker les données de bail. Cette situation est plus susceptible de se produire si vous avez un grand nombre de partitions. Pour résoudre ce problème, augmentez la capacité d'écriture attribuée à la table de partition. Pour de plus amples informations, veuillez consulter Utilisez un tableau des baux pour suivre les partitions traitées par l'application KCL client.

Le traitement des dossiers des consommateurs prend du retard

Dans la plupart des cas d'utilisation, les applications consommateur lisent les données les plus récentes dans le flux. Dans certains cas, les lectures de l'application consommateur peuvent être en retard, ce qui n'est pas souhaitable. Une fois que vous avez identifié quel est le retard dans les lectures des applications consommateur, examinez les motifs les plus courants du retard des applications consommateur.

Commencez par la métrique GetRecords.IteratorAgeMilliseconds, qui suit la position de lecture dans toutes les partitions et les applications consommateur dans le flux. Notez que si l'ancienneté de l'itérateur dépasse 50 % de la période de conservation (par défaut 24 heures, configurable jusqu'à 365 jours), il y a un risque de perte de données suite à l'expiration des enregistrements. Une solution rapide provisoire consiste à augmenter la période de conservation. Cela arrête la perte de données importantes pendant que vous continuez à résoudre le problème. Pour de plus amples informations, veuillez consulter Surveillez le service Amazon Kinesis Data Streams avec Amazon CloudWatch. Identifiez ensuite le retard pris par votre application client pour lire chaque partition à l'aide d'une CloudWatch métrique personnalisée émise par la bibliothèque cliente Kinesis KCL (),. MillisBehindLatest Pour de plus amples informations, veuillez consulter Surveillez la bibliothèque cliente Kinesis avec Amazon CloudWatch.

Voici les raisons les plus courantes pour lesquelles les applications consommateur sont en retard :

Erreur d'autorisation de clé KMS principale non autorisée

Cette erreur se produit lorsqu'une application grand public lit un flux chiffré sans autorisation sur la clé KMS principale. Pour attribuer à une application des autorisations d'accès à une KMS clé, consultez les sections Utilisation de politiques clés dans AWS KMS et Utilisation de IAM politiques avec AWS KMS.

Résoudre d'autres problèmes courants rencontrés par les consommateurs