Squid žurnalai: ar 407, po kurio seka 200, laikomas gedimu?
Skaičiuokite užbaigtas operacijas atskirai nuo autentifikavimo mainų, kai Squid įrašo iššūkį, po kurio seka sėkmingas tunelis.
Tarkime, klientas išsiunčia vieną užklausą be proxy kredencialų, gauna iššūkį ir sėkmingai bando dar kartą. Užklausų žurnale gali būti du įrašai. Tačiau programą naudojantis asmuo patyrė vieną užbaigtą operaciją.
Todėl žurnalas, po lygiai padalytas tarp TCP_DENIED/407 ir TCP_TUNNEL/200, savaime neįrodo penkiasdešimt procentų gedimų dažnio. Pirmiausia nustatykite, ar įrašai sudaro iššūkio ir pakartotinio bandymo poras.
Skaičiuokite tai, kas jums iš tikrųjų svarbu
| Matas | Skaičius |
|---|---|
| Autentifikavimo iššūkiai | Proxy atsakymai, reikalaujantys autentifikavimo |
| Proxy bandymai | Atskiros transakcijos, kurias įrašo tarpininkas |
| Užbaigti darbai | Programos operacijos, pasiekiančios numatytą rezultatą |
Suskirkite laiko žymes, kliento kontekstą, paskirties vietą ir bet kokį prieinamą užklausos identifikatorių. Neautentifikuotas bandymas gali neturėti įrašyto vartotojo vardo, o sėkmingas pakartotinis bandymas jį turi. Vienu metu vykstanti veikla reiškia, kad gretutinės eilutės pačios savaime yra silpnas įrodymas, kad du įrašai priklauso kartu.
Sėkmingą tunelį taip pat laikykite atskirai nuo sėkmingos svetainės operacijos. CONNECT priėmimas sukuria tunelį; paskirties vieta vis tiek gali nepavykti TLS metu arba vėliau grąžinti programos klaidą.
Tyrinėkite pasikartojančius galutinius iššūkius, darbus, kurie vėliau niekada nebaigiami, ar staigų mainų skaičiaus pokytį. Tai skiriasi nuo stabilaus kliento, kuris pradeda iššūkiu ir daro būtent tai, ko reikalauja jo konfigūracija. Autentifikavimo slopinimas vien tam, kad prietaisų skydelis būtų žalesnis, pakeistų paslaugą, o ne pataisytų matavimą.