Como comparar o tráfego em tempo real da Astrina com os logs do servidor
Comparar o tráfego em tempo real da Astrina com os logs do servidor parece simples até surgir a primeira divergência. Um relatório diz 18 visitas. O log mostra 24 solicitações. Essa diferença quase sempre tem um motivo, e o motivo costuma ser chato da melhor maneira possível: um redirecionamento, um bot, um proxy ou um carimbo de data/hora que ficou 60 segundos fora de sincronia.
A tarefa não é fazer os dois números concordarem a qualquer custo. A tarefa é tornar a comparação honesta o suficiente para que você possa confiar nela. Se você quer saber como comparar tráfego em tempo real com logs do servidor, comece reduzindo o problema antes de discutir com os números. Em especial, vale entender a diferença entre tráfego em tempo real e logs do servidor antes de concluir que há um erro. E, quando chegar a hora de comparar logs do servidor com analytics em tempo real, faça isso com escopo, tempo e caminhos bem definidos.
1. Confirme o escopo do log do servidor antes de comparar
Escolha primeiro os arquivos de log exatos. Muitas equipes misturam tráfego de produção, staging e pré-visualização em uma única planilha e depois se perguntam por que a Astrina mostra um padrão e o servidor mostra outro. Mantenha um site, um ambiente e um recorte de tráfego. Isso significa nomear o host, o app e a origem do log em texto claro antes de qualquer outra coisa.
Se a configuração do servidor grava vários arquivos por dia, anote a regra de rotação. Se você tiver logs separados para a borda da CDN e para o servidor de origem, escolha um caminho e mantenha-o para a primeira passada. Um escopo limpo deixa o restante do trabalho menor. Um escopo confuso faz cada divergência parecer suspeita.
Um exemplo prático: compare apenas www.example.com em produção, apenas solicitações de páginas e apenas as últimas 24 horas. Não inclua tráfego de API, verificações de saúde ou URLs administrativas na mesma comparação. São coisas diferentes.
2. Escolha uma janela de tempo exata e normalize os carimbos de data e hora
O tráfego em tempo real da Astrina funciona melhor quando a janela é exata. Os logs do servidor funcionam melhor quando a janela é exata. Use o mesmo minuto inicial e o mesmo minuto final nos dois lados, não “por volta do meio-dia” ou “algum tempo depois do almoço”. O corte no nível de minuto importa porque uma solicitação na borda pode alterar a contagem.
Use um único fuso horário para os dois lados. Se a Astrina estiver mostrando UTC e seus logs estiverem em horário local, a comparação vai falhar antes mesmo de começar. Converta os carimbos de data e hora do log uma vez e mantenha-os nesse formato durante toda a análise. Um deslocamento de 15 minutos pode criar um pico falso. Um deslocamento de 1 hora pode fazer os dados parecerem quebrados.
Há uma regra pequena que economiza tempo: nunca compare uma janela móvel de 5 minutos da Astrina com um extrato de log de um dia inteiro. Parece óbvio. Mesmo assim, as pessoas ainda fazem isso. Escolha uma janela, anote-a e use-a em todos os lugares.
3. Filtre os logs do servidor para solicitações humanas de páginas
Os logs do servidor contêm tudo, e esse é o problema. Imagens, CSS, pacotes JavaScript, solicitações de favicon, pré-buscas e acessos de rastreadores ficam lado a lado com as visitas às páginas. A Astrina normalmente conta visitas de páginas, então o log precisa ser reduzido ao mesmo tipo de solicitação.
Filtre os ativos primeiro. Depois remova verificações de saúde, sondas de disponibilidade, endpoints administrativos e ferramentas internas. Se o balanceador de carga chama /health a cada minuto, essas linhas podem distorcer o total rapidamente. Uma página como /pricing não deve ser comparada com 400 solicitações de ativos e três pings de monitoramento.
O filtro de bots também merece atenção. Alguns bots parecem humanos por alguns segundos, e alguns navegadores parecem robóticos por causa do user agent. Não confie em um único sinal. Use uma combinação de caminho da requisição, user agent e intervalos de IP internos conhecidos quando possível. Se o seu log incluir um marcador de “bot” de um WAF ou proxy reverso, mantenha esse rótulo. Ele ajuda depois.
4. Mapeie os campos da Astrina para os campos do log
Crie um mapa simples de campos antes de tentar combinar registros. A Astrina pode mostrar carimbo de data e hora, caminho da página, referenciador e um identificador semelhante a sessão. O log pode mostrar a linha bruta da requisição, o código de status, o user agent e o endereço IP. Isso não é a mesma coisa e não deve ser tratado como se fosse.
Monte uma tabela de duas colunas no papel ou em uma planilha. À esquerda: campo da Astrina. À direita: campo do log. O carimbo de data e hora mapeia para o carimbo de requisição, o caminho mapeia para o caminho da URL, o referenciador mapeia para o cabeçalho referer e o user agent mapeia para a string do user agent. IDs semelhantes a sessão são mais complicados, porque o log do servidor talvez nem tenha um. Isso não é uma falha. É apenas uma limitação.
| Campo da Astrina | Campo de log mais próximo | Observações |
|---|---|---|
| Timestamp | Horário da requisição | Converta primeiro para um único fuso horário |
| Caminho da página | Caminho da URL | Remova strings de consulta para agrupar |
| Referenciador | Cabeçalho Referer | Pode estar ausente ou abreviado |
| User agent | String do user agent | Útil para verificar bots |
Não espere que todo campo da Astrina tenha um campo equivalente no log. Alguns valores são inferidos. Alguns são modelados. Alguns simplesmente não existem no log do servidor. É por isso que o mapa importa: ele mostra onde a comparação direta é possível e onde ela é apenas aproximada.
5. Reconcilie o tráfego pelo caminho da URL, não pela linha bruta da requisição
As linhas brutas de requisição são ruidosas. Uma visita a /docs pode aparecer como /docs, /docs/ ou /docs?utm_source=newsletter. Se você comparar essas strings literalmente, vai dividir uma página em três. A Astrina pode já normalizar parte disso. O seu log provavelmente não.
Use caminhos canônicos. Agrupe todas as variantes sob o mesmo caminho de página antes de comparar as contagens. Remova as strings de consulta se elas não fizerem parte da identidade da página. Unifique barras finais quando o site tratar as versões como a mesma página. Se houver redirecionamentos, conte o destino final, não o primeiro salto.
Essa etapa costuma revelar uma surpresa. Uma página com 50 visitas na Astrina pode mostrar 63 entradas no log porque 13 solicitações atingiram primeiro a versão não canônica e depois foram redirecionadas. Isso não é um erro no tráfego. É um problema de caminho. Corrija a regra de agrupamento antes de mudar a interpretação.
6. Verifique divergências causadas por cache, proxies ou CDNs
Camadas intermediárias mudam o que chega ao servidor de origem. Uma CDN pode responder à solicitação antes que a origem a veja. Um proxy pode reescrever cabeçalhos. Um acerto de cache pode servir uma página ao usuário sem deixar uma linha correspondente na origem. Isso significa que a Astrina pode ver uma visita enquanto o log do servidor permanece em silêncio.
O contrário também pode acontecer. O log da origem pode registrar uma solicitação que a Astrina nunca conta porque o navegador não concluiu o carregamento da página, o script foi bloqueado ou a solicitação aconteceu antes de o código de rastreamento ser executado. Uma página de teste rápida pode deixar isso óbvio. Abra a página em um navegador, inspecione a aba de rede e veja se a solicitação de rastreamento dispara antes de a página terminar de carregar.
Se você usa uma CDN, verifique se a origem do log é a borda ou a origem. São registros diferentes. Uma resposta 304, uma resposta HTML em cache ou um objeto desatualizado na borda podem produzir diferenças falsas. É aqui que uma nota curta na sua planilha de comparação economiza uma hora depois.
Para equipes que estão configurando o rastreador pela primeira vez, o caminho de instalação também importa. A configuração do agente fica mais fácil de verificar se você seguir o mesmo método de implantação usado em produção, e é por isso que muitas equipes mantêm o guia de configuração no runbook ao lado do script de exportação de logs.
7. Use um registro curto de divergências para classificar cada diferença
Não deixe divergências como células vermelhas anônimas. Escreva um registro de divergências com uma linha por diferença. Dê uma categoria para cada linha. Cinco categorias geralmente são suficientes no início: ruído de bots, cobertura de log ausente, ingestão atrasada, acessos duplicados e problema de normalização de caminho.
Um formato simples é: caminho da página, contagem da Astrina, contagem do log, tamanho da diferença, categoria, observação. Essa observação deve mencionar uma causa concreta, não uma impressão. “CDN serviu HTML em cache” é útil. “Parece estranho” não é. Se uma diferença se repete em três páginas, isso é uma pista. Se aparece uma vez, ainda é uma pista, só um pouco menor.
Uma equipe pode descobrir que uma diferença de 12 solicitações é causada por atraso no envio dos logs. Outra pode perceber que uma extensão de navegador bloqueia o script de rastreamento em dispositivos internos. Uma terceira pode aprender que o servidor grava linhas duplicadas em tentativas repetidas. As categorias evitam que você trate todas as divergências como o mesmo tipo de falha.
Se você quiser um enquadramento operacional mais profundo para esse trabalho, astrina para equipes internas de produto que acompanham pode ser um complemento útil, especialmente quando uma divergência de tráfego acaba ligada a um deploy.
8. Execute a comparação novamente em uma amostra pequena antes de escalar
Comece com uma página ou um dia. Não com dez páginas. Não com um mês inteiro. Uma amostra força as regras a ficarem explícitas, o que é bom. Se a amostra incluir apenas /pricing, você pode inspecionar cada divergência manualmente e ver se o método se sustenta.
Procure estabilidade antes de amplitude. Se o mesmo filtro, a mesma regra de caminho e a mesma janela de tempo produzirem a mesma resposta duas vezes, amplie para uma segunda página. Se os números mudarem depois que você adicionar outro dia, pare e verifique se houve um deploy, uma mudança de cache ou uma rotação de logs no meio do caminho. Uma amostra pequena é mais rápida de corrigir do que uma grande.
Há uma disciplina útil aqui: altere apenas uma variável por vez. Passe de uma página para três páginas, ou de um dia para dois dias, mas não os dois ao mesmo tempo. Caso contrário, você não vai saber qual mudança quebrou a correspondência. Parece lento. É mais rápido do que voltar atrás em 40 linhas de suposições erradas.
Equipes que estão migrando de outra ferramenta de analytics costumam ver o mesmo padrão durante o trabalho de transição. Se esse for o seu caso, como migrar do Plausible é uma referência prática para manter aberta enquanto você valida a primeira amostra contra os logs.
O que verificar quando os números ainda não batem
Se a comparação ainda parecer errada após as oito etapas acima, inspecione três coisas nesta ordem: a origem do log, a regra de caminho e a janela de tempo. Não pule direto para o script de rastreamento. Um número surpreendente de “bugs de rastreamento” na verdade são bugs de extração de logs. Outra causa comum é um redirecionamento esquecido de /page para /page/.
Verifique também se a sessão do navegador termina antes de a solicitação de rastreamento ser concluída. Conexões móveis são mais frágeis do que conexões de desktop. Uma página pode carregar visualmente enquanto a chamada de analytics é cancelada. Isso faz a Astrina registrar menos visitas do que o log do servidor. O oposto pode acontecer quando o navegador tenta novamente uma solicitação e o servidor conta as duas tentativas.
Mais um detalhe: se o seu site tiver uma página ou modo de manutenção, trate esse tráfego separadamente. Um evento de manutenção muda tanto o comportamento do usuário quanto o formato do log. Se você precisar de uma referência complementar para essa situação, o que fazer quando a disponibilidade da Astrina pode ajudar a enquadrar o incidente antes de compará-lo com os logs.
As comparações mais fortes são pequenas, documentadas e repetíveis. Um escopo limpo, uma janela de tempo, solicitações de página filtradas e caminhos canônicos geralmente explicam a maior parte da diferença. O restante é onde mora o trabalho útil.
