Solução de problemas de consumidores do Kinesis Data Streams - Amazon Kinesis Data Streams
Alguns registros do Kinesis Data Streams são ignorados ao usar a Kinesis Client LibraryRegistros pertencentes ao mesmo estilhaço são processados por processadores de registros diferentes ao mesmo tempoAplicativo consumidor está lendo a uma taxa menor que a esperadaGetRecords Retorna uma matriz de registros vazia mesmo quando há dados no fluxoIterador do estilhaço expira inesperadamenteProcessamento de registros de consumidores ficando atrasadosErro de permissão de chave mestra do KMS não autorizadaProblemas, perguntas e ideias de solução de problemas comuns para 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á.

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

Alguns registros do Kinesis Data Streams são ignorados ao usar a Kinesis Client Library

A causa mais comum de registros ignorados é uma exceção não processada lançada de processRecords. A Kinesis Client Library (KCL) dependeprocessRecords do seu código para lidar com quaisquer exceções decorrentes do processamento dos registros de dados. Qualquer exceção retiradaprocessRecords é absorvida pela KCL. Para evitar repetições infinitas em uma falha recorrente, o KCL não reenvia o lote de registros processados no momento da exceção. Em seguida, o KCLprocessRecords 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 estilhaço 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, a KCL presume 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 atualprocessRecords for concluída, o 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 controlar um trabalhador “zumbi”, o KCL lançaShutdownException. Depois de receber essa exceção, seu código deve sair do método atual de forma limpa.

Para obter mais informações, consulteTratar registros duplicados

Aplicativo consumidor está lendo a uma taxa menor que a esperada

Os motivos mais comuns para a taxa de transferência 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 obter mais informações, consulteCotas 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 a KCL, poderá configurar o operador com um valor baixo para a propriedade maxRecords. Em geral, recomendamos o uso dos padrões do sistema para essa propriedade.

  3. A lógica em sua chamada processRecords está demorando mais do que o esperado por várias razões possíveis. A lógica pode usar muitos recursos da CPU, bloquear a E/S ou estar afunilada na sincronização. Para testar se isso é verdadeiro, teste a execução de processadores de registros vazios e comparar a taxa de transferência de leitura. Para obter informações sobre como acompanhar os dados de entrada, consulte Reestilhaçamento, escalabilidade e processamento paralelo.

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. Isso porque é possível escrever até 1.000 registros por segundo para gravações, até um número máximo de gravações de 1 MB de dados por segundo (incluindo chaves de partição). Cada fragmento aberto pode suportar até 5 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 dos dados queGetRecords podem retornar é de 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 ciclo contínuo sem recuos. 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 o KCL, 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ê.

Iterador do estilhaço 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 de fragmentos expirar imediatamente, antes que você possa usá-lo, isso pode indicar que a tabela do DynamoDB usada pelo Kinesis não tem capacidade suficiente para armazenar os dados da concessão. 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 obter mais informações, consulteUsando 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, 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 ultrapassar 50% do período de retenção (por padrão, 24 horas, configurável por até 365 dias), há risco de perda de dados devido à expiração do 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 obter mais informações, consulteMonitorar o Amazon Kinesis Data Streams Service com o Amazon CloudWatch Em seguida, identifique até que ponto 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, consulteMonitorar a biblioteca de cliente Kinesis com o Amazon CloudWatch

Veja os motivos mais comuns para consumidores ficarem atrasados:

  • Grandes aumentos súbitos em GetRecords.IteratorAgeMilliseconds ou MillisBehindLatest geralmente indicam um problema transitório, como falhas de operação da API para um aplicativo de downstream. 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 taxa de transmissão do stream. Você pode verificar esse comportamento examinando as outras CloudWatch métricas personalizadas que o KCL emite associadas àprocessTask operaçãoRecordProcessor.processRecords.Time, incluindoSuccess,RecordsProcessed e.

    • Caso veja um aumento na métrica processRecords.Time correlacionada ao aumento na taxa de transferência, 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 taxa de transferência.

    • Caso veja um aumento nos valores de processRecords.Time que não esteja correlacionado com aumento na taxa de transferência, 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. Finalmente, confirme se você tem uma quantidade adequada de recursos físicos (memória, utilização da CPU etc.) nos nós de processamento subjacentes durante o pico de demanda.

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

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

Problemas, perguntas e ideias de solução de problemas comuns para consumidores