Registos do Squid: um 407 seguido de 200 conta como falha?
Conte as operações concluídas separadamente das trocas de autenticação quando o Squid regista um desafio seguido de um túnel bem-sucedido.
Suponhamos que um cliente envia um pedido sem credenciais de proxy, recebe um desafio e tenta novamente com sucesso. Um registo de pedidos pode conter duas entradas. A pessoa que usa a aplicação viveu, porém, uma única operação concluída.
Por isso, um registo dividido igualmente entre TCP_DENIED/407 e TCP_TUNNEL/200 não estabelece automaticamente uma taxa de falhas de cinquenta por cento. Primeiro determine se as entradas formam pares de desafio e nova tentativa.
Conte aquilo que realmente lhe importa
| Medição | Contagem |
|---|---|
| Desafios de autenticação | Respostas do proxy que pedem autenticação |
| Tentativas de proxy | Transações individuais registadas pelo intermediário |
| Tarefas concluídas | Operações da aplicação que atingem o resultado pretendido |
Correlacione marcas temporais, contexto do cliente, destino e qualquer identificador de pedido disponível. Uma tentativa sem autenticação pode não ter nome de utilizador registado, enquanto a sua nova tentativa bem-sucedida tem. Atividade simultânea significa que linhas adjacentes, por si só, são prova fraca de que duas entradas pertencem uma à outra.
Mantenha também um túnel bem-sucedido separado de uma operação de site bem-sucedida. A aceitação de CONNECT estabelece o túnel; o destino ainda pode falhar durante o TLS ou devolver depois um erro da aplicação.
Investigue desafios finais repetidos, tarefas sem conclusão posterior ou uma mudança súbita no número de trocas. Estes casos diferem de um cliente estável que começa com um desafio e faz exatamente o que a sua configuração exige. Suprimir a autenticação apenas para tornar um painel mais verde alteraria o serviço em vez de reparar a medição.