[Upgrade] ARMS Application Monitoring Agent 4.x - Application Real-Time Monitoring Service: Central de Documentação do Alibaba Cloud

As versões 4.x e posteriores do agente de Monitoramento de Aplicações do ARMS baseiam-se no OpenTelemetry Java Agent e adotam totalmente os padrões open-source. Embora ofereçam paridade completa de recursos com as versões anteriores, algumas funcionalidades sofreram pequenos ajustes. Este tópico descreve essas alterações, seus possíveis impactos e explica por que o volume de dados reportados pode aumentar.

Alterações e impactos

Por padrão, a instrumentação de métodos para beans gerenciados pelo Spring está desativada. O agente agora instrumenta apenas métodos de controller.

Riscos potenciais:
- Após a atualização, os métodos em classes anotadas com @Service ou @Component não aparecerão mais nos traces.
- Exceções lançadas por métodos em classes anotadas com @Service ou @Component não serão capturadas.
Os nomes das métricas de monitoramento de pool de threads e de pool de conexões foram alterados. Para obter detalhes, consulte Monitoramento de pool de threads e pool de conexões.

Riscos potenciais:
- Se você configurou regras de alerta para monitoramento de pool de threads no Monitoramento de Aplicações, configure-as novamente.
  
  Na página Crie Regra de Alerta de Monitoramento de Aplicações, defina Metric Type como Thread_Pool_Version_2.
- Painéis personalizados que utilizam métricas de pool de threads deixarão de exibir dados.
- O aumento no volume de métricas pode elevar os custos de pagamento conforme o uso.
A métrica de monitoramento de atraso de mensagens foi renomeada para arms_mq_delay_seconds.

Risco potencial: painéis personalizados que utilizam essa métrica deixarão de exibir dados.
O agente agora propaga automaticamente o contexto de trace para chamadas assíncronas, eliminando a necessidade de configurar nomes de pacotes.
Não é mais necessário definir consumers personalizados para RabbitMQ ou métodos de consumo personalizados para Kafka. As definições existentes permanecem inalteradas.
A obtenção do ID de trace por meio de MDC.get("EagleEye-TraceID") não é mais suportada. No entanto, a correlação entre log e ID de trace permanece inalterada.

Risco potencial: o ID de trace recuperado via MDC.get("EagleEye-TraceID") retornará null.
Chamadas internas sem ponto de entrada agora geram um span.

Risco potencial: o aumento na quantidade de spans pode elevar os custos de pagamento conforme o uso.
O agente agora calcula estatísticas de quantil usando um método de distribuição de buckets baseado em interpolação linear, substituindo o algoritmo anterior baseado em Prometheus Summary.

Risco potencial: as métricas de quantil podem perder precisão se a distribuição real de duração diferir significativamente do bucketing atual.
O SpanStatus agora segue o padrão OpenTelemetry. Nesse padrão, requisições HTTP com código de resposta 4xx ou 5xx são marcadas como error. Todos os demais casos são marcados como unset. Versões anteriores do agente marcavam esses outros casos como ok.
Após a atualização para o agente 4.x, o ID de trace deve ter 32 caracteres. Esse formato é incompatível com o recurso legado de Monitoramento de Navegador. Recomendamos a integração com o novo serviço de Monitoramento de Usuário Real.
Versões do agente até a 4.1.12 não são compatíveis com o recurso de virtual threads do JDK 21. A compatibilidade total está planejada para a versão 4.3.x. Se sua aplicação depende fortemente de virtual threads, recomendamos manter uma versão 3.x do agente.
Em aplicações que usam arms-sdk para adicionar baggage por meio de um filtro spring-cloud-gateway, a propagação de baggage falha ao atualizar para o agente 4.2.x e ative o plugin spring-bean na configuração personalizada.

Aumento no reporte de dados na versão 4.x

Ao atualizar de um agente 3.x para um agente 4.x, você pode notar um aumento no volume de métricas reportadas em determinados cenários. Esse aumento ocorre devido às seguintes alterações:

O agente agora cria spans para chamadas internas sem ponto de entrada, aumentando a quantidade de spans e métricas reportados.
O suporte a mais pools de threads personalizados no monitoramento de pool de threads elevou o número de métricas reportadas.
O suporte a mais tipos de pool de conexões no monitoramento de pool de conexões aumentou o volume de métricas reportadas.
Para chamadas assíncronas, a quantidade de métricas upstream e downstream aumentou porque o agente 4.x propaga automaticamente o contexto de trace.
O suporte ampliado a plugins, como a instrumentação estendida para Lettuce, resultou em maior volume de métricas reportadas.
Para melhorar o desempenho do profiling de threads em aplicações com alta contagem de threads, o agente 4.x ajustou a coleta e o armazenamento de dados. Em comparação com o agente 3.x, a ativação do profiling de threads agora reporta um pequeno conjunto adicional de métricas com o prefixo arms_grouped_thread. Para desativar esse recurso, consulte Profiling de Threads.
No consumo em lote de mensagens em uma fila de mensagens (MQ), o agente agora cria um span separado para cada mensagem do lote, em vez de um único span para todo o lote. Isso pode aumentar significativamente o número de spans reportados quando os lotes contêm muitas mensagens. Trata-se de uma alteração intencional que fornece dados mais granulares. Caso o volume de dados seja uma preocupação, considere ajustar a taxa de amostragem ou desativar o plugin MQ correspondente.