Application Real-Time Monitoring Service:Dependências

Por que as chamadas de banco de dados não apresentam dados?

Existem duas causas comuns:

• O ARMS não suporta o banco de dados. Verifique a lista de componentes suportados.

• O agente do ARMS é anterior à versão v4.x, que não suporta bancos de dados chamados de forma assíncrona ou sem um ponto de entrada.

Por que o ARMS mostra chamadas lentas de banco de dados que o servidor de banco de dados não relata?

O ARMS mede a duração no lado do cliente — todo o ciclo completo, desde o momento em que a aplicação envia a requisição, passando pela transmissão de rede e processamento no servidor, até a chegada da resposta. Pausas para coleta de lixo (garbage collection) e latência de rede podem inflar esses números além do que o servidor de banco de dados registra.

O ARMS também utiliza seu próprio Slow SQL Threshold (padrão: 500 ms), configurado na página Custom Configuration. Esse limiar pode diferir das configurações do servidor de banco de dados.

Por que o volume de chamadas de banco de dados no ARMS difere dos dados de monitoramento do servidor de banco de dados?

O ARMS exibe apenas o volume de chamadas da aplicação atualmente monitorada. Se várias aplicações acessarem o mesmo banco de dados, o ARMS não agregará o tráfego delas.

Por que algumas chamadas externas não são registradas?

Isso geralmente afeta o agente 3.x, por dois motivos:

• Sem ponto de entrada: O agente 3.x captura apenas chamadas externas executadas dentro do fluxo de processamento de interfaces HTTP, interfaces RPC, tarefas agendadas e consumo de mensagens. Chamadas externas acionadas diretamente por meio de um pool de threads em um agendamento não são capturadas.

• Troca de threads: O agente 3.x não suporta propagação automática de contexto assíncrono. Se a chamada externa real for executada em uma thread diferente, não haverá contexto de trace após a troca, e a chamada será ignorada.

Ambos os problemas são resolvidos ao atualizar o agente para a versão v4.x.

Por que as chamadas externas mostram dados "undefined"?

As versões 3.1.x e anteriores do agente possuem um defeito na instrumentação do Dubbo que impede a captura do endereço IP do par. Isso foi corrigido na versão v3.2.x.

Por que as chaves de chamadas Redis exibem texto corrompido?

Um problema de instrumentação do framework Lettuce causa valores de chave incorretos. A parte corrompida pode ser ignorada — as partes restantes são válidas.

Por que não há dados ao navegar de uma instrução SQL para o Trace Explorer?

Por padrão, o agente do ARMS compacta spans para reduzir o volume de dados. Quando vários spans filhos de um span pai compartilham o mesmo SpanName, apenas um span filho é retido. Os atributos desse span registram a contagem, a duração total e a duração mínima/máxima dos spans compactados. Instruções SQL em spans compactados não podem ser consultadas na página Trace Explorer.

Para resolver isso, desative a compactação de traces.

Qual é a diferença entre os dados da página de Publicação de Mensagens e os dados de monitoramento da instância de fila de mensagens?

As páginas Message Subscription e Message Publishing mostram métricas de desempenho sob a perspectiva do cliente — como a aplicação selecionada se comporta como consumidora ou produtora. Já o painel de monitoramento da instância de fila de mensagens exibe métricas no nível do tópico sob a perspectiva do servidor.

Quais são os formatos de SpanName para envio e recebimento de mensagens?

O agente do ARMS para Java suporta Spring Cloud Alibaba RocketMQ?

Sim, a partir do agente v4.x. Se o seu agente for anterior à v4.x, atualize-o.

O que significa a métrica "Message Delay"?

O atraso da mensagem é o tempo total desde a produção até o consumo da mensagem, medido em milissegundos (ms). Essa métrica é suportada apenas para RocketMQ Client e ONS Client.

Por que a aplicação possui lógica de consumidor, mas não há dados de trace ou métricas de consumidor?

Provavelmente o agente é anterior à v4.x e expressões lambda definem a lógica de consumo dentro do messageListener. Devido a falhas no aprimoramento de classes para expressões lambda nas versões 2.x e 3.x do agente, a lógica de consumo não pode ser instrumentada.

Atualize o agente para a versão v4.x para resolver isso.

Por que recebi um erro "Magic v1 does not support record headers" com Kafka?

O agente do ARMS passa o contexto de trace através do campo Header da mensagem Kafka. Versões do Kafka anteriores a 0.11.0.0 (tanto Client quanto Broker) não suportam campos Header.

Migre para o Kafka 0.11.0.0 ou posterior. Se a migração imediata não for possível:

• Agente anterior à v4.x: Desative a opção kafka-plugin na seção Probe switch settings da aba Custom Configuration.

• Agente v4.x e posterior: Adicione o parâmetro JVM -Dotel.instrumentation.kafka.producer-propagation.enabled=false ao iniciar o serviço.

Por que os traces não têm spans para envio ou recebimento de mensagens?

1. Verifique se o SDK do cliente de fila de mensagens usado pelas suas aplicações produtora e consumidora é suportado pelo ARMS. Consulte Componentes e frameworks Java suportados pelo ARMS.

2. Confirme se tanto a aplicação produtora quanto a consumidora são monitoradas pelo Application Monitoring ou Managed Service for OpenTelemetry, com as opções de agente e plugin ativadas, e se ambas reportam para a mesma região. Spans de envio de mensagens são gerados pelo produtor, e spans de recebimento são gerados pelo consumidor. Se uma aplicação não estiver devidamente monitorada, os spans correspondentes estarão ausentes.

3. Se os spans de envio de mensagens estiverem ausentes, verifique a versão do agente da aplicação produtora. Em versões do agente anteriores à v4.x, o envio de uma mensagem não cria um span separado. Em vez disso, ele é registrado na pilha de métodos do span pai. Clique no ícone à direita do span pai para visualizar a pilha real do método de chamada.

   

4. Se os spans de recebimento de mensagens estiverem ausentes, verifique se a opção Invalid Interface Filter está ativada na seção Interface Call Configurations da aba Custom Configuration. Essa opção filtra spans que não são relevantes.

Por que há uma grande diferença nos tempos de resposta do Kafka entre o agente v4.x e versões anteriores?

No agente v3.x e anteriores, um lote BatchMessageListener é contado como uma única chamada com todas as durações agregadas. No agente v4.x, cada mensagem é contada individualmente.

Após atualizar da v3.x para a v4.x, a duração relatada por chamada diminui enquanto a contagem de chamadas aumenta proporcionalmente. Esse comportamento é esperado — a v4.x fornece métricas por mensagem mais precisas.