Les problèmes pointés sur syslog sont réels, mais j'ai du mal avec les réponses apportées.
Comment un sysadmin pourrait-il faire confiance en un système de logs binaires dont le format de stockage est et restera non documenté, pouvant évoluer à tout moment.
Quand je vois que pour la centralisation des logs, il ne propose que rsync, ça laisse songeur. (Le un jour peut-être on fera du réseau si on a le temps, j’y crois pas tant que c’est pas fait).
En plus, le démon de log semble choisir aléatoirement les lignes conservées en fonction de la charge système et de l’espace disque.
Qu’est-ce qui est prévu au niveau de la structure des fichiers logs en cas de crash machine ? La seule mention que je vois s'est :
> It is designed in a way that log data is only attached at the end (in order to ensure robustness and atomicity with mmap()-based access), with some meta data changes in the header to reference the new additions
Le système de fichier dessous à intérêt de bien gérer les crashs et d’être journalisé...
Comme pour syslog, chaque application devra écrire son propre parseur ayant connaissance des UUID spécifiques à l’application pour pouvoir les interpréter...
Il ne parle que de GUI pour lire les logs, donc encore une fois, après PA, et surtout NM, un système bas niveau qui devient inutilisable en console...
Je suppose que son parseur sera assez light pour pouvoir être utilisé depuis un initramfs au cas où systemd plante le démarrage de la machine ?
# Bonnes questions, mais...
Posté par Hobgoblins Master . En réponse au journal Lennart casse les logs!. Évalué à 5.
Les problèmes pointés sur syslog sont réels, mais j'ai du mal avec les réponses apportées.
Comment un sysadmin pourrait-il faire confiance en un système de logs binaires dont le format de stockage est et restera non documenté, pouvant évoluer à tout moment.
Quand je vois que pour la centralisation des logs, il ne propose que rsync, ça laisse songeur. (Le un jour peut-être on fera du réseau si on a le temps, j’y crois pas tant que c’est pas fait).
En plus, le démon de log semble choisir aléatoirement les lignes conservées en fonction de la charge système et de l’espace disque.
Qu’est-ce qui est prévu au niveau de la structure des fichiers logs en cas de crash machine ? La seule mention que je vois s'est :
> It is designed in a way that log data is only attached at the end (in order to ensure robustness and atomicity with mmap()-based access), with some meta data changes in the header to reference the new additions
Le système de fichier dessous à intérêt de bien gérer les crashs et d’être journalisé...
Comme pour syslog, chaque application devra écrire son propre parseur ayant connaissance des UUID spécifiques à l’application pour pouvoir les interpréter...
Il ne parle que de GUI pour lire les logs, donc encore une fois, après PA, et surtout NM, un système bas niveau qui devient inutilisable en console...
Je suppose que son parseur sera assez light pour pouvoir être utilisé depuis un initramfs au cas où systemd plante le démarrage de la machine ?