Re: Log testuali vs binari [Era Re: Debian systemd maintainer resigns due to online bullying + risultati votazione DD]
On 24/11/2014 10:41, Gian Uberto Lauri wrote:
Un messaggio per commentarne 2.
Davide Prina writes:
>
> > 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.
Colpa dell'editor che usi per rispondere. Ripeto. Che ci piaccia o no
non è obbligatorio terminare le righe con un CR.
non ho mica detto questo. I MUA sono configurabili per spezzare in
automatico le righe al 72° carattere (circa).
Per esempio il tuo lo fa.
Peraltro: dispositivi diversi con larghezze di riga diverse
riformattano il messaggio in modo diverso.
questo si ha con il messaggio in visualizzazione, se c'è lo spezzamento
delle righe. Non nelle risposte.
> Poi non capisco perché nelle tue risposte metti il triplo degli spazi
> necessari nell'indentazione...
È uno stile perfettamente legale.
ma, la risposta dovrebbe rispettare gli standard ormai consolidati
> > > > 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?
Ho fatto un pelo confusione. Ma non sono il solo ...
> Qui si sta parlando di usare un file strutturato, se il file è
> strutturato riesci a fare ricerche esatte su un determinato campo.
Anche se non lo è. Certo, devi saperlo fare e devi lavorarci di più.
Ma affermare che solo con i file suddivisi in campi puoi farlo è o
non sapere di che si parla o essere in cattiva fede.
se hai campi di lunghezza variabile e il tuo file è di testo puro senza
suddivisione in campi, allora non puoi sapere né dove inizia, né dove
finisce. Se poi si parla di log la struttura potrebbe essere diversa a
seconda del tipo di log.
Quindi ne desumo che se fai una ricerca su una concatenazione di campi
non puoi sapere se quello che stai cercando è nel campo che interessa a
te o in un altro campo.
es (banale):
campo1: tipo di errore descrittivo
campo2: nota leggibile dall'utente
tu devi cercare gli errori che presumibilmente hanno al loro interno la
scritta ERRORE
Se sono suddivisi in campi:
campo1 | campo 2
ERRORE di posizionamento |la posizione trovata: non è esatta
segnalazione |questo non è un: ERRORE
se hai un file di testo ti trovi
ERRORE di posizionamento la posizione trovata: non è esatta
segnalazione questo non è un: ERRORE
se fai un
$ grep ERRORE mylog.log
ti trovi tutte e due i messaggi. Non potendo sapere, per qualsiasi tipo
di riga che ti trovi nel log quale regola seguire per capire dove inizia
e termina il campo 1, allora fai ricerche che sono approssimative.
> > 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.
No. Non dire cavolate.
Un indice serve a sostituire una ricerca "full table scan" (lo ho già
usato questo gergo dei DB) fatta analizzando sequenzialmente ogni
record con una ricerca basata su strutture dati più complesse (e
delicate), usualmente ad albero.
forse intendi un accesso "full table scan", non una ricerca.
Se guardi l'explain plan di una query quasi tutte le righe generate sono
join tra tabelle, condizioni di inclusione/esclusione... la ricerca
effettiva è al massimo 1-2 righe dell'explain plan.
Naturalmente questo non vale se fai sempre query su una singola
tabella... ma allora non ti serve un database (e quindi non hai in ogni
caso un full table scan, perché non stai usando una tabella, ma al
massimo un file indicizzato a cui accedi al massimo senza indice).
Se hai delle relazioni (che a seconda degli strumenti puoi o meno
esplicitare) allora è saggio progettare gli indici in modo da favorire
gli accessi ai record fatti attraverso queste relazioni.
scusa, ma questa non è ricerca, è relazione tra entità
Quali indici creare non dipende dai dati ma dall'uso che ne viene fatto.
l'unico uso che puoi prevedere sono le relazioni tra le tabelle e quindi
le join. Se metti gli indici sulle join, allora stai dicendo la stessa
cosa che dico io... negando che quello che dico io è corretto.
Una volta che hai usato gli indici per le relazioni, la ricerca
effettiva viene fatta, il più delle volte, in full scan, ma sui dati
ritornati dall'uso degli indici, che di solito sono di numero contenuto.
> > > 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?
Non li usi e vai avanti con cat.
Se puoi usarlo il tool lo usi, ovvio, ma devi essere pronto a lavorare
anche senza.
ma questo lo puoi fare anche con systemd, dato che i log testuali ci
sono sempre... forse li puoi disattivare, non ho indagato.
Quindi tu mi stai dicendo che systemd è ottimale per il tuo uso, se puoi
usarlo lo usi, altrimenti vai direttamente in /var/log/syslog & C.
> 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?
Perché non sono affatto certo che journald sia un buon database quanto lo
può essere Postgres.
attenzione. Prima di tutto un database non è di per sé buono o cattivo,
dipende da come è stata realizzata la struttura ER che ci sta sopra.
Non è che perché ho un insieme di dati su un database, qualsiasi esso
sia, che ho un buon database (inteso come possibilità di uso di quei
dati)... se chi lo ha progettato non ha preso in considerazione problemi
come la consistenza dei dati, l'integrità referenziale, ...
La filosofia Unix dei tool che fanno una sola cosa serve ad avere tool che
fanno una sola cosa bene.
systemd fa una sola cosa! e la fa bene ;-) gestisce tutto :-) del resto
non fa nulla! :-)))
scherzi a parte, allora neanche Linux fa questo... e ci sono moltissimi
altri software che usi che non fanno quanto affermi.
> > 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.
3 righe per dire quello che avevo detto in una.
L'unico modo per ridurre lo spazio dei log è comprimerli, non basta
suddividerli (come esercizio: provare che il suddividere un file di
grosse dimensioni in vari file di dimensioni minori non è un buon modo
per l'uso dello spazio).
?
forse intendi dire che avevo detto che le varie parti vengono suddivise
in campi strutturati?
Ma questo cosa centra con la modalità in cui vengono registrati?
> Logrotate può cancellarmi oggi
> log raccolti 10 anni fa o 10 secondi fa... con le stesse regole...
Questo comportamento si ha se e solo se gli dici di fare una rotazione
sulla base della dimensione.
se sai che il log può crescere molto velocemente devi per forza usare la
regola size, altrimenti puoi finire lo spazio su disco.
> Un file
> binario, in generale, ha un'entropia nettamente più bassa di un file di
> testo.
No. La rappresentazione testuale di dati binari ha più entropia
dell'originale binario. Ma non significa che l'originale binario abbia
necessariamente il livello più alto di informazione per bit.
?
io ho detto un file binario ha meno entropia di uno testuale
tu dici: un file testuale ha più entropia di uno binario
e dici che quello che ho scritto io non è corretto?
> è fatto in modo corretto, ha già ridotto l'entropia.
Cosa [... beeep ...] è un file binario corretto? Vuoi forse dire con
la struttura migliore?
corretto nel senso che tende ad usare un minor numero di bit per
rappresentare quell'informazione, rispetto ad un corrispettivo testuale.
Però un file può essere binario e occupare più spazio di quello che gli
serve e anche più spazio del corrispettivo testuale.
> > 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.
Questo pagando tempo macchina. Queste a casa mia si chiamano s.... mentali.
a me sembra che tu stia cercando di contraddire qualsiasi cosa che io
scrivo mettendo cose a vanvera... anche invertendo la frase e dicendo
esattamente la stessa cosa che ho detto io... dichiarando però che
quello che ho scritto io è sbagliato.
A questo punto termino qui e non rispenderò più alle tue mail, anche
perché questa discussione non penso interessi più a nessuno in lista.
Se si vuole discutere bene, può portare benefici ad entrambi, ma a me
sembra che si è individuato un nemico, senza conoscerlo, senza averlo
neanche visto e quindi, essendo un nemico, bisogna inventare contro di
lui qualsiasi cosa che possa essere vista come negativa.
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: