Gni? Non, il suffit de faire un bête logiciel qui sort du texte des fichiers de log (bref, un bête remplaçant de journalctl qui fait qu'une chose)
Et qui interprete les meta systemd, comme la date, le numero de PID, le nom de la machine etc. Bref un truc qui prend un fichier binaire raw et qui le formatte pour l'affichage, et bien entendu qui prend en paramètre les éléments qui m'interressent, sinon je remonte TOUT le journal à chaque fois, et qui jongle avec les différents formats de contenu pour que l'on puisse traiter les sorties simultanément (avec un cat par exemple) et qui possède un système pour faire du back and forth (non parceque des fois je vais vouloir revenir en arrière sur le fichier qui défile, par exemple depuis un more - toujours sans charger TOUT le journal en mémoire).
Contrairement à ce que tu as l'air de penser faire un système qui fonctionne avec tous les outils traditionnels unix dans un nombre satisfaisant de consoles est loin d'être évident. Il ne s'agit pas juste de cracher les logs ligne à ligne.
Idéalement il faudrait que le lecteur de log émule un comportement de fichier, ce qui implique à son tour de faire un FS user space (petit et en user space), et donc d'installer des cochonneries sur la machine qui reçoit les logs.
Je ne suis pas sur que ce soit beaucoup plus simple que de recoder les outils unix pour qu'ils attaquent le raw directement. (Moi en tout cas je me sens plus à l'aise à écrire journalcat et journalgrep qu'à faire journalFS).
alors que c'est assez simple en fait
Ca doit être parce que c'est "super simple" que la première chose que dit la page freedesktop est "Faites pas les cons, utilisez l'API C (qui nécessite bien sur d'avoir tout systemd installé) sinon vous allez vous vautrer". Ils ajoutent aussi que si on ne veut vraiment pas utiliser l'API C il faut faire des exports complets (toujours via systemd). Mais alors attaquer les fichiers en raw - surtout pas mon bon ami.
La résistance au changement fait dire pas mal de choses…
Etre convaincu d'avoir raison et penser que toute personne qui vous contredit ne peut être qu'un réactionnaire mal avisé et stupide fait dire pas mal de conneries aussi.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 3.
Gni? Non, il suffit de faire un bête logiciel qui sort du texte des fichiers de log (bref, un bête remplaçant de journalctl qui fait qu'une chose)
Et qui interprete les meta systemd, comme la date, le numero de PID, le nom de la machine etc. Bref un truc qui prend un fichier binaire raw et qui le formatte pour l'affichage, et bien entendu qui prend en paramètre les éléments qui m'interressent, sinon je remonte TOUT le journal à chaque fois, et qui jongle avec les différents formats de contenu pour que l'on puisse traiter les sorties simultanément (avec un cat par exemple) et qui possède un système pour faire du back and forth (non parceque des fois je vais vouloir revenir en arrière sur le fichier qui défile, par exemple depuis un more - toujours sans charger TOUT le journal en mémoire).
Contrairement à ce que tu as l'air de penser faire un système qui fonctionne avec tous les outils traditionnels unix dans un nombre satisfaisant de consoles est loin d'être évident. Il ne s'agit pas juste de cracher les logs ligne à ligne.
Idéalement il faudrait que le lecteur de log émule un comportement de fichier, ce qui implique à son tour de faire un FS user space (petit et en user space), et donc d'installer des cochonneries sur la machine qui reçoit les logs.
Je ne suis pas sur que ce soit beaucoup plus simple que de recoder les outils unix pour qu'ils attaquent le raw directement. (Moi en tout cas je me sens plus à l'aise à écrire journalcat et journalgrep qu'à faire journalFS).
alors que c'est assez simple en fait
Ca doit être parce que c'est "super simple" que la première chose que dit la page freedesktop est "Faites pas les cons, utilisez l'API C (qui nécessite bien sur d'avoir tout systemd installé) sinon vous allez vous vautrer". Ils ajoutent aussi que si on ne veut vraiment pas utiliser l'API C il faut faire des exports complets (toujours via systemd). Mais alors attaquer les fichiers en raw - surtout pas mon bon ami.
La résistance au changement fait dire pas mal de choses…
Etre convaincu d'avoir raison et penser que toute personne qui vous contredit ne peut être qu'un réactionnaire mal avisé et stupide fait dire pas mal de conneries aussi.