Mais dans le cas des logs, les logs de syslog n'ont pas de structure et les logs de journald en ont.
Non, l’un comme l’autre peuvent être structurés ou non-structurés.
Plus précisément :
Les informations autour du message de log (telles que la date, la machine, la priorité, etc.) sont toujours structurées, que ce soit avec syslog ou avec journald. La seule différence est que journald stocke beaucoup plus d’informations de ce genre qu’une implémentation typique de syslog (chez moi, syslog stocke uniquement la date/heure, le nom d’hôte, et le nom et PID du processus — mais toutes ces informations sont enregistrées d’une façon cohérente dans tous les fichiers de logs et sont parsables sans surprise).
Le message de log proprement dit (ce qu’envoie le programme au système de journalisation, via syslog(3) ou sd_journal_print(3)) peut être structuré ou non, mais la plupart du temps il ne l’est pas, c’est une chaîne de caractères que le programme formatte à sa guise. Je doute fort que journald change quoi que ce soit à ça, c’est entièrement du ressort du programme émetteur (et ça fait des années que la possibilité d’envoyer des messages structurés à syslog existe sans que personne ne s’en serve, donc je ne vois pas pourquoi tout le monde déciderait subitement de le faire juste parce que journald le permet aussi).
Exemple, le format de mod_security est relou [...] Le fait d'inventer son format fait que je doit refaire la machinerie pour chercher la bas.
Les programmes qui se chargent eux-mêmes de leurs propres logs (souvent avec leur propre format) au lieu de passer par le démon de journalisation du système poseront toujours problème, peu importe que le démon de journalisation soit syslogd ou journald...
[^] # Re: Pour toi?
Posté par gouttegd . En réponse au journal Vivent les journaux binaires !. Évalué à 5. Dernière modification le 10 mai 2015 à 21:08.
Non, l’un comme l’autre peuvent être structurés ou non-structurés.
Plus précisément :
Les informations autour du message de log (telles que la date, la machine, la priorité, etc.) sont toujours structurées, que ce soit avec syslog ou avec journald. La seule différence est que journald stocke beaucoup plus d’informations de ce genre qu’une implémentation typique de syslog (chez moi, syslog stocke uniquement la date/heure, le nom d’hôte, et le nom et PID du processus — mais toutes ces informations sont enregistrées d’une façon cohérente dans tous les fichiers de logs et sont parsables sans surprise).
Le message de log proprement dit (ce qu’envoie le programme au système de journalisation, via syslog(3) ou sd_journal_print(3)) peut être structuré ou non, mais la plupart du temps il ne l’est pas, c’est une chaîne de caractères que le programme formatte à sa guise. Je doute fort que journald change quoi que ce soit à ça, c’est entièrement du ressort du programme émetteur (et ça fait des années que la possibilité d’envoyer des messages structurés à syslog existe sans que personne ne s’en serve, donc je ne vois pas pourquoi tout le monde déciderait subitement de le faire juste parce que journald le permet aussi).
Les programmes qui se chargent eux-mêmes de leurs propres logs (souvent avec leur propre format) au lieu de passer par le démon de journalisation du système poseront toujours problème, peu importe que le démon de journalisation soit syslogd ou journald...