Re: Log testuali vs binari [Era Re: Debian systemd maintainer resigns due to online bullying + risultati votazione DD]
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.
Peraltro: dispositivi diversi con larghezze di riga diverse
riformattano il messaggio in modo diverso.
> Poi non capisco perché nelle tue risposte metti il triplo degli spazi
> necessari nell'indentazione...
È uno stile perfettamente legale.
> > > > 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.
> 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).
No. Puoi avere la MEDESIMA precisione. Il lavoro impiegato è maggiore.
> > 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.
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.
Quali indici creare non dipende dai dati ma dall'uso che ne viene fatto.
> > > 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.
> 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.
La filosofia Unix dei tool che fanno una sola cosa serve ad avere tool che
fanno una sola cosa bene.
> > 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).
> 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.
> 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.
In una sequenza ravvicinata di timestamp a 64 bit, una buona parte dei
64 bit può essere codificata con un numero bassissimo di bit...
> è fatto in modo corretto, ha già ridotto l'entropia.
Cosa [... beeep ...] è un file binario corretto? Vuoi forse dire con
la struttura migliore?
> > 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.
Una cosa che deve fare il log è non mangiarne. Si usano log server
principalmente per quello. Sono macchine il cui solo scopo è l'analisi
dei log, e non solo.
Peraltro estrarre i log dal loro contesto può far perdere informazione
allo stesso modo in cui uno stesso insieme di parole può comunicare
messaggi diversissimi in contesti diversi.
> certamente, quindi ammetti che in alcuni casi l'uso di soli log di testo
> non è ottimale, ti serve qualcos'altro...
Dico che i log di testo sono essenziali perché stare senza può portare
a situazioni analoghe a tagliarsi gli zebedei con un rasoio.
> quel qualcos'altro che systemd
> già ti offre di default.
Dubito fortemente sia la forma migliore. Non puoi saper fare tutto nella
vita, anche in quella di un programmatore.
> > 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.
Evidentemente i tuoi esempi fanno compagnia al Titanic ed alla Bismark.
> ?
Non riconosci il manuale di journald?
> > 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.
Dipende.
> > 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 ;-)
Meglio tenerli in ASCII, quelli li vedi sempre. O alla peggio non deviare dal plain text,
> ?
> Qui si sta parlando di un file binario e, normalmente, in un file
> binario i dati non sai dove vengono messi...
Palle. Questo avviene in un random access file con redord ad accesso
variabile, per cui vai a riciclare "slot" riutilizzati.
Un log non è un file ad accesso casuale, ma uno stream. E non ha
formato fisso, nemmeno quello di journald.
> lo stesso per i file di testo, se usi una codepage non compatibile con
> il tuo sistema di arrivo avrai problemi analoghi.
Ma usi windows?
In ogno caso i problemi relativo all'uso di una diversa codepage sono
facilmente risolvibili da un noto dispositivo che riocnocse le praole
anhce con cartateri fouri ordine :)
> 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
Quel sistema disponde di doppie API (ANSI e UNICODE) da un decennio...
Certo, se non hai tutti i glifi per UTF-8 in qualsiasi sistema se in
messo male.
Ma se hai un log in cinese mandarino allora sicuramente hai anche le
macchine configurate per gestire correttamente il cinese mandarino...
> > Nel momento in cui ho un DDoS, o anche solo un periodo molto buono per la
> > mia webapp, mi può capitare che il server scriva qualche migliaio di
> > righe al secondo, anche per diversi minuti o ore di fila.
> >
> > Con un log indicizzato, il processo di log mi porta via più risorse
> > (perché è in scrittura) di quante ne porti via l'app in sé, ammazzandomi
> > il server. Se invece si limita a scrivere righe alla fine di un file di
> > testo, il carico è praticamente nullo (soprattutto se uso un disco
> > dedicato).
>
> questo lo dici perché ti è capitato? Non penso...
Io invece penso che possa capitare.
> Ora visto che avete così tante domande perché non le chiedete
> direttamente ad esempio a quelli che hanno creato systemd, così avrete
> delle risposte più appropriate e un caso d'uso reale.
Bisogna vedere quali casi di uso reale hanno affrontato. È questo ciò
che lascia molto molto molto perplessi.
> se invece viene usato un log binario può essere che quei 258 byte
> vengano ridotti notevolmente perché se l'indirizzo di provenienza è lo
> stesso possono cambiare 2-3 parametri, se l'indirizzo è diverso ne
> possono cambiare 4-5. Questo vuol dire che l'informazione necessaria a
> registrare ogni singolo evento può essere ridotta drasticamente a 10-15
Vero. Ma valli a rileggere con cat.
> 2) Poi, se io devo gestire un log binario indicizzato posso far sì che
> l'indicizzazione venga calcolata solo se il sistema è scarico o tramite
> nice o se c'è una richiesta di lettura del log...
Ah, journald è stato segnalato come vulnerabile a corruzione dei dati, che
a quanto pare risolve con la rotazione...
> un attimo, qui si sta dicendo che chi crea/gestisce i log li crea in
> binario e quindi è lui che è in grado di leggerli e di presentarteli.
Questo è vero se ti crei i tuoi log. Se invece il log lo ha fatto
l'autore del pacchetto...
> se ogni applicazione definisce i tipi di errore che può generare hai
> risolto il problema :-)
Se facciamo il motore a moto perpetuo risolviamo ogni crisi energetica.
--
/\ ___ 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: