Realtime Compute for Apache Flink:Monitoring and log FAQ

Como verifico o tipo de service de monitoramento usado por um workspace?

Você define o tipo de service de monitoramento durante a criação do workspace e não pode alterá-lo posteriormente. Para identificar qual tipo seu workspace utiliza, acesse Operation Center > Job O&M e clique em no nome de um job. Se a aba Alert Configuration estiver visível, o workspace utiliza o Prometheus Service com pagamento conforme o uso, parte do Application Real-Time Monitoring Service (ARMS). Caso a aba não apareça, o workspace usa o service gratuito Cloud Monitor. Para obter instruções de configuração de cada tipo de service, consulte Monitoramento e alertas de jobs.

Quais são as limitações dos alertas do Cloud Monitor em comparação ao ARMS?

O Cloud Monitor apresenta três limitações em relação ao ARMS:

• Não há suporte para sintaxe de análise de consultas.

• Curvas com granularidade de subtarefa não estão disponíveis. Em cenários com múltiplas sources e subtarefas, isso dificulta a identificação rápida de problemas de latência após o agrupamento.

• Não é possível visualizar métricas provenientes de instrumentação personalizada no código do usuário, o que pode complicar a solução de problemas.

Como configuro ou adiciono um contato de alerta?

Ao utilizar alertas do console do Cloud Monitor ou do ARMS, adicione ou configure os contatos no console correspondente. Para mais detalhes, consulte Configurar monitoramento e alertas.

Se o seu workspace utiliza o ARMS e você deseja configurar alertas de métricas ou falhas de job diretamente no console de desenvolvimento do Realtime Compute for Apache Flink, siga os passos abaixo para adicionar ou configurar contatos de alerta.

1. Acesse a página de configuração de alertas.

   1. Faça login no console de gerenciamento do Realtime Compute for Apache Flink. Na coluna Operation do workspace desejado, clique em Console.

   2. Na página Operation Center > Job O&M, clique em no nome do job alvo.

   3. Clique em na aba Alert Configuration.

2. Na aba Alert Rules, escolha Add Rule > Custom Rule para abrir o painel de criação de regras.

3. Configure ou adicione um contato de alerta.

   • Adicionar: Clique em Notification Recipient Management ao lado do parâmetro Notification Recipient para adicionar contatos, robôs do DingTalk, entre outros. Para informações sobre como configurar alertas para robôs do DingTalk, webhooks e robôs do Lark, consulte a seção FAQ do guia de alertas. Após adicionar um contato, caso utilize chamadas telefônicas para alertas, verifique se o número de telefone do destinatário foi validado. Caso contrário, os alertas não serão entregues. Se o rótulo Unverified aparecer na coluna Phone do contato desejado na aba Contacts, clique em no rótulo para concluir a verificação.

   • Configurar: No parâmetro Notification Object, selecione os contatos de alerta desejados. Se o contato não estiver listado, adicione-o seguindo os passos acima.

Como desativo o Prometheus Service ativado automaticamente?

Se você selecionou o Prometheus Service com pagamento conforme o uso ao criar seu workspace, o ARMS é ativado automaticamente. Para parar de utilizá-lo, desinstale a instância do Prometheus no console do Prometheus.

Importante

Desinstalar a instância do Prometheus de um workspace interrompe a coleta de dados de monitoramento desse workspace e resulta na perda das curvas de dados de monitoramento dos jobs. Se um job apresentar anomalias, você não conseguirá identificar o momento inicial da falha nem receber alertas de monitoramento. Proceda com cautela.

1. Faça login no console do Prometheus.

2. No painel de navegação à esquerda, clique em Instance List.

3. Na lista suspensa Tag Filtering, selecione o ID ou o nome do workspace desejado.

4. Localize a instância com Instance Type definida como Prometheus for Flink Serverless e clique em Uninstall na coluna Operation.

5. Na caixa de diálogo, clique em Confirm.

Como encontro o job que acionou um alerta?

Os eventos de alerta contêm tanto um JobID quanto um Deployment ID. Como o JobID muda após um failover do job, utilize o Deployment ID para identificar o job específico que reportou o erro.

Visualize o Deployment ID em um destes locais:

• No console de desenvolvimento do Realtime Compute for Apache Flink, na aba Deployment Details, encontre o Deployment ID na seção Basic.

  

• Na URL do job.

  

Como configuro monitoramento e alertas para reinícios de jobs do Flink?

O console de desenvolvimento do Realtime Compute for Apache Flink configura regras de alerta baseadas em métricas do Flink. Portanto, após um failover do job, as curvas de métricas não são exibidas e os alertas não podem ser acionados. Para gerar alertas sobre reinícios de jobs, configure uma regra personalizada no ARMS baseada na taxa de crescimento instantâneo da métrica flink_jobmanager_job_numRestarts. Isso permite o envio de alertas para eventos de failover do job manager (JM).

1. Faça login no console de gerenciamento do Realtime Compute for Apache Flink.

2. Na coluna Operation do workspace desejado, clique em More > Monitoring Indicator Configuration para abrir o console do ARMS.

3. Na página Alert Rules, clique em Create Prometheus Alert Rule.

4. Defina Detection Type como Custom PromQL e selecione a instância de alerta.

5. Insira uma expressão personalizada em Prometheus Query Language (PromQL). Por exemplo:

   irate(flink_jobmanager_job_numRestarts{jobId=~"$jobId",deploymentId=~"$deploymentId"}[1m])>0

   Esta expressão consulta a métrica flink_jobmanager_job_numRestarts no último minuto e aciona um alerta se a taxa instantânea de variação for maior que 0.

6. Clique em Finish.

Como defino parâmetros de nível de log para uma única classe?

Configure os parâmetros de nível de log por classe em Log Levels, e não em Other Configuration. Por exemplo, para definir níveis de log do conector Kafka, adicione os seguintes parâmetros em Log Levels:

• log4j.logger.org.apache.kafka.clients.consumer=trace (para uma tabela source)

• log4j.logger.org.apache.kafka.clients.producer=trace (para uma tabela sink)

Como ativo os parâmetros de log de GC?

Na página Operation Center > Job O&M, clique em no nome do job desejado. Na aba Deployment Details, em Parameters, adicione a seguinte configuração em Other Configuration e salve para aplicar.

env.java.opts: >-
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/flink/log/gc.log
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=2 -XX:GCLogFileSize=50M

Falha ao iniciar job após configurar logs para o SLS

Após configurar um job para enviar logs ao Simple Log Service (SLS), o job falha com a mensagem Job startup failed. Please retry. e o seguinte erro:

Unknown ApiException {exceptionType=com.ververica.platform.appmanager.controller.domain.TemplatesRenderException, exceptionMessage=Failed to render {userConfiguredLoggers={}, jobId=3fd090ea-81fc-4983-ace1-0e0e7b******, rootLoggerLogLevel=INFO, clusterName=f7dba7ec27****, deploymentId=41529785-ab12-405b-82a8-1b1d73******, namespace=flinktest-default, priorityClassName=flink-p5, deploymentName=test}}
029999 202312121531-8SHEUBJUJU

Esse erro ocorre quando uma variável de modelo Twig — como namespace ou deploymentId — é modificada acidentalmente durante a configuração de logs.

Para corrigir, reconfigure as definições de log seguindo Configurar saída de logs do job. Não modifique variáveis Twig no modelo de configuração de logs.

Como visualizo, pesquiso e analiso logs operacionais históricos do Flink?

O Realtime Compute for Apache Flink oferece duas formas de acessar logs operacionais históricos.

• No console de desenvolvimento: Na aba Deployment Details, o recurso Log Archiving vem ativado por padrão com um período de retenção de 7 dias. Os 5 MB mais recentes de logs operacionais são mantidos. Ajuste o Log Archive Retention Period conforme necessário.

  

• Em armazenamento externo: Configure os jobs para enviar logs ao Object Storage Service (OSS), SLS ou Kafka e defina o nível de log para saída. Para mais detalhes, consulte Configurar saída de logs do job.

Como resolvo o problema em que logs de métodos não estáticos não são enviados ao SLS?

Devido à lógica de implementação do SLS Logger Appender, logs gerados por métodos não estáticos não são enviados ao SLS.

Corrija isso declarando seu logger usando o padrão estático convencional:

private static final Logger LOG = LoggerFactory.getLogger(xxx.class);

Os dados são gravados corretamente, mas a visão geral do status do job Flink mostra 0 dados. O que fazer?

Isso acontece quando um job possui apenas um nó, sendo que a source tem apenas saída e o sink tem apenas entrada. Nessa topologia, o Flink não exibe o volume de dados no gráfico de topologia.

Para visualizar o tráfego de dados no gráfico de topologia, separe os operadores de source e sink em operadores independentes. Adicione o seguinte parâmetro em Other Configuration, dentro de Parameter Settings na aba Deployment Details:

pipeline.operator-chaining: 'false'

Acesse Operation Center > Job O&M, clique em no nome do job e localize Other Configuration em Parameter Settings na aba Deployment Details.

O que fazer se um job DataStream não tiver atraso, mas a curva de saída mostrar atraso?

Se as métricas CurrentEmitEventTimeLag e CurrentFetchEventTimeLag apresentarem um atraso de aproximadamente 52 anos, o job está utilizando um conector Kafka da comunidade em vez do conector nativo do Flink. Conectores da comunidade não implementam a lógica de reporte de métricas para essas curvas, fazendo com que os valores pareçam anormais.

Mude para a dependência do conector nativo do Flink. Encontre a versão correta no Maven Repository.

O que fazer se uma NullPointerException for lançada nos logs do Task Manager (TM) de um job DataStream sem um stack trace detalhado?

A JVM omite stack traces para exceções lançadas frequentemente como uma otimização de desempenho. Adicione o seguinte flag em Other Configuration, dentro de Parameter Settings na aba Deployment Details para desativar esse comportamento:

env.java.opts: "-XX:-OmitStackTraceInFastThrow"

Acesse Operation Center > Job O&M, clique em no nome do job e localize Other Configuration em Parameter Settings na aba Deployment Details.

A métrica currentFetchEventTimeLag mostra um valor anormalmente alto após reinício do job com o conector Hologres

• Sintoma

  Após um job Flink que utiliza o conector Hologres reiniciar ou retomar a partir de um checkpoint, a métrica currentFetchEventTimeLag apresenta brevemente um pico extremamente alto (horas ou até dias) e depois retorna gradualmente ao normal.

• Causa

  A métrica currentFetchEventTimeLag é calculada como System.currentTimeMillis() - record.getBinlogTimestamp() / 1000. Essa métrica possui as seguintes características:

  • É um valor de snapshot transitório que não é persistido com checkpoints. Após o reinício do job, ela é redefinida para seu valor inicial de 0.

  • Ela é atualizada apenas quando registros de dados reais são consumidos. Registros de heartbeat não disparam atualização.

  Após o reinício do job, o conector Hologres retoma o consumo de binlog a partir da posição do último checkpoint. Operações internas do Hologres — como compactação, alterações de schema e manutenção de partições — podem produzir registros históricos de binlog com timestamps anteriores. Quando esses registros históricos são consumidos, a grande diferença entre a hora atual do sistema e o timestamp do registro causa o pico na métrica. A métrica volta ao normal após todos os dados históricos serem consumidos e o job alcançar os dados em tempo real.

• Solução

  Essa anomalia na métrica é um comportamento conhecido do conector Hologres durante reinícios de jobs e não afeta a correção do processamento de dados. Verifique se a magnitude do pico da métrica corresponde ao tempo de inatividade do job. A métrica retorna aos níveis normais depois que o job termina de consumir os dados históricos e alcança os dados em tempo real.