Který bajtový čítač Squidu má používat kvóta provozu?
Rozhodněte, zda kvóta proxy měří odpovědi, požadavky, těla směrem k upstreamu, nebo provoz přístupového spoje, než sečtete pole logu Squidu.
„Dejte každému uživateli deset gigabajtů“ zní přesně, dokud se dva přehledy nerozejdou. Jeden sečetl odpovědi odeslané klientům; druhý počítal bajty stažené z upstreamu. Oba mohou svěřené pole vykazovat správně.
Formát logu Squidu má samostatné čítače:
| Pole | Dokumentované měření |
|---|---|
%<st | Celkový provoz odpovědí odeslaných klientovi po adaptaci |
%>st | Celková velikost požadavku přijatého od klienta bez bajtů chunked kódování |
%<bs | Bajty těla zprávy ekvivalentní HTTP přijaté od dalšího skoku, s dokumentovanými výjimkami |
Sloupec bajtů nativního logu Squidu používá čítač odpovědí klientovi. Není to slib, že se hodnota rovná délce uloženého souboru, ani měření každého ethernetového či IP bajtu účtovaného poskytovatelem.
Zásahy do cache ukazují rozdíl: Squid může odeslat odpověď bez nového načtení z upstreamu. Práce s velkým odesíláním ukazuje jiný: počítání jen odpovědí nechává směr požadavku mimo rozpočet.
U CONNECT může proxy účtovat přeposílaný provoz, aniž by rozuměla každému šifrovanému souboru či stránce v tunelu. Nedokáže však celkový počet bajtů tunelu převést na přesný seznam stažených objektů aplikací.
Smlouvu o kvótě napište vedle čítače: směr, pozorovací bod, zúčtovací období a identitu. Potom uchovávejte verzi formátu logu spolu s přehledy. Nesoulad v tom, co bajt znamená, by se neměl „opravovat“ násobením každé hodnoty odhadnutým opravným koeficientem. Pro vymáhání součty dokončených transakcí mohou zaostávat za živým využitím.