Rexistros de Squid: conta como fallo un 407 seguido dun 200?
Conta as operacións completadas por separado dos intercambios de autenticación cando Squid rexistra un desafío seguido dun túnel correcto.
Supoñamos que un cliente envía unha solicitude sen credenciais de proxy, recibe un desafío e volve tentar con éxito. Un rexistro de solicitudes pode conter dúas entradas. Porén, a persoa que usa a aplicación viviu unha soa operación completada.
Por iso, un rexistro dividido a partes iguais entre TCP_DENIED/407 e TCP_TUNNEL/200 non establece automaticamente unha taxa de fallos do cincuenta por cento. Primeiro determina se as entradas forman parellas de desafío e reintento.
Conta o que realmente che importa
| Medición | Reconto |
|---|---|
| Desafíos de autenticación | Respostas do proxy que solicitan autenticación |
| Tentativas de proxy | Transaccións individuais rexistradas polo intermediario |
| Traballos completados | Operacións da aplicación que acadan o resultado previsto |
Correlaciona as marcas de tempo, o contexto do cliente, o destino e calquera identificador de solicitude dispoñible. Unha tentativa sen autenticar pode non ter ningún nome de usuario rexistrado, mentres que o seu reintento correcto si o ten. A actividade simultánea fai que as liñas contiguas, por si soas, sexan unha proba feble de que dúas entradas van xuntas.
Mantén tamén un túnel correcto separado dunha operación web correcta. A aceptación de CONNECT establece o túnel; o destino aínda pode fallar durante TLS ou devolver despois un erro de aplicación.
Investiga os desafíos terminais repetidos, os traballos sen ningunha finalización posterior ou un cambio repentino no número de intercambios. Son distintos dun cliente estable que comeza cun desafío e fai exactamente o que lle pide a súa configuración. Suprimir a autenticación só para que un panel se vexa máis verde cambiaría o servizo en lugar de reparar a medición.