ma hai un monitor con 5.000.000 di colonne?
potresti impostare il tuo client per spezzare le righe al 72° carattere?
è davvero difficile rispondere alle tue mail
On 20/11/2014 03:03, gerlos wrote:
Allora, io un file testuale lo so spezzare: lo faccio al newline, e conosco
mille e più modi per farlo (sed, awk, split, ed anche sh con un po’ di vodoo).
So anche concatenare i log spezzati e compressi da logrotate, per estendere una
indagine a più file log. E probabilmente sarei capace di scrivermi un “coso” in
python che emula il funzionamento di logrotate, senza essere un pythonista
cintura nera.
bene :-)
E forse sono ingenuo, ma pensavo che per fare ricerche e filtrare i contenuti
di quei log potessi usare grep, awk, sec e vim. O al peggio i miei occhi,
scorrendo le righe dei log.
ma queste sono ricerche approssimative, che non ti permettono di trovare
sempre ed esattamente e solo quello che cerchi... questo se sai cosa
cercare. Se non lo sai le cose si complicano parecchio (es: vuoi vedere
se c'è l'indizio di qualche possibile problema futuro)
Se usi i tuoi occhi, è facile farsi sfuggire qualche informazione
"interessante", quando le righe da guardare sono davvero tante.
Ripeto, sarò ingenuo, ma non capisco alcune cose (sarei felice se me le poteste
spiegare, davvero, non è polemica, è ignoranza tecnica):
1. Come si fa a “spezzare” un file binario? “dove” si fa? Con che logica
dovrebbe funzionare un clone di logrotate che funziona su un log binario?
perché lo devi spezzare? a cosa serve questa operazione?
perché dovrebbe esserci un clone di logrotate per un file binario? a
cosa servirebbe?
logrotate esiste perché:
1) i file testuali occupano molto più spazio di quello che gli
occorrerebbe per rappresentare la stessa informazione (anche l'80-90% in
più... in alcuni casi anche il 99% in più)
2) i file di log tendono a diventare enormi e questo può rallentare i
tempi necessari per analizzarli... fino a rendere inutilizzabili alcuni
programmi che cercano di leggerli
2. Il fatto che il log sia binario elimina la necessità di ruotarlo e
comprimerlo? Come?
se è binario si può diminuire l'entropia e arrivare ad occupare uno
spazio vicino al minimo indispensabile... quindi non serve comprimerlo.
Inoltre se il file è binario, nella mia ipotesi (non so effettivamente,
perché non ho ancora indagato, cosa usa systemd per i suoi log), è un
database e quindi non ha necessario neanche del punto 2, perché
l'accesso all'informazione è mantenuta bassa da indici e magari
suddivisione dell'informazione su più tabelle relazionate tra loro
3. Perché dovrei indicizzare un file di log? Cosa c’è che non va nelle ricerche
fatte ad esempio con grep semplicemente quando serve? Come potrebbe un file
binario agevolare il lavoro di tool come logcheck, per esempio? (tempo fa ho
“greppato” un log di 30MB da un server con un problema hardware che rendeva il
kernel logorroico, e sono sopravvissuto senza avere indici…)
se spezzi l'informazione in campi e crei delle tabelle relazionate tra
di loro e indicizzi l'accesso a tali tabelle, allora puoi:
* accedere ad un'informazione in tempi brevi
* fare ricerche complesse con semplici query
* avere una quantità di dati enorme e non avere problemi di attesa per
trovare un'informazione
* accedere a dati in modo esatto e non approssimativo
se usi grep, hai i problemi che ho detto sopra.
Un esempio concreto, voglio vedere gli errori che possono essere critici
che sono stati generati dall'ultimo boot (o dagli ultimi X boot).
Con systemd ho la risposta immediatamente con un semplice comando:
# journalctl -b -p 3
se dovessi usare syslog (ma in realtà i messaggi critici potrebbero
essere presenti su più log che vorrei analizzare) dovrei:
1) cercare di crearmi almeno un file (o flusso dati) che contiene almeno
tutti i log generati dall'ultimo boot e quindi prendere tutte le
rotazioni di syslog non compresse, quelle compresse (scomprimendole).
Devo usare cat, gunzip (o altro programma che devo usare per decomprimerli)
2) buttare via da tale file (flusso dati) tutte le righe che non sono
dell'ultimo boot. Con una o più grep (ma devo stare attendo a non
prendere anche altre righe che non c'entrano nulla con il log generato
dall'ultimo boot o buttarne via alcune che sono dell'ultimo boot...
potrebbe essere a cavallo di due giorni e quindi le cose si complicano
un po'... potrebbero essere stati fatti più boot nello stesso giorno...
altra complicazione)
3) a questo punto, se ho fatto le cose correttamente, devo cercare quali
sono i log che potrebbero visualizzarmi qualche criticità... e qui
iniziano i problemi più grossi, perché non esiste una regola facile per
trovarli... in pratica dovrei per ogni programma/demone/quant'altro che
scrive sui log che sto analizzando conoscere quali sono i messaggi
critici, per poterli estrarre ed estrarre solo quelli
4. Abbiate pazienza, non capisco neanche perché dovrebbe essere più semplice o
più efficiente appendere contenuti ad un file binario rispetto ad appendere una
riga ad un file testuale.
appendere?
In un file binario non aggiungi dati in fondo ad un file, ma li aggiungi
in una struttura.
5. In condizioni assurdamente disperate, potrei copiare un file log sul
computer di mio cugino ;-) su cui gira Windows, con l’intenzione di esaminarli.
Come faccio se sono binari? (se sono testuali, in assenza di meglio, posso
usare il buon vecchio Wordpad).
lo stesso lo puoi fare con il file binario.
Nella mia ipotesi è un database, ad esempio di sqlite3... e sufficiente
scaricarti sqlite3 e puoi leggerteli senza problemi su qualsiasi PC dove
si può installare sqlite3.
Mi sembra che tu stia confrontando una bicicletta con un aereo e ti
chiedi perché dovrei usare un aereo al posto di una bicicletta,
prendendo come metodo di indagine quello che fai passo passo con la tua
bicicletta e non quello che l'aereo fa. Conclusione l'aereo è inutile
perché non lo puoi usare come una bicicletta...
Ciao
Davide
PS: purtroppo ho poco tempo e non riesco a leggere tutti i messaggi :-(
--
Dizionari: http://linguistico.sourceforge.net/wiki
Petizione contro i brevetti software in Europa:
http://petition.stopsoftwarepatents.eu/
Non autorizzo la memorizzazione del mio indirizzo su outlook
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
[email protected] con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a [email protected]
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: https://lists.debian.org/[email protected]
