O que é APM e como ele ajuda a identificar lentidão nas aplicações?

Como o APM coleta os dados?

A coleta é feita por instrumentação. Um agente ou uma biblioteca é instalado junto à aplicação e registra o que acontece em cada requisição: quanto tempo cada função levou, quais consultas foram feitas ao banco de dados e quais serviços externos foram chamados.

Em linguagens como Java, .NET, Node.js e Python, boa parte disso acontece de forma automática. A instrumentação manual entra quando a equipe quer medir uma etapa específica do negócio, como o cálculo de frete ou a emissão de uma nota fiscal.

Cada requisição gera um trace, formado por spans, que são os trechos de trabalho. Quando a aplicação é dividida em vários serviços, o trace acompanha a requisição entre eles, o que se chama rastreamento distribuído. O OpenTelemetry (OTel) é um padrão aberto para essa coleta e reduz a dependência de um único fornecedor.

Instrumentar tem custo. O agente consome um pouco de recurso, e o volume de dados pode encarecer a ferramenta. Por isso as soluções usam amostragem, guardando só parte dos traces, de preferência os lentos e os que terminaram em erro.

Quais indicadores acompanhar?

Três medidas formam a base e são conhecidas pelo método RED:

• Taxa (rate): quantas requisições a aplicação recebe por segundo ou por minuto.
• Erros (errors): quantas dessas requisições falham.
• Duração (duration): quanto tempo elas levam.

Na duração, a média engana. Se a maioria das requisições responde rápido e uma parte demora muito, a média parece aceitável enquanto alguns usuários sofrem. Por isso as equipes olham percentis: o p95 indica o tempo abaixo do qual estão 95% das requisições, e o p99 mostra o comportamento das mais lentas.

Algumas ferramentas usam também o Apdex (Application Performance Index), uma nota de 0 a 1 que resume a satisfação com base em um tempo de resposta considerado aceitável. Mais útil ainda é medir separadamente as transações que importam para o negócio, como login, busca, fechamento de pedido e emissão de nota, em vez de olhar só a média da aplicação inteira.

Como fica uma investigação com APM na prática?

Imagine que os vendedores reclamam que o fechamento de pedidos no sistema comercial fica lento perto do fim do mês. Os servidores mostram CPU e memória dentro do normal, e a primeira suspeita recai sobre a rede.

No APM, a equipe filtra a transação de fechamento de pedido e compara o período lento com uma semana tranquila. O trace mostra que a maior parte do tempo está em uma consulta ao banco de dados executada uma vez para cada item do pedido. Com poucos itens, ninguém percebe. Nos pedidos grandes do fim do mês, a mesma consulta roda centenas de vezes.

Com essa evidência, o desenvolvimento ajusta o código para buscar todos os itens de uma só vez, e a correção é validada no próprio APM, comparando a duração antes e depois. Sem a ferramenta, a investigação provavelmente começaria pela troca do link ou pelo aumento do servidor, sem atacar a causa.

APM, RUM e monitoramento sintético: qual a diferença?

O APM observa a aplicação do lado do servidor. Ele mostra o que acontece depois que a requisição chega, mas não enxerga tudo o que o usuário vive no navegador ou no celular.

• RUM (Real User Monitoring) mede a experiência real de quem usa o sistema: tempo de carregamento das páginas, erros no navegador e desempenho por região ou tipo de dispositivo.
• Monitoramento sintético executa testes automáticos em intervalos definidos, simulando um usuário que faz login ou conclui uma compra. Detecta falhas mesmo de madrugada, quando ninguém está usando o sistema.

As três abordagens se complementam. O sintético avisa que o login parou, o RUM mostra quantos usuários foram afetados e o APM aponta em qual componente está o problema.