Je crois qu'il faut arrêter avec le XML partout, c'était il y a 10 ans en arrière. Des évènements qui arrive de manière temporelle et régulière, on sens bien qu'une écriture en mode append ligne à ligne, c'est vachement adapté.
Quand au XSLT, c'est de la merde en boite… Cela date encore de l'époque ou on voulait tout faire rentrer dans du XML. C'est vraiment vouloir faire du LISP en moins bien, on est capable de faire un langage à moteur d'inférence un peu plus humain je pense ;-)
Au vu de ce que j'ai vu lors de cette discution, il me semble qu'un envoi vers un serveur central type syslog d'une structure normalisé type JSON, YAML… me semble effectivement mieux qu'une simple chaine. Le mieux est de prendre un format rapide, simple et peu verbeux, c'est la partie réseau qui sera interchangeable…
Ensuite, coté syslog, plusieurs backend sont possible et par défaut, un système compatible avec l'actuel d'un append ligne à ligne dans un fichier d'une structure JSON semble relativement efficace à tout point de vue. Le syslog pourrait rajouter au mesage son timestamp d'écriture en début de structure pour avoir l'ordre chronologique.
Bref, le retour à la ligne gère le temps et chaque ligne est une structure JSON indépendante. Ainsi l'analyse de celles-ci ne prends pas trop de ressource mémoire…
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Projet Lumberjack. Évalué à 3.
Je crois qu'il faut arrêter avec le XML partout, c'était il y a 10 ans en arrière. Des évènements qui arrive de manière temporelle et régulière, on sens bien qu'une écriture en mode append ligne à ligne, c'est vachement adapté.
Quand au XSLT, c'est de la merde en boite… Cela date encore de l'époque ou on voulait tout faire rentrer dans du XML. C'est vraiment vouloir faire du LISP en moins bien, on est capable de faire un langage à moteur d'inférence un peu plus humain je pense ;-)
Au vu de ce que j'ai vu lors de cette discution, il me semble qu'un envoi vers un serveur central type syslog d'une structure normalisé type JSON, YAML… me semble effectivement mieux qu'une simple chaine. Le mieux est de prendre un format rapide, simple et peu verbeux, c'est la partie réseau qui sera interchangeable…
Ensuite, coté syslog, plusieurs backend sont possible et par défaut, un système compatible avec l'actuel d'un append ligne à ligne dans un fichier d'une structure JSON semble relativement efficace à tout point de vue. Le syslog pourrait rajouter au mesage son timestamp d'écriture en début de structure pour avoir l'ordre chronologique.
Bref, le retour à la ligne gère le temps et chaque ligne est une structure JSON indépendante. Ainsi l'analyse de celles-ci ne prends pas trop de ressource mémoire…