Application Real-Time Monitoring Service:Serviços Fornecidos

O que é trace upstream para uma chamada de API?

Refere-se à quantidade de vezes que aplicações upstream chamam esta aplicação. Os registros aparecem apenas se a aplicação upstream tiver um probe do ARMS instalado. Caso a aplicação upstream não possua um probe, nenhum registro será exibido. Autochamadas da aplicação também aparecem como upstream.

Algumas APIs sem endpoint de ingestão upstream

Se uma interface realmente possui chamadas upstream, mas essas aplicações upstream não possuem probes do ARMS, as chamadas upstream não aparecerão.

Upstream e downstream do link confundidos

Se o seu trace utiliza componentes SkyWalking, todo o trace usa o protocolo SkyWalking por padrão. O ARMS apresentou problemas no suporte ao protocolo SkyWalking antes da versão 4.2.x, causando falhas na identificação de upstream/downstream. Atualize para a versão 4.2.x ou posterior ou, na página Custom Configuration, em Trace Context Propagation Protocol Settings, force o uso de um protocolo não-SkyWalking para propagação de contexto de trace. Para instruções, consulte Trace Context Propagation Protocol Settings.

A contagem de erros da interface Dubbo não é zero, mas nenhum trace é encontrado

Em versões de probe anteriores a 3.2.x, os traces do Dubbo não registravam corretamente os códigos de status, impedindo a aparição de traces de erro. Esse problema foi corrigido na versão 3.2.x e posteriores.

A contagem de exceções não é zero nas chamadas de API, mas nenhum trace de exceção aparece na busca de traces

Antes da versão 4.1.x, os probes registravam apenas traces de erro e lentos, portanto exceções sem erros ou lentidão podiam não ser amostradas. A partir da versão 4.1.x, os probes amostram traces de erro, lentos e de exceção, de modo que as exceções agora acionam a amostragem.

Por que o tráfego da interface caiu?

Primeiro, confirme se o tráfego realmente caiu verificando o uso de CPU, I/O de rede e outras métricas no momento da queda:

• Em caso afirmativo, geralmente trata-se de uma queda no tráfego real.

• Caso contrário, podem existir problemas no lado do servidor do ARMS. Nesse cenário, abra um ticket para obter assistência.

O tráfego de monitoramento do Spring Cloud Gateway está impreciso

Versões de probe anteriores a 4.x apresentavam bugs na instrumentação do Spring Cloud Gateway, causando perda de tráfego em alguns cenários. Atualize para a versão de probe 4.x ou posterior.

É possível visualizar instruções SQL lentas para uma interface?

O que significam os pontos amarelos antes das interfaces no Legacy Console?

Passe o mouse sobre um ponto para ver seu significado.

• Um ponto amarelo indica uma chamada lenta. Por padrão, requisições que levam mais de 500 ms são marcadas como lentas. Ajuste esse limiar na seção Interface Call Configuration da página Custom Configuration.

• Um ponto vermelho indica um erro.

Por que alguns códigos de status 5xx não são coletados?

Conforme a RFC7231, códigos de status como 502 e 504 são gerados por gateways e não refletem necessariamente a resposta real do service chamado. Se o gateway não tiver monitoramento ARMS, mas o service de backend possuir, essas respostas 5xx não serão contabilizadas.

O que é NetWork And Dubbo Response Decode?

É um span que mede o tempo gasto na desserialização de dados da camada de transporte do Dubbo.

Por que os nomes das interfaces contêm * ou palavras-chave do ARMS?

Isso ocorre quando os nomes das interfaces são altamente variáveis. O ARMS converge interfaces semelhantes substituindo as partes diferentes. Para detalhes, consulte ARMS Convergence Mechanism.

Por que a duração da chamada externa difere da duração real do service downstream?

A duração no lado do servidor mede apenas o tempo em que a interface processa a requisição. A duração no lado do cliente inclui o estabelecimento de conexão e o tempo de rede. O console do ARMS mostra ambas as durações separadamente, mas o tempo relacionado à rede não pode ser determinado com precisão.

A interface retorna normalmente, mas a contagem de exceções de chamada única não é zero

Esse comportamento é esperado. Alguns frameworks (como OkHttp3) lançam internamente exceções que são capturadas externamente, mantendo a lógica de negócios normal. Como o ARMS instrumenta esses frameworks, ele registra essas exceções — mas elas não indicam problemas reais de negócios. Você decide se deve tratá-las. Essas estatísticas ignoram detalhes da mensagem de exceção. Para ver a mensagem real da exceção, clique em um trace da exceção e depois clique em ícone ao lado da interface para visualizar a exceção na pilha de métodos.

Nomes de interface HTTP como /error, /404, /*, /**

Geralmente resultam de requisições inesperadas que o ARMS não consegue associar a uma rota. As causas comuns incluem:

• Requisição de uma URL inexistente.

• Cabeçalhos de requisição inválidos causando falhas de validação, como cabeçalhos contendo caracteres inválidos.

• Uso de servidores HTTP sem mecanismos de roteamento, como Netty puro.

Por que as contagens de requisições nas chamadas de interface diferem das da análise de trace?

A análise de trace baseia-se em dados de trace e é afetada pela taxa de amostragem.

Por que os tempos de resposta quantílicos diferem entre os detalhes da interface e a análise de trace?

Os detalhes da interface calculam quantis por instância usando algoritmos de bucketing. A análise de trace calcula quantis a partir de spans amostrados para a interface. Portanto, os valores diferem. Para detalhes, consulte ARMS Quantile Metric Calculation Principles.

Volume de chamadas de API aproximadamente dobrou

Isso geralmente acontece se os probes 3.x e 4.x forem anexados acidentalmente durante uma atualização. Acesse Application Configuration > Agent Management, selecione qualquer probe e clique em View Details para verificar os parâmetros da JVM.

Dois parâmetros -javaagent indicam que ambos os probes 3.x e 4.x estão anexados.

Por exemplo, o probe 3.x usa -javaagent:/home/admin/.opt/ArmsAgent/arms-bootstrap-1.7.0-SNAPSHOT.jar, enquanto o probe 4.x usa -javaagent:/srv/ArmsAgent/aliyun-java-agent.jar.

Por que o volume de chamadas no console do ARMS difere de outras fontes?

Discrepâncias podem surgir de várias maneiras. Dois cenários comuns:

• O ARMS mostra 500 chamadas/minuto para uma interface de aplicação, enquanto o Nginx mostra 200/minuto. Isso frequentemente significa que parte do tráfego ignora o Nginx e acessa a aplicação diretamente.

• O ARMS mostra 400 acessos ao DB/minuto a partir de uma aplicação, enquanto o monitoramento do servidor de DB mostra 1.000 execuções/minuto. Isso geralmente significa que múltiplas aplicações acessam o mesmo DB; o ARMS mostra apenas o tráfego da aplicação especificada.

Qual é o suporte do ARMS para cenários WebFlux?

Probes anteriores à versão 4.x suportam apenas Spring WebFlux nativo e spring-cloud-gateway. Modificações personalizadas de WebHandler (como Apache Shenyu) não são suportadas.

Por que vejo aplicações upstream que não são minhas e por que não consigo visualizar seus detalhes?

Se essas aplicações fornecem serviços públicos, isso é normal. A aplicação upstream pertence a outro usuário, criando uma relação de chamada entre usuários. O ARMS registra o nome da aplicação upstream e a contagem de chamadas, mas devido ao isolamento de usuários, você não consegue visualizar os detalhes da aplicação do outro usuário.

Por que não vejo dados upstream/downstream esperados apesar de existirem relações claras de chamada?

O ARMS inspeciona aleatoriamente traces de usuários e verifica o campo trace.protocol.type no LocalRootSpan. Se o valor for Jager, problemas de conversão de maiúsculas/minúsculas causam falhas na identificação de upstream/downstream. Para corrigir isso, switch to another protocol ou abra um ticket.

Na página Trace Details, selecione LocalRootSpan e verifique o campo trace.protocol.type em Additional Information à direita. Um exemplo de valor normal é EagleEye.