Suivre les logs en direct
Suivez une unité systemd, un conteneur Docker, un process pm2 ou n'importe quel fichier de votre serveur depuis le navigateur — avec les cibles déjà détectées par votre agent proposées en un clic.
L'onglet Logs suit n'importe quel log d'un serveur au fil de son écriture :
une unité systemd, un conteneur Docker, un process pm2, ou un simple fichier.
Aucune session SSH à ouvrir, aucune commande tail à retenir — et les cibles que
votre agent a déjà détectées sont à un clic.
Déverrouillez votre coffre d'abord
Suivre un log exécute une commande sur la machine : il faut donc un coffre déverrouillé — voir Déverrouiller votre coffre. Les lecteurs n'ont pas accès à cet onglet.
Suivre un log
Ouvrez l'onglet Logs
Dans Serveurs, ouvrez un serveur connecté et cliquez sur Logs.
Choisissez une source
systemd, Docker, pm2 ou Fichier. Chacune change ce qu'attend le champ cible : une unité, un conteneur, un process ou un chemin absolu.
Choisissez une cible
Cliquez sur une puce sous Détecté sur ce serveur — elles viennent de ce que l'agent a rapporté en dernier, vous avez donc rarement à taper un nom. Les unités en échec arrivent en premier : c'est généralement pour elles qu'on ouvre cet onglet. Vous pouvez aussi saisir n'importe quelle cible.
Réglez l'historique, puis suivez
Historique décide du nombre de lignes passées affichées avant le début du flux (100 à 1000). Cliquez sur Suivre — la sortie arrive au fil de l'eau.
Ce que suit chaque source
| Source | Ce qui est suivi |
|---|---|
| systemd | journalctl -f sur l'unité — l'endroit standard pour la sortie d'un service |
| Docker | le flux de logs du conteneur, exactement ce que montre docker logs -f |
| pm2 | le fichier de log du process quand pm2 en rapporte un, sa sortie live sinon |
| Fichier | n'importe quel chemin absolu — /var/log/syslog, le log d'une app, tout ce qui est lisible |
Pourquoi pm2 lit un fichier
pm2 fait tourner un daemon distinct par utilisateur et n'est pas nécessairement lancé par systemd : demander ses logs à pm2 ne répond donc que pour l'utilisateur propriétaire de ce daemon. Le fichier qu'il écrit n'a pas cette ambiguïté, alors Servor suit le fichier dès que pm2 en a rapporté le chemin — ça fonctionne quelle que soit la façon dont pm2 a été démarré.
Pendant le flux
Le flux se comporte comme le terminal web : il survit à une coupure réseau brève et se réattache au lieu de repartir de zéro. Fermez le panneau pour arrêter de suivre, puis choisissez une autre cible.
Suivre un log est une opération en lecture seule, mais cela reste une commande sur la machine : elle apparaît donc dans votre historique des commandes et dans le journal d'audit, comme tout ce que Servor exécute.
Qui peut quoi
| Rôle | Suivre les logs |
|---|---|
| Propriétaire / Admin / Membre | Oui |
| Lecteur | Non |
Dépannage
- « Cible invalide » — le nom ou le chemin n'a pas passé la validation. Une
cible ne peut pas commencer par un tiret (elle serait lue comme une option), et
un chemin de fichier doit être absolu et déjà normalisé :
/var/log/nginx/error.log, pas/var/log/../log/nginx/error.log. - Un process pm2 n'affiche rien — pm2 n'avait pas encore rapporté de chemin de log, Servor est donc retombé sur une interrogation directe de pm2, qui ne répond que pour l'utilisateur propriétaire du daemon. Mettez l'agent à jour, ou suivez le fichier directement avec la source Fichier.
- Le flux est refusé — certains chemins sont bloqués pour toute commande
exécutée par Servor,
/etc/shadowen fait partie. Ce garde-fou s'applique ici aussi. - Rien n'arrive — l'unité ou le conteneur est peut-être simplement silencieux. Augmentez l'historique pour confirmer que vous visez la bonne cible.
- Toujours bloqué ? Voir Dépannage.