APM em produção: como monitorar performance de aplicações além das métricas básicas

O limite das métricas de infraestrutura

Monitorar CPU, memória, disco e rede é necessário mas insuficiente. Quando um usuário reclama que a página de checkout demora 8 segundos, saber que o CPU está em 40% não ajuda a resolver o problema. Application Performance Monitoring (APM) preenche essa lacuna: instrumenta a aplicação para capturar quanto tempo cada transação leva, onde esse tempo é gasto (banco de dados, chamadas externas, processamento interno) e como a performance varia por endpoint, por usuário e por versão de código.

O que APM revela que métricas básicas não mostram

• Rastreamento de transações lentas — identificar os endpoints mais lentos com percentil 95 e 99, não apenas média. Médias mascaram usuários com experiência degradada.
• Profiling de queries de banco de dados — qual percentual do tempo de cada requisição vai para banco? Quais queries específicas são responsáveis? N+1 queries são um dos padrões mais comuns de degradação silenciosa.
• Dependências externas — chamadas a APIs de terceiros, serviços de pagamento, provedores de notificação. Quanto tempo e qual taxa de erro cada dependência contribui?
• Análise de erros por deploy — correlacionar aumento de taxa de erro com deploy específico permite diagnóstico rápido de regressões.
• Gargalos de código — hot paths em código de aplicação que consomem tempo desproporcional por chamada.

Ferramentas de APM: do gerenciado ao open source

• Datadog APM — solução gerenciada com integração automática para a maioria dos frameworks populares. Distributed tracing, profiling contínuo e correlação automática com logs e métricas de infraestrutura. O custo escala com volume de dados ingeridos.
• New Relic — alternativa ao Datadog com pricing diferente (baseado em usuários para o plano base, não apenas em dados). Forte em análise de experiência do usuário final com RUM integrado.
• Elastic APM — componente do Elastic Stack (open source com versão gerenciada). Se a stack já usa Elasticsearch para logs, APM se integra naturalmente sem custo adicional de ferramenta.
• OpenTelemetry + Jaeger/Tempo — para times que não querem vendor lock-in. OpenTelemetry é o padrão open source neutro de instrumentação (traces, metrics, logs). Dados podem ser enviados para qualquer backend compatível. Grafana Tempo como backend de traces open source é a combinação mais adotada.

Profiling contínuo em produção

Profiling tradicional (pprof, async-profiler) é executado manualmente quando há suspeita de problema. Profiling contínuo coleta amostras de stack trace de forma permanente em produção, com overhead baixo (1-5% de CPU), permitindo análise retrospectiva de uso de CPU e memória para qualquer período.

Datadog Continuous Profiler, Pyroscope (open source) e Grafana Pyroscope são as opções disponíveis. O caso de uso principal: quando uma transação ficou lenta na semana passada e você quer entender o que estava acontecendo no código naquele momento específico, sem ter que reproduzir.

Estabelecendo SLOs com dados de APM

APM é a fonte de dados para definir e monitorar SLOs (Service Level Objectives) de performance: "99% das requisições de checkout devem completar em menos de 2 segundos". Sem APM, essa métrica é uma aspiração. Com APM, é um número monitorado em tempo real com alertas automáticos quando degrada.