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á.
As informações a seguir podem ajudar você a solucionar problemas que possam surgir com seu cluster do Amazon MSK. Você também pode publicar seu problema no AWS re:Post
Tópicos
A substituição do volume causa a saturação do disco devido à sobrecarga de replicação
Erro ao entregar os registros do corretor para o Amazon CloudWatch Logs
As partições ficam offline ou as réplicas estão fora de sincronia
Número de partições com replicação insuficiente (URP) maior que zero
O cluster tem tópicos chamados __amazon_msk_canary e __amazon_msk_canary_state
Não é possível acessar o cluster que está com o acesso público ativado
Não é possível acessar o cluster de dentro AWS: problemas de rede
MSK com tecnologia sem servidor: falha na criação do cluster
A substituição do volume causa a saturação do disco devido à sobrecarga de replicação
Durante uma falha de hardware de volume não planejada, o Amazon MSK pode substituir o volume por uma nova instância. O Kafka preenche novamente o novo volume replicando partições de outros agentes no cluster. Depois que as partições são replicadas e recuperadas, elas se qualificam para associação de liderança e réplica em sincronia (ISR).
Problema
Em um agente se recuperando da substituição de volume, algumas partições de tamanhos variados podem voltar a ficar on-line antes de outras. Isso pode ser problemático, pois essas partições podem estar fornecendo tráfego do mesmo agente que ainda está recuperando (replicando) outras partições. Às vezes, esse tráfego de replicação pode saturar os limites de throughput do volume subjacente, que são de 250 MiB por segundo no caso padrão. Quando essa saturação ocorre, todas as partições que já estão atualizadas serão afetadas, resultando em latência em todo o cluster para qualquer agente que compartilhe a ISR com essas partições atualizadas (não apenas partições líderes devido a acks remotos acks=all). Esse problema é mais comum em clusters maiores que têm um número maior de partições que variam em tamanho.
Recomendação
Para melhorar a postura de E/S de replicação, certifique-se de que as configurações de threads das práticas recomendadas estejam aplicadas.
Para reduzir a probabilidade de saturação do volume subjacente, habilite o armazenamento provisionado com um throughput mais alto. Um valor mínimo de throughput de 500 MiB/s é recomendado para casos de replicação de alto throughput, mas o valor real necessário variará de acordo com o throughput e o caso de uso. Provisione a taxa de transferência de armazenamento para corretores padrão em um cluster Amazon MSK.
Para minimizar a pressão de replicação, reduza
num.replica.fetcherspara o valor padrão de2.
Grupo de consumidores preso no estado PreparingRebalance
Se um ou mais de seus grupos de consumidores estiverem presos em um estado perpétuo de rebalanceamento, a causa disso pode ser o problema KAFKA-9752
Para solucionar esse problema, recomendamos que você atualize seu cluster para a versão Correção de bugs do Amazon MSK versão 2.4.1.1, que contém uma correção para esse problema. Para obter informações sobre a atualização de um cluster existente para a versão 2.4.1.1 de correção de bugs do Amazon MSK, consulte Atualizar a versão do Apache Kafka.
As soluções alternativas para resolver esse problema sem atualizar o cluster para a versão 2.4.1.1 de correção de bugs do Amazon MSK são definir os clientes do Kafka para usar Protocolo de associação estática ou Identificar e reiniciar o nó do agente de coordenação do grupo de consumidores que está preso.
Implementação de protocolo de associação estática
Para implementar o protocolo de associação estática em seus clientes, faça o seguinte:
Defina a propriedade
group.instance.idda sua configuração Consumidores do Kafkacomo uma string estática que identifica o consumidor no grupo. Certifique-se de que outras instâncias da configuração sejam atualizadas para usar a string estática.
Implante as mudanças em seus consumidores do Kafka.
O uso do Protocolo de associação estática é mais eficaz se o tempo limite da sessão na configuração do cliente for definido para uma duração que permita ao consumidor se recuperar sem acionar prematuramente um rebalanceamento do grupo de consumidores. Por exemplo, se sua aplicação consumidora conseguir tolerar 5 minutos de indisponibilidade, um valor razoável para o tempo limite da sessão seria 4 minutos em vez do valor padrão de 10 segundos.
nota
O uso do protocolo de associação estática simplesmente reduz a probabilidade de se deparar com esse problema. Você ainda poderá se deparar com esse problema mesmo ao usar o protocolo de associação estática.
Como reinicializar o nó do agente de coordenação
Para reinicializar o nó agente de coordenação, faça o seguinte:
Identifique o coordenador do grupo usando o comando
kafka-consumer-groups.sh.Reinicie o coordenador do grupo de consumidores bloqueados usando a ação RebootBrokerda API.
Erro ao entregar os registros do corretor para o Amazon CloudWatch Logs
Ao tentar configurar seu cluster para enviar registros do agente para a Amazon CloudWatch Logs, você pode obter uma das duas exceções.
Se você receber uma exceção InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded, tente novamente, mas use grupos de log que começam com /aws/vendedlogs/. Para obter mais informações, consulte Habilitar o registro em log de determinados serviços da Amazon Web Services.
Se você receber uma InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded exceção, escolha uma política existente do Amazon CloudWatch Logs em sua conta e acrescente o seguinte JSON a ela.
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}Se você tentar anexar o JSON acima a uma política existente, mas receber um erro informando que você atingiu o tamanho máximo da política escolhida, tente anexar o JSON a outra de suas políticas do Amazon Logs. CloudWatch Depois de acrescentar o JSON a uma política existente, tente novamente configurar a entrega de registros do corretor para o Amazon Logs. CloudWatch
Nenhum grupo de segurança padrão
Se você tentar criar um cluster e obter um erro indicando que não há grupo de segurança padrão, talvez esteja usando uma VPC que foi compartilhada com você. Peça para o administrador conceder permissão para descrever os grupos de segurança nesta VPC e tente novamente. Para ver um exemplo de uma política que permite essa ação, consulte Amazon EC2: Permite gerenciar grupos de EC2 segurança associados a uma VPC específica, programaticamente e no console.
O cluster parece estar preso no estado CRIANDO
Às vezes a criação do cluster pode levar até 30 minutos. Aguarde 30 minutos e verifique o estado do cluster novamente.
O estado do cluster é alterado de CRIANDO para COM FALHA
Tente criar o cluster novamente.
O estado do cluster está ATIVO, mas os produtores não conseguem enviar dados ou os consumidores não conseguem receber dados
-
Se a criação do cluster tiver êxito (o estado do cluster será
ACTIVE), mas não será possível enviar nem receber dados. Certifique-se de que os aplicativos produtor e consumidor tenham acesso ao cluster. Para obter mais informações, consulte as diretrizes no Etapa 3: criar uma máquina cliente.
-
Caso os produtores e os consumidores tenham acesso ao cluster, mas ainda assim enfrentem problemas ao gerar e consumir dados, a causa pode ser KAFKA-7697
, que afeta o Apache Kafka versão 2.1.0 e pode levar a um deadlock em um ou mais agentes. Considere migrar para o Apache Kafka 2.2.1, que não é afetado por este bug. Para obter informações sobre como migrar, consulte Migrar para um cluster do Amazon MSK.
AWS CLI não reconhece o Amazon MSK
Se você o tiver AWS CLI instalado, mas ele não reconhecer os comandos do Amazon MSK, atualize-o AWS CLI para a versão mais recente. Para obter instruções detalhadas sobre como atualizar o AWS CLI, consulte Instalando AWS Command Line Interface o. Para obter informações sobre como usar os comandos AWS CLI para executar o Amazon MSK, consultePrincipais recursos e conceitos do Amazon MSK.
As partições ficam offline ou as réplicas estão fora de sincronia
Estes podem ser sintomas de pouco espaço em disco. Consulte O espaço em disco está acabando.
O espaço em disco está acabando
Consulte as melhores práticas para gerenciar o espaço em disco: Monitorar o espaço em disco e Ajustar os parâmetros de retenção de dados.
A memória está baixa
Caso a métrica MemoryUsed esteja alta ou a MemoryFree esteja baixa, isso não significa que existe um problema. O Apache Kafka foi desenvolvido para usar o máximo de memória possível, que é gerenciada de forma ideal.
O produtor recebe NotLeaderForPartitionException
Geralmente, isto é um erro transitório. Defina o parâmetro de configuração de retries do produtor com um valor mais alto que o atual.
Número de partições com replicação insuficiente (URP) maior que zero
A UnderReplicatedPartitions é uma métrica importante e deve ser monitorada. Em um cluster MSK íntegro, essa métrica tem o valor igual a 0. Se for maior que zero, isso pode ocorrer por um dos motivos a seguir.
-
Se
UnderReplicatedPartitionsestiver apresentando picos, o problema pode ser que o cluster não foi provisionado no tamanho correto para tratar o tráfego de entrada e saída. Consulte Melhores práticas para corretores padrão. -
Se
UnderReplicatedPartitionsfor consistentemente maior que 0, inclusive durante períodos de baixo tráfego, o problema pode ser que você tenha definido restrições ACLs que não concedem acesso ao tópico aos corretores. Para replicar partições, os agentes devem estar autorizados a READ (ler) e DESCRIBE (descrever) os tópicos. DESCRIBE é concedido por padrão com a autorização READ. Para obter informações sobre configuração ACLs, consulte Autorização e ACLsna documentação do Apache Kafka.
O cluster tem tópicos chamados __amazon_msk_canary e __amazon_msk_canary_state
Você pode ver que seu cluster do MSK tem um tópico com o nome __amazon_msk_canary e outro com o nome __amazon_msk_canary_state. Trata-se de tópicos internos que o Amazon MSK cria e usa para métricas de integridade e diagnóstico do cluster. Esses tópicos têm um tamanho insignificante e não podem ser excluídos.
Falha na replicação de partições
Certifique-se de que você não tenha definido ACLs CLUSTER_ACTIONS.
Não é possível acessar o cluster que está com o acesso público ativado
Siga as etapas abaixo se o seu cluster estiver com o acesso público ativado, mas você ainda não conseguir acessá-lo pela Internet:
Certifique-se de que as regras de entrada do grupo de segurança do cluster tenham permissão para seu endereço IP e a porta do cluster. Para obter uma lista dos números de portas do cluster, consulte Informações de porta. Certifique-se também de que as regras de saída do grupo de segurança permitam comunicações de saída. Para ter mais informações sobre grupos de segurança e suas regras de entrada e saída, consulte Grupos de segurança para sua VPC no Guia do usuário da Amazon VPC.
Certifique-se de que seu endereço IP e a porta do cluster tenham permissão nas regras de entrada da ACL da rede VPC do cluster. Ao contrário dos grupos de segurança, ACLs as redes não têm estado. Isso significa que você deve configurar as regras de entrada e saída. Nas regras de saída, permita que todo o tráfego (intervalo de portas: 0-65535) chegue ao seu endereço IP. Para obter mais informações, consulte Adicionar e excluir regras no Guia do usuário da Amazon VPC.
-
Verifique se você está usando a string bootstrap-brokers de acesso público para acessar o cluster. Um cluster do MSK com acesso público ativado tem duas strings distintas de agentes de inicialização, uma para acesso público e outra para acesso interno diretamente da AWS. Para obter mais informações, consulte Obtenha os corretores de bootstrap usando o AWS Management Console.
Não é possível acessar o cluster de dentro AWS: problemas de rede
Se você tiver uma aplicação do Apache Kafka que não consiga se comunicar com êxito com um cluster do MSK, comece executando o teste de conectividade a seguir.
Use qualquer um dos métodos descritos em Obter os agentes de bootstrap para um cluster do Amazon MSK para obter os endereços dos agentes de bootstrap.
-
No comando a seguir,
bootstrap-brokersubstitua por um dos endereços do broker que você obteve na etapa anterior.port-numberSubstitua por 9094 se o cluster estiver configurado para usar a autenticação TLS. Se o cluster não usar a autenticação TLS,port-numbersubstitua por 9092. Execute o comando usando a máquina cliente.telnetbootstrap-brokerport-numberEm que o número da porta será:
9094 se o cluster estiver configurado para usar a autenticação TLS.
9092 se o cluster não usar a autenticação TLS.
Um número de porta diferente será necessário se o acesso público estiver habilitado.
Execute o comando usando a máquina cliente.
-
Repita o comando anterior para todos os agentes de bootstrap.
Se a máquina cliente é capaz de acessar os agentes, isso significa que não há problemas de conectividade. Nesse caso, execute o comando a seguir para verificar se o cliente do Apache Kafka está configurado corretamente. Para obterbootstrap-brokers, use qualquer um dos métodos descritos emObter os agentes de bootstrap para um cluster do Amazon MSK. topicSubstitua pelo nome do seu tópico.
<path-to-your-kafka-installation>/bin/kafka-console-producer.sh --broker-listbootstrap-brokers--producer.config client.properties --topictopic
Se o comando anterior for bem-sucedido, isso indica que o cliente está configurado corretamente. Se você ainda não consegue produzir e consumir de um aplicativo, depure o problema no nível do aplicativo.
Se a máquina cliente não consegue acessar os agentes, consulte as subseções a seguir para obter orientações baseadas na configuração da máquina cliente.
EC2 Cliente Amazon e cluster MSK na mesma VPC
Se a máquina cliente estiver na mesma VPC que o cluster do MSK, verifique se o grupo de segurança do cluster tem uma regra de entrada que aceite tráfego do grupo de segurança da máquina cliente. Para obter informações sobre como configurar essas regras, consulte Regras do grupo de segurança. Para ver um exemplo de como acessar um cluster a partir de uma EC2 instância da Amazon que está na mesma VPC do cluster, consulte. Conceitos básicos sobre como usar o Amazon MSK
EC2 Cliente Amazon e cluster MSK em diferentes VPCs
Se a máquina cliente e o cluster estiverem em duas partes diferentes VPCs, verifique o seguinte:
-
Os dois VPCs são examinados.
-
O status da conexão de emparelhamento está ativo.
-
As tabelas de rotas dos dois VPCs estão configuradas corretamente.
Para obter informações sobre o emparelhamento de VPC, consulte Trabalhar com conexões de emparelhamento de VPC.
Cliente on-premises
No caso de um cliente local configurado para se conectar ao cluster MSK usando AWS VPN, verifique o seguinte:
-
O status da conexão VPN é
UP. Para obter informações sobre como verificar o status da conexão VPN, consulte Como verificar o status atual do meu túnel VPN?. -
A tabela de rotas da VPC do cluster contém a rota para um CIDR on-premises, cujo destino tem o formato
Virtual private gateway(vgw-xxxxxxxx). -
O grupo de segurança do cluster do MSK permite tráfego na porta 2181, na porta 9092 (se o cluster aceitar tráfego em texto simples) e na porta 9094 (se o cluster aceitar tráfego com criptografia TLS).
Para obter mais orientações sobre AWS VPN solução de problemas, consulte Solução de problemas do Client VPN.
AWS Direct Connect
Se o cliente usar AWS Direct Connect, consulte Solução de problemas AWS Direct Connect.
Se as orientações para a solução de problemas anteriores não resolverem a situação, certifique-se de que nenhum firewall esteja bloqueando o tráfego de rede. Para depuração adicional, use ferramentas como tcpdump e Wireshark para analisar o tráfego e garantir que ele esteja alcançando o cluster do MSK.
Falha na autenticação: muitas conexões
O erro Failed authentication ... Too many connects indica que um agente está se protegendo porque um ou mais clientes do IAM estão tentando se conectar a ele em um ritmo agressivo. Para ajudar os agentes a aceitarem uma taxa maior de novas conexões do IAM, você pode aumentar o parâmetro de configuração reconnect.backoff.ms
Para saber mais sobre os limites de taxa para novas conexões por agente, consulte a página Cota do Amazon MSK.
Falha na autenticação: sessão muito curta
O Failed authentication ... Session too short erro ocorre quando seu cliente tenta se conectar a um cluster usando credenciais do IAM que estão prestes a expirar. Certifique-se de verificar como suas credenciais do IAM estão sendo atualizadas. Provavelmente, as credenciais estão sendo substituídas muito perto da expiração da sessão, o que causa problemas no servidor e falhas de autenticação.
MSK com tecnologia sem servidor: falha na criação do cluster
Se você tentar criar um cluster do MSK com a tecnologia sem servidor e o fluxo de trabalho falhar, talvez você não tenha permissão para criar um endpoint da VPC. Verifique se o administrador concedeu permissão para você criar um endpoint da VPC permitindo a ação ec2:CreateVpcEndpoint.
Para obter uma lista completa das permissões necessárias para realizar todas as ações do Amazon MSK, consulte AWS política gerenciada: Amazon MSKFull Access.
