Re: Log testuali vs binari [Era Re: Debian systemd maintainer resigns due to online bullying + risultati votazione DD]
On 21/11/2014 10:47, Gian Uberto Lauri wrote:
Davide Prina writes:
> ma hai un monitor con 5.000.000 di colonne?
Purtroppo è negli standard l'uso del terminatore di riga per
terminare il paragrafo.
cosa c'entra questo?
In pratica non si fanno assunzioni sulla larghezza della "pagina" su
cui viene reso il messaggio e il client dovrebbe autonomamente fare il
word wrap.
è nelle risposte il problema, se la riga non è spezzata non si riesce a
vedere bene a cosa si risponde.
Tutti i client di posta permettono di indicare a quanto spezzare le righe.
Poi non capisco perché nelle tue risposte metti il triplo degli spazi
necessari nell'indentazione...
> > 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)
Anche con gli indici, che cavolo!
e cosa c'entrano gli indici?
Gli indici servono, al massimo, per velocizzare determinati tipi di
ricerca, non, in generale, per effettuare ricerche.
Qui si sta parlando di usare un file strutturato, se il file è
strutturato riesci a fare ricerche esatte su un determinato campo. Se
non lo è, come un file di testo, allora le ricerche sono quasi sempre
approssimative (ci possono essere falsi positivi di altri elementi su
cui non si voleva ricercare).
Un indice serve solo a rendere le rapida la ricerca, a patto
ovviamente che il tuo pattern di ricerca sia in grado di sfruttare
l'eventuale indice e non costringa ad andare in ogni caso in "full
table scan" (databasese per "smazzarsi tutti i dati").
no, l'indice serve principalmente per mettere in relazione "veloce"
diverse strutture. Nel caso di un database relazionale le strutture sono
le tabelle.
Possono essere creati degli indici appositi per ricerche "standard", ma
per il resto non è detto che la clausola che determina la ricerca usi un
indice.
> Se usi i tuoi occhi, è facile farsi sfuggire qualche informazione
> "interessante", quando le righe da guardare sono davvero tante.
Ma su questo non ti aiutano gli indici, ma tool di analisi dei log.
accidenti, ma non eri tu che dicevi che a volte hai disposizione cat e
poco altro... come fai ad usare questi tool in queste situazioni?
Perché usare un tool esterno, quando systemd ti offre un tool interno
che è ottimizzato al massimo per tali analisi? Che è aggiornato
costantemente per trovare il tipo di problema che ti interessa e non
devi aspettare una versione nuova del tool esterno quando cambia qualcosa?
> > 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 serve a permettere comprimere dati vecchi.
non è proprio così, logrotate serve principalmente a imporre delle
regole di mantenimento dei log per evitare che questi occupino troppo
spazio e che creino file troppo grandi. Logrotate può cancellarmi oggi
log raccolti 10 anni fa o 10 secondi fa... con le stesse regole...
dipende da quanti messaggi finiscono nel log. Non si può chiamare
vecchio un log di 10 secondi fa.
> 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ù)
Ma non spariamo cifre lanciando dadi.
Se è vero che, per fare un esempio, "yyyymmdd hh:mm:ss.fff" sono 21
byte contro 8 con meno di 7 bit di informazione per byte, è anche vero
che c'è ridondanza anche nei valori binari. Conta tutta una sequenza
di timestamp di eventi relativi all'ultima ora hanno tutti i 5 byte
più alti uguali. E questa è ridondanza che un compressore sa eliminare.
prima di tutto esistono molte teorie di compressione e ognuna si basa su
basi molto diverse tra di loro. Tutto dipende dall'entropia. Un file
binario, in generale, ha un'entropia nettamente più bassa di un file di
testo. Basta questo per capire che la compressione di un file testuale
avrà percentuali altissime rispetto a quanto si può applicare
normalmente ad un file binario. Tutto questo perché il file binario, se
è fatto in modo corretto, ha già ridotto l'entropia.
> > 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.
Errato. Arriva a risparmiare spazio. Ma non arriva al minimo di ridondanza
(la compressione elimina la ridondanza, non credo l'entropia).
No, la compressione riduce l'entropia e non può andare oltre al limite
minimo d'entropia che può avere l'informazione (c'è un teorema che dice
questo!). In realtà, in generale, non si riesce a creare un algoritmo
che arrivi al limite inferiore... altrimenti non ci sarebbe la "lotta"
che c'è attualmente tra vari metodi di compressione... ormai da molti
anni (non sono i programmi che si usano usualmente, ma alcuni sono solo
sperimentali e servono a dimostrare che si riesce ad avvicinarsi a tale
limite più degli altri, i programmi di test magari possono solo
comprimere un solo file e magari registrano solo il suo contenuto in un
output che ha sempre lo stesso nome).
Entropia e ridondanza hanno delle caratteristiche comuni: più è alta la
ridondanza e più è alta l'entropia.
Però l'entropia non può essere mai zero (se si esclude il caso limite di
messaggio vuoto).
Però devi pagare lo spazio per gli indici.
cosa c'entra questo?
La domanda era perché, normalmente, non si ruota/comprime un file binario?
In un log strutturato puoi decidere di mantenere per 30 giorni i log
critici, 20 giorni quelli importanti, 10 giorni i warning, 5 giorni le
segnalazioni, 2 giorni i messaggi informativi. Basterebbe fare una cosa
del genere per risparmiare spazio... se lo vuoi risparmiare. Ma ripeto,
non era questa la domanda.
> 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
Questo lo ottieni inviando (via syslog) i dati ad un logserver dove i
dati entrano in un database. E allora lì ti metti una macchina
dedicata sufficientemente carrozzata per ricevere tutti i messaggi ed
indicizzarli efficientemente.
certamente, quindi ammetti che in alcuni casi l'uso di soli log di testo
non è ottimale, ti serve qualcos'altro... quel qualcos'altro che systemd
già ti offre di default.
Ma questo lo fai tranqillissimamente anche con dati in formato testo.
non è detto.
Mi è sembrato di aver già dato esempi per questo argomento e non ci
ritorno su ancora.
Per altro "Log data collected by the journal is primarily text-based
but can also include binary data where necessary. All objects stored
in the journal can be up to 2^64-1 bytes in size."
?
> * avere una quantità di dati enorme e non avere problemi di attesa per
> trovare un'informazione
Oppure tempi lunghi per calcolare gli indici. Di solito il tempo di
indicizzazione "non lo senti" dato che viene speso un po' alla volta,
record per record.
non è proprio così.
Se crei una tabella e devi immettere tanti dati, allora è meglio che
prima metti i dati in tabella e poi crei gli indici... è nettamente più
veloce. Se devi inserire tanti dati in una tabella sarebbe meglio fare
il drop degli indici, inserire i dati e ricrearli.
Qui si devono fare altre considerazioni. Su una macchina personale
dove oltre il 90% del tempo lo passi in idle, il costo è sostenibile.
dipende da molti fattori, ma in generale la gestione degli indici incide
poco.
Tienti anche le copie in ASCII
ma c'è ancora qualcuno che usa la codifica ASCII? :-)
Forse è per questo che ti poni così tanti problemi per i tuoi server...
stai usando macchine e sistemi di qualche decina di anni fa ;-)
> > 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.
Append. È strutturato il record, ma è il prossimo record (e i record
non hanno nemmeno grandezza fissa) e quindi si va in append.
?
Qui si sta parlando di un file binario e, normalmente, in un file
binario i dati non sai dove vengono messi... non è detto che vengano
messi in fondo. Per questo il nuovo record inserito potrebbe poi essere
prelevato come primo e non ultimo, se non viene messo anche un ordinamento.
> > 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.
Devi trovare un sqlite che abbia lo stesso formato ed avere una
macchina con la stessa endianity. Per i pc non è un problema, sono
tutti little endian oramai. Ooops, il file sqllite è stato scritto
da un segmento big endian del tuo server bi-endian...
lo stesso per i file di testo, se usi una codepage non compatibile con
il tuo sistema di arrivo avrai problemi analoghi.
Anzi ti dirò di più, se vai su una macchina con windows avrai grossi
problemi... da quello che ho letto sembra che i programmi di
lettura/scrittura standard di tale piattaforma non siano in grado di
leggere file, ad esempio, UTF-8 se non c'è il BOM
Ciao
Davide
--
Dizionari: http://linguistico.sourceforge.net/wiki
Strumenti per l'ufficio: https://www.libreoffice.org
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook
Reply to: