Кой брояч на байтове в Squid да използва квотата за трафик?
Решете дали квотата на прокси измерва отговори, заявки, тела към upstream или трафик на връзката за достъп, преди да сумирате полетата на журнала на Squid.
„Дай на всеки потребител десет гигабайта“ звучи точно, докато два отчета не се разминат. Единият сумира отговорите, изпратени към клиентите; другият брои байтовете, изтеглени от upstream. И двата може да отчитат правилно избраното от тях поле.
Форматът на журнала на Squid има отделни броячи:
| Поле | Документирано измерване |
|---|---|
%<st | Общ трафик на отговорите, изпратени към клиента, след адаптация |
%>st | Общ размер на заявката, получена от клиента, без байтовете за chunked кодиране |
%<bs | Байтове на тялото на съобщението, еквивалентни на HTTP, получени от следващия хоп, с документирани изключения |
Колоната за байтове в собствения журнал на Squid използва брояча на отговорите към клиента. Това не е обещание, че стойността е равна на дължината на запазения файл, нито измерване на всеки Ethernet или IP байт, таксуван от доставчика.
Попаденията в кеша показват разликата: Squid може да изпрати отговор, без да прави ново изтегляне от upstream. Работата с много качване показва друга: броенето само на отговори оставя посоката на заявките извън бюджета.
При CONNECT проксито може да отчита препредавания трафик, без да разбира всеки криптиран файл или страница в тунела. То не може да превърне общия брой байтове на тунела в точен опис на изтеглените обекти на приложенията.
Запишете договора за квота до брояча: посока, точка на наблюдение, отчетен период и идентичност. След това съхранявайте версията на формата на журнала заедно с отчетите. Разногласието какво означава един байт не бива да се „поправя“ чрез умножаване на всяка стойност по предполагаем коригиращ коефициент. За налагане сумите на завършените транзакции може да изостават от текущото използване.