Squid žurnāli: vai 407, kam seko 200, skaitās kļūme?
Skaitiet pabeigtās operācijas atsevišķi no autentifikācijas apmaiņām, kad Squid reģistrē izaicinājumu, kam seko veiksmīgs tunelis.
Pieņemsim, ka klients nosūta vienu pieprasījumu bez proxy akreditācijas datiem, saņem izaicinājumu un veiksmīgi mēģina vēlreiz. Pieprasījumu žurnālā var būt divi ieraksti. Taču persona, kas lieto lietotni, piedzīvoja vienu pabeigtu operāciju.
Tāpēc žurnāls, kas vienmērīgi sadalīts starp TCP_DENIED/407 un TCP_TUNNEL/200, automātiski nepierāda piecdesmit procentu kļūmju līmeni. Vispirms nosakiet, vai ieraksti veido izaicinājuma un atkārtota mēģinājuma pārus.
Skaitiet to, kas jums patiešām svarīgi
| Mērījums | Skaits |
|---|---|
| Autentifikācijas izaicinājumi | Proxy atbildes, kas pieprasa autentifikāciju |
| Proxy mēģinājumi | Atsevišķi darījumi, ko reģistrē starpnieks |
| Pabeigti darbi | Lietotnes operācijas, kas sasniedz paredzēto rezultātu |
Sasaistiet laikspiedolus, klienta kontekstu, galamērķi un jebkuru pieejamo pieprasījuma identifikatoru. Neautentificētam mēģinājumam var nebūt reģistrēta lietotājvārda, savukārt tā veiksmīgajam atkārtotajam mēģinājumam tas ir. Vienlaicīga aktivitāte nozīmē, ka blakus esošās rindas vienas pašas ir vājš pierādījums tam, ka divi ieraksti pieder kopā.
Turiet arī veiksmīgu tuneli atsevišķi no veiksmīgas tīmekļa vietnes operācijas. CONNECT pieņemšana izveido tuneli; galamērķis joprojām var neizdoties TLS laikā vai vēlāk atgriezt lietotnes kļūdu.
Izpētiet atkārtotus galīgos izaicinājumus, darbus, kas vēlāk nekad netiek pabeigti, vai pēkšņas izmaiņas apmaiņu skaitā. Tie atšķiras no stabila klienta, kas sāk ar izaicinājumu un dara tieši to, ko prasa tā konfigurācija. Autentifikācijas nomākšana tikai tāpēc, lai informācijas panelis kļūtu zaļāks, mainītu pakalpojumu, nevis salabotu mērījumu.