Dnevniki Squid: ali se 407, ki mu sledi 200, šteje kot napaka?
Štejte dokončane operacije ločeno od izmenjav preverjanja pristnosti, ko Squid zabeleži izziv, ki mu sledi uspešen tunel.
Predpostavimo, da odjemalec pošlje eno zahtevo brez poverilnic proxyja, prejme izziv in uspešno poskusi znova. Dnevnik zahtev lahko vsebuje dva vnosa. Oseba, ki uporablja aplikacijo, pa je doživela eno dokončano operacijo.
Zato dnevnik, enakomerno razdeljen med TCP_DENIED/407 in TCP_TUNNEL/200, samodejno ne dokazuje petdesetodstotne stopnje napak. Najprej ugotovite, ali vnosi tvorijo pare izziva in ponovnega poskusa.
Štejte tisto, kar vam je res pomembno
| Meritev | Število |
|---|---|
| Izzivi preverjanja pristnosti | Odgovori proxyja, ki zahtevajo preverjanje pristnosti |
| Poskusi proxyja | Posamezne transakcije, ki jih zabeleži posrednik |
| Dokončana opravila | Operacije aplikacije, ki dosežejo predvideni izid |
Povežite časovne žige, kontekst odjemalca, cilj in vsak razpoložljivi identifikator zahteve. Neoverjen poskus morda nima zabeleženega uporabniškega imena, medtem ko ga njegov uspešni ponovni poskus ima. Sočasna dejavnost pomeni, da so sosednje vrstice same po sebi šibek dokaz, da dva vnosa sodita skupaj.
Uspešen tunel hranite ločeno od uspešne operacije spletnega mesta. Sprejetje CONNECT vzpostavi tunel; cilj lahko še vedno ne uspe med TLS ali pozneje vrne napako aplikacije.
Preverite ponavljajoče se končne izzive, opravila brez poznejše dokončanja ali nenadno spremembo števila izmenjav. To se razlikuje od stabilnega odjemalca, ki se začne z izzivom in naredi natanko to, kar zahteva njegova konfiguracija. Zatiranje preverjanja pristnosti samo zato, da bi bila nadzorna plošča bolj zelena, bi spremenilo storitev, namesto da bi popravilo meritev.