Realtime Compute for Apache Flink:Configurações e modelos de alertas

Cenário

Nome da métrica/evento

Configuração da regra

Severidade

Ações

Job failure

Evento de status de execução do job

= FAILED (Alerta baseado em evento)

P0

1. Verifique se a política de reinício está configurada incorretamente. Recomenda-se usar a configuração padrão.

2. Determine se a falha é causada pela política de reinício ou por uma exceção no JobManager/TaskManager.

3. Restaure o job a partir do último savepoint ou checkpoint bem-sucedido.

Spike in failovers

Overview / NumOfRestart

≥ 1 por 1 período consecutivo

P0

1. Identifique a causa raiz.

• Analise os logs de failover, JobManager e TaskManager para obter detalhes do erro.

• Ignorar: Falhas de máquina infrequentes e com recuperação automática.

• Corrigir: Bugs de código, gargalos de recursos ou erros de configuração.

2. Restaure o job a partir do último savepoint ou checkpoint bem-sucedido.

Consecutive checkpoint failures

NumOfCheckpoints (agregação de 5 minutos)

≤ 0 por 1 período consecutivo

P0

1. Consulte System checkpoints para solucionar a causa raiz das falhas de checkpoint.

2. Identifique e resolva o problema.

• Problemas de parâmetro (ex.: timeout): Ajuste as configurações relacionadas ao checkpoint.

• Dimensionamento de recursos (ex.: backpressure): Use dynamic scaling para adicionar recursos ao operador com backpressure.

3. Atualize dinamicamente a configuração ou restaure o job a partir do último checkpoint bem-sucedido.

High latency (with data ingress)

Overview / CurrentEmitEventTimeLag && NumOfRecordsInFromSourcePerSecond

Latência máxima ≥ 180.000 ms

Registros de entrada ≥ 0

por 3 períodos consecutivos

P1

1. Consulte Monitor metrics para identificar a causa da latência.

• Dados: Os horários dos eventos estão fora de ordem?

• Tráfego: Há um pico no tráfego de upstream ou backpressure de um sistema de downstream?

2. Ajuste com base na causa específica.

• Interno: Ajuste as opções WITH do conector ou aumente o dimensionamento do operador com gargalo.

• Externo: Otimize as configurações do service externo, como ajustar políticas de limitação de taxa ou aumentar a contagem de conexões.

Upstream data flow interruption

Overview / NumOfRecordsInFromSourcePerSecond &&

SourceIdleTime

Registros de entrada ≤ 0 (dependendo da sua lógica de negócios)

Tempo ocioso máximo ≥ 60.000 ms

por 5 períodos consecutivos

P1

1. Verifique o taskmanager.log, os gráficos de chama e as métricas do service de upstream para confirme se o problema é ausência de dados de upstream, limitação de taxa ou uma exceção, ou uma pilha de threads travada.

2. Ajuste com base na causa específica.

• Problemas de conector: Otimize os parâmetros do conector (ex.: timeout, concorrência) ou adicione mais recursos ao TaskManager.

• Problemas no service de upstream: Notifique o responsável pelo service de upstream para resolver o problema.

• Gargalos internos do Flink (ex.: backpressure ou congelamento do sistema): Resolva a causa raiz do gargalo (como um problema de downstream) e reinicie o job a partir do último checkpoint.

No data output

Overview / NumOfRecordsOutToSinkPerSecond

≤ 0 por 5 períodos consecutivos

P1

1. Verifique se os dados estão chegando ao operador sink.

• Filtragem por lógica de negócios: Use logs ou métricas para confirme se todos os dados de entrada estão sendo filtrados por não atenderem a determinadas condições.

• Dados atrasados descartados: Verifique as configurações de watermark e janela para confirme se os dados estão sendo descartados por atraso.

2. Verifique se o sink pode gravar no sistema externo.

• Nível de conexão: O pool de conexões do sink está esgotado? A conexão de rede está estável?

• Nível do sistema de destino: Verifique se o banco de dados ou service de downstream apresenta bloqueios de tabela, espaço em disco insuficiente, limitação de gravação ou outros erros.

3. Para uma solução de contingência temporária, implemente uma gravação dupla em um sistema de armazenamento de backup.

cpu performance bottleneck

cpu / TMCPUUsage

≥ 85% por 10 períodos consecutivos

P2

1. Use um gráfico de chama ou a UI do Flink para identificar o operador com gargalo.

• Lógica de negócios: Computações complexas, parsing de JSON ou funções definidas pelo usuário (UDFs) ineficientes.

• Skew de dados: Uma chave quente está sobrecarregando uma única tarefa com um grande volume de dados.

• Recursos insuficientes: O paralelismo atual e os recursos do TaskManager correspondem ao tráfego de dados? Há backpressure severo?

• GC frequente: Use logs ou métricas da JVM para verificar se a pressão de memória está causando Full GCs frequentes, que consomem muita cpu.

2. Aumente o paralelismo do operador com gargalo ou aloque mais núcleos de cpu para o TaskManager.

Memory performance bottleneck

TMHeapMemoryUsed

≥ 90% por 10 períodos consecutivos

P2

1. Analise os logs de GC para identificar o problema.

• Vazamento de memória: Use a UI do Flink ou painéis de monitoramento para observar se a memória heap não retorna à sua linha de base após o GC e se a linha de base continua subindo.

• Capacidade insuficiente: Se o uso de memória heap estiver consistentemente alto, isso pode acionar Full GCs frequentes e degradar o desempenho.

• OOM repentino: Verifique se o processamento de um registro específico ou lote de dados faz com que a memória se esgote instantaneamente, levando diretamente a um OutOfMemoryError.

2. Aumente o tamanho do heap ou o paralelismo para reduzir o volume de dados por slot.