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á.
Monitoramento em serviço gerenciado para Apache Flink
Ao executar aplicativos de streaming em produção, você decide executar o aplicativo de forma contínua e indefinida. É fundamental implementar o monitoramento e o alarme adequados para todos os componentes, não apenas os do aplicativo Flink. Caso contrário, você corre o risco de deixar passar problemas emergentes logo no início e só perceber um evento operacional quando ele estiver totalmente elucidado e for muito mais difícil de mitigar. No geral é preciso monitorar:
A fonte está ingerindo dados?
Os dados são lidos a partir da fonte (da perspectiva da fonte)?
O aplicativo Flink está recebendo dados?
O aplicativo Flink é capaz de acompanhar ou está ficando para trás?
O aplicativo Flink está persistindo em colocar dados no coletor (do ponto de vista do aplicativo)?
O coletor está recebendo dados?
Métricas mais específicas devem, em seguida, ser consideradas para o aplicativo Flink. Esse CloudWatch painel
records_lag_max e millisbehindLatest— Se o aplicativo estiver consumindo do Kinesis ou do Kafka, essas métricas indicam se o aplicativo está atrasado e precisa ser escalado para acompanhar a carga atual. Essa é uma boa métrica genérica que é fácil de rastrear para todos os tipos de aplicativos. Mas, ele só pode ser usado para escalonamento reativo, ou seja, quando o aplicativo já ficou para trás.
cpuUtilizatione heapMemoryUtilization— Essas métricas fornecem uma boa indicação da utilização geral dos recursos do aplicativo e podem ser usadas para escalabilidade proativa, a menos que o aplicativo esteja vinculado à E/S.
Tempo de inatividade – um tempo de inatividade maior que zero indica que o aplicativo falhou. Se o valor for maior que zero, o aplicativo não está processando nenhum dado.
lastCheckpointSizee lastCheckpointDuration— Essas métricas monitoram a quantidade de dados armazenados no estado e quanto tempo é necessário para chegar a um ponto de verificação. Se os pontos de verificação aumentarem ou demorarem muito, o aplicativo gastará tempo continuamente fazendo pontos de verificação e terá menos ciclos para o processamento real. Em alguns pontos, os pontos de verificação podem ficar muito grandes ou demorar tanto tempo que acabam falhando. Além de monitorar valores absolutos, os clientes também devem considerar monitorar a taxa de alteração com
RATE(lastCheckpointSize)eRATE(lastCheckpointDuration).numberOfFailedPontos de verificação — Essa métrica conta o número de pontos de verificação com falha desde o início do aplicativo. Dependendo do aplicativo, pode ser tolerável que os pontos de verificação falhem de vez em quando. Mas, se os pontos de verificação falharem regularmente, é provável que o aplicativo não esteja íntegro e precise de mais atenção. Recomendamos o monitoramento
RATE(numberOfFailedCheckpoints)para gerar alertas sobre o gradiente e não sobre os valores absolutos.
