Je pense que soit tu estimes les logs sont transients, et tu t'en fout de les perdre.
Soit tu estimes qu'ils sont importants, et tu traites ça comme tel ( cad, des backups, ou tu logues en double sur 2 machines, etc ). Et à ce niveau la, journald permet de tirer les logs, ou de les pousser de façon native. On va me dire que les logs non binaire le font aussi, mais c'est un peu moins simple en pratique. En fait, pour la partie "pousser", c'est kifkif.
Tout d'abord pour tirer les logs, car il faut mettre rsync en place pour tirer les logs de façon sécurisé. C'est pas dur, mais c'est un peu chiant si on le fait par ssh ( je passe à chaque fois 5 minutes sur la syntaxe de forcecommand et les options exactes à mettre, donc 4 minutes à retrouver le truc pour les voir ). Ca se fait bien via rsync tout court ( via xinetd par exemple ), mais ç'est en clair, et je suis pas sur que tout le monde soit ok avec ça. On peut monter ça via nfs, ftp, http, etc, mais c'est moins efficace sur des gros fichiers que rsync AMHA.
L'autre souci, c'est la configuration par défaut des distributions et de logrotate. Par défaut sur certaines distribs ( Debian based, Mandriva ), logrotate va renommer les fichiers en utilisant un incrément, ce qui fait qu'un fichier nommé logrotate.2.gz un jour sera logrotate.3.gz plus tard, ce qui est pas terrible pour faire des backups. Il semble que RHEL 7 utilise l'option dateext dans logrotate.conf pour éviter ça, donc on peut éviter ( il semble aussi que ça date de 2007, donc je me prends un peu la honte sur ma demonstration ).
Journald utilise un timestamp ( encodé en hexa , le 3eme champ du nom de fichier cf http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-server.c#n273 ) ce qui fait que c'est facile de trier et de retirer les plus anciens. Je regrette ceci dit que le timestamp ne soit pas lisible à l'oeil nu. Mais il a le bon gout d'avoir une taille fixe, ce qui evite des corners cases avec le tri en shell ( genre, oublier de faire un tric sur une valeur numérique au lieu d'une valeur lexicographique, ce qui fait que toto-400 est vu comme avant toto-50, car on compare caractères par caractères ).
Donc rien d'insurmontable bien sur, rien de novateur, mais la force de systemd, c'est aussi d'offrir ça par défaut, ce qui permet de construire par dessus des choses haut niveau réutilisable, et ce qui démocratise la bonne pratique.
Un truc bien fait avec journald, c'est que le logiciel va gérer nativement le faire d'avoir des fichiers de log venant de n'importe ou, car le nommage le permet, et le logiciel en tire parti. On peut tout mettre tel quel dans /var/log/journal, et journal va faire "the right thing". On peut donc suivre les logs sur plusieurs machines, etc, etc. Le nommage des logs classiques implique un post traitement plus complexe, ce qui est faisable encore une fois. Par exemple, splunk, elastic search sont des solutions pour ça qui vont bien au delà de journald. mais qui requiert une infra plus conséquente, la ou journald va juste tirer parti du nommage des fichiers et d'un design simple.
C'est donc vraiment dans l'approche d'offrir un truc parce que c'est facile à faire, une solution intermédiaire entre rien et le truc plus complet et plus compliqué ( un peu comme le protocole de notification de systemd ). Ça règle pas tout les soucis de tout le monde, mais ça peut aider.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 8.
Je pense que soit tu estimes les logs sont transients, et tu t'en fout de les perdre.
Soit tu estimes qu'ils sont importants, et tu traites ça comme tel ( cad, des backups, ou tu logues en double sur 2 machines, etc ). Et à ce niveau la, journald permet de tirer les logs, ou de les pousser de façon native. On va me dire que les logs non binaire le font aussi, mais c'est un peu moins simple en pratique. En fait, pour la partie "pousser", c'est kifkif.
Tout d'abord pour tirer les logs, car il faut mettre rsync en place pour tirer les logs de façon sécurisé. C'est pas dur, mais c'est un peu chiant si on le fait par ssh ( je passe à chaque fois 5 minutes sur la syntaxe de forcecommand et les options exactes à mettre, donc 4 minutes à retrouver le truc pour les voir ). Ca se fait bien via rsync tout court ( via xinetd par exemple ), mais ç'est en clair, et je suis pas sur que tout le monde soit ok avec ça. On peut monter ça via nfs, ftp, http, etc, mais c'est moins efficace sur des gros fichiers que rsync AMHA.
L'autre souci, c'est la configuration par défaut des distributions et de logrotate. Par défaut sur certaines distribs ( Debian based, Mandriva ), logrotate va renommer les fichiers en utilisant un incrément, ce qui fait qu'un fichier nommé logrotate.2.gz un jour sera logrotate.3.gz plus tard, ce qui est pas terrible pour faire des backups. Il semble que RHEL 7 utilise l'option dateext dans logrotate.conf pour éviter ça, donc on peut éviter ( il semble aussi que ça date de 2007, donc je me prends un peu la honte sur ma demonstration ).
Journald utilise un timestamp ( encodé en hexa , le 3eme champ du nom de fichier cf http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-server.c#n273 ) ce qui fait que c'est facile de trier et de retirer les plus anciens. Je regrette ceci dit que le timestamp ne soit pas lisible à l'oeil nu. Mais il a le bon gout d'avoir une taille fixe, ce qui evite des corners cases avec le tri en shell ( genre, oublier de faire un tric sur une valeur numérique au lieu d'une valeur lexicographique, ce qui fait que toto-400 est vu comme avant toto-50, car on compare caractères par caractères ).
Donc rien d'insurmontable bien sur, rien de novateur, mais la force de systemd, c'est aussi d'offrir ça par défaut, ce qui permet de construire par dessus des choses haut niveau réutilisable, et ce qui démocratise la bonne pratique.
Un truc bien fait avec journald, c'est que le logiciel va gérer nativement le faire d'avoir des fichiers de log venant de n'importe ou, car le nommage le permet, et le logiciel en tire parti. On peut tout mettre tel quel dans /var/log/journal, et journal va faire "the right thing". On peut donc suivre les logs sur plusieurs machines, etc, etc. Le nommage des logs classiques implique un post traitement plus complexe, ce qui est faisable encore une fois. Par exemple, splunk, elastic search sont des solutions pour ça qui vont bien au delà de journald. mais qui requiert une infra plus conséquente, la ou journald va juste tirer parti du nommage des fichiers et d'un design simple.
C'est donc vraiment dans l'approche d'offrir un truc parce que c'est facile à faire, une solution intermédiaire entre rien et le truc plus complet et plus compliqué ( un peu comme le protocole de notification de systemd ). Ça règle pas tout les soucis de tout le monde, mais ça peut aider.