2015-09-17 2 views
0

Si vous envisagez de souscrire plus de données de journal CloudWatch à un flux Kinesis spécifique qu'un seul fragment peut gérer, est-il possible de mettre à l'échelle votre flux en ajoutant plusieurs fragments? plusieurs abonnements au journal CloudWatch sur ces fragments?Comment affecter un fragment Kinesis spécifique dans l'abonnement CloudWatch

Les documents here traitent un peu la gestion des fragments, en se référant uniquement à "shardId-000000000000". Le API docs (du moins pour le SDK .NET) suggère qu'une destination arn est spécifiée lors de la création de l'abonnement, mais je crois comprendre qu'un arn ne peut pas être plus spécifique qu'un flux Kinesis, mais je ne sais pas pense que les fragments individuels sont assignés arns. Essentiellement, si vous envisagez de vous abonner à plus de données CloudWatch qu'un seul fragment peut gérer, existe-t-il un moyen de "faire passer" votre flux dans un flux multi-shard (en utilisant les abonnements CloudWatch et en évitant d'écrire client pour traiter les données), ou sera-t-il strictement nécessaire de «passer à l'échelle» dans plusieurs flux à une seule partition?

+0

Vous pouvez diviser des fragments pour augmenter la capacité du flux de kinésis: http://docs.aws.amazon.com/kinesis/latest/APIReference/API_SplitShard.html – Guy

+0

Oui, bien sûr. Mais lorsque vous utilisez l'API Kinesis pour transmettre des enregistrements à un flux Kinesis, vous devez être quelque peu explicite sur le fragment dans le flux vers lequel vous voulez que votre enregistrement se rende (voir le paramètre PartitionKey requis ici http: //docs.aws.amazon .com/kinesis/latest/APIReference/API_PutRecord.html) La documentation de CloudWatch ne fait aucune mention d'un tel paramètre, et la documentation ne fait aucune mention de la façon dont elle pourrait se comporter en l'absence d'un tel paramètre. –

+0

Vous n'écrivez pas sur un fragment par ID, vous écrivez en utilisant la clé de partition. Chacun de vos fragments a une gamme de clés de hachage, et la clé de partition sera mappée à l'un d'entre eux. Par conséquent, vous devez uniquement définir la clé de partition dans votre appel d'API. – Guy

Répondre

0

J'ai reçu cette réponse du représentant AWS mon org:

L'abonnement CloudWatch crée en interne un PartitionKey pour chaque message en fonction de l'ensemble des paramètres suivants: Le OWNERID, le logGroupName, et le logStreamName. Compte tenu de l'absence de mention dans la documentation, j'avais supposé que la partition shard était négligée par le système d'abonnement CloudWatch, mais il semble que vous obteniez automatiquement un mécanisme assez correct pour distribuer vos messages sur votre système. éclats de flux.