Ce contor de octeți Squid ar trebui să folosească o cotă de trafic?
Decideți dacă o cotă de proxy măsoară răspunsuri, cereri, corpuri din amonte sau traficul legăturii de acces înainte de a însuma câmpurile din jurnalul Squid.
„Dați fiecărui utilizator zece gigabaiți” sună precis până când două rapoarte nu se potrivesc. Unul însuma răspunsurile trimise către clienți; altul număra octeții preluați din amonte. Ambele pot raporta corect câmpul ales.
Formatul jurnalului Squid are contoare distincte:
| Câmp | Măsurătoare documentată |
|---|---|
%<st | Traficul total de răspuns trimis clientului, după adaptare |
%>st | Dimensiunea totală a cererii primite de la client, fără octeții de codificare pe bucăți |
%<bs | Octeții corpului mesajului echivalent HTTP primiți de la următorul salt, cu excepțiile documentate |
Coloana bytes din jurnalul nativ Squid folosește contorul răspunsurilor către client. Nu este o promisiune că valoarea este egală cu lungimea fișierului salvat și nici o măsurare a fiecărui octet Ethernet sau IP taxat de un furnizor de internet.
Loviturile din cache ilustrează diferența: Squid poate trimite un răspuns fără a prelua ceva nou din amonte. Munca cu multe încărcări ilustrează altceva: numărând doar răspunsurile, direcția cererilor rămâne în afara bugetului.
Pentru CONNECT, proxy-ul poate contabiliza traficul retransmis fără să înțeleagă fiecare fișier sau pagină criptată din tunel. Nu poate transforma totalul de octeți al unui tunel într-un inventar exact al obiectelor de aplicație descărcate.
Scrieți contractul cotei lângă contor: direcție, punct de observare, perioadă contabilă și identitate. Apoi păstrați versiunea formatului de jurnal împreună cu rapoartele. O neînțelegere privind sensul unui octet nu trebuie „rezolvată” înmulțind fiecare valoare cu un factor de corecție ghicit. Pentru aplicare, totalurile tranzacțiilor finalizate pot rămâne în urma utilizării în timp real.