Realtime Compute for Apache Flink:Configurações de monitoramento recomendadas

Pré-requisitos

Antes de começar, conclua a configuração descrita em Configurar monitoramento e alertas. Escolha a ferramenta de monitoramento adequada à configuração do seu workspace.

O alerta de múltiplas métricas no ARMS (Application Real-Time Monitoring Service) requer PromQL personalizado . Para uma configuração mais simples, use o CloudMonitor.

Regras de alerta recomendadas

A tabela a seguir resume os alertas abordados neste guia. Configure-os por ordem de prioridade: alertas P0 indicam impacto imediato no job, enquanto alertas P2 sinalizam pressão emergente sobre os recursos.

<table> <thead> <tr> <td> <p><b>Cenário</b></p> </td> <td> <p><b>Métrica ou evento</b></p> </td> <td> <p><b>Condição de acionamento</b></p> </td> <td> <p><b>Nível</b></p> </td> <td> <p><b>Ação</b></p> </td> </tr> </thead> <colgroup></colgroup> <colgroup></colgroup> <colgroup></colgroup> <colgroup></colgroup> <colgroup></colgroup> <tbody> <tr> <td> <p><a href="#e7130392f32oe">Falha no job</a></p> </td> <td> <p>Evento de status do job</p> </td> <td> <p>= FAILED (alerta de evento)</p> </td> <td> <p>P0</p> </td> <td> <p>1. Verifique se a estratégia de reinicialização está configurada incorretamente. Use as configurações padrão, a menos que tenha um motivo específico para substituí-las.</p> <p>2. Determine se a falha foi causada pela estratégia de reinicialização ou por uma anomalia no JobManager ou TaskManager.</p> <p>3. Restaure o job a partir do snapshot ou checkpoint bem-sucedido mais recente.</p> </td> </tr> <tr> <td> <p><a href="#0056509ea2937">Pico de failover</a></p> </td> <td> <p>Overview/Número de recuperações de erro por minuto para o job</p> </td> <td> <p>≥ 1 por 1 período consecutivo</p> </td> <td> <p>P0</p> </td> <td> <p>1. Identifique a causa raiz.</p> <ul> <li> <p>Analise os logs de failover, JobManager e TaskManager.</p> </li> <li> <p><b>Ignorar</b>: Falhas de máquina infrequentes e autorrecuperáveis.</p> </li> <li> <p><b>Corrigir</b>: Bugs de código, gargalos de recursos ou erros de configuração.</p> </li> </ul> <p>2. Restaure o job a partir do snapshot ou checkpoint bem-sucedido mais recente.</p> </td> </tr> <tr> <td> <p><a href="#5435fcd4abo9e">Falhas consecutivas de checkpoint</a></p> </td> <td> <p>Número de checkpoints bem-sucedidos (cumulativo de 5 min)</p> </td> <td> <p>≤ 0 por 1 período consecutivo</p> </td> <td> <p>P0</p> </td> <td> <p>1. Consulte <a href="https://www.alibabacloud.com/help/en/document_detail/414257.html#caf8e65a8awv1">Checkpoints do sistema</a> para identificar a causa raiz.</p> <p>2. Atue sobre a causa.</p> <ul> <li> <p>Problema de configuração (como timeout): Ajuste as configurações de checkpoint.</p> </li> <li> <p>Pressão de recursos (como backpressure): Use o <a href="https://www.alibabacloud.com/help/en/document_detail/2536572.html">dimensionamento dinâmico</a> para adicionar recursos ao operador com backpressure.</p> </li> </ul> <p>3. Atualize a configuração dinamicamente ou restaure o job a partir do último checkpoint bem-sucedido.</p> </td> </tr> <tr> <td> <p><a href="#c339292e4e6p7">Alta latência de negócio (com dados de entrada)</a></p> </td> <td> <p>Overview/Latência de negócio && Registros de entrada da source por segundo</p> </td> <td> <p>Latência máxima ≥ 180000</p> <p>Registros de entrada ≥ 0</p> <p>por 3 períodos consecutivos</p> </td> <td> <p>P1</p> </td> <td> <p>1. Consulte a <a href="https://www.alibabacloud.com/help/en/document_detail/2543043.html">Descrição das métricas</a> para investigar a causa.</p> <ul> <li> <p><b>Plano de dados</b>: Os timestamps dos eventos estão fora de ordem?</p> </li> <li> <p><b>Tráfego</b>: Há um pico upstream ou backpressure downstream?</p> </li> </ul> <p>2. Atue sobre a causa.</p> <ul> <li> <p><b>Interno</b>: Ajuste os parâmetros WITH do conector e escale horizontalmente o operador com gargalo.</p> </li> <li> <p><b>Externo</b>: Otimize as configurações do serviço externo, como ajustar políticas de limitação ou aumentar limites de conexão.</p> </li> </ul> </td> </tr> <tr> <td> <p><a href="#ff3815bfc11gq">Interrupção de dados upstream</a></p> </td> <td> <p>Overview/Registros de entrada da source por segundo && Timestamp de dados brutos da source</p> </td> <td> <p>Registros de entrada ≤ 0 (dependente do negócio)</p> <p>Tempo ocioso máximo ≥ 60000</p> <p>por 5 períodos consecutivos</p> </td> <td> <p>P1</p> </td> <td> <p>1. Verifique o taskmanager.log, gráficos de chama e métricas do serviço upstream para confirmar a causa: ausência de dados upstream, limitação, erro ou pilha de threads travada.</p> <p>2. Atue sobre a causa.</p> <ul> <li> <p><b>Problema no conector:</b> Ajuste parâmetros do conector, como timeout ou concorrência, ou adicione recursos ao TaskManager.</p> </li> <li> <p><b>Problema no serviço upstream ou downstream:</b> Notifique a equipe responsável pelo upstream para investigar.</p> </li> <li> <p><b>Gargalo interno do Flink</b> (como backpressure ou congelamento): Resolva primeiro a causa raiz e reinicie o job a partir do checkpoint mais recente.</p> </li> </ul> </td> </tr> <tr> <td> <p><a href="#10fd3e302b76j">Sem saída downstream</a></p> </td> <td> <p>Overview/Registros de saída para o sink por segundo</p> </td> <td> <p>≤ 0 por 5 períodos consecutivos</p> </td> <td> <p>P1</p> </td> <td> <p>1. Confirme se os dados chegam ao operador sink.</p> <ul> <li> <p><b>Filtragem por lógica de negócio</b>: Verifique logs ou métricas para determinar se toda a entrada foi filtrada.</p> </li> <li> <p><b>Descarte de dados atrasados</b>: Verifique as configurações de watermark e janela para determinar se os dados foram descartados por chegada tardia.</p> </li> </ul> <p>2. Confirme se o sink consegue gravar no sistema externo.</p> <ul> <li> <p><b>Camada de conexão</b>: O pool de conexões está cheio? A conectividade de rede está normal?</p> </li> <li> <p><b>Sistema de destino</b>: O banco de dados ou serviço downstream apresenta tabela bloqueada, espaço em disco insuficiente, limitação de gravação ou outros erros?</p> </li> </ul> <p>3. Como medida temporária, ative a gravação dupla em um sistema de armazenamento de backup.</p> </td> </tr> <tr> <td> <p><a href="#1e5b7fcf1cdsj">Gargalo de CPU</a></p> </td> <td> <p>CPU/Utilização de CPU de um único TM</p> </td> <td> <p>≥ 85% por 10 períodos consecutivos</p> </td> <td> <p>P2</p> </td> <td> <p>1. Use gráficos de chama ou a UI do Flink para localizar o operador com ponto crítico.</p> <ul> <li> <p><b>Lógica de negócio</b>: Verifique cálculos complexos, análise de JSON ou funções definidas pelo usuário (UDFs) ineficientes.</p> </li> <li> <p><b>Skew de dados</b>: Verifique se uma chave de ponto crítico está sobrecarregando uma única tarefa com volume excessivo de dados.</p> </li> <li> <p><b>Recursos insuficientes</b>: Determine se o grau atual de paralelismo e os recursos do TaskManager suportam o tráfego e se há backpressure severo.</p> </li> <li> <p><b>GC frequente</b>: Verifique logs ou métricas da JVM para determinar se a pressão de memória está acionando Full GCs frequentes.</p> </li> </ul> <p>2. Aumente o grau de paralelismo do operador com gargalo ou aloque mais núcleos de CPU ao TaskManager.</p> </td> </tr> <tr> <td> <p><a href="#5d68057bafc8w">Gargalo de memória</a></p> </td> <td> <p>Memória heap do TM utilizada</p> </td> <td> <p>≥ 90% por 10 períodos consecutivos</p> </td> <td> <p>P2</p> </td> <td> <p>1. Verifique os logs de GC para identificar o tipo de problema.</p> <ul> <li> <p><b>Vazamento de memória</b>: A memória heap não retorna à linha de base após o GC e a linha de base continua subindo.</p> </li> <li> <p><b>Capacidade insuficiente</b>: O uso do heap permanece consistentemente alto, acionando Full GCs frequentes e degradando o desempenho.</p> </li> <li> <p><b>OutOfMemoryError (OOM) repentino</b>: A memória enche instantaneamente ao processar um registro ou lote específico.</p> </li> </ul> <p>2. Aumente o tamanho do heap ou o grau de paralelismo para reduzir o volume de dados por slot.</p> </td> </tr> </tbody> </table>

Disponibilidade do job

Tempestividade dos dados

Gargalos de desempenho de recursos