Log testuali vs binari [Era Re: Debian systemd maintainer resigns due to online bullying + risultati votazione DD]
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.
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.
> > 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!
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").
> 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.
> > 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.
> 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.
> > 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).
Però devi pagare lo spazio per gli indici.
> 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.
Ma questo lo fai tranqillissimamente anche con dati in formato testo.
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."
> > 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:
>
> * fare ricerche complesse con semplici query
No. Non sono i file in formato fisso o con dati in binario (occhio, ci
sono file con record a formato fisso di puro testo e file binari con
record a formato variabile) a permettere questo. Casomai sono gli
strumenti di indagine e indicizzazione.
journald è un piccolo db dedicato, probabilmente una buona scelta
per una macchina personale stand alone. Per altre situazioni meglio
altro.
> * 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.
Qui si devono fare altre considerazioni. Su una macchina personale
dove oltre il 90% del tempo lo passi in idle, il costo è sostenibile.
Altrimenti passa il record ad una macchina dedicata per l'indicizzazione
e tienine anche copia leggibile con i mezzi più primitivi (utili quanto
tutto il resto va a quel paese)
> * accedere a dati in modo esatto e non approssimativo
Non è che senza non ci arrivi. Sicuro, diventa più laborioso. Ma
sempre possibile (anche quando il resto va a quel paese).
> se dovessi usare syslog (ma in realtà i messaggi critici potrebbero
> essere presenti su più log che vorrei analizzare)
Puoi farli convergere in syslog e poi dal syslog locale a quello (ng)
del server, o se hai voglia, usare syslog-ng direttamente ed andare
su un DB come backend. Ma non te lo consiglio. Tienti anche le copie
in ASCII. Meglio usare spazio che perdere dati.
> > 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.
> > 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...
> Mi sembra che tu stia confrontando una bicicletta con un aereo e ti
> chiedi perché dovrei usare un aereo al posto di una bicicletta,
No, sta chiedendo perché può avere meno problemi con una biciclietta
rispetto ad un utlitaria con motore a combustione interna.
La bicicletta è più lenta, più pericolosa, più faticosa. Ma se c'è
il blocco del traffico la bicicletta circola ancora.
Il discorso è questo. Avere _anche_ l'utilitaria può essere comodo,
avere la bicicletta è sicurezza di non rimanere a piedi.
--
/\ ___ Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____ African word
//--\| | \| | Integralista GNUslamico meaning "I can
\/ coltivatore diretto di software not install
già sistemista a tempo (altrui) perso... Debian"
Warning: gnome-config-daemon considered more dangerous than GOTO
Reply to: