Vercel libera rastreamento contínuo de tráfego real em produção e preview

A Vercel anunciou no seu changelog o always-on tracing, um recurso em beta que coleta traces de forma contínua a partir do tráfego real de produção e preview. A promessa central, nas palavras da própria empresa, é permitir "debugar requisições de usuários reais sem reproduzi-las". Para quem já passou horas tentando reencenar um bug de performance que só aparece em produção, sob carga e com dados reais, é uma mudança de peso na estratégia de observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps →.

O que muda em relação ao session tracing

Até agora, o tracing da Vercel funcionava no modelo de session tracing: ele capturava apenas as requisições originadas do próprio navegador do desenvolvedor. Ótimo para investigar um fluxo específico enquanto você navega pela aplicação, mas inútil quando o problema acontece com um usuário do outro lado do mundo, num horário de pico, com um payload que você não conseguiria adivinhar.

O always-on tracing inverte essa lógica. Em vez de depender de você reproduzir o cenário, ele amostra o tráfego ao vivo. Ou seja, uma fração das requisições reais é instrumentada e guardada, o que dá visibilidade sobre o comportamento efetivo da aplicação em condições de produção, e não sobre uma simulação.

Como a amostragem controla o custo

O ponto mais importante do design é que nada é coletado até você criar uma regra. O recurso funciona com sampling rules configuráveis, e cada regra define:

• Uma trace rate (a taxa de amostragem);
• Um ambiente alvo: All, Production ou Preview;
• Opcionalmente, um prefixo de path, por exemplo /checkout.

Essa granularidade é o que torna o "sem overhead" da pauta algo real e não marketing. Você pode, por exemplo, tracear 100% do fluxo de checkout em produção (onde cada milissegundo vira receita perdida) e deixar o resto do site sem instrumentação, ou amostrar uma fração pequena do tráfego geral só para ter uma linha de base. Como a Vercel resume: "você paga apenas pelo que escolher tracear".

Na prática, isso muda a decisão de arquitetura. Em vez de a observabilidade ser um custo fixo que cresce com o tráfego, ela vira um dial que você ajusta por rota e por ambiente conforme a criticidade.

O que é capturado automaticamente e o que exige instrumentação

De fábrica, o always-on tracing captura spans de infraestrutura e de fetch de saída (as chamadas HTTP que sua função faz para APIs externas, bancos, serviços). Isso já cobre boa parte dos gargalos típicos de uma app serverless, onde a latência costuma vir de uma chamada externa lenta encadeada com outra.

Para ir além disso, capturando spans de framework e spans customizados, é preciso instrumentar a aplicação com o pacote @vercel/otel, que é a integração da Vercel com o padrão OpenTelemetry. A escolha do OTel aqui é relevante: significa que os spans customizados que você já mantém (se seguir o padrão aberto) tendem a se encaixar sem reescrita proprietária, e que os dados não ficam presos num formato exclusivo.

Para visualizar um trace, há dois caminhos: abrir a aba Logs no dashboard ou usar a CLI com vercel traces get . Esse acesso via CLI é o tipo de detalhe que agrada a quem vive no terminal, já que dá para partir de um ID que apareceu num log de erro e puxar o trace completo daquela requisição sem sair do fluxo de trabalho.

Preço, planos e retenção

O recurso está em beta e disponível para times em todos os planos. A cobrança é por uso: US$ 0,50 por 1 milhão de span units. Vale entender que a unidade cobrada é o span, não a requisição: uma única requisição pode gerar vários spans (um para cada fetch de saída, mais os de infraestrutura, mais os customizados que você adicionar). Ou seja, quanto mais instrumentada a app, mais spans por request, o que reforça a importância de calibrar as regras de amostragem.

A retenção acompanha a do runtime log de cada plano:

• Hobby: 1 hora;
• Pro: 1 dia;
• Enterprise: 3 dias.

Esse é um limite importante de ter em mente. O always-on tracing é uma ferramenta de debug reativo de curto prazo, não um data warehouse de observabilidade histórica. Se a estratégia depende de analisar tendências de performance ao longo de semanas ou de correlacionar incidentes antigos, os traces já terão expirado, especialmente no Pro. Nesses casos, continua fazendo sentido exportar para uma solução de APM dedicada.

Quando vale, e quando não vale

O cenário ideal é o clássico bug "que só acontece em produção": aquela rota que fica lenta esporadicamente, o fetch externo que degrada em horário de pico, o timeout intermitente que você nunca consegue reproduzir localmente. Ligar uma regra amostrando a rota afetada e esperar o problema reaparecer no tráfego real é muito mais barato, em tempo de engenheiro, do que tentar encenar as condições.

Já não compensa usar como observabilidade permanente e ampla se o time já roda uma stack de APM madura (Datadog, Grafana, Honeycomb) com retenção longa e alertas, ou se a preocupação é análise histórica de longo prazo, algo que a janela de retenção curta não atende. E, como sempre, atenção à conta: uma regra mal calibrada, com trace rate alto num endpoint de altíssimo volume, pode multiplicar os spans rapidamente.

Para começar, a Vercel indica adicionar uma regra em Settings → Tracing ou pelo ícone de configurações dentro de Logs. O primeiro movimento sensato é escolher uma única rota crítica, definir uma taxa modesta e observar o custo real de spans antes de expandir.

Fonte: Vercel Changelog