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 -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21615.2597.146440.466...@mail.eng.it