Peut-on utiliser tail -f sur des fichiers journaux volumineux

Je voudrais surveiller un gros fichier journal (près de 1 Go) pour les erreurs. Je veux que ce soit proche du temps réel (un délai de quelques secondes est très bien). Mon plan est d'utiliser tail -f | grep. Existe-t-il des problèmes de performances avec l'utilisation d'une telle méthode lors de son exécution sur une longue période, par exemple de zéro octet à 1 Go? Existe-t-il des pratiques normatives utilisées pour une telle surveillance? Notez que je voudrais le faire en utilisant les commandes standard Unix disponibles sur Solaris 10.

Si c'est possible, mon fichier est même retourné et j'ai encore un problème à régler :). l'utilisation de tail -F( --follow=name) n'est pas une option pour moi car elle -Fn'est pas prise en charge par le serveur sur lequel je veux exécuter cela. Mon plan est d'utiliser un script qui démarrera cette queue et interrogera pour savoir si le fichier est retourné. Si oui, tuez la queue et redémarrez-la. Une meilleure approche?

logs monitoring tail

— Manoj NV
source

Vous voulez dire "tuer le tail", non?

— Stéphane Gimenez

Oui, "tuer la queue", pas trouver. Merci, édité la question

— Manoj NV

Si un fichier de 2 Go ne contient pas de nouveau caractère de ligne, comment fonctionne tail?

Réponses:

Sur mon système Linux (GNU coreutils 8.12), j'ai pu vérifier (en utilisant strace) que tail -f¹ utilise l' lseekappel système pour ignorer la plupart du fichier rapidement:

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

Cela signifie que la taille du fichier suivi ne devrait en aucun cas avoir d'importance.

Vous pouvez peut-être vérifier si la même chose s'applique à votre système. (Évidemment, cela devrait être le cas.)

-
^{1. J'ai également essayé de désactiver le support inotify avec les sans-papiers ---disable-inotify, juste au cas où.}

— Stéphane Gimenez
source

Real Men a lu la source (:

— Gilles 'SO- arrête d'être méchant'

@Gilles. Je ne peux pas apprendre au PO (ou au lecteur) comment lire la source s'il ne le sait pas déjà. Beaucoup plus facile de lui dire d'utiliser strace;)

— Stéphane Gimenez

En fait, sur un système qui tail -Fn'est pas supporté, il y a des chances qu'il stracene soit pas disponible…

— Stéphane Gimenez

trussest l'utilitaire correspondant sur Solaris.

— Gilles 'SO- arrête d'être méchant'

et il montre des appels de recherche similaires. llseek (0, 0, SEEK_CUR) = 0, llseek (0, 0xFFFFFFFFFFF5FFF6, SEEK_END) = 7923269

— jlliagre

Si elle est invoquée sur un fichier normal (par opposition à un tube), GNU tail et OpenBSD tail (sauf si appelé avec -n +N) cherchent à la fin du fichier, puis travaillent en arrière pour trouver la ligne où il devrait commencer l'impression. Je ne sais pas si Solaris fait de même, mais c'est une approche raisonnable, donc je m'attends à ce que la plupart des unités fassent de même. Par conséquent, la taille du fichier n'est pas pertinente pour les performances.

— Gilles 'SO- arrête d'être méchant'
source

Je fais ça tous les jours. J'analyse généralement une douzaine de journaux sur nos serveurs de test et de production à l'aide de tail -f logs/*.{log,err,out}. La charge initiale est un peu élevée (en fonction du nombre de fichiers globalisés), mais après cela, la diffusion en temps réel.

Au lieu d'envoyer à grep, j'utilise la execfonctionnalité screendepuis car je veux généralement voir toutes les sorties (pour les retraits complets et les messages liés au problème). Par exemple,

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

Pour que le terminal émette un bip (ou clignote) chaque fois que le mot Exception est trouvé.

— Arcege
source