Posté par khivapia .
En réponse au journal Le journal.
Évalué à 6.
Dernière modification le 06 septembre 2012 à 16:02.
Merci pour ta réponse, je ne comprends toujours pas tout (un utilisateur pas vraiment admin système)…
Pour moi il y a deux aspects dans les logs d'une application :
les métadonnées des logs : date, heure, PID, état de l'OS etc. etc. : dans ce cas, que ce soit journalctl ou syslog ou autres, c'est facile de l'écrire de sorte que ce soit facile à parser, et la performance de lecture ne risque pas d'être déterminante (au doigt mouillé, on s'intéresse pas mal au contenu des logs tout de même !).
les logs proprement dits, ce que l'application a elle-même craché : à moins de modifier l'application, journalctl ne parsera pas les informations plus facilement que les scripts existants à grands coups de regex ; je veux dire, toute la complexité d'écriture des parseurs de logs pour l'appli X demeure, à la merci des moindre changements de formats de ce qu'elle loggue par l'application.
Donc grosso modo journalctl propose un format unique pour les métadonnées des logs de tous les services qu'il lance ? Ça n'était pas déjà le cas avant avec syslog ? (de ce que j'en vois mais je ne comprends pas tous les cas d'usage, dans mon daemon.log toutes les lignes commencent par la date, puis le nom de machine, puis le nom de l'application et son PID (on pourrait ajouter toutes les infos sorties par ps pour le même prix), selon un ordre immuable qui se parse en deux coups de cuiller à pot ; qu'y manque-t-il ? ) En fait ce que journalctl apporte, c'est une forme de standardisation de ces infos qui n'existe actuellement pas ?
Mis à part le gain de performance par un format binaire des logs, en fait je ne comprends toujours pas le problème que ça résout :).
[^] # Re: Grep
Posté par khivapia . En réponse au journal Le journal. Évalué à 6. Dernière modification le 06 septembre 2012 à 16:02.
Merci pour ta réponse, je ne comprends toujours pas tout (un utilisateur pas vraiment admin système)…
Pour moi il y a deux aspects dans les logs d'une application :
les métadonnées des logs : date, heure, PID, état de l'OS etc. etc. : dans ce cas, que ce soit journalctl ou syslog ou autres, c'est facile de l'écrire de sorte que ce soit facile à parser, et la performance de lecture ne risque pas d'être déterminante (au doigt mouillé, on s'intéresse pas mal au contenu des logs tout de même !).
les logs proprement dits, ce que l'application a elle-même craché : à moins de modifier l'application, journalctl ne parsera pas les informations plus facilement que les scripts existants à grands coups de regex ; je veux dire, toute la complexité d'écriture des parseurs de logs pour l'appli X demeure, à la merci des moindre changements de formats de ce qu'elle loggue par l'application.
Donc grosso modo journalctl propose un format unique pour les métadonnées des logs de tous les services qu'il lance ? Ça n'était pas déjà le cas avant avec syslog ? (de ce que j'en vois mais je ne comprends pas tous les cas d'usage, dans mon daemon.log toutes les lignes commencent par la date, puis le nom de machine, puis le nom de l'application et son PID (on pourrait ajouter toutes les infos sorties par ps pour le même prix), selon un ordre immuable qui se parse en deux coups de cuiller à pot ; qu'y manque-t-il ? ) En fait ce que journalctl apporte, c'est une forme de standardisation de ces infos qui n'existe actuellement pas ?
Mis à part le gain de performance par un format binaire des logs, en fait je ne comprends toujours pas le problème que ça résout :).