Application Real-Time Monitoring Service:Instance monitoring for Java applications

Métricas por ambiente

As métricas disponíveis variam conforme a execução da aplicação em ECS ou em contêineres e dependem também da integração do ambiente de contêineres com o Managed Service for Prometheus.

Métricas dos gráficos de tendência

Em ambientes ECS, use a lista suspensa ao lado do título de cada gráfico de infraestrutura para alternar entre valores médios e máximos.

Nos gráficos de GC, alterne entre contagem de GC e duração média do GC. Nos gráficos de memória da JVM, alterne entre visualizações de memória heap e non-heap.

Colunas da lista de instâncias

No ambiente Contêiner (Prometheus), os campos de utilização de CPU, memória e disco exibem - quando nenhum limite está definido para o recurso.

Requisitos para ambiente de contêineres

• Com Managed Service for Prometheus: As métricas do contêiner provêm do Managed Service for Prometheus. Para configurar a integração, consulte Observabilidade de contêineres.

• Sem Managed Service for Prometheus: Atualize o probe do Application Monitoring para a versão 4.1.0 ou posterior. Versões anteriores do probe não reportam métricas básicas de contêiner. Para obter detalhes sobre versões do probe, consulte Guia de versão do Probe (Java Agent).

Interações com gráficos

Cada gráfico de tendência oferece duas ações:

• Clique em para visualizar estatísticas de métricas em um intervalo de tempo ou comparar o mesmo período em datas diferentes.

• Clique em para alternar entre gráficos de colunas e gráficos de tendência.

Ações na lista de instâncias

• Clique no IP de uma instância (ou em Details na coluna Actions para ambientes de contêiner) para abrir os detalhes da instância.

• Clique em Trace na coluna Actions para visualizar detalhes do trace. Para mais informações, consulte Análise de traces.

Visão geral

A aba Overview exibe a contagem de requisições, contagem de erros, tempo médio de resposta e informações de chamadas lentas para a interface selecionada.

Monitoramento da JVM

A aba JVM Monitoring apresenta métricas de GC, memória, threads e descritores de arquivo da instância selecionada.

Monitoramento de pool de threads

O monitoramento de pool de threads rastreia a configuração de threads principais, o status de threads ativas e métricas de execução de tarefas. Filtre os pools de threads por tipo e nome na parte superior da aba.

Monitoramento de pool de conexões

O monitoramento de pool de conexões rastreia a configuração de inicialização e o status das conexões em tempo de execução. Filtre os pools de conexões por tipo na parte superior da aba.

Monitoramento do host

A aba Host Monitoring exibe métricas de CPU, memória, disco, carga, tráfego de rede e pacotes de rede.

Monitoramento de contêineres

A aba Container Monitoring apresenta métricas de recursos no nível do contêiner. As métricas disponíveis dependem do método de integração:

Análise de traces

A análise de traces consulta dados armazenados em tempo real. Combine filtros e dimensões de agregação para diagnosticar problemas de desempenho em diversos cenários. Para obter detalhes, consulte Análise de traces.

Por que o tráfego está desigual entre as instâncias?

Na versão 3.x do probe, ativar a otimização de memória pode resultar na perda de algumas métricas. Atualize para a versão 4.x do probe.

Por que uma única requisição do Undertow é contada duas vezes?

Em versões do probe anteriores a 3.2.x, a instrumentação do DeferredResult faz com que uma chamada seja registrada duas vezes. Atualize para a versão 3.2.x ou posterior do probe.

Por que as cotas de CPU ou memória no Monitoramento de Contêineres não correspondem às configurações do Pod?

Verifique se o Pod define múltiplos contêineres. Essa métrica representa a soma das cotas de todos os contêineres presentes no Pod.

Por que algumas métricas de sistema estão ausentes, imprecisas ou mostram 100% de uso de CPU?

Versões do probe anteriores a 4.x não coletam métricas de sistema no Windows. Atualize para a versão 4.x ou posterior.

Por que ocorre Full GC logo após a inicialização da aplicação?

O tamanho padrão do metaspace é de aproximadamente 20 MB. Durante a inicialização, a expansão do metaspace aciona o Full GC. Defina os tamanhos inicial e máximo do metaspace usando os parâmetros -XX:MetaspaceSize e -XX:MaxMetaspaceSize.

Como a VM Stack é calculada?

A VM Stack é calculada multiplicando-se o número de threads ativas por 1 MB (tamanho padrão da pilha de threads). Se você definir um tamanho de pilha diferente com -Xss, essa métrica poderá não corresponder ao valor real.

Como as métricas da JVM são coletadas?

O ARMS obtém métricas da JVM usando interfaces padrão do JDK.

Métricas de memória:

• ManagementFactory.getMemoryPoolMXBeans

• java.lang.management.MemoryPoolMXBean#getUsage

Métricas de GC (probe anterior a 4.4.0):

• ManagementFactory.getGarbageCollectorMXBeans

• GarbageCollectorMXBean#getCollectionCount

• GarbageCollectorMXBean#getCollectionTime

Métricas de GC (probe 4.4.0 ou posterior):

Obtidas através da assinatura do evento GarbageCollectionNotificationInfo do GarbageCollectorMXBean.

Por que o valor da memória heap máxima da JVM é -1?

Um valor de -1 indica que o tamanho máximo do heap não foi configurado. Defina-o usando o parâmetro -Xmx.

Por que o uso de memória heap da JVM não é igual ao tamanho máximo da memória heap?

O parâmetro -Xms define o tamanho inicial do heap. A JVM expande o heap conforme necessário, até o limite máximo estabelecido por -Xmx. Uma discrepância significa que o heap ainda não se expandiu totalmente.

Por que a frequência de GC da JVM aumenta gradualmente?

Isso geralmente ocorre com o ParallelGC, algoritmo padrão de GC no JDK 8. O ParallelGC ativa -XX:+UseAdaptiveSizePolicy por padrão, ajustando dinamicamente o dimensionamento do heap. Quando o Young GC é executado frequentemente, o espaço survivor pode encolher, fazendo com que objetos sejam promovidos para a geração antiga mais rapidamente. Isso acelera o crescimento da geração antiga e dispara Full GCs mais frequentes. Para obter detalhes, consulte a documentação de Ergonomia de GC do Java.

Por que não há dados para monitoramento de pool de threads ou pool de conexões?

1. Na página Custom Configuration, em Advanced Settings, confirme se o monitoramento de pool de threads e pool de conexões está ativado.

2. Verifique se o framework é suportado. Consulte Monitoramento de pool de threads e pool de conexões.

Por que a contagem máxima de conexões do HikariCP não corresponde ao esperado?

Versões do probe anteriores a 3.2.x recuperam incorretamente a contagem máxima de conexões. Atualize para a versão 3.2.x ou posterior do probe.

Por que as métricas de monitoramento de pooling aparecem como valores decimais?

O probe coleta dados a cada 15 segundos. O console exibe a média durante o intervalo de tempo selecionado. Por exemplo, se quatro pontos de dados em um minuto forem 0, 0, 1 e 0, o valor exibido será 0,25.

Por que os pools de threads ou conexões estão cheios, mas o monitoramento não mostra alterações?

O ARMS coleta métricas de pool de threads e pool de conexões a cada 15 segundos. Picos de curta duração dentro desse intervalo podem não ser capturados.

Por que a contagem máxima de threads do pool é inesperada ou mostra 2,1 bilhões?

O ARMS lê a contagem máxima de threads diretamente do objeto do pool de threads. Um valor de 2,1 bilhões normalmente indica um pool de threads agendados (scheduled thread pool), cujo padrão é Integer.MAX_VALUE.

Por que as métricas do pool de threads do Tomcat não correspondem ao esperado?

Se várias métricas (contagem máxima de threads, contagem de threads ativas, contagem de threads principais) diferirem dos valores esperados, verifique se a aplicação expõe serviços do Tomcat em múltiplas portas. Por exemplo, o Spring Actuator abre uma porta extra para métricas. Nesse caso, o ARMS pode mesclar métricas de vários pools de threads devido à convergência de dimensões.

Para corrigir isso, atualize para a versão 4.1.10 ou posterior do probe. Em seguida, acesse Application Configuration > Custom Configuration > Pooling Monitoring Configuration e defina Thread Pool Thread Name Pattern Extraction Strategy como Replace trailing digits with *.

Por que não há dados para um pool de threads ou conexões antes de um determinado horário?

Isso ocorre quando uma tarefa agendada cria o pool. Os dados aparecem somente após a tarefa inicializar o pool. Métricas baseadas em tráfego, como contagens de requisições de API, comportam-se de maneira similar.

Por que não há dados para pools de conexões do HttpClient?

A partir da versão 4.x do probe do ARMS, o monitoramento de pool de conexões para OkHttp3 e Apache HttpClient deixou de ser suportado. Esses frameworks criam um pool de conexões separado para cada domínio externo. Quando muitos domínios estão envolvidos, isso gera sobrecarga excessiva e riscos à estabilidade.

Por que não há dados de monitoramento de contêiner após integrar uma aplicação ACK?

O ARMS exibe dados de monitoramento de contêiner apenas para recursos sob a mesma conta da Alibaba Cloud. Verifique se a conta usada para criar o cluster ACK corresponde à conta utilizada para a integração com o ARMS.

Por que a taxa de abertura de handles de arquivo é diferente de zero, mas a contagem de handles é zero?

Esse cenário ocorre no JDK 9 ou posterior ao usar a versão 3.x do probe do ARMS. Atualize para a versão 4.2.2 ou posterior do probe. Consulte Atualizar o agente do ARMS.

Por que o uso de memória física do processo JVM difere significativamente do uso de memória heap no monitoramento da JVM?

Provavelmente o processo JVM está utilizando uma quantidade significativa de memória off-heap, que o ARMS não monitora completamente. Para obter detalhes sobre quais áreas de memória da JVM são cobertas pelo ARMS, consulte Detalhes de memória do monitoramento da JVM.

Por que o Druid mostra mais conexões ociosas do que a configuração máxima de conexões ociosas?

O parâmetro MaxIdle no Druid existe apenas para compatibilidade de migração do DBCP. Ele não possui efeito funcional.

Por que não há dados após atualizar algumas instâncias para a versão mais recente do probe?

Ao atualizar de uma versão do probe anterior a 4.1.x, todas as instâncias devem ser atualizadas. A página se adapta automaticamente depois que todas as instâncias estiverem executando a mesma versão.