c'est que le journal a besoin d'un effort de standardisation au niveau de sa présentation. Le format binaire ne
représente pas la seule et unique méthode pour y arriver.
Pour standardiser, tu as 2 choix. Soit tu va dire à tout le monde "maintenant, c'est ça" et tu t'assures que tout le monde le fait. Soit tu mets un truc entre les logs et le programme qui va se charger de faire ça. Notamment dans le cas de la date, c'est flagrant. C'est ce 2eme cas que journald a choisi.
Ensuite, journald a le choix entre stocker ça en binaire ou en texte. En texte, soit tu prends un format ad-hoc ( ce qui est actuellement mis dans les logs ), soit tu reprends un truc existant ( genre du json, du xml, du yaml ) avec une grammaire. Les auteurs de journald se sont orienté vers le binaire et fait de tout mettre dans une base de données directement pour éviter de faire du parsing sans arrêt.
Les avantages sont multiples. Comme c'est indexé, l'accès aux données est peu couteux et ça permet de voir les logs avec systemctl status. Comme c'est indexé, les recherches sur la date peuvent se faire de manière précise.
Comme les champs sont souvent répétés ( hostname, boot_id, etcetc ), il y a moyen de compresser ça de manière efficace, ce qui permet de logger plus d'info sans pour autant prendre plus de place. Et d'utiliser les informations. Par exemple, plus besoin de regarder la date d'un truc pour savoir si un log correspond au boot courant ou pas, l'information est stocké dans boot_id. L'utilisateur et le service sont enregistré, plus de magouille avec la commande logger. Donc c'est pas "on rajoute des champs pour rien". De plus, la compression a mon avis peut jouer dans le cas de l'embarqué ( embarqué qui inclue aussi les tablette ), et on peut râler ce qu'on veut sur Apple, si on veut pas avoir un futur ou ils deviennent le microsoft d'hier, faut prendre en compte ce cas.
Ouais, on aurait pu faire autrement. Guess what, au lieu de troller sur linuxfr, y a des gens qui ont commencés le boulot : https://fedorahosted.org/lumberjack/
Tu peux même trouver des choses comme https://github.com/deirf/libumberlog pour faire ce que tu veux, à savoir un format texte standardisé pour les logs. Je te propose donc de compiler la lib chez toi, de l'utiliser et de nous dire après 2 mois comment ça a trop changé ta vie. Moi, j'utilise le journal et systemd, et j'ai déjà expliqué pourquoi je trouve que le résultat est pratique.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Misc (site web personnel) . En réponse à la dépêche Documentation du format du Journal. Évalué à 6.
Pour standardiser, tu as 2 choix. Soit tu va dire à tout le monde "maintenant, c'est ça" et tu t'assures que tout le monde le fait. Soit tu mets un truc entre les logs et le programme qui va se charger de faire ça. Notamment dans le cas de la date, c'est flagrant. C'est ce 2eme cas que journald a choisi.
Ensuite, journald a le choix entre stocker ça en binaire ou en texte. En texte, soit tu prends un format ad-hoc ( ce qui est actuellement mis dans les logs ), soit tu reprends un truc existant ( genre du json, du xml, du yaml ) avec une grammaire. Les auteurs de journald se sont orienté vers le binaire et fait de tout mettre dans une base de données directement pour éviter de faire du parsing sans arrêt.
Les avantages sont multiples. Comme c'est indexé, l'accès aux données est peu couteux et ça permet de voir les logs avec systemctl status. Comme c'est indexé, les recherches sur la date peuvent se faire de manière précise.
Comme les champs sont souvent répétés ( hostname, boot_id, etcetc ), il y a moyen de compresser ça de manière efficace, ce qui permet de logger plus d'info sans pour autant prendre plus de place. Et d'utiliser les informations. Par exemple, plus besoin de regarder la date d'un truc pour savoir si un log correspond au boot courant ou pas, l'information est stocké dans boot_id. L'utilisateur et le service sont enregistré, plus de magouille avec la commande logger. Donc c'est pas "on rajoute des champs pour rien". De plus, la compression a mon avis peut jouer dans le cas de l'embarqué ( embarqué qui inclue aussi les tablette ), et on peut râler ce qu'on veut sur Apple, si on veut pas avoir un futur ou ils deviennent le microsoft d'hier, faut prendre en compte ce cas.
Ouais, on aurait pu faire autrement. Guess what, au lieu de troller sur linuxfr, y a des gens qui ont commencés le boulot :
https://fedorahosted.org/lumberjack/
L'origine est expliqué ici : http://bazsi.blogs.balabit.com/2012/02/project-lumberjack-to-improve-linux-logging/
Donc tu va pouvoir maintenant défendre le fait d'utiliser xml :
https://fedorahosted.org/lumberjack/wiki/sampleXml#ExamplelumberjackLogEventsinXMLFormat
ou json :
https://fedorahosted.org/lumberjack/wiki/sampleJson#ExamplelumberjackLogEventsinJSONFormat
Tu peux même trouver des choses comme https://github.com/deirf/libumberlog pour faire ce que tu veux, à savoir un format texte standardisé pour les logs. Je te propose donc de compiler la lib chez toi, de l'utiliser et de nous dire après 2 mois comment ça a trop changé ta vie. Moi, j'utilise le journal et systemd, et j'ai déjà expliqué pourquoi je trouve que le résultat est pratique.