Solution 1 :
Si les fichiers journaux sont générés sur le serveur client via le syslog alors la meilleure façon est de configurer le démon syslog des clients pour qu'il transmette ces journaux à un hôte séparé. Par exemple, si j'ai un nom interne syslog.private qui pointe vers le serveur distant sur lequel je souhaite recevoir les entrées du journal. Je peux ajouter la ligne suivante au /etc/syslog.conf sur le serveur client.
*.* @syslog.private
puis redémarrez le démon syslog sur le client
service syslog reload
Cela entraînera l'envoi de chaque entrée qui passe par le syslog du client sur le réseau à syslog.private et si cette machine est configurée correctement, les entrées y seront également disponibles. Dans les systèmes RedHat, ceci est contrôlé par le /etc/sysconfig/syslog dossier. Assurez-vous que le -r l'option est présente
% grep "SYSLOGD" /etc/sysconfig/syslog
SYSLOGD_OPTIONS="-m 0 -r"
puis redémarrez le démon syslog sur le serveur de réception.
Vous pouvez également contrôler ce qui est transmis au serveur distant en ajoutant des exclusions, voir l'exemple ci-dessous
*.*;mail.none @syslog.private
Qui dit tout transmettre à syslog.private à l'exception de tout ce qui est envoyé au mail installation.
Si cette solution vous convient, vous pouvez envisager l'une des implémentations alternatives de syslog telles que rsyslog ou syslog-ng, qui fournissent des options de journalisation et de stockage supplémentaires.
Solution 2 :
Si vous configurez l'authentification ssh basée sur une clé et sudo sur les hôtes distants sur les hôtes distants pour autoriser l'exécution de tail sur les fichiers journaux sans demander de mot de passe. Il serait assez facile de créer un script taillog qui fait ce que vous voulez comme ci-dessous. Cela n'évite pas vraiment ssh, mais cela vous évite quelques étapes.
#!/bin/bash
ssh $1 sudo tail -f $2
Ou, vous pouvez configurer syslog pour transférer tous les messages du journal vers un système central, puis exécuter votre commande tail sur le serveur syslog. Regardez simplement les fichiers journaux sur le système central.
Solution 3 :
Je recommanderais fortement multitail pour une visualisation avancée des journaux. Se décrit comme une queue sous stéroïdes.
Solution 4 :
Cela ne répond clairement pas à votre question, mais si vous avez plus que quelques journaux à surveiller, et moins que la limite de l'édition gratuite, vous pouvez essayer Splunk gratuitement pour avoir une interface agréable et utile pour toutes vos données de journalisation.
tail -f prend en charge plus d'un journal, mais pas côte à côte, uniquement vers le bas.
Solution 5 :
Multitail fera ce que vous recherchez sur la machine locale. Il ne mentionne pas spécifiquement s'il fonctionnera sur un réseau, bien qu'il existe plusieurs façons de contourner cela (montages NFS, montages SMB, etc.). Il indique également qu'il fonctionnera comme un serveur syslog, ce qui implique qu'il pourrait être capable pour recevoir des données actives du syslog d'une autre machine, bien que je n'aie jamais utilisé cette fonctionnalité et que je ne sache pas si c'est le cas.