la question est pas tant "texte" vs "binaire" que le degré de structuration que tu mets dans le format.
Un format XML va être du texte, va avoir une structure, et les métadonnées pour l’interpréter. Un format binaire qui est juste un dump mémoire ( comme le .doc l'était ) va pas avoir la structure.
Donc ça depend plus du format que juste "binaire" vs "texte". C'est un détail d'encodage en pratique.
Mais dans le cas des logs, les logs de syslog n'ont pas de structure et les logs de journald en ont.
Y a du pour et du contre, le fait de pas avoir de structure est plus rapide à développer et moins rigide vu que tu fais ce que tu veux. Exemple si je veux rajouter un truc à la fin des logs, j'ai pas à faire changer un schema ou quoi que ce soit.
Mais du coup, l’interopérabilité en souffre, dans le sens ou je peux pas m'appuyer sur le format. Et ça, c'est relou. Exemple, le format de mod_security est relou, vu qu'il log dans un premier fichier avec un format difficilement lisible par un humain, puis donne des détails dans un 2eme, un chouia plus difficilement scriptable car sur plusieurs lignes. Le fait d'inventer son format fait que je doit refaire la machinerie pour chercher la bas.
Donc la discussion devrait être "structure" vs "non structure".
Pas "texte" vs "pas texte". Car des formats texte de log avec une structure, y a gelf par exemple, qui peut être compressé et non compressé. Et même de manière plus amusante, il y a des convertisseurs ( https://github.com/systemd/journal2gelf ) depuis journald, parce que justement, il y a une structure.
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 6.
la question est pas tant "texte" vs "binaire" que le degré de structuration que tu mets dans le format.
Un format XML va être du texte, va avoir une structure, et les métadonnées pour l’interpréter. Un format binaire qui est juste un dump mémoire ( comme le .doc l'était ) va pas avoir la structure.
Donc ça depend plus du format que juste "binaire" vs "texte". C'est un détail d'encodage en pratique.
Mais dans le cas des logs, les logs de syslog n'ont pas de structure et les logs de journald en ont.
Y a du pour et du contre, le fait de pas avoir de structure est plus rapide à développer et moins rigide vu que tu fais ce que tu veux. Exemple si je veux rajouter un truc à la fin des logs, j'ai pas à faire changer un schema ou quoi que ce soit.
Mais du coup, l’interopérabilité en souffre, dans le sens ou je peux pas m'appuyer sur le format. Et ça, c'est relou. Exemple, le format de mod_security est relou, vu qu'il log dans un premier fichier avec un format difficilement lisible par un humain, puis donne des détails dans un 2eme, un chouia plus difficilement scriptable car sur plusieurs lignes. Le fait d'inventer son format fait que je doit refaire la machinerie pour chercher la bas.
Donc la discussion devrait être "structure" vs "non structure".
Pas "texte" vs "pas texte". Car des formats texte de log avec une structure, y a gelf par exemple, qui peut être compressé et non compressé. Et même de manière plus amusante, il y a des convertisseurs ( https://github.com/systemd/journal2gelf ) depuis journald, parce que justement, il y a une structure.