Re: Debian systemd maintainer resigns due to online bullying + risultati votazione DD
Il 20 novembre 2014 22:37, Davide Prina <davide.prina@gmail.com> ha scritto:
> ma hai un monitor con 5.000.000 di colonne?
> potresti impostare il tuo client per spezzare le righe al 72° carattere?
> è davvero difficile rispondere alle tue mail
Scusa, normalmente uso Thunderbird, mutt ed Apple Mail, che
normalmente mi impaginano automaticamente le righe, e ogni tanto
dimentico che non tutti hanno (o vogliono usare) queste comodità.
Mi sa che Apple Mail non è un bravo cittadino... vedrò come risolvere,
nel frattempo ti scrivo direttamente da gmail che dovrebbe "fare la
cosa giusta".
>
> On 20/11/2014 03:03, gerlos wrote:
>
>> 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)
Forse il mio punto di vista è limitato, e non capisco situazioni più
grandi/complesse, perché non capisco perché parli di ricerche
approssimative sul testo.
Proviamo con un esempio pratico. Quando guardo una riga di
/var/log/syslog vedo un timestamp, un hostname ed il nome del processo
che ha lasciato il messaggio, oltre ai dettagli del messaggio, che
ovviamente dipendono da "chi" li scrive.
Filtrare sul timestamp è facile, per esempio con "grep -e '^Nov' "
vedo i messaggi registrati a novembre.
Similmente è facile filtrare sull'hostname o sul processo: uso per
esempio "grep -e 'hostname\ kernel:\ ' "
Queste sono ricerche molto precise.
Se ho sospetti "generici" poi posso sempre usare grep per cercare
messaggi che contengono parole come "error" o "warning".
Insomma, hai capito che mi so orientare.
Mi fai un esempio pratico di una situazione con un indizio di un
possibile problema futuro difficile da identificare con questo
sistema?
>> 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?
Perché potrei non essere più interessato a log molto vecchi e potrei
volerli cancellare per liberare spazio su disco, o perché vorrei
spostarli altrove.
Nel momento in cui non c'è più utilità in quelle informazioni
(chiaramente dipende da caso a caso), perché occupare inutilmente
spazio di storage?
OK, i log binari crescono più lentamente di quelli testuali. Ma
crescono comunque. Arriverà un momento in cui "peseranno" decine di MB
di informazioni ormai irrilevanti (che ne so, magari relative ad
eventi vecchi di anni). Perché dovrei tenere queste informazioni
irrilevanti nello stesso storage delle informazioni recenti e
rilevanti? Imho ci sarà comunque un momento in cui vorrò (o dovrò)
"fare pulizia".
> se spezzi l'informazione in campi e crei delle tabelle relazionate tra di
> loro e indicizzi l'accesso a tali tabelle, allora puoi:
> * accedere ad un'informazione in tempi brevi
> * fare ricerche complesse con semplici query
> * avere una quantità di dati enorme e non avere problemi di attesa per
> trovare un'informazione
> * accedere a dati in modo esatto e non approssimativo
Effettivamente queste cose sono comode....
> Un esempio concreto, voglio vedere gli errori che possono essere critici che
> sono stati generati dall'ultimo boot (o dagli ultimi X boot).
> Con systemd ho la risposta immediatamente con un semplice comando:
> # journalctl -b -p 3
Beh, questo mi sembra un caso da "sai esattamente cosa cerchi", che si
risolve facilmente con grep. Mi sbaglio?
> se dovessi usare syslog (ma in realtà i messaggi critici potrebbero essere
> presenti su più log che vorrei analizzare) dovrei:
> 1) cercare di crearmi almeno un file (o flusso dati) che contiene almeno
> tutti i log generati dall'ultimo boot e quindi prendere tutte le rotazioni
> di syslog non compresse, quelle compresse (scomprimendole). Devo usare cat,
> gunzip (o altro programma che devo usare per decomprimerli)
Sì, effettivamente serve un bel po' di expertise con strumenti per
manipolare flussi di testo come cat, zcat, grep, zgrep, sed, awk,
sort, etc. Ma non è quello che ci hanno detto di imparare quando ci
siamo avvicinati a gnu/linux? ;-)
Da un lato ci sono tanti piccoli tool in stile "KISS", e dall'altro
c'è un tool specifico (journalctl). Non conosco journalctl, ma spero
che sia almeno altrettanto versatile dei tool tradizionali nel
filtrare e reperire informazioni.
> 2) buttare via da tale file (flusso dati) tutte le righe che non sono
> dell'ultimo boot.
Io non la vedo così dura.
Dopo tutto, "who -b" (o anche last) mi dice quando ho fatto l'ultimo
boot. Quindi so data ed ora da cercare nei log, posso perciò spezzarli
in quel punto usando awk oppure csplit, e tenere solo le righe create
da quel momento in poi.
Per esempio (le righe che mi interessano finiscono nel file xx01):
zcat /var/log/syslog.5.gz | csplit - '/Nov 17 06:01/'
> 3) a questo punto, se ho fatto le cose correttamente, devo cercare quali
> sono i log che potrebbero visualizzarmi qualche criticità... e qui iniziano
> i problemi più grossi, perché non esiste una regola facile per trovarli...
> in pratica dovrei per ogni programma/demone/quant'altro che scrive sui log
> che sto analizzando conoscere quali sono i messaggi critici, per poterli
> estrarre ed estrarre solo quelli
Non lo devo fare lo stesso?
O in un log binario di systemd ci sarà scritto in grande "SONO IO
L'ERRORE CHE STAVI CERCANDO"? ;-)
>
>> 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.
OK. Aggiungo dati ad una struttura.
E' qualcosa più semplice o più complessa da fare rispetto ad appendere
dati ad un file di testo?
> 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.
Sicuramente sarebbe figo se fosse sqlite. C'è un mondo di strumenti
per giocarci.
> Mi sembra che tu stia confrontando una bicicletta con un aereo e ti chiedi
> perché dovrei usare un aereo al posto di una bicicletta, prendendo come
> metodo di indagine quello che fai passo passo con la tua bicicletta e non
> quello che l'aereo fa. Conclusione l'aereo è inutile perché non lo puoi
> usare come una bicicletta...
Forse capisco il tuo punto di vista.
E' che so cosa posso farci con la bicicletta e come usarla, mentre non
ho idea di cosa farci con l'aereo, né se e come potrebbe aiutarmi.
Non so neanche se per me valga la pena prendere l'aereo (che comporta
prenotazione, controlli di sicurezza, imbarcare il bagaglio, attesa al
gate, ritiro bagagli...), o se non sia molto più facile e sbrigativo
fare lo stesso viaggio in bicicletta.
Probabilmente dipende dalla destinazione! ;-)
Proverò un viaggio in aereo!
grazie per le dritte,
gerlos
--
"Life is pretty simple: You do some stuff. Most fails. Some works. You do
more of what works. If it works big, others quickly copy it. Then you do
something else. The trick is the doing something else."
< http://gerlos.altervista.org >
gerlos +- - - > gnu/linux registred user #311588
Reply to: