Newsgroup: it.comp.os.linux.sys
Titolo: Snellire access.log di squid

Ciao a tutti.
Squid configurato per l' autenticazione NTLM e come giusto che sia per
ogni richiesta fatta da un client nell' access.log trovo prima
bla bla TCP_DENIED/407 bla bla
bla bla TCP_DENIED/407 bla bla
bla bla TCP_DENIED/407 bla bla
bla bla TCP_MISS/200 bla bla
tanto che...
cat access.log | wc -l
453
cat access.log | grep -v "TCP_DENIED/407" | wc -l
237
Ho già creato un "logformat" alleggerito di dati al momento non
necessari, ma siccome i log saranno da tenere per x=mesi esiste un
modo di evitare di aver un access.log senza i suddetti TCP_DENIED/
407 ?
o devo per forza ritrattare i log pulendoli nel momento della
rotazione?

 rotazione?
Potresti gestirli tramite syslog e quindi seccare le linee 407 alla fonte
direttamente con rsyslog o syslog-ng.
Personalmente se possibile preferisco gestire sempre tutti i log tramite
syslog, sia quelli di sistema che di squid, apache, ecc.ecc. dato che cosě,
oltre a poter fare elaborazioni online, mi evito anche di dover gestire con
logrotate la rotazione ed ho i log che vanno dalle 00:00:00 alle 23:59:59
precisi senza interruzioni, nominati con la data corretta e giŕ suddivisi
per mese (o giorno).
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 syslog, sia quelli di sistema che di squid, apache, ecc.ecc.
Purtroppo non e` sempre possibile, in quanto l'applicativo potrebbe non 
implementare le chiamate necessarie ad impostare un server syslog che riceva 
i messaggi di log generati. Tra questi, poi, ci sono proprio i server web ed 
i proxy, in quanto, come motivazione ufficiale, viene riportato il fatto che 
una chiamata al syslog potrebbe impattare sulle performance del servizio
Enrico

 una chiamata al syslog potrebbe impattare sulle performance del servizio
Penso che in genere un accesso a disco sia più impattante di una chiamata
syslog. In ogni caso se uno arriva ad aver problemi di performance per il
logging vuol dire che ha spremuto lo spremibile dal resto del sistema, e non
sono certo io che può insegnarli come ottimizzare ulteriormente le
performances :-)
Ma presumo sia cosa molto rara e non sia il problema dell'OP.


 cos tanto spazio a disposizione????
E' presto per dire quante linee di log saranno generate giornalmente,
per ora siamo in test con 5 utenti che presto diventeranno 250/300.
Non è un problema di spazio...ma seguendo i tuoi calcoli... perchè
avere mediamente circa un 25% di informazioni nei log di squid
completamente inutili e che ti incasinano la lettura dei log?

 completamente inutili e che ti incasinano la lettura dei log?
Perché asserisci che siano inutili? Il fatto che *oggi* non ti servano è
garanzia che in futuro non ti serviranno mai?
Togliere informazioni è un'operazione distruttiva che si può fare quando si
vuole, mentre ricostruire le informazioni tagliate non è possibile.
Se mantenere le informazioni comporta un aumento di costo (
p.es
. necessità
di acquistare più spazio disco, penalizzazione di performance, ecc.ecc.) o
rende impossibile eseguire un filtraggio a posteriori delle informazioni non
strettamente necessarie (perché per esempio non puoi discriminare la
provenienza dell'informazione dall'informazione stessa) allora ha senso
ridurre il logging e probabilmente ha senso farlo direttamente alla fonte.
Se invece come in questo caso il costo è praticamente lo stesso (non penso
che pochi GB di spazio siano un problema anche per te) e le informazioni
puoi comunque filtrarle in qualsiasi momento anche dopo averle salvate (di
fatto già adesso fai così), allora è inutile e potenzialmente dannoso
eliminare quelle informazioni anche se *adesso* sono superflue e non vedi un
modo proficuo per utilizzarle.
I log li leggi senza problemi ugualmente, basta che elimini l'informazione
superflua nel momento del bisogno:
zgrep -v 'DENIED/407' /var/log/squid/access-20101124.log.tgz | less


 garanzia che in futuro non ti serviranno mai?
Direi che questo tipo di informazione, dato che è assodata o comunque
attesa possa essere tranquillamente tralasciata...
Ma se domani un servizio al momento del login di un utente ti dovesse
scrivere in un log:
DEVO CHIEDERE LA PASSWORD A PIPPO
DEVO CHIEDERE LA PASSWORD A PIPPO
DEVO CHIEDERE LA PASSWORD A PIPPO
DEVO CHIEDERE LA PASSWORD A PIPPO
DEVO CHIEDERE LA PASSWORD A PIPPO
DEVO CHIEDERE LA PASSWORD A PIPPO
DEVO CHIEDERE LA PASSWORD A PIPPO
DEVO CHIEDERE LA PASSWORD A PIPPO
DEVO CHIEDERE LA PASSWORD A PIPPO
DEVO CHIEDERE LA PASSWORD A PIPPO
PIPPO HA SCRITTO LA PASSWORD CORRETTA
accetteresti di avere un 90% di informazioni completamente superflue?
Già ora greppo -v "DENIED/407"
La domanda iniziale non era con il fine di trovare una soluzione per
stare dentro a limiti stretti... ma è per cercare di migliorare dove
possibile evitando sprechi...

 possibile evitando sprechi...
Ecco, trattasi di differenza di vedute. Quella notifica di squid non è
totalmente inutile perché può aiutare in caso di problemi, quindi eliminarlo
è dannoso, non è certo un miglioramento.
Però come detto libero di fare quel che ritieni migliore; una soluzione per
farlo te l'ho indicata: rsyslog.


 compresso con bzip2 sono 3.6MB.
mi intrometto.
log di rsync. dimensione: circa 4GB.
compresso in bzip: inferiore a 10MB
non scherzo, ho compresso più volte il log di rsync e tutte le volte
diventa una manciata di mega
partendo da 2-3-4GB (giga)
non credo sia un problema archiviare i log, se si comprimono in bzip e
magari in -9

 Ma è cosa rara ed esistono quasi sempre i workaround
Non sempre, e non sempre e` possibile applicarli. Ad esempio per Nginx vi 
sono un paio di patch che permettono di implementare le chiamate a syslog, 
questo significa doversi tenere una copia ad hoc del software, senza 
considerare che l'operazione di applicazione della patch e la successiva 
compilazione non e` alla portata di tutti (anche se un sysadmin dovrebbe 
esserne capace...)
Enrico

possibile evitando sprechi...
Legge di Amdahl. Anche il cercare di migliorare e' un costo... e va visto
quanto conviene.
Leonardo
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!


A questo non avevo pensato effettivamente.

Mmm...
# sarg -x -i
SARG: getword loop detected.
SARG: searching for 'x20'
SARG: Maybe you have a broken record or garbage in your access.log
file.
L' access.log è nel formato 'nativo' di squid senza modifiche...
Debian lenny (5.0.6), mo perchè anche SARG c'è l' ha con me?
WTF?

 WTF?
prova con:
LANG=en_US.UTF-8 sarg -x -i
