Ça me parait plus générique et flexible que d'avoir en effet des fichiers de logs spécifiques pour chaque application.
Marrant, j'ai l'opinion exactement inverse (sur cet aspect d'avoir un fichier unique).
Sur le système lui-même, je préfère avoir un processus qui log par processus qui tourne. Comme ça, si l'un des loggers se ramasse, seul ce qu'il faisait est possiblement erroné/corrompu.
Puis, comme centraliser, extraire des données, tout ça, c'est quand même plus simple dans un flux unique, tu as un autre processus qui, lui, va avoir un accès en lecture seule a tous ces fichiers de logs journalisés, et en faire un truc plus simple à utiliser.
Autrement dit, chaque instance de daemon à son propre logger, qui est le seul autorisé à écrire dans son dossier de log. D'autres process sont, en revanche, autorisés à y lire (ça, ça serait l'idéal, en vrai j'ai toujours eu la flemme de faire un user par instance de logger, j'avoue, mais au moins c'est techniquement trivial à faire, et ce depuis facile 20 ans).
Un cas qui m'est arrivé, c'est un daemon qui se met à log BEAUCOUP TROP (sur un système embarqué). Avec un rsyslog, la rotation aurait pourri les logs du système entier (ou alors il aurait fallu une configuration bien capillo-tractée, et je perds assez mes cheveux comme ça).
Avec un stockage dédié par instance, seule une instance voit ses logs détruits par la rotation. Du coup, en analysant les journaux des autres applications qui causaient avec, on a pu avoir des indices pour reproduire et régler le bug.
Le regroupage de log pour en faire un truc plus utile au quotidien, c'est la tâche d'un outil tiers, qui ne détruit pas ses sources de données.
Le jour ou une donnée manque, ça permets d'aller interroger les journaux bruts, avec plus de facilité que s'ils étaient dans un flux unique (puisque par instance).
On peut évidemment me répondre de remonter toutes les données en vrac. Mais ça génère le problème suivant: quid des connexion à volumétrie limitée, type 20 megs / mois?
Réponse: on passe en hors-forfait pour rien.
[^] # Re: Sinon, pour les logs
Posté par freem . En réponse au journal Douze facteurs dans ta tronche. Évalué à 5.
Marrant, j'ai l'opinion exactement inverse (sur cet aspect d'avoir un fichier unique).
Sur le système lui-même, je préfère avoir un processus qui log par processus qui tourne. Comme ça, si l'un des loggers se ramasse, seul ce qu'il faisait est possiblement erroné/corrompu.
Puis, comme centraliser, extraire des données, tout ça, c'est quand même plus simple dans un flux unique, tu as un autre processus qui, lui, va avoir un accès en lecture seule a tous ces fichiers de logs journalisés, et en faire un truc plus simple à utiliser.
Autrement dit, chaque instance de daemon à son propre logger, qui est le seul autorisé à écrire dans son dossier de log. D'autres process sont, en revanche, autorisés à y lire (ça, ça serait l'idéal, en vrai j'ai toujours eu la flemme de faire un user par instance de logger, j'avoue, mais au moins c'est techniquement trivial à faire, et ce depuis facile 20 ans).
Un cas qui m'est arrivé, c'est un daemon qui se met à log BEAUCOUP TROP (sur un système embarqué). Avec un rsyslog, la rotation aurait pourri les logs du système entier (ou alors il aurait fallu une configuration bien capillo-tractée, et je perds assez mes cheveux comme ça).
Avec un stockage dédié par instance, seule une instance voit ses logs détruits par la rotation. Du coup, en analysant les journaux des autres applications qui causaient avec, on a pu avoir des indices pour reproduire et régler le bug.
Le regroupage de log pour en faire un truc plus utile au quotidien, c'est la tâche d'un outil tiers, qui ne détruit pas ses sources de données.
Le jour ou une donnée manque, ça permets d'aller interroger les journaux bruts, avec plus de facilité que s'ils étaient dans un flux unique (puisque par instance).
On peut évidemment me répondre de remonter toutes les données en vrac. Mais ça génère le problème suivant: quid des connexion à volumétrie limitée, type 20 megs / mois?
Réponse: on passe en hors-forfait pour rien.