Którego licznika bajtów Squida powinien używać limit ruchu?
Zdecyduj, czy limit proxy mierzy odpowiedzi, żądania, treści z serwera nadrzędnego czy ruch łącza dostępowego, zanim zsumujesz pola logu Squida.
„Daj każdemu użytkownikowi dziesięć gigabajtów” brzmi precyzyjnie, dopóki dwa raporty się nie różnią. Jeden sumował odpowiedzi wysłane do klientów; drugi liczył bajty pobrane z serwera nadrzędnego. Oba mogą poprawnie raportować wybrane pole.
Format logu Squida ma odrębne liczniki:
| Pole | Udokumentowany pomiar |
|---|---|
%<st | Łączny ruch odpowiedzi wysłany do klienta, po adaptacji |
%>st | Łączny rozmiar żądania odebranego od klienta, bez bajtów kodowania chunked |
%<bs | Bajty treści komunikatu w odpowiedniku HTTP odebrane od następnego węzła, z udokumentowanymi wyjątkami |
Kolumna bytes w natywnym logu Squida używa licznika odpowiedzi do klienta. Nie jest to obietnica, że wartość równa się długości zapisanego pliku, ani pomiar każdego bajtu Ethernet lub IP, za który pobiera opłatę dostawca internetu.
Trafienia w pamięć podręczną pokazują różnicę: Squid może wysłać odpowiedź bez świeżego pobrania od serwera nadrzędnego. Praca z dużym wysyłaniem pokazuje inną: licząc tylko odpowiedzi, kierunek żądań zostaje poza budżetem.
W przypadku CONNECT proxy może rozliczać przekazywany ruch bez rozumienia każdego zaszyfrowanego pliku czy strony w tunelu. Nie może zamienić sumy bajtów tunelu w dokładny wykaz pobranych obiektów aplikacji.
Zapisz umowę limitu obok licznika: kierunek, punkt obserwacji, okres rozliczeniowy i tożsamość. Następnie przechowuj wersję formatu logu razem z raportami. Nieporozumienia co do znaczenia bajta nie należy „naprawiać”, mnożąc każdą wartość przez zgadywany współczynnik korekcyjny. Do egzekwowania sumy zakończonych transakcji mogą pozostawać za bieżącym użyciem.