[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian systemd maintainer resigns due to online bullying + risultati votazione DD



Il 27/11/2014 22:03, Davide Prina ha scritto:
On 22/11/2014 01:25, gerlos wrote:
Il 20 novembre 2014 22:37, Davide Prina ha scritto:

On 20/11/2014 03:03, gerlos wrote:
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.

esatto

Se ho sospetti "generici" poi posso sempre usare grep per cercare
messaggi che contengono parole come "error" o "warning".

però la stringa error potrebbe essere contenuta in una più lunga terror, ad esempio. O potrebbe essere nella parte descrittiva che dice: "L'error è codificato con EE" o nella descrizione che dice "questo non è un error"

Quindi ti puoi ritrovare dei falsi positivi... e di sicuro ti sarà capitato tante volte. Se invece tu dai la possibilità di fornirti o ricavarti dei messaggi strutturati, dove nel campo in posizione X c'è il tipo di messaggio: errore, warning, segnalazione, ... allora la ricerca risulta precisa anche in questo caso.

Poi i falsi positivi li puoi avere lo stesso perché magari ti viene segnalato come errore una cosa che in realtà non lo è, però questo è un falso positivo di livello più alto.

Ora, non per essere ostinati, ma questa cosa non è dovuta tanto al fatto che i log attuali siano testuali, ma che non siano strutturati in modo più "granulare".

Al momento in syslog di default abbiamo praticamente 4 "colonne":
- timestamp
- hostname
- servizio/processo
- messaggio "lasciato" dal processo, ed ogni processo fa un po' a modo suo (da cui la difficoltà a filtrare i contenuti del log)

Per esempio se dessimo un po' di disciplina ai processi che usano syslog, e aggiungessimo un'altra "colonna", che identifichi il tipo di messaggio (che ne so, INFO, DEBUG, ERROR, WARNING...), potremmo filtrare più facilmente i messaggi, anche senza scomodare i log binari.

Per esempio righe di questo tipo sarebbero un po' più da analizzare con awk o con programmi scritti ad hoc: Nov 28 07:35:01 dc01 anacron[9629]: [INFO] Updated timestamp for job `cron.daily' to 2014-11-28


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? ;-)

fino ad un certo punto... certe cose sono molto complesse e ci vuole molto tempo per farle ogni volta da zero che non conviene... conviene delegare ad altri strumenti e sfruttare il risultato già pronto.

Ma anche con i log testuali si possono scrivere (e forse pure più facilmente) strumenti per analizzarne il contenuto.

Vedi per esempio multitail:
http://www.vanheusden.com/multitail/

O se ti piacciono le comodità, ksystemlog:
https://www.kde.org/applications/system/ksystemlog/

O se il tuo strumento principale di analisi sono gli occhi, c'è ccze:
http://blog.tersmitten.nl/how-to-colorize-your-log-files-with-ccze.html

saluti
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: