Solucionar problemas dos consumidores do Kinesis Data Streams - Amazon Kinesis Data Streams
Alguns registros do Kinesis Data Streams são ignorados ao usar a Biblioteca de cliente do KinesisRegistros pertencentes ao mesmo fragmento são processados por processadores de registros diferentes ao mesmo tempoO aplicativo do consumidor está lendo em um ritmo mais lento do que o esperadoGetRecords retorna uma matriz de registros vazia mesmo quando há dados no fluxoO uterador fragmentado expira inesperadamenteO processamento de registros de consumidores está ficando para trásErro de permissão de chave KMS mestra não autorizadaSolucionar outros problemas comuns dos consumidores

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á.

Solucionar problemas dos consumidores do Kinesis Data Streams

Alguns registros do Kinesis Data Streams são ignorados ao usar a Biblioteca de cliente do Kinesis

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 estilhaço. 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 estilhaço.

Você deve definir um tempo de failover que seja apropriado para seu aplicativo. Para aplicativos de baixa latência, o padrão de 10 segundos pode representar o tempo máximo que você deseja esperar. No entanto, nos casos em que você espera 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 estilhaços executados por outro processador de registros, ele deve lidar com os dois casos seguintes para executar o encerramento normal:

  1. Depois que a chamada atual processRecords for concluída, ele KCL invoca o método de desligamento no processador de gravação com o motivo de desligamento ''. ZOMBIE Espera-se que seus processadores de registros limpem quaisquer recursos conforme apropriado e, em seguida, saiam.

  2. Quando você tenta fazer o checkpoint de um trabalhador “zumbi”, ele joga. KCL ShutdownException Depois de receber essa exceção, seu código deve sair do método atual de forma limpa.

Para ter mais informações, consulte Lidar com registros duplicados.

O aplicativo do consumidor está lendo em um ritmo mais lento do que o esperado

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

  1. Vários aplicativos consumidores com um total de leituras que excedem os limites por estilhaço. Para ter mais informações, consulte Cotas e limites. Nesse caso, aumente o número de fragmentos no fluxo de dados do Kinesis.

  2. O limite que especifica o número máximo de GetRecords por chamada pode ter sido configurado com um valor baixo. Se você estiver usando oKCL, talvez tenha configurado o trabalhador com um valor baixo para a maxRecords propriedade. Em geral, recomendamos o uso dos padrões do sistema para essa propriedade.

  3. A lógica de sua processRecords chamada pode estar demorando mais do que o esperado por vários motivos possíveis; a lógica pode ser CPU intensa, bloquear a E/S ou ter um gargalo na sincronização. Para testar se isso é verdadeiro, teste a execução de processadores de registros vazios e comparar a throughput de leitura. Para obter informações sobre como acompanhar os dados de entrada, consulte Use refragmentação, escalonamento e processamento paralelo para alterar o número de fragmentos.

Se você tem apenas um aplicativo consumidor, 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 estilhaço. 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:

  1. Atualmente, não há mais dados no estilhaço.

  2. Não há dados perto da parte do estilhaço indicada pelo ShardIterator.

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, o aplicativo de consumo de streaming 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 estilhaço foi fechado e o valor de ShardIterator apontaria para além do último registro. Se o aplicativo consumidor nunca chamar SplitShard ou MergeShards, o estilhaço 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 estilhaços 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 para você.

O uterador fragmentado expira inesperadamente

Um novo iterador de estilhaço é retornado por toda solicitação a GetRecords (como NextShardIterator), que você usa na próxima solicitação GetRecords (como ShardIterator). Normalmente, esse iterador do estilhaço não expira antes de você usá-lo. No entanto, você pode descobrir que iteradores de estilhaço expiram porque você não chamou GetRecords por mais de cinco minutos, ou porque você executou uma reinicialização do seu aplicativo consumidor.

Se o iterador do fragmento expirar imediatamente, antes que você possa 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 você tiver um grande número de estilhaços. Para solucionar esse problema, aumente a capacidade de gravação atribuída à tabela do estilhaço. Para ter mais informações, consulte Use uma tabela de leasing para rastrear os fragmentos processados pelo aplicativo consumidor KCL.

O processamento de registros de consumidores está ficando para trás

Para a maioria dos casos de uso, os aplicativos consumidores estão lendo os últimos dados do stream. 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 estilhaços e consumidores no stream. 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 você soluciona o problema. Para ter 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 ter mais informações, consulte Monitore a biblioteca de cliente do Kinesis com a Amazon CloudWatch.

Veja os motivos mais comuns para consumidores ficarem atrasados:

  • Grandes aumentos repentinos GetRecords.IteratorAgeMilliseconds ou MillisBehindLatest geralmente indicam um problema transitório, como falhas de API operação em um aplicativo posterior. Você deve investigar esses aumentos repentinos se uma das métricas exibir esse comportamento constantemente.

  • Um aumento gradual nessas métricas indica que um consumidor não está acompanhando o stream porque não está processando registros com a rapidez necessária. As causas raiz mais comuns para esse comportamento são recursos físicos insuficientes ou lógica de processamento de registros que não escalou com o aumento na throughput do stream. Você pode verificar esse comportamento observando as outras CloudWatch métricas personalizadas que ele KCL emite associadas à processTask operação, incluindo RecordProcessor.processRecords.TimeSuccess, e. RecordsProcessed

    • Caso veja um aumento na métrica processRecords.Time correlacionada ao aumento na throughput, você deve analisar a lógica do processamento de registros para identificar por que ela não está se dimensionando de acordo com a maior throughput.

    • Caso veja um aumento nos valores de processRecords.Time que não esteja correlacionado com aumento na throughput, verifique se você está fazendo chamadas de bloqueio no caminho crítico, que muitas vezes são a causa de lentidão no processamento de registros. Uma abordagem alternativa é aumentar o paralelismo, aumentando o número de estilhaços. Por fim, confirme se você tem uma quantidade adequada de recursos físicos (memória, CPU utilização etc.) nos nós de processamento subjacentes durante o pico de demanda.

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 dos consumidores