{"id":17859,"date":"2021-05-13T11:33:34","date_gmt":"2021-05-13T11:33:34","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2021\/05\/13\/monitoramento-de-rastreamento-de-pilhas-lacunas-na-medicao-da-experiencia-do-usuario\/"},"modified":"2026-08-22T14:44:26","modified_gmt":"2026-08-22T14:44:26","slug":"monitoramento-de-rastreamento-de-pilhas-lacunas-na-medicao-da-experiencia-do-usuario","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/monitoramento-de-rastreamento-de-pilhas-lacunas-na-medicao-da-experiencia-do-usuario\/","title":{"rendered":"Monitoramento de Rastreamento de Pilha: Lacunas na Experi\u00eancia do Usu\u00e1rio"},"content":{"rendered":"<figure id=\"attachment_34459\" aria-describedby=\"caption-attachment-34459\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img fetchpriority=\"high\" decoding=\"async\" class=\"size-full wp-image-34459\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/hero-stack-trace-monitoring-gaps.webp\" alt=\"Developer viewing a green APM dashboard while a frustrated user stares at a loading spinner on the same web application\" width=\"1200\" height=\"800\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/hero-stack-trace-monitoring-gaps.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/hero-stack-trace-monitoring-gaps-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/hero-stack-trace-monitoring-gaps-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/hero-stack-trace-monitoring-gaps-768x512.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34459\" class=\"wp-caption-text\">Um painel APM verde e uma experi\u00eancia do usu\u00e1rio falhando podem ser verdadeiros ao mesmo tempo.<\/figcaption><\/figure>\n<p>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\u00e7\u00e3o foi disparada, nenhuma stack trace foi capturada, porque nada no seu c\u00f3digo falhou. O script do provedor de pagamento travou, a p\u00e1gina nunca terminou de renderizar, e o pedido foi perdido. Seu backend nem sequer viu a requisi\u00e7\u00e3o final do checkout, ent\u00e3o n\u00e3o h\u00e1 transa\u00e7\u00e3o falhada para inspecionar: do ponto de vista da aplica\u00e7\u00e3o, nada aconteceu. Do ponto de vista do usu\u00e1rio, a \u00fanica etapa que importava falhou.<\/p>\n<p>Esse \u00e9 o ponto cego sobre o qual este artigo trata. O monitoramento de stack trace \u00e9 realmente bom no que faz: quando seu c\u00f3digo gera um erro, ele entrega aos desenvolvedores o arquivo, a linha e a cadeia de chamadas que levaram at\u00e9 l\u00e1. O problema \u00e9 o que ele n\u00e3o consegue ver estruturalmente. Uma classe inteira de falhas vis\u00edveis ao usu\u00e1rio acontece antes que uma requisi\u00e7\u00e3o alcance seu c\u00f3digo, depois que sua resposta sai dele ou sem que nenhuma exce\u00e7\u00e3o seja disparada.<\/p>\n<p>Aqui est\u00e1 o que o monitoramento de stack trace captura bem, as cinco lacunas que ele deixa na medi\u00e7\u00e3o da experi\u00eancia do usu\u00e1rio e como o monitoramento sint\u00e9tico em navegador real cobre o territ\u00f3rio que ele n\u00e3o consegue.<\/p>\n<h2 id='o-que-\u00e9-monitoramento-de-stack-trace'  id=\"boomdevs_1\" id=\"what-is-stack-trace-monitoring\">O Que \u00c9 Monitoramento de Stack Trace?<\/h2>\n<p>Um stack trace \u00e9 um instant\u00e2neo da pilha de chamadas no momento em que um erro ocorre: quais fun\u00e7\u00f5es estavam executando, em quais arquivos, em quais n\u00fameros de linha e em que ordem foram chamadas. Se voc\u00ea j\u00e1 viu um erro no console listando uma cascata de m\u00e9todos e caminhos de arquivos, voc\u00ea leu um.<\/p>\n<p>O monitoramento de stack trace, como praticado por ferramentas de <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/aprenda-com-o-dotcom-monitor\/o-que-e-apm-application-performance-management\/\">monitoramento de desempenho de aplica\u00e7\u00f5es (APM)<\/a>, captura essas traces automaticamente, as agrupa e acompanha com que frequ\u00eancia cada exce\u00e7\u00e3o reaparece. Quando uma NullPointerException come\u00e7a a disparar no servi\u00e7o de checkout, a plataforma APM informa aos desenvolvedores exatamente onde olhar e qu\u00e3o difundido o problema est\u00e1. Exce\u00e7\u00f5es que, de outra forma, desapareceriam em um arquivo de log tornam-se trabalh\u00e1veis, rankeadas e monitoradas.<\/p>\n<p>Note a condi\u00e7\u00e3o de gatilho, pois tudo o mais neste artigo decorre dela: um stack trace existe apenas quando o c\u00f3digo \u00e9 executado e gera um erro. Ambas as metades dessa condi\u00e7\u00e3o importam. Se seu c\u00f3digo nunca roda, ou roda sem lan\u00e7ar exce\u00e7\u00e3o, n\u00e3o h\u00e1 trace, n\u00e3o importa o que o usu\u00e1rio acabou de experimentar.<\/p>\n<p>Uma forma pr\u00e1tica de manter isso na cabe\u00e7a: o c\u00f3digo rodou e gerou erro, voc\u00ea recebe uma trace. O c\u00f3digo rodou lentamente sem erro, sem trace. O navegador falhou antes de alcan\u00e7ar seu c\u00f3digo, sem trace. Algo fora do seu c\u00f3digo bloqueou ap\u00f3s sua resposta sair, sem trace. Apenas um estado em quatro produz evid\u00eancia, e os usu\u00e1rios vivem em todos os quatro.<\/p>\n<h2 id='o-que-o-monitoramento-de-stack-trace-captura-bem'  id=\"boomdevs_2\" id=\"what-stack-trace-monitoring-catches-well\">O Que o Monitoramento de Stack Trace Captura Bem<\/h2>\n<p>Nada do que segue \u00e9 um argumento contra APM. Para falhas que se originam em seu c\u00f3digo, stacks traces s\u00e3o a rota mais r\u00e1pida do sintoma \u00e0 solu\u00e7\u00e3o:<\/p>\n<ul>\n<li><strong>Identifica\u00e7\u00e3o r\u00e1pida da causa raiz.<\/strong> Uma trace aponta para a linha com falha e o caminho de chamadas que a alcan\u00e7ou, eliminando a maior parte do trabalho de adivinha\u00e7\u00e3o que o debug manual requer.<\/li>\n<li><strong>Contexto profundo do erro.<\/strong> Boas traces carregam argumentos de m\u00e9todos, estado de vari\u00e1veis e metadados de requisi\u00e7\u00e3o, para que desenvolvedores vejam n\u00e3o s\u00f3 onde o c\u00f3digo quebrou, mas as condi\u00e7\u00f5es sob as quais quebrou.<\/li>\n<li><strong>Uma linguagem compartilhada para equipes t\u00e9cnicas.<\/strong> Uma trace \u00e9 precisa e reproduz\u00edvel. Col\u00e1-la em um ticket comunica mais do que par\u00e1grafos de descri\u00e7\u00e3o poderiam.<\/li>\n<li><strong>Tend\u00eancias de qualidade de c\u00f3digo.<\/strong> Rastrear quais exce\u00e7\u00f5es reaparecem e onde exp\u00f5e m\u00f3dulos fr\u00e1geis e padr\u00f5es ruins que valem a pena refatorar antes que causem queda.<\/li>\n<\/ul>\n<p>Mantenha sua ferramenta APM. A quest\u00e3o n\u00e3o \u00e9 se stack traces s\u00e3o \u00fateis. \u00c9 se elas descrevem o que seus usu\u00e1rios est\u00e3o experimentando. Elas n\u00e3o descrevem, e as lacunas caem em cinco categorias distintas.<\/p>\n<h2 id='as-lacunas-o-que-stack-traces-n\u00e3o-capturam-sobre-a-experi\u00eancia-do-usu\u00e1rio'  id=\"boomdevs_3\" id=\"the-gaps-what-stack-traces-miss-about-the-user-experience\">As Lacunas: O Que Stack Traces N\u00e3o Capturam Sobre a Experi\u00eancia do Usu\u00e1rio<\/h2>\n<p>Essas cinco lacunas n\u00e3o s\u00e3o pontos cegos aleat\u00f3rios. S\u00e3o problemas de fronteira: c\u00f3digo emprestado, infraestrutura pr\u00e9-aplica\u00e7\u00e3o, execu\u00e7\u00e3o no navegador, geografia e tempo. Stack traces s\u00e3o fortes dentro dos limites da aplica\u00e7\u00e3o e fracas em todos os lugares onde a jornada do usu\u00e1rio ultrapassa esses limites.<\/p>\n<figure id=\"attachment_34466\" aria-describedby=\"caption-attachment-34466\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-34466\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/apm-visibility-gap.webp\" alt=\"Diagram showing the visibility gap between what stack trace APM sees inside application code and what users experience in the browser, with third-party scripts, CDN and DNS failures, rendering issues, and regional outages falling in between\" width=\"1200\" height=\"800\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/apm-visibility-gap.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/apm-visibility-gap-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/apm-visibility-gap-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/apm-visibility-gap-768x512.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34466\" class=\"wp-caption-text\">O APM de stack trace instrumenta seu c\u00f3digo. Os usu\u00e1rios experimentam tudo entre o navegador e esse c\u00f3digo.<\/figcaption><\/figure>\n<h3 id='scripts-de-terceiros-e-apis-externas'  id=\"boomdevs_4\">Scripts de Terceiros e APIs Externas<\/h3>\n<p>Uma p\u00e1gina t\u00edpica hoje carrega widgets de pagamento, gerenciadores de tags, chat, an\u00e1lises e scripts de an\u00fancios de servidores de outras empresas. Quando uma dessas depend\u00eancias trava ou desacelera, a p\u00e1gina para para o usu\u00e1rio, mas o c\u00f3digo com falha n\u00e3o \u00e9 seu, ent\u00e3o sua instrumenta\u00e7\u00e3o n\u00e3o dispara nada. Muitas vezes n\u00e3o h\u00e1 exce\u00e7\u00e3o expl\u00edcita em lugar algum: o endpoint de terceiros responde, s\u00f3 que lentamente o suficiente para bloquear a renderiza\u00e7\u00e3o. <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/monitoramento-de-conteudo-de-terceiros\/\">Conte\u00fado de terceiros<\/a> \u00e9 o caso cl\u00e1ssico em que os usu\u00e1rios sofrem enquanto todos os pain\u00e9is internos permanecem verdes.<\/p>\n<h3 id='falhas-de-dns-tls-e-cdn'  id=\"boomdevs_5\">Falhas de DNS, TLS e CDN<\/h3>\n<p>Antes que uma requisi\u00e7\u00e3o alcance sua aplica\u00e7\u00e3o, ela precisa resolver seu dom\u00ednio, negociar uma handshake TLS, e muitas vezes passar por uma borda de CDN. Um registro DNS mal configurado, um certificado expirado ou um n\u00f3 de borda com falha bloqueiam os usu\u00e1rios na porta da frente. Seu c\u00f3digo nunca executa para esses visitantes, o que significa que a falha n\u00e3o pode gerar um stack trace por defini\u00e7\u00e3o. De dentro da sua infraestrutura, o sintoma mais vis\u00edvel \u00e9 o sil\u00eancio: o tr\u00e1fego cai, e nada explica por qu\u00ea. As <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/website-monitoring-errors-dns-tcp-tls-http\/\">camadas DNS, TCP, TLS e HTTP<\/a> falham em modos que s\u00f3 uma verifica\u00e7\u00e3o externa consegue observar.<\/p>\n<h3 id='falhas-de-renderiza\u00e7\u00e3o-e-ui-frontend'  id=\"boomdevs_6\">Falhas de Renderiza\u00e7\u00e3o e UI Frontend<\/h3>\n<p>O APM do lado do servidor confirma que seu backend retornou uma resposta v\u00e1lida em tempo adequado. Ele n\u00e3o diz nada sobre o que o navegador fez com isso. Um pacote JavaScript que quebra em uma vers\u00e3o de navegador, um layout que desaba no mobile, um bot\u00e3o cujo handler de clique nunca \u00e9 associado: cada um deixa usu\u00e1rios encarando uma p\u00e1gina quebrada enquanto o servidor registra um 200 limpo. Exce\u00e7\u00f5es do lado cliente podem ser coletadas separadamente, mas renderiza\u00e7\u00e3o lenta, mudan\u00e7as de layout e controles sem resposta geralmente n\u00e3o disparam erros. Eles apenas silenciosamente perdem usu\u00e1rios. Uma falha de hydration em um app Next.js \u00e9 o cl\u00e1ssico moderno: o servidor envia um 200 perfeito com HTML totalmente formado, o JavaScript do lado cliente falha, e os usu\u00e1rios recebem uma p\u00e1gina que parece estar certa e n\u00e3o faz nada. O evento que vale a pena monitorar n\u00e3o \u00e9 se o JavaScript lan\u00e7ou exce\u00e7\u00e3o, mas se o marco foi completado: bot\u00e3o clic\u00e1vel, formul\u00e1rio enviado, confirma\u00e7\u00e3o mostrada. Stack traces registram exce\u00e7\u00f5es; usu\u00e1rios experimentam marcos ausentes.<\/p>\n<h3 id='falhas-regionais'  id=\"boomdevs_7\">Falhas Regionais<\/h3>\n<p>Sua instrumenta\u00e7\u00e3o vive dentro da sua infraestrutura e reporta agregados. Se uma rota de operadora degrada entre uma regi\u00e3o e seus servidores, ou um ponto de presen\u00e7a CDN come\u00e7a a falhar em uma geografia, os usu\u00e1rios l\u00e1 enfrentam timeouts enquanto suas m\u00e9dias quase n\u00e3o mudam. Um stack trace n\u00e3o tem conceito de onde o usu\u00e1rio estava; ele s\u00f3 sabe qual c\u00f3digo estava sendo executado. Falhas regionais s\u00e3o invis\u00edveis por constru\u00e7\u00e3o a uma vis\u00e3o centrada no c\u00f3digo.<\/p>\n<h3 id='lento-n\u00e3o-\u00e9-uma-exce\u00e7\u00e3o'  id=\"boomdevs_8\">Lento N\u00e3o \u00e9 uma Exce\u00e7\u00e3o<\/h3>\n<p>A lacuna mais sutil: a deteriora\u00e7\u00e3o de desempenho nunca lan\u00e7a exce\u00e7\u00e3o. Uma p\u00e1gina que passa de dois segundos para oito segundos gera zero erros enquanto afasta usu\u00e1rios lentamente. Geralmente \u00e9 o marketing que percebe primeiro, em um m\u00e9trico de funil caindo, muito antes da pager do engenheiro disparar, porque do ponto de vista do c\u00f3digo nada est\u00e1 quebrado. O monitoramento de stack trace \u00e9 tamb\u00e9m reativo por design, pois reporte ap\u00f3s um erro j\u00e1 ter ocorrido, e sua sa\u00edda \u00e9 compreendida apenas por quem conhece a base de c\u00f3digo. Um stack trace n\u00e3o acompanha tempos de resposta, carregamento de p\u00e1gina ou qualquer m\u00e9trica de desempenho vis\u00edvel ao usu\u00e1rio. Uma aplica\u00e7\u00e3o pode estar lenta o suficiente para ser inutiliz\u00e1vel e, da perspectiva de stack trace, perfeitamente saud\u00e1vel.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Falha<\/th>\n<th>O Que o Usu\u00e1rio Experimenta<\/th>\n<th>O Que o APM de Stack Trace Mostra<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Script de terceiros trava<\/td>\n<td>P\u00e1gina para no meio do carregamento, checkout bloqueado<\/td>\n<td>Verde \u2014 nenhuma exce\u00e7\u00e3o no seu c\u00f3digo<\/td>\n<\/tr>\n<tr>\n<td>Script de teste A\/B falha<\/td>\n<td>Metade dos usu\u00e1rios recebe uma variante com p\u00e1gina quebrada<\/td>\n<td>Verde \u2014 o experimento n\u00e3o \u00e9 seu c\u00f3digo<\/td>\n<\/tr>\n<tr>\n<td>Registro DNS mal configurado<\/td>\n<td>Site inacess\u00edvel<\/td>\n<td>Verde \u2014 requisi\u00e7\u00f5es nunca chegam<\/td>\n<\/tr>\n<tr>\n<td>Certificado TLS expira<\/td>\n<td>Aviso de seguran\u00e7a no navegador, usu\u00e1rio sai<\/td>\n<td>Verde \u2014 handshake falha antes do seu c\u00f3digo executar<\/td>\n<\/tr>\n<tr>\n<td>Pacote JS quebra em um navegador<\/td>\n<td>Bot\u00f5es mortos, layout quebrado<\/td>\n<td>200 limpo no servidor<\/td>\n<\/tr>\n<tr>\n<td>Borda CDN degrada em uma regi\u00e3o<\/td>\n<td>Carregamento de dez segundos naquela geografia<\/td>\n<td>Tempos de resposta agregados normais<\/td>\n<\/tr>\n<tr>\n<td>Decaimento gradual de desempenho<\/td>\n<td>P\u00e1ginas mais lentas, aumento do abandono<\/td>\n<td>Sem erros, nada a relatar<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h2 id='como-o-monitoramento-sint\u00e9tico-preenche-as-lacunas'  id=\"boomdevs_9\" id=\"how-synthetic-monitoring-fills-the-gaps\">Como o Monitoramento Sint\u00e9tico Preenche as Lacunas<\/h2>\n<p>O <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/what-is-synthetic-monitoring\/\">monitoramento sint\u00e9tico<\/a> aborda o problema pela dire\u00e7\u00e3o oposta. Em vez de instrumentar seu c\u00f3digo e esperar que ele lance erro, ele executa verifica\u00e7\u00f5es agendadas e roteirizadas contra sua aplica\u00e7\u00e3o em navegadores reais de locais ao redor do mundo, medindo exatamente o que um usu\u00e1rio naquele local e momento receberia. Essa invers\u00e3o cobre cada lacuna diretamente:<\/p>\n<ul>\n<li><strong>Carrega a p\u00e1gina inteira, n\u00e3o s\u00f3 seu c\u00f3digo.<\/strong> Uma verifica\u00e7\u00e3o em navegador real executa todos os scripts de terceiros que a p\u00e1gina carrega. Se o gerenciador de tags trava ou um widget de pagamento desacelera o carregamento, a verifica\u00e7\u00e3o detecta, e um gr\u00e1fico waterfall mostra <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/otimizando-o-desempenho-da-web-entendendo-graficos-de-cachoeira\/\">qual recurso travou e por quanto tempo<\/a>.<\/li>\n<li><strong>Come\u00e7a de onde o usu\u00e1rio come\u00e7a.<\/strong> Cada verifica\u00e7\u00e3o resolve DNS, negocia TLS e atravessa a CDN fora da sua rede. Um certificado expirado ou n\u00f3 de borda morto falha na verifica\u00e7\u00e3o dentro de um ciclo de monitoramento, em vez de aparecer como queda inexplicada de tr\u00e1fego horas depois.<\/li>\n<li><strong>Renderiza em um navegador real.<\/strong> Como a verifica\u00e7\u00e3o usa um motor real de navegador, scripts quebrados, elementos sem resposta e falhas de renderiza\u00e7\u00e3o aparecem como passos falhos, n\u00e3o como problemas invis\u00edveis no lado cliente.<\/li>\n<li><strong>Executa de muitas geografias.<\/strong> Verifica\u00e7\u00f5es de uma <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/frequencia-de-monitoramento-sintetico\/\">rede global de locais<\/a> isolam falhas regionais: quando Frankfurt falha e Dallas passa, voc\u00ea sabe o escopo do problema antes dos usu\u00e1rios tweetarem sobre isso.<\/li>\n<li><strong>Mede velocidade a cada execu\u00e7\u00e3o, com erro ou n\u00e3o.<\/strong> Cada verifica\u00e7\u00e3o grava o tempo de carregamento e o tempo de cada etapa, ent\u00e3o uma p\u00e1gina de oito segundos dispara alerta em um limite que voc\u00ea define, muito antes de algo tecnicamente quebrar.<\/li>\n<\/ul>\n<p>A regra de triagem que surge disso: uma verifica\u00e7\u00e3o que falha antes do primeiro byte indica problema em DNS, TLS ou CDN. Um waterfall travado em um dom\u00ednio terceiro significa que o dono do fornecedor recebe a primeira chamada, n\u00e3o a equipe da aplica\u00e7\u00e3o. Um passo roteirizado que alcan\u00e7a seu backend enquanto o APM mostra uma exce\u00e7\u00e3o vai para a engenharia com a trace j\u00e1 anexada.<\/p>\n<p>Fluxos multi-etapas recebem o mesmo tratamento. Com <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/caracteristicas\/everystep\/\">roteiriza\u00e7\u00e3o EveryStep<\/a>, uma verifica\u00e7\u00e3o pode fazer login, buscar, adicionar ao carrinho e pagar em uma agenda, 24\/7, assim os caminhos que geram receita s\u00e3o verificados continuamente em vez de assumidos como saud\u00e1veis.<\/p>\n<p>Para ser claro sobre o que o monitoramento sint\u00e9tico n\u00e3o \u00e9: ele n\u00e3o v\u00ea dentro do seu c\u00f3digo. Quando uma verifica\u00e7\u00e3o falha porque seu backend gerou exce\u00e7\u00e3o, \u00e9 o stack trace, n\u00e3o o navegador, que informa ao desenvolvedor qual linha corrigir. \u00c9 exatamente por isso que os dois devem andar juntos.<\/p>\n<h2 id='apm-e-monitoramento-sint\u00e9tico-melhor-juntos'  id=\"boomdevs_10\" id=\"apm-and-synthetic-monitoring-better-together\">APM e Monitoramento Sint\u00e9tico: Melhor Juntos<\/h2>\n<p>Essa n\u00e3o \u00e9 uma decis\u00e3o de um ou outro, e trat\u00e1-la assim \u00e9 como equipes acabam despreparadas. O APM com stack traces monitora de dentro para fora e responde <em>por que o c\u00f3digo falhou?<\/em> O monitoramento sint\u00e9tico observa de fora para dentro e responde <em>os usu\u00e1rios conseguem realmente fazer as coisas que importam, agora, daonde est\u00e3o?<\/em> Cada um cobre os pontos cegos do outro.<\/p>\n<blockquote><p>As falhas perigosas s\u00e3o aquelas que cada ferramenta isoladamente perderia: para o APM, um checkout bloqueado por script de fornecedor; para verifica\u00e7\u00f5es sint\u00e9ticas isoladas, uma exce\u00e7\u00e3o que dispara s\u00f3 sob entradas raras. Execute ambos e nenhuma classe se esconde.<\/p><\/blockquote>\n<p>Na pr\u00e1tica, os dois formam uma cadeia. Uma verifica\u00e7\u00e3o sint\u00e9tica falha o fluxo de checkout em Frankfurt. O waterfall isola a camada com falha: DNS, CDN, uma chamada de terceiro ou seu pr\u00f3prio backend. Se o rastro termina na sua aplica\u00e7\u00e3o, o stack trace no seu APM assume e aponta a fun\u00e7\u00e3o que lan\u00e7ou exce\u00e7\u00e3o. Detec\u00e7\u00e3o por fora, diagn\u00f3stico por dentro e nenhuma lacuna entre o que seus pain\u00e9is dizem e o que seus usu\u00e1rios veem. Tamb\u00e9m termina o impasse que todo respondedor conhece, onde um time insiste que o APM est\u00e1 verde e outro que os usu\u00e1rios est\u00e3o reclamando: usar s\u00f3 APM \u00e9 como c\u00e2meras de seguran\u00e7a dentro do cofre sem nenhuma na porta da frente, uma filmagem perfeita do furto descoberta depois que o cofre est\u00e1 vazio.<\/p>\n<p>O Dotcom-Monitor est\u00e1 no lado sint\u00e9tico desse casamento. N\u00e3o \u00e9 uma plataforma APM nem substitui ferramentas como New Relic ou Datadog; complementa com <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/solucoes\/synthetic-monitoring\/\">monitoramento sint\u00e9tico em navegador real<\/a> de uma rede global de locais, com tempo por etapa, detalhe waterfall e alertas quando um fluxo desacelera ou quebra.<\/p>\n<h2 id='a-conclus\u00e3o'  id=\"boomdevs_11\" id=\"the-bottom-line\">A Conclus\u00e3o<\/h2>\n<p>O monitoramento de stack trace merece seu lugar: quando seu c\u00f3digo lan\u00e7a erro, nada leva um desenvolvedor para a linha com falha mais r\u00e1pido. Mas sua condi\u00e7\u00e3o de gatilho, c\u00f3digo executado que falha, define exatamente o que ele nunca pode mostrar. Scripts de terceiros, falhas de DNS e CDN, falhas de renderiza\u00e7\u00e3o frontend, quedas regionais e degrada\u00e7\u00e3o lenta mas sem erros afetam usu\u00e1rios sem deixar rastros, no sentido literal.<\/p>\n<p>O monitoramento sint\u00e9tico em navegador real preenche essas lacunas testando o caminho completo que os usu\u00e1rios percorrem, de todas as geografias que voc\u00ea se importa, em uma agenda que detecta problemas antes que tickets de suporte apare\u00e7am. Mantenha as stack traces para diagn\u00f3stico. Adicione verifica\u00e7\u00f5es de fora para dentro para detec\u00e7\u00e3o. Seus usu\u00e1rios experimentam o caminho inteiro, seu monitoramento tamb\u00e9m deve cobrir o caminho inteiro.<\/p>\n<section class=\"final-cta\">\n<h2 id='veja-o-que-seu-apm-n\u00e3o-consegue'  id=\"boomdevs_12\">Veja O Que Seu APM N\u00e3o Consegue<\/h2>\n<p>Execute <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/solucoes\/synthetic-monitoring\/\">monitoramento sint\u00e9tico em navegador real<\/a> nos seus fluxos cr\u00edticos de usu\u00e1rio a partir de uma rede global e detecte falhas que nunca geram exce\u00e7\u00e3o. <a href=\"https:\/\/userauth.dotcom-monitor.com\/Account\/FreeTrialSignUp?SolutionType=Monitoring\">Comece um teste gr\u00e1tis<\/a>.<\/p>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>Rastreamentos de pilha mostram onde o c\u00f3digo quebrou, n\u00e3o o que os usu\u00e1rios experimentaram. Veja as lacunas no rastreamento de pilha APM e como o monitoramento sint\u00e9tico as preenche.<\/p>\n","protected":false},"author":21,"featured_media":34464,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5170],"tags":[],"class_list":["post-17859","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-nao-categorizado"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts\/17859","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/comments?post=17859"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts\/17859\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/media\/34464"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/media?parent=17859"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/categories?post=17859"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/tags?post=17859"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}