web-dev-qa-db-fra.com

Fichier journal de queue sur plusieurs machines via ssh

J'essaie de tail un fichier journal sur plusieurs machines distantes et de transmettre la sortie à mon poste de travail local. Je souhaite que les connexions se ferment en appuyant sur Ctrl-C.

Pour le moment, j'ai la fonction suivante qui presque fonctionne comme prévu.

function dogfight_tail() {
 logfile=/var/log/server.log
 pids=""
 for box in 02 03; do
   ssh server-$box tail -f $logfile | grep $1 &
   pids="$pids $!"
 done
 trap 'kill -9 $pids' SIGINT
 trap  wait
}

Les connexions se ferment et je reçois la sortie de tail. MAIS, il y a une sorte de mise en mémoire tampon car la sortie est fournie par lots.

Et voici la partie amusante…

Je peux voir le même comportement de mise en mémoire tampon lors de l'exécution de ce qui suit et ajouter "test" au fichier /var/log/server.log sur les machines distantes 4-5 fois…

ssh server-01 "tail -f /var/log/server.log | grep test"

… Et a trouvé deux façons de le désactiver…

  1. Ajoutez le drapeau -t à ssh.

    ssh -t server-01 "tail -f /var/log/server.log | grep test"

  2. Supprimez le devis de la commande à distance.

    ssh server-01 tail -f /var/log/server.log | grep test

Cependant, aucune de ces approches ne fonctionne pour la fonction qui s'exécute sur plusieurs machines mentionnées ci-dessus.

J'ai essayé dsh, qui a le même comportement de mise en mémoire tampon lors de l'exécution.

dsh -m server-01,server-02 -c "tail -f /var/log/server.log | grep test"

Même chose ici, si je supprime la citation, la mise en mémoire tampon disparaît et tout fonctionne bien.

dsh -m server-01,server-02 -c tail -f /var/log/server.log | grep test

A également essayé parallel-ssh qui fonctionne exactement comme dsh. Quelqu'un peut-il expliquer ce qui se passe ici?

Comment résoudre ce problème? Ce serait idéal pour aller avec ssh directement si possible.

P.S. Je ne veux pas utiliser multitail ou similaire car je veux pouvoir exécuter des commandes arbitraires.

linuxsshtail
38
deephacks

Ce que vous voyez est l'effet d'un tampon stdout standard dans grep fourni par Glibc. La meilleure solution consiste à le désactiver en utilisant --line-buffered (GNU grep, je ne sais pas quelles autres implémentations pourraient le supporter ou quelque chose de similaire).

Quant à pourquoi cela ne se produit que dans certains cas:

ssh server "tail -f /var/log/server.log | grep test"

exécute toute la commande entre guillemets sur le serveur - ainsi grep attend de remplir son tampon.

ssh server tail -f /var/log/server.log | grep test

exécute grep sur votre machine locale sur la sortie tail envoyée via le canal ssh.

La partie clé ici est que grep ajuste son comportement selon que son stdin est un terminal ou non. Lorsque vous exécutez ssh -t, la commande distante s'exécute avec un terminal de contrôle et donc la télécommande grep se comporte comme la votre locale.

37
peterph

vérifiez ceci: multitail

MultiTail vous permet de surveiller les fichiers journaux et la sortie des commandes dans plusieurs fenêtres dans un terminal, de coloriser, de filtrer et de fusionner.

Pour suivre les journaux sur plusieurs serveurs, utilisez:

multitail -l 'ssh user@Host1 "tail -f /path/to/log/file"' -l 'ssh user@Host2 "tail -f /path/to/log/file"'
2
LeoChu

Vous pouvez commander dans le journal de côté.

A Java outil que j'ai créé, capable de lire des fichiers journaux locaux et distants en utilisant SSH. Il est assez simple à utiliser.

Quelques explications supplémentaires: https://github.com/pschweitz/insidelog/wiki

Téléchargez simplement la version correspondant à votre système d'exploitation, de la version native du pot exécutable dans votre Java Runtime (nécessite Java 8_40 ou supérieur):

https://github.com/pschweitz/insidelog/releases

Vous pouvez trouver une documentation complète (intégrée avec et dans la page de Github également)

0
Philippe Schweitzer