Дневници на Squid: дали 407 по кој следи 200 се смета за неуспех?
Бројте ги завршените операции одделно од размените за автентикација кога Squid запишува предизвик по кој следи успешен тунел.
Да претпоставиме дека клиент праќа едно барање без акредитиви за прокси, добива предизвик и успешно се обидува повторно. Дневникот на барања може да содржи два записи. Но, лицето што ја користи апликацијата доживеало една завршена операција.
Затоа дневникот поделен рамномерно помеѓу TCP_DENIED/407 и TCP_TUNNEL/200 не утврдува автоматски педесет проценти стапка на неуспех. Прво утврдете дали записите образуваат парови на предизвик и повторен обид.
Бројте го она што навистина ви е важно
| Мерење | Број |
|---|---|
| Предизвици за автентикација | Одговори на проксито што бараат автентикација |
| Обиди преку прокси | Поединечни трансакции што ги запишува посредникот |
| Завршени задачи | Операции на апликацијата што го постигнуваат предвидениот резултат |
Поврзете ги временските ознаки, контекстот на клиентот, одредиштето и секој достапен идентификатор на барање. Обидот без автентикација може да нема запишано корисничко име, додека неговиот успешен повторен обид има. Истовремената активност значи дека само соседните редови се слаб доказ дека два записи припаѓаат заедно.
Успешниот тунел држете го одделно од успешната операција на веб-страницата. Прифаќањето на CONNECT го воспоставува тунелот; одредиштето сепак може да не успее за време на TLS или подоцна да врати грешка на апликацијата.
Истражете повторени завршни предизвици, задачи без подоцнежно завршување или нагла промена во бројот на размени. Тие се разликуваат од стабилен клиент што започнува со предизвик и го прави точно она што го бара неговата конфигурација. Потиснувањето на автентикацијата само за да биде контролната табла позелена би ја сменило услугата наместо да го поправи мерењето.