Журналы Squid: считается ли 407, за которым следует 200, сбоем?
Считайте завершённые операции отдельно от обменов аутентификации, когда Squid записывает запрос учётных данных, за которым следует успешный туннель.
Предположим, клиент отправляет один запрос без учётных данных прокси, получает запрос учётных данных и успешно повторяет попытку. В журнале запросов может быть две записи. Но человек, использующий приложение, пережил одну завершённую операцию.
Поэтому журнал, поделённый поровну между TCP_DENIED/407 и TCP_TUNNEL/200, сам по себе не означает пятидесятипроцентную долю сбоев. Сначала определите, образуют ли записи пары «запрос и повтор».
Считайте то, что действительно важно
| Показатель | Число |
|---|---|
| Запросы аутентификации | Ответы прокси с требованием аутентификации |
| Попытки прокси | Отдельные транзакции, зафиксированные посредником |
| Завершённые задачи | Операции приложения, достигающие нужного результата |
Сопоставьте отметки времени, контекст клиента, назначение и любой доступный идентификатор запроса. У неаутентифицированной попытки может не быть записанного имени пользователя, а у её успешного повтора оно есть. Одновременная активность означает, что соседние строки сами по себе — слабое доказательство того, что две записи относятся друг к другу.
Также держите успешный туннель отдельно от успешной операции с сайтом. Принятие CONNECT устанавливает туннель; назначение всё равно может отказать во время TLS или позже вернуть ошибку приложения.
Исследуйте повторяющиеся финальные запросы, задачи без последующего завершения или резкое изменение числа обменов. Это отличается от стабильного клиента, который сначала получает запрос учётных данных и делает именно то, что требует его конфигурация. Подавление аутентификации только ради более зелёной панели изменило бы сервис, а не исправило измерение.