Dzienniki Squida: czy 407, po którym następuje 200, to błąd?
Licz ukończone operacje osobno od wymian uwierzytelniania, gdy Squid zapisuje wyzwanie, po którym następuje udany tunel.
Załóżmy, że klient wysyła jedno żądanie bez poświadczeń proxy, otrzymuje wyzwanie i z powodzeniem ponawia próbę. Dziennik żądań może zawierać dwa wpisy. Osoba korzystająca z aplikacji doświadczyła jednak jednej ukończonej operacji.
Dlatego dziennik podzielony równo między TCP_DENIED/407 i TCP_TUNNEL/200 nie dowodzi automatycznie pięćdziesięcioprocentowego wskaźnika błędów. Najpierw ustal, czy wpisy tworzą pary wyzwania i ponowienia.
Licz to, na czym naprawdę ci zależy
| Miara | Liczba |
|---|---|
| Wyzwania uwierzytelniania | Odpowiedzi proxy żądające uwierzytelnienia |
| Próby proxy | Pojedyncze transakcje rejestrowane przez pośrednika |
| Ukończone zadania | Operacje aplikacji osiągające zamierzony wynik |
Powiąż znaczniki czasu, kontekst klienta, miejsce docelowe i dowolny dostępny identyfikator żądania. Nieuwierzytelniona próba może nie mieć zapisanej nazwy użytkownika, a jej udane ponowienie już ma. Równoczesna aktywność oznacza, że sąsiednie wiersze same w sobie są słabym dowodem, że dwa wpisy należą do siebie.
Utrzymuj też udany tunel oddzielnie od udanej operacji witryny. Akceptacja CONNECT ustanawia tunel; miejsce docelowe nadal może zawieść podczas TLS lub później zwrócić błąd aplikacji.
Badaj powtarzające się końcowe wyzwania, zadania bez późniejszego ukończenia lub nagłą zmianę liczby wymian. Różnią się one od stabilnego klienta, który zaczyna od wyzwania i robi dokładnie to, czego wymaga jego konfiguracja. Tłumienie uwierzytelniania tylko po to, by pulpit był bardziej zielony, zmieniłoby usługę zamiast naprawić pomiar.