As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Solução de problemas de consumidores do Kinesis Data Streams

Erro de compilação com o construtor LeaseManagementConfig

Ao fazer o upgrade para a Kinesis Client Library KCL () versão 3.x ou posterior, você pode encontrar um erro de compilação relacionado ao construtor. LeaseManagementConfig Se você estiver criando diretamente um LeaseManagementConfig objeto para definir configurações em vez de usar ConfigsBuilder nas KCL versões 3.x ou posteriores, talvez veja a seguinte mensagem de erro ao compilar o código do aplicativoKCL.

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

KCLcom as versões 3.x ou posteriores, é necessário adicionar mais um parâmetro, applicationName (tipo: String), após o tableName parâmetro.

Em vez de criar diretamente um LeaseManagementConfig objeto, recomendamos usá-lo ConfigsBuilder para definir configurações na KCL versão 3.x e versões posteriores. ConfigsBuilderfornece uma maneira mais flexível e sustentável de configurar seu KCL aplicativo.

Veja a seguir um exemplo de uso ConfigsBuilder para definir KCL configurações.

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()
);

Alguns registros do Kinesis Data Streams são ignorados quando a Kinesis Client Library é usada

A causa mais comum de registros ignorados é uma exceção não processada lançada de processRecords. A Kinesis Client Library (KCL) depende do seu processRecords código para lidar com quaisquer exceções decorrentes do processamento dos registros de dados. Qualquer exceção lançada processRecords é absorvida peloKCL. Para evitar repetições infinitas em caso de falha recorrente, o KCL não reenvia o lote de registros processados no momento da exceção. KCLEm seguida, processRecords solicita o próximo lote de registros de dados sem reiniciar o processador de registros. Isso resulta efetivamente em aplicativos consumidores observando registros ignorados. Para impedir registros ignorados, processe todas as exceções em processRecords da forma apropriada.

Registros pertencentes ao mesmo fragmento são processados por processadores de registros diferentes ao mesmo tempo

Para qualquer aplicativo Kinesis Client Library (KCL) em execução, um fragmento tem apenas um proprietário. No entanto, vários processadores de registro pode temporariamente processar o mesmo fragmento. No caso de uma instância de trabalho que perde a conectividade de rede, KCL pressupõe que o trabalhador inacessível não está mais processando registros após o término do tempo de failover e orienta outras instâncias de trabalho a assumirem o controle. Por um breve período, novos processadores de registros e processadores de registros provenientes do operador inacessível podem processar dados do mesmo fragmento.

É necessário definir um tempo de failover que seja apropriado para o aplicativo. Para aplicativos de baixa latência, o padrão de 10 segundos pode representar o tempo máximo que deseja esperar. No entanto, nos casos em que se esperam problemas de conectividade, como fazer chamadas em áreas geográficas em que a conectividade pode ser perdida com mais frequência, esse número pode ser muito baixo.

O aplicativo deve prever e lidar com esse cenário, especialmente porque a conectividade de rede normalmente é restaurada para o operador anteriormente inacessível. Se um processador de registros tem seus fragmentos executados por outro processador de registros, ele deve lidar com os dois casos seguintes para executar o encerramento normal:

Para obter mais informações, consulte Tratar registros duplicados.

O aplicativo consumidor está lendo a uma taxa menor que a esperada

Os motivos mais comuns para a throughput de leitura ser mais lenta do que o esperado são os seguintes:

Se houver apenas uma aplicação de consumo, sempre é possível ler pelo menos duas vezes mais rápido do que a taxa de colocação. É possível gravar até 1.000 registros por segundo, até uma taxa máxima total de gravação de dados de 1 MB por segundo (incluindo chaves de partição). Cada fragmento aberto oferece suporte a até cinco transações por segundo para leituras, até uma taxa máxima total de leitura de dados de 2 MB por segundo. Observe que cada leitura (chamada a GetRecords) obtém um lote de registros. O tamanho dos dados retornados pelo GetRecords varia de acordo com a utilização do fragmento. O tamanho máximo de dados que GetRecords pode retornar é 10 MB. Se uma chamada retorna esse limite, as chamadas subsequentes feitas nos próximos 5 segundos lançam ProvisionedThroughputExceededException.

GetRecords retorna uma matriz de registros vazia mesmo quando há dados no fluxo

O consumo, ou a obtenção, de registros é um modelo de envio. Espera-se que os desenvolvedores GetRecordsliguem em um loop contínuo, sem atrasos. Cada chamada a GetRecords também retorna um valor de ShardIterator que deve ser usado na próxima iteração do loop.

A operação GetRecords não bloqueia. Em vez disso, ela retorna imediatamente; com registros de dados relevantes ou com um elemento Records vazio. Um elemento Records vazio é retornado em duas condições:

A última condição é sutil, mas é uma característica de compensação necessária para evitar tempo de busca ilimitado (latência) ao recuperar registros. Desse modo, a aplicação de consumo de fluxo deve fazer um loop e chamar GetRecords tratando os registros vazios como de costume.

Em um cenário de produção, o único momento em que o loop contínuo deve ser encerrado é quando o valor de NextShardIterator é NULL. Quando NextShardIterator é NULL, significa que o fragmento foi fechado e o valor de ShardIterator apontaria para além do último registro. Se o aplicativo consumidor nunca chamar SplitShard ou MergeShards, o fragmento permanecerá aberto e as chamadas a GetRecords nunca retornarão um valor de NextShardIterator que seja NULL.

Se você usa a Kinesis Client Library (KCL), o padrão de consumo acima é resumido para você. Isso inclui a manipulação automática de um conjunto de fragmentos que mudam dinamicamente. Com oKCL, o desenvolvedor fornece apenas a lógica para processar os registros recebidos. Isso é possível porque a biblioteca faz chamadas contínuas a GetRecords.

O iterador de fragmentos expira inesperadamente

Um novo iterador de fragmento é retornado por toda solicitação a GetRecords (como NextShardIterator), que é usado na próxima solicitação GetRecords (como ShardIterator). Normalmente, esse iterador do fragmento não expira antes de ser usado. No entanto, pode-se encontrar iteradores de fragmento que expiram por não chamar GetRecords por mais de cinco minutos, ou porque executar uma reinicialização da aplicação de consumo.

Se o iterador do fragmento expirar imediatamente, antes que seja possível usá-lo, isso poderá indicar que a tabela do DynamoDB usada pelo Kinesis não tem capacidade suficiente para armazenar os dados de concessões. Essa situação tem maior probabilidade de ocorrer se houver um grande número de fragmentos. Para solucionar esse problema, aumente a capacidade de gravação atribuída à tabela do fragmento. Para obter mais informações, consulte Use uma tabela de leasing para rastrear os fragmentos processados pelo aplicativo do consumidor KCL.

Processamento de registros de consumidores ficando atrasados

Para a maioria dos casos de uso, as aplicações de consumo estão lendo os últimos dados do fluxo. Em determinadas circunstâncias, as leituras dos consumidores podem ficar atrasadas, o que pode não ser desejado. Depois de identificar a dimensão do atraso da leitura dos consumidores, veja os motivos mais comuns disso ocorrer.

Comece com a métrica GetRecords.IteratorAgeMilliseconds, que rastreia a posição de leitura em todos os fragmentos e aplicações de consumo no fluxo. Observe que, se a idade de um iterador passar de 50% do período de retenção (24 horas por padrão, configurável até 365 dias), haverá risco de perda de dados devido à expiração de registro. Uma solução provisória rápida é aumentar o período de retenção. Isso interrompe a perda de dados importantes enquanto o problema é solucionado. Para obter mais informações, consulte Monitore o serviço Amazon Kinesis Data Streams com a Amazon CloudWatch. Em seguida, identifique o quão atrasado seu aplicativo consumidor está lendo cada fragmento usando uma CloudWatch métrica personalizada emitida pela Kinesis Client Library (),. KCL MillisBehindLatest Para obter mais informações, consulte Monitore a biblioteca de cliente do Kinesis com a Amazon CloudWatch.

Veja os motivos mais comuns para consumidores ficarem atrasados:

Erro de permissão de chave KMS mestra não autorizada

Esse erro ocorre quando um aplicativo consumidor lê um fluxo criptografado sem permissões na chave KMS mestra. Para atribuir permissões a um aplicativo para acessar uma KMS chave, consulte Usando políticas de chaves em AWS KMS e Usando IAM políticas com AWS KMS.

Solucionar outros problemas comuns para consumidores