Registros de Squid: ¿un 407 seguido de un 200 cuenta como fallo?
Cuenta las operaciones completadas por separado de los intercambios de autenticación cuando Squid registra un desafío seguido de un túnel correcto.
Supongamos que un cliente envía una solicitud sin credenciales de proxy, recibe un desafío y reintenta con éxito. Un registro de solicitudes puede contener dos entradas. Sin embargo, la persona que usa la aplicación vivió una sola operación completada.
Por eso, un registro dividido a partes iguales entre TCP_DENIED/407 y TCP_TUNNEL/200 no establece automáticamente una tasa de fallos del cincuenta por ciento. Primero determina si las entradas forman parejas de desafío y reintento.
Cuenta lo que realmente te importa
| Medición | Recuento |
|---|---|
| Desafíos de autenticación | Respuestas del proxy que solicitan autenticación |
| Intentos de proxy | Transacciones individuales registradas por el intermediario |
| Trabajos completados | Operaciones de la aplicación que alcanzan el resultado previsto |
Correlaciona las marcas de tiempo, el contexto del cliente, el destino y cualquier identificador de solicitud disponible. Un intento sin autenticar puede no tener ningún nombre de usuario registrado, mientras que su reintento correcto sí lo tiene. La actividad simultánea hace que las líneas contiguas, por sí solas, sean una prueba débil de que dos entradas van juntas.
Mantén también un túnel correcto separado de una operación web correcta. La aceptación de CONNECT establece el túnel; el destino aún puede fallar durante TLS o devolver un error de aplicación después.
Investiga los desafíos terminales repetidos, los trabajos sin ninguna finalización posterior o un cambio repentino en el número de intercambios. Son distintos de un cliente estable que empieza con un desafío y hace exactamente lo que le pide su configuración. Suprimir la autenticación solo para que un panel se vea más verde cambiaría el servicio en lugar de reparar la medición.