Bonne chance pour standardiser les messages de logs de tous les logiciels existants.
Tout ce qui est formaté automatiquement par journald dans un format binaire peut être formaté dans un format texte "standardisé". Je ne comprend pas l’argument.
Not even the most basic requirements like binary blobs or sensible structured logging. Let alone stuff like indexing or proper access control.
La structuration se fait très bien en texte, cf JSON.
Les blobs peuvent être mis dans un fichier à part s’ils sont gros (coredump par exemple) ou peuvent être sérialisés en base64.
L’indexation peut (et c’est même une très bonne idée, c’est ce que font la plupart des base de données à ma connaissance) se faire dans un fichier à part des données.
Pour l’access control, encore une fois je ne vois pas le rapport avec le débat texte/binaire
Tu arrives à avoir un OS avec journald et ses logs binaires, mais sans journalctl ? Où, quand, comment, pourquoi ?
Système non bootable, je veux voir les logs, j’ai un dual-boot MacOS X ou Windows (desktop). Même situation, j’ai une option netboot sur FreeBSD (serveur). Comment je lis les logs binaires pour savoir pourquoi ça boot pas ?
Et puis bon, c'est pas comme si journald n'était pas compatible avec syslog (il te manquera juste les méta-données, les blobs binaires au sein du journal ("ATA SMART health data, SCSI sense data, coredumps or firmware dumps"), l'access control & chiffrement du journal - comment savoir si le journal a été modifié ou non sans ça ? -, et la structuration du journal).
C’est en pratique ce que je fais, mais s’il faut avoir les logs en double pour avoir la fonctionnalité « être lisible en toute circonstance », je trouve que c’est loin d’être optimal... (et ça pénalise à peu près tous les autres critères discutés : vitesse (écrire deux fois sur le disque dans des fichiers séparés, pas glop), fiabilité dans une situation d’espace disque plein (le problème est doublé), taille prise sur le disque).
[^] # Re: GNU/SystemD/Linux
Posté par Moonz . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3.
Tout ce qui est formaté automatiquement par journald dans un format binaire peut être formaté dans un format texte "standardisé". Je ne comprend pas l’argument.
La structuration se fait très bien en texte, cf JSON.
Les blobs peuvent être mis dans un fichier à part s’ils sont gros (coredump par exemple) ou peuvent être sérialisés en base64.
L’indexation peut (et c’est même une très bonne idée, c’est ce que font la plupart des base de données à ma connaissance) se faire dans un fichier à part des données.
Pour l’access control, encore une fois je ne vois pas le rapport avec le débat texte/binaire
Système non bootable, je veux voir les logs, j’ai un dual-boot MacOS X ou Windows (desktop). Même situation, j’ai une option netboot sur FreeBSD (serveur). Comment je lis les logs binaires pour savoir pourquoi ça boot pas ?
C’est en pratique ce que je fais, mais s’il faut avoir les logs en double pour avoir la fonctionnalité « être lisible en toute circonstance », je trouve que c’est loin d’être optimal... (et ça pénalise à peu près tous les autres critères discutés : vitesse (écrire deux fois sur le disque dans des fichiers séparés, pas glop), fiabilité dans une situation d’espace disque plein (le problème est doublé), taille prise sur le disque).