Кој бројач на бајти на Squid треба да го користи квотата за сообраќај?
Одлучете дали квотата на проксито мери одговори, барања, тела од горниот слој или сообраќај на пристапната врска, пред да ги соберете полињата од дневникот на Squid.
„Дајте му на секој корисник десет гигабајти” звучи прецизно сè додека два извештаја не се разидат. Едниот ги собираше одговорите испратени до клиентите; другиот ги броеше бајтите преземени од горниот слој. И двата можеби го пријавуваат своето избрано поле точно.
Форматот на дневникот на Squid има посебни бројачи:
| Поле | Документирано мерење |
|---|---|
%<st | Вкупен сообраќај на одговор испратен до клиентот, по приспособувањето |
%>st | Вкупна големина на барање примено од клиентот, без бајтите за chunked кодирање |
%<bs | Бајти на HTTP-еквивалентно тело на порака примено од следниот хоп, со документирани исклучоци |
Колоната bytes во изворниот дневник на Squid го користи бројачот на одговор кон клиентот. Тоа не е ветување дека вредноста е еднаква на должината на зачуваната датотека, ниту пак мерење на секој Ethernet или IP бајт што го наплатува ISP.
Ударите во кешот ја илустрираат разликата: Squid може да испрати одговор без свежо преземање од горниот слој. Работата со многу поставувања илустрира друго: броењето само одговори ја остава насоката на барањата надвор од буџетот.
За CONNECT, проксито може да го евидентира пренесениот сообраќај без да ја разбира секоја шифрирана датотека или страница во тунелот. Не може вкупниот број бајти на тунелот да го претвори во точен попис на преземени апликациски објекти.
Запишете го договорот за квота до бројачот: насока, точка на набљудување, пресметковен период и идентитет. Потоа чувајте ја верзијата на форматот на дневникот со извештаите. Несогласувањето за тоа што значи еден бајт не треба да се „поправа” со множење на секоја вредност со претпоставен корекциски фактор. За спроведување вкупните износи на завршените трансакции може да заостануваат зад живата употреба.