Va bene usare tail -f su file di registro di grandi dimensioni

Vorrei monitorare un file di registro di grandi dimensioni (vicino a 1 GB) per errori. Voglio che questo sia vicino al tempo reale (qualche secondo di ritardo va bene). Il mio piano è di usare tail -f | grep. Esistono problemi di prestazioni con l'utilizzo di un metodo simile quando lo si esegue per un lungo periodo, ad esempio da zero byte a 1 GB? Esistono pratiche standard utilizzate per tale monitoraggio? Si noti che vorrei farlo utilizzando i comandi unix standard disponibili su Solaris 10.

Se ciò è possibile, il mio file si sposta persino e ho ancora un problema da risolvere :). using tail -F( --follow=name) non è un'opzione per me perché -Fnon è supportato nel server su cui voglio eseguirlo. Il mio piano è quello di utilizzare uno script che avvierà questa coda e scruterà per scoprire se il file viene girato. Se sì, allora uccidi la coda e riavviala. Qualche approccio migliore?

logs monitoring tail

— Manoj NV
fonte

Intendi "uccidi tail", vero?

— Stéphane Gimenez,

Sì, "uccidi la coda", non trova. Grazie, ha modificato la domanda

— Manoj NV,

Se un file di dimensioni pari a 2 GB non contiene un nuovo carattere di linea, come funziona tail?

Risposte:

Sul mio sistema Linux (GNU coreutils 8.12), sono stato in grado di verificare (usando strace) che tail -f¹ usa la lseekchiamata di sistema per saltare rapidamente la maggior parte del file:

lseek(3, 0, SEEK_CUR)                   = 0
lseek(3, 0, SEEK_END)                   = 194086
lseek(3, 188416, SEEK_SET)              = 188416

Ciò significa che la dimensione del file tracciato non dovrebbe comunque importare.

Forse puoi verificare se lo stesso vale per il tuo sistema. (Ovviamente, dovrebbe essere il caso.)

-
^{1. Ho anche provato a disabilitare il supporto inotify con il non documentato ---disable-inotify, per ogni evenienza.}

— Stéphane Gimenez
fonte

I veri uomini leggono la fonte (:

— Gilles 'SO- smetti di essere malvagio'

@Gilles. Non posso insegnare all'OP (o al lettore) come leggere la fonte se non lo sa già. Molto più facile dirgli di usare strace;)

— Stéphane Gimenez

In realtà, su un sistema in cui tail -Fnon è supportato, è probabile che stracenon sia disponibile ...

— Stéphane Gimenez

trussè l'utilità corrispondente su Solaris.

— Gilles 'SO- smetti di essere malvagio'

e mostra chiamate di ricerca simili. llseek (0, 0, SEEK_CUR) = 0, llseek (0, 0xFFFFFFFFFFF5FFF6, SEEK_END) = 7923269

— jlliagre

Se viene invocato su un file normale (al contrario di una pipe), sia GNU tail che OpenBSD tail (a meno che non sia chiamato con -n +N) cercano la fine del file, quindi lavora all'indietro per trovare la linea da cui dovrebbe iniziare a stampare. Non so se Solaris faccia lo stesso, ma è un approccio ragionevole, quindi mi aspetto che la maggior parte dei unice faccia lo stesso. Pertanto, la dimensione del file è irrilevante per le prestazioni.

— Gilles 'SO- smetti di essere malvagio'
fonte

Lo faccio ogni giorno. In genere eseguo la scansione di una dozzina di registri sui nostri server di test e di produzione utilizzandotail -f logs/*.{log,err,out} . Il caricamento iniziale è un po 'eccessivo (a seconda del numero di file disturbati), ma dopo ciò lo streaming è in tempo reale.

Invece di inviare a grep, utilizzo la execfunzionalità in screenquanto desidero generalmente vedere tutto l'output (per i traceback completi e i messaggi relativi al problema). Per esempio,

!:sed -n s/.*Exception.*/\007/p

Per fare in modo che il terminale emetta un segnale acustico (o lampeggi) ogni volta che viene trovata la parola Eccezione.

— Arcege
fonte