Um comprador em Frankfurt clica em Pagar e assiste a um spinner por dez segundos antes de desistir. Seu painel APM permanece verde o tempo todo. Nenhuma exceção foi disparada, nenhuma stack trace foi capturada, porque nada no seu código falhou. O script do provedor de pagamento travou, a página nunca terminou de renderizar, e o pedido foi perdido. Seu backend nem sequer viu a requisição final do checkout, então não há transação falhada para inspecionar: do ponto de vista da aplicação, nada aconteceu. Do ponto de vista do usuário, a única etapa que importava falhou.
Esse é o ponto cego sobre o qual este artigo trata. O monitoramento de stack trace é realmente bom no que faz: quando seu código gera um erro, ele entrega aos desenvolvedores o arquivo, a linha e a cadeia de chamadas que levaram até lá. O problema é o que ele não consegue ver estruturalmente. Uma classe inteira de falhas visíveis ao usuário acontece antes que uma requisição alcance seu código, depois que sua resposta sai dele ou sem que nenhuma exceção seja disparada.
Aqui está o que o monitoramento de stack trace captura bem, as cinco lacunas que ele deixa na medição da experiência do usuário e como o monitoramento sintético em navegador real cobre o território que ele não consegue.
O Que É Monitoramento de Stack Trace?
Um stack trace é um instantâneo da pilha de chamadas no momento em que um erro ocorre: quais funções estavam executando, em quais arquivos, em quais números de linha e em que ordem foram chamadas. Se você já viu um erro no console listando uma cascata de métodos e caminhos de arquivos, você leu um.
O monitoramento de stack trace, como praticado por ferramentas de monitoramento de desempenho de aplicações (APM), captura essas traces automaticamente, as agrupa e acompanha com que frequência cada exceção reaparece. Quando uma NullPointerException começa a disparar no serviço de checkout, a plataforma APM informa aos desenvolvedores exatamente onde olhar e quão difundido o problema está. Exceções que, de outra forma, desapareceriam em um arquivo de log tornam-se trabalháveis, rankeadas e monitoradas.
Note a condição de gatilho, pois tudo o mais neste artigo decorre dela: um stack trace existe apenas quando o código é executado e gera um erro. Ambas as metades dessa condição importam. Se seu código nunca roda, ou roda sem lançar exceção, não há trace, não importa o que o usuário acabou de experimentar.
Uma forma prática de manter isso na cabeça: o código rodou e gerou erro, você recebe uma trace. O código rodou lentamente sem erro, sem trace. O navegador falhou antes de alcançar seu código, sem trace. Algo fora do seu código bloqueou após sua resposta sair, sem trace. Apenas um estado em quatro produz evidência, e os usuários vivem em todos os quatro.
O Que o Monitoramento de Stack Trace Captura Bem
Nada do que segue é um argumento contra APM. Para falhas que se originam em seu código, stacks traces são a rota mais rápida do sintoma à solução:
- Identificação rápida da causa raiz. Uma trace aponta para a linha com falha e o caminho de chamadas que a alcançou, eliminando a maior parte do trabalho de adivinhação que o debug manual requer.
- Contexto profundo do erro. Boas traces carregam argumentos de métodos, estado de variáveis e metadados de requisição, para que desenvolvedores vejam não só onde o código quebrou, mas as condições sob as quais quebrou.
- Uma linguagem compartilhada para equipes técnicas. Uma trace é precisa e reproduzível. Colá-la em um ticket comunica mais do que parágrafos de descrição poderiam.
- Tendências de qualidade de código. Rastrear quais exceções reaparecem e onde expõe módulos frágeis e padrões ruins que valem a pena refatorar antes que causem queda.
Mantenha sua ferramenta APM. A questão não é se stack traces são úteis. É se elas descrevem o que seus usuários estão experimentando. Elas não descrevem, e as lacunas caem em cinco categorias distintas.
As Lacunas: O Que Stack Traces Não Capturam Sobre a Experiência do Usuário
Essas cinco lacunas não são pontos cegos aleatórios. São problemas de fronteira: código emprestado, infraestrutura pré-aplicação, execução no navegador, geografia e tempo. Stack traces são fortes dentro dos limites da aplicação e fracas em todos os lugares onde a jornada do usuário ultrapassa esses limites.
Scripts de Terceiros e APIs Externas
Uma página típica hoje carrega widgets de pagamento, gerenciadores de tags, chat, análises e scripts de anúncios de servidores de outras empresas. Quando uma dessas dependências trava ou desacelera, a página para para o usuário, mas o código com falha não é seu, então sua instrumentação não dispara nada. Muitas vezes não há exceção explícita em lugar algum: o endpoint de terceiros responde, só que lentamente o suficiente para bloquear a renderização. Conteúdo de terceiros é o caso clássico em que os usuários sofrem enquanto todos os painéis internos permanecem verdes.
Falhas de DNS, TLS e CDN
Antes que uma requisição alcance sua aplicação, ela precisa resolver seu domínio, negociar uma handshake TLS, e muitas vezes passar por uma borda de CDN. Um registro DNS mal configurado, um certificado expirado ou um nó de borda com falha bloqueiam os usuários na porta da frente. Seu código nunca executa para esses visitantes, o que significa que a falha não pode gerar um stack trace por definição. De dentro da sua infraestrutura, o sintoma mais visível é o silêncio: o tráfego cai, e nada explica por quê. As camadas DNS, TCP, TLS e HTTP falham em modos que só uma verificação externa consegue observar.
Falhas de Renderização e UI Frontend
O APM do lado do servidor confirma que seu backend retornou uma resposta válida em tempo adequado. Ele não diz nada sobre o que o navegador fez com isso. Um pacote JavaScript que quebra em uma versão de navegador, um layout que desaba no mobile, um botão cujo handler de clique nunca é associado: cada um deixa usuários encarando uma página quebrada enquanto o servidor registra um 200 limpo. Exceções do lado cliente podem ser coletadas separadamente, mas renderização lenta, mudanças de layout e controles sem resposta geralmente não disparam erros. Eles apenas silenciosamente perdem usuários. Uma falha de hydration em um app Next.js é o clássico moderno: o servidor envia um 200 perfeito com HTML totalmente formado, o JavaScript do lado cliente falha, e os usuários recebem uma página que parece estar certa e não faz nada. O evento que vale a pena monitorar não é se o JavaScript lançou exceção, mas se o marco foi completado: botão clicável, formulário enviado, confirmação mostrada. Stack traces registram exceções; usuários experimentam marcos ausentes.
Falhas Regionais
Sua instrumentação vive dentro da sua infraestrutura e reporta agregados. Se uma rota de operadora degrada entre uma região e seus servidores, ou um ponto de presença CDN começa a falhar em uma geografia, os usuários lá enfrentam timeouts enquanto suas médias quase não mudam. Um stack trace não tem conceito de onde o usuário estava; ele só sabe qual código estava sendo executado. Falhas regionais são invisíveis por construção a uma visão centrada no código.
Lento Não é uma Exceção
A lacuna mais sutil: a deterioração de desempenho nunca lança exceção. Uma página que passa de dois segundos para oito segundos gera zero erros enquanto afasta usuários lentamente. Geralmente é o marketing que percebe primeiro, em um métrico de funil caindo, muito antes da pager do engenheiro disparar, porque do ponto de vista do código nada está quebrado. O monitoramento de stack trace é também reativo por design, pois reporte após um erro já ter ocorrido, e sua saída é compreendida apenas por quem conhece a base de código. Um stack trace não acompanha tempos de resposta, carregamento de página ou qualquer métrica de desempenho visível ao usuário. Uma aplicação pode estar lenta o suficiente para ser inutilizável e, da perspectiva de stack trace, perfeitamente saudável.
| Falha | O Que o Usuário Experimenta | O Que o APM de Stack Trace Mostra |
|---|---|---|
| Script de terceiros trava | Página para no meio do carregamento, checkout bloqueado | Verde — nenhuma exceção no seu código |
| Script de teste A/B falha | Metade dos usuários recebe uma variante com página quebrada | Verde — o experimento não é seu código |
| Registro DNS mal configurado | Site inacessível | Verde — requisições nunca chegam |
| Certificado TLS expira | Aviso de segurança no navegador, usuário sai | Verde — handshake falha antes do seu código executar |
| Pacote JS quebra em um navegador | Botões mortos, layout quebrado | 200 limpo no servidor |
| Borda CDN degrada em uma região | Carregamento de dez segundos naquela geografia | Tempos de resposta agregados normais |
| Decaimento gradual de desempenho | Páginas mais lentas, aumento do abandono | Sem erros, nada a relatar |
Como o Monitoramento Sintético Preenche as Lacunas
O monitoramento sintético aborda o problema pela direção oposta. Em vez de instrumentar seu código e esperar que ele lance erro, ele executa verificações agendadas e roteirizadas contra sua aplicação em navegadores reais de locais ao redor do mundo, medindo exatamente o que um usuário naquele local e momento receberia. Essa inversão cobre cada lacuna diretamente:
- Carrega a página inteira, não só seu código. Uma verificação em navegador real executa todos os scripts de terceiros que a página carrega. Se o gerenciador de tags trava ou um widget de pagamento desacelera o carregamento, a verificação detecta, e um gráfico waterfall mostra qual recurso travou e por quanto tempo.
- Começa de onde o usuário começa. Cada verificação resolve DNS, negocia TLS e atravessa a CDN fora da sua rede. Um certificado expirado ou nó de borda morto falha na verificação dentro de um ciclo de monitoramento, em vez de aparecer como queda inexplicada de tráfego horas depois.
- Renderiza em um navegador real. Como a verificação usa um motor real de navegador, scripts quebrados, elementos sem resposta e falhas de renderização aparecem como passos falhos, não como problemas invisíveis no lado cliente.
- Executa de muitas geografias. Verificações de uma rede global de locais isolam falhas regionais: quando Frankfurt falha e Dallas passa, você sabe o escopo do problema antes dos usuários tweetarem sobre isso.
- Mede velocidade a cada execução, com erro ou não. Cada verificação grava o tempo de carregamento e o tempo de cada etapa, então uma página de oito segundos dispara alerta em um limite que você define, muito antes de algo tecnicamente quebrar.
A regra de triagem que surge disso: uma verificação que falha antes do primeiro byte indica problema em DNS, TLS ou CDN. Um waterfall travado em um domínio terceiro significa que o dono do fornecedor recebe a primeira chamada, não a equipe da aplicação. Um passo roteirizado que alcança seu backend enquanto o APM mostra uma exceção vai para a engenharia com a trace já anexada.
Fluxos multi-etapas recebem o mesmo tratamento. Com roteirização EveryStep, uma verificação pode fazer login, buscar, adicionar ao carrinho e pagar em uma agenda, 24/7, assim os caminhos que geram receita são verificados continuamente em vez de assumidos como saudáveis.
Para ser claro sobre o que o monitoramento sintético não é: ele não vê dentro do seu código. Quando uma verificação falha porque seu backend gerou exceção, é o stack trace, não o navegador, que informa ao desenvolvedor qual linha corrigir. É exatamente por isso que os dois devem andar juntos.
APM e Monitoramento Sintético: Melhor Juntos
Essa não é uma decisão de um ou outro, e tratá-la assim é como equipes acabam despreparadas. O APM com stack traces monitora de dentro para fora e responde por que o código falhou? O monitoramento sintético observa de fora para dentro e responde os usuários conseguem realmente fazer as coisas que importam, agora, daonde estão? Cada um cobre os pontos cegos do outro.
As falhas perigosas são aquelas que cada ferramenta isoladamente perderia: para o APM, um checkout bloqueado por script de fornecedor; para verificações sintéticas isoladas, uma exceção que dispara só sob entradas raras. Execute ambos e nenhuma classe se esconde.
Na prática, os dois formam uma cadeia. Uma verificação sintética falha o fluxo de checkout em Frankfurt. O waterfall isola a camada com falha: DNS, CDN, uma chamada de terceiro ou seu próprio backend. Se o rastro termina na sua aplicação, o stack trace no seu APM assume e aponta a função que lançou exceção. Detecção por fora, diagnóstico por dentro e nenhuma lacuna entre o que seus painéis dizem e o que seus usuários veem. Também termina o impasse que todo respondedor conhece, onde um time insiste que o APM está verde e outro que os usuários estão reclamando: usar só APM é como câmeras de segurança dentro do cofre sem nenhuma na porta da frente, uma filmagem perfeita do furto descoberta depois que o cofre está vazio.
O Dotcom-Monitor está no lado sintético desse casamento. Não é uma plataforma APM nem substitui ferramentas como New Relic ou Datadog; complementa com monitoramento sintético em navegador real de uma rede global de locais, com tempo por etapa, detalhe waterfall e alertas quando um fluxo desacelera ou quebra.
A Conclusão
O monitoramento de stack trace merece seu lugar: quando seu código lança erro, nada leva um desenvolvedor para a linha com falha mais rápido. Mas sua condição de gatilho, código executado que falha, define exatamente o que ele nunca pode mostrar. Scripts de terceiros, falhas de DNS e CDN, falhas de renderização frontend, quedas regionais e degradação lenta mas sem erros afetam usuários sem deixar rastros, no sentido literal.
O monitoramento sintético em navegador real preenche essas lacunas testando o caminho completo que os usuários percorrem, de todas as geografias que você se importa, em uma agenda que detecta problemas antes que tickets de suporte apareçam. Mantenha as stack traces para diagnóstico. Adicione verificações de fora para dentro para detecção. Seus usuários experimentam o caminho inteiro, seu monitoramento também deve cobrir o caminho inteiro.
Veja O Que Seu APM Não Consegue
Execute monitoramento sintético em navegador real nos seus fluxos críticos de usuário a partir de uma rede global e detecte falhas que nunca geram exceção. Comece um teste grátis.
