Estatísticas da porta de proxy
A porta 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 a porta está desafiando visitantes em vez de deixar passar um visitante liberado?" É como você confirma que a porta está ligada e afinada, 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 da porta é 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 ao jogo.
- Passe emitido: um visitante resolveu o jogo e um passe foi cunhado (o callback então definiu o cookie).
- Negado: o autorizador rejeitou a requisição sob uma política fail-closed enquanto não conseguia confirmar um passe.
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 a porta, 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ê resolver, 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.
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 em fail-open do seu proxy. Quando o seu proxy está configurado em fail-open e o Caputchin está inalcançável, o proxy deixa a requisição passar por conta própria; o Caputchin nunca a vê, então ela não pode ser contada aqui.
- 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 é a porta e o cookie de liberação.
- Configure a porta de 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.