Ca change que le programme peut logguer des données de facon structurée.
Et combien vont le faire ? Sachant que seul systemd-journald offre cette possibilité et qu’il n’est pas seul en jeu. Tu crois que les développeurs de démons vont laisser tomber syslog(3), largement disponible, et se mettre à utiliser l’API propre à systemd-journald ? Moi je n’y crois pas. Oh, certains le feront, certainement, mais je doute fort qu’ils soient nombreux.1
D’ailleurs, d’après Lennart Poettering, la meilleure façon de logger, pour les démons « new style » (c’est comme ça qu’il appelle les démons conçus dès le départ pour profiter de systemd), c’est d’utiliser... le bon vieux printf(3), systemd se chargeant d’envoyer la sortie standard du démon vers journald.
Et meme si le programme ne le fait pas, journald log de base certaines infos de facon structurée, comme le PID et l'UID du process, l'ID de boot, l'unit systemd, les infos SELinux, etc
Sauf que typiquement ce ne sont pas ces informations que l’on veut aller grepper dans les logs, mais bien les informations propres au programme, celles contenues dans le message qu’il a envoyé.
Pour illustrer mon propos, mettons que je veuille récupérer les adresses des petits malins qui tentent de bruteforcer mon serveur SSH. Actuellement, avec des journaux au format texte gérés par syslog, je ferais quelque chose du genre :
$ grep sshd /var/log/messages | sed -nre 's/^.*\[(.+)\] failed - POSSIBLE BREAK-IN ATTEMPT!/1円/p'
avec une belle regex fragile qui peut ne plus marcher à la prochaine mise à jour de sshd si les développeurs de celui-ci ont jugé bon de changer le format de ce message.
Avec des journaux au format binaire gérés par systemd-journald, je ferais (attention, révolution) :
$ journalctl _SYSTEMD_UNIT=sshd.service | sed -nre 's/^.*\[(.+)\] failed - POSSIBLE BREAK-IN ATTEMPT!/1円/p'
... avec une belle regex fragile qui peut ne plus marcher à la prochaine mise à jour de sshd si les développeurs de celui-ci ont jugé bon de changer le format de ce message. Zut alors, ni systemd-journald ni le fait de stocker les journaux au format binaire n’ont empêché ça.
Le seul bénéfice visible de journald, ici, c’est de faire l’économie de la première regex, celle qui sert à filtrer les messages issus de sshd — c’est-à-dire, la plus simple et surtout celle qui n’est pas vraiment susceptible de changer.
il est relativement simple de ne pas casser la compatibilité, l'ajout d'un nouveau champ ne va pas poser de problèmes.
Je considérerai cet avantage lorsque je verrai les développeurs de sshd opter pour l’API de journald en lieu et place de syslog(3). En attendant, c’est purement théorique.
1 Quand je vois le nombre de programmes qui enregistrent encore leurs données directement à la racine de $HOME au lieu d’utiliser les répertoires proposés par la « XDG Base Directory Specification »... il ne suffit pas de proposer quelque chose de pratique pour que ce soit utilisé.
[^] # Re: GNU/SystemD/Linux
Posté par gouttegd . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 4. Dernière modification le 05 décembre 2013 à 23:56.
Et combien vont le faire ? Sachant que seul systemd-journald offre cette possibilité et qu’il n’est pas seul en jeu. Tu crois que les développeurs de démons vont laisser tomber syslog(3), largement disponible, et se mettre à utiliser l’API propre à systemd-journald ? Moi je n’y crois pas. Oh, certains le feront, certainement, mais je doute fort qu’ils soient nombreux.1
D’ailleurs, d’après Lennart Poettering, la meilleure façon de logger, pour les démons « new style » (c’est comme ça qu’il appelle les démons conçus dès le départ pour profiter de systemd), c’est d’utiliser... le bon vieux printf(3), systemd se chargeant d’envoyer la sortie standard du démon vers journald.
Sauf que typiquement ce ne sont pas ces informations que l’on veut aller grepper dans les logs, mais bien les informations propres au programme, celles contenues dans le message qu’il a envoyé.
Pour illustrer mon propos, mettons que je veuille récupérer les adresses des petits malins qui tentent de bruteforcer mon serveur SSH. Actuellement, avec des journaux au format texte gérés par syslog, je ferais quelque chose du genre :
avec une belle regex fragile qui peut ne plus marcher à la prochaine mise à jour de sshd si les développeurs de celui-ci ont jugé bon de changer le format de ce message.
Avec des journaux au format binaire gérés par systemd-journald, je ferais (attention, révolution) :
... avec une belle regex fragile qui peut ne plus marcher à la prochaine mise à jour de sshd si les développeurs de celui-ci ont jugé bon de changer le format de ce message. Zut alors, ni systemd-journald ni le fait de stocker les journaux au format binaire n’ont empêché ça.
Le seul bénéfice visible de journald, ici, c’est de faire l’économie de la première regex, celle qui sert à filtrer les messages issus de sshd — c’est-à-dire, la plus simple et surtout celle qui n’est pas vraiment susceptible de changer.
Je considérerai cet avantage lorsque je verrai les développeurs de sshd opter pour l’API de journald en lieu et place de syslog(3). En attendant, c’est purement théorique.
1 Quand je vois le nombre de programmes qui enregistrent encore leurs données directement à la racine de $HOME au lieu d’utiliser les répertoires proposés par la « XDG Base Directory Specification »... il ne suffit pas de proposer quelque chose de pratique pour que ce soit utilisé.