Jurnalele Squid: un 407 urmat de 200 contează ca eșec?
Numărați operațiunile finalizate separat de schimburile de autentificare atunci când Squid înregistrează o provocare urmată de un tunel reușit.
Să presupunem că un client trimite o cerere fără acreditări de proxy, primește o provocare și reîncearcă cu succes. Un jurnal de cereri poate conține două intrări. Persoana care folosește aplicația a trăit însă o singură operațiune finalizată.
De aceea, un jurnal împărțit egal între TCP_DENIED/407 și TCP_TUNNEL/200 nu stabilește automat o rată de eșec de cincizeci la sută. Stabiliți mai întâi dacă intrările formează perechi de provocare și reîncercare.
Numărați ceea ce vă interesează cu adevărat
| Măsură | Număr |
|---|---|
| Provocări de autentificare | Răspunsuri ale proxy-ului care cer autentificare |
| Încercări prin proxy | Tranzacții individuale înregistrate de intermediar |
| Sarcini finalizate | Operațiuni ale aplicației care ating rezultatul dorit |
Corelați momentele de timp, contextul clientului, destinația și orice identificator de cerere disponibil. O încercare neautentificată poate să nu aibă niciun nume de utilizator înregistrat, în timp ce reîncercarea sa reușită are. Activitatea simultană înseamnă că liniile alăturate, singure, sunt o dovadă slabă că două intrări aparțin împreună.
De asemenea, păstrați un tunel reușit separat de o operațiune reușită a site-ului. Acceptarea CONNECT stabilește tunelul; destinația poate eșua în continuare în timpul TLS sau poate returna ulterior o eroare a aplicației.
Investigați provocările finale repetate, sarcinile fără nicio finalizare ulterioară sau o schimbare bruscă a numărului de schimburi. Acestea diferă de un client stabil care începe cu o provocare și face exact ceea ce cere configurația sa. Suprimarea autentificării doar pentru a face un panou mai verde ar schimba serviciul în loc să repare măsurarea.