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 dependendo 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 de contêiner provêm do Managed Service for Prometheus. Para configurar a integração, consulte Container Observability.

• 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 Probe (Java Agent) version guide.

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 Trace analysis.

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.

A Host List lateral permite alternar entre hosts para visualizar dados de monitoramento. Os cartões de resumo mostram alterações percentuais dia a dia. Abaixo dos cartões, gráficos de tendência de séries temporais exibem Requests/1m, Errors/1m e Response Time/1m com granularidade de minutos. A página também inclui as abas JVM Monitoring, Host Monitoring e Trace Analysis.

Monitoramento da JVM

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

A seção de GC contém os gráficos Full GC Count/1m, Young GC Count/1m, Full GC Trigger Reason/1m e Young GC Trigger Reason/1m. A seção de memória inclui Memory Usage Distribution/1m, Heap Memory/1m, Heap Memory (used)/1m, entre outros. O painel lateral permite selecionar uma instância específica da aplicação para visualizar seus dados de monitoramento.

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 no topo 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 no topo da aba.

Monitoramento de 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:

A aba Container Monitoring mostra uma área de Visão Geral com Namespace, Cluster e métricas resumidas de CPU (cores) e Média/Máx/Últ/Limite de Memória. Abaixo, a área de Recursos contém os quatro gráficos de linha a seguir:

• Memory/Limit(%)

• Memory Usage

• CPU Usage(%)

• CPU Usage By Cores (com curvas user/system/total)

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 diferentes cenários. Para obter detalhes, consulte Trace analysis.

No console de Tracing, insira critérios de busca como serviceName: "mall-gateway" para consultar dados de trace. A página contém:

• Painel de filtro rápido à esquerda: filtre por Status, Duration (intervalo deslizante de 0ns–5s), Interface Name e Host Address.

• Gráficos estatísticos superiores: histograma de Call Count, histograma de Errors/HTTP Errors, gráfico de linha de Average Duration.

• Tabela de dados de Span inferior: as colunas incluem TraceId, Interface Name, Application Name, Duration, Status, Start Time, Host Address. Clique em Details ou Logs para visualizar detalhes do trace.

• Painel Slow Trace Analysis à direita: exibe os principais spanNames por contribuição de duração.

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 causar a 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 no Pod.

Por que algumas métricas de sistema estão ausentes, imprecisas ou mostrando 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 do probe.

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

O tamanho padrão do metaspace é de cerca de 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 o número de threads ativas por 1 MB (tamanho padrão da stack de thread). Se você definir um tamanho diferente de stack com -Xss, essa métrica pode 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 máximo de memória heap 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 máximo definido 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 executa 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 aciona 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 Thread pool and connection pool monitoring.

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 pools de threads ou conexões estão cheios, mas o monitoramento não mostra alteração?

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, cujo padrão é Integer.MAX_VALUE.

/**
 * Creates a new ScheduledThreadPoolExecutor with the given core pool size.
 * @param corePoolSize the number of threads to keep in the pool, even if they are idle,
 *        unless allowCoreThreadTimeOut is set
 * @throws IllegalArgumentException if corePoolSize < 0
 */
public ScheduledThreadPoolExecutor(int corePoolSize) {
    super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
            new DelayedWorkQueue());
}

/**
 * Creates a new ScheduledThreadPoolExecutor with the given initial parameters.
 * @param corePoolSize the number of threads to keep in the pool, even if they are idle,
 *        unless allowCoreThreadTimeOut is set
 * @param threadFactory the factory to use when the executor creates a new thread
 * @throws IllegalArgumentException if corePoolSize < 0
 * @throws NullPointerException if threadFactory is null
 */
public ScheduledThreadPoolExecutor(int corePoolSize,
                        ThreadFactory threadFactory) {
    super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
            new DelayedWorkQueue(), threadFactory);
}

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

Se múltiplas 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 várias 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 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 não é mais suportado. Esses frameworks criam um pool de conexões separado para cada domínio externo. Quando muitos domínios estão envolvidos, isso causa sobrecarga excessiva e riscos de estabilidade.

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

O ARMS exibe dados de monitoramento de contêineres apenas para recursos na mesma conta Alibaba Cloud. Verifique se a conta usada para criar o cluster ACK corresponde à conta usada 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?

Isso 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 Upgrade the ARMS agent.

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 usa 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 o ARMS cobre, consulte JVM monitoring memory details.

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 tem 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 executarem a mesma versão.