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