Estatísticas do portão de página no proxy
O portão mantém as próprias estatísticas, separadas das estatísticas de verificação de uma chave de site. A página de verificação responde "pessoas reais estão passando pelo jogo?"; esta página responde a uma pergunta mais estreita: "com que frequência o portão está desafiando visitantes em vez de deixar passar um visitante liberado?" É como você confirma que o portão está ligado e afinado, e é a mesma superfície na qual o modo prévia escreve enquanto você ainda testa.
Onde ela vive
Há duas visões:
- Por chave de site: a página Estatísticas de proxy sob uma chave de site, para uma origem protegida.
- Por equipe: a página Estatísticas de proxy no nível da equipe, agregada por cada chave de site na equipe.
Ambas precisam do plano Alpha ou superior; abaixo disso a página mostra um cartão de upgrade em vez.
As quatro contagens
Cada decisão do portão é registrada como uma de quatro espécies:
- Passagem direta: uma requisição chegou com um passe válido e foi permitida. Esta é a condição de vitória; um visitante liberado navegando o site gera estas.
- Desafio mostrado: uma requisição não tinha um passe válido, então o visitante foi enviado à verificação.
- Passe emitido: um visitante completou a verificação e um passe foi cunhado (o callback então definiu o cookie).
- Negado: chegou uma requisição levando um passe que não era válido: expirado, adulterado, ou emitido para outra chave de site. Uma primeira visita sem cookie nenhum não é contada aqui; isso aparece como um desafio.
A razão de passagem direta sobre desafio
O número de destaque é a passagem direta relativa aos desafios. Uma vez que os visitantes liberam o portão, a maioria das requisições deles deveria ser passagem direta, com um desafio só no início de uma visita ou depois que um passe expira. Uma razão de passagem direta alta significa que a sua TTL de liberação está fazendo o trabalho, uma única resolução compra muitas requisições. Se os desafios ficam altos relativos à passagem direta, a TTL pode estar curta demais (visitantes re-desafiados no meio da sessão) ou o cookie não está sendo definido (confira o callback).
Lendo-a durante o rollout
Enquanto o modo prévia está ligado, fique de olho na sequência em uma única visita de teste: um challenge_served (ainda sem cookie), depois um pass_issued após você passar na verificação, depois passthrough subindo enquanto você recarrega. Desafios ausentes significam que o bloco do autorizador não está sendo atingido; um pass_issued que nunca vira passagem direta significa que o cookie não está grudando.
As contagens são próximas, não exatas
Os resultados do portão são agrupados em lotes antes de serem gravados, então um contador pode perder alguns eventos se a edge se reciclar no meio de um segundo. Razões e tendências são confiáveis; trate uma contagem individual como bem próxima, não como exata, especialmente em um site de pouco movimento.
Retenção
O histórico é retido por camada de plano e os buckets mais antigos são podados em um agendamento diário, então a janela sobre a qual você pode olhar para trás se alarga com o seu plano. A razão ao vivo e a atividade recente estão sempre disponíveis.
O que não está aqui
- Sem passagens diretas nem bloqueios de modo de falha vindos do seu proxy. Fail-open e fail-closed são decisões que o seu proxy toma quando não consegue alcançar o Caputchin. O Caputchin nunca vê essas requisições, então nenhum dos dois desfechos aparece aqui, em coluna nenhuma.
- Sem dados por visitante. Só contagens, sem IP, sem user agent, sem conteúdo de requisição, em linha com a postura de privacidade do Caputchin.
Veja também
- Visão geral: o que é o portão e o cookie de liberação.
- Configure o portão de página no proxy: o modo prévia escreve nesta superfície antes de você ir ao ar.
- Estatísticas de verificação hospedada: a superfície equivalente para a opção sem backend.