Anteriormente, o Amazon Managed Service for Apache Flink era conhecido como Amazon Kinesis Data Analytics for Apache Flink.
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á.
O aplicativo está sendo reiniciado
Se seu aplicativo não estiver íntegro, seu trabalho do Apache Flink falhará e será reiniciado continuamente. Esta seção descreve os sintomas e as etapas de solução de problemas dessa condição.
Sintomas
Essa condição pode ter os seguintes sintomas:
A métrica
FullRestarts
não é zero. Essa métrica representa o número de vezes que o trabalho do aplicativo foi reiniciado desde que você iniciou o aplicativo.A métrica
Downtime
não é zero. Essa métrica representa o número de milissegundos em que o aplicativo está no statusFAILING
ouRESTARTING
.O log do aplicativo contém alterações de status para
RESTARTING
ouFAILED
. Você pode consultar o registro do seu aplicativo para essas mudanças de status usando a seguinte consulta do CloudWatch Logs Insights:Analise erros: falhas relacionadas à tarefa do aplicativo.
Causas e soluções
As condições a seguir podem fazer com que seu aplicativo fique instável e seja reiniciado repetidamente:
O operador está lançando uma exceção: se alguma exceção em um operador em seu aplicativo não for tratada, o aplicativo falhará (interpretando que a falha não pode ser tratada pelo operador). O aplicativo é reiniciado a partir do ponto de verificação mais recente para manter a semântica de processamento “exatamente uma vez”. Como resultado, o
Downtime
não é zero durante esses períodos de reinicialização. Para evitar que isso aconteça, recomendamos que você trate de quaisquer exceções que possam ser repetidas no código do aplicativo.Você pode investigar as causas dessa condição consultando os logs do aplicativo em busca de alterações no estado do aplicativo de
RUNNING
paraFAILED
. Para ter mais informações, consulte Analise erros: falhas relacionadas à tarefa do aplicativo.Os streams de dados do Kinesis não estão provisionados adequadamente: se uma fonte ou coletor do seu aplicativo for um stream de dados do Kinesis, verifique se há erros ou métricas do stream.
ReadProvisionedThroughputExceeded
WriteProvisionedThroughputExceeded
Se você encontrar esses erros, poderá aumentar a throughput disponível para o fluxo do Kinesis aumentando o número de fragmentos do fluxo. Para obter mais informações, consulte Como alterar o número de fragmentos abertos no Kinesis Data Streams?
. Outras fontes ou coletores não estão adequadamente provisionados ou disponíveis: verifique se seu aplicativo está provisionando corretamente as fontes e coletores. Verifique se todas as fontes ou coletores usados no aplicativo (como outros AWS serviços ou fontes ou destinos externos) estão bem provisionados, não estão sofrendo limitação de leitura ou gravação ou se estão periodicamente indisponíveis.
Se você estiver enfrentando problemas relacionados à throughput com seus serviços dependentes, aumente os recursos disponíveis para esses serviços ou investigue a causa de quaisquer erros ou indisponibilidade.
Os operadores não são provisionados adequadamente: se a workload nos threads de um dos operadores em seu aplicativo não for distribuída corretamente, o operador poderá ficar sobrecarregado e o aplicativo poderá falhar. Para obter informações sobre como ajustar o paralelismo do operador, consulte Gerencie o escalonamento do operador adequadamente.
-
O aplicativo falha com DaemonException: Esse erro aparece no registro do aplicativo se você estiver usando uma versão do Apache Flink anterior à 1.11. Talvez seja necessário atualizar para uma versão posterior do Apache Flink para que uma versão KPL 0.14 ou posterior seja usada.
O aplicativo falha com TimeoutException, FlinkException, ou RemoteTransportException: Esses erros podem aparecer no registro do aplicativo se seus gerenciadores de tarefas estiverem falhando. Se seu aplicativo estiver sobrecarregado, seus gerenciadores de tarefas podem sofrer pressão de recursos de CPU ou memória, fazendo com que falhem.
Esses erros podem ter a seguinte aparência:
java.util.concurrent.TimeoutException: The heartbeat of JobManager with id xxx timed out
org.apache.flink.util.FlinkException: The assigned slot xxx was removed
org.apache.flink.runtime.io.network.netty.exception.RemoteTransportException: Connection unexpectedly closed by remote task manager
Para solucionar essa condição, verifique o seguinte:
Verifique suas CloudWatch métricas quanto a picos incomuns no uso da CPU ou da memória.
Verifique se há problemas de throughput em seu aplicativo. Para ter mais informações, consulte Solucionar problemas de desempenho.
Examine o log do aplicativo em busca de exceções não tratadas que o código do aplicativo está gerando.
O aplicativo falha com o erro JaxbAnnotationModule Não encontrado: esse erro ocorre se seu aplicativo usa o Apache Beam, mas não tem as dependências ou versões de dependências corretas. Os aplicativos do Managed Service for Apache Flink que usam o Apache Beam devem usar as seguintes versões de dependências:
<jackson.version>2.10.2</jackson.version> ... <dependency> <groupId>com.fasterxml.jackson.module</groupId> <artifactId>jackson-module-jaxb-annotations</artifactId> <version>2.10.2</version> </dependency>
Se você não fornecer a versão correta do
jackson-module-jaxb-annotations
como uma dependência explícita, seu aplicativo a carrega das dependências do ambiente e, como as versões não coincidem, o aplicativo falha no runtime.Para obter informações sobre como usar o Apache Beam com o Managed Service para Apache Flink, consulte. Use CloudFormation com o serviço gerenciado para Apache Flink
O aplicativo falha com java.io.IOException: número insuficiente de buffers de rede
Isso acontece quando um aplicativo não tem memória suficiente alocada para buffers de rede. Os buffers de rede facilitam a comunicação entre as subtarefas. Eles são usados para armazenar logs antes da transmissão por uma rede e para armazenar dados recebidos antes de dissecá-los em logs e entregá-los a subtarefas. O número de buffers de rede necessários é escalado diretamente com o paralelismo e a complexidade do seu gráfico de trabalho. Há várias abordagens para mitigar esse problema:
Você pode configurar um
parallelismPerKpu
menor para que haja mais memória alocada por subtarefa e buffers de rede. Observe que a redução deparallelismPerKpu
aumentará a KPU e, portanto, o custo. Para evitar isso, você pode manter a mesma quantidade de KPU diminuindo o paralelismo pelo mesmo fator.Você pode simplificar seu gráfico de tarefas reduzindo o número de operadores ou encadeando-os para que sejam necessários menos buffers.
Caso contrário, você pode acessar https://aws.amazon.com/premiumsupport/ para obter uma configuração personalizada do buffer de rede.