Re: gérer des fichiers log

Le 26-09-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit :

In article <slrnsks8om.83t.sc@scarpet42p.localdomain>,
 Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:
>

Soit tu ne veux voire les choses que d'un côté applicatif. Dans ce cas,
c'est simple, tu balances tout sur stdout et stderr et tu laisses les
intégrateurs, admins systèmes et utilisateurs finaux gérer ce qu'ils en
font comme ils le veulent.

>

Si les logs sont perdus lancés en mode
graphique, c'est pas grave, l'utilisateur a toujours la possibilité de
lancer en ligne de commande (même le mode graphique) pour voir les logs
qui l'intéressent sur le terminal le jour où il veut comprendre.

>
mon souci c'est que si qqn a juste des bugs à faire remonter, faut pas
que ça soit trop compliqué.

Il n'y a rien de compliqué. Si tu balances tous tes logs sur ta sortie
d'erreur, tu dis à l'utilisateur de tapper la commande
« $> monsuperprogramme 2> fichier.log »
et de t'envoyer le fichier « fichier.log » quand il a reproduit le bug.

c'est pas comme s'il lui prend simplement l'envie de regarder sous le
capot. dans ce cas là c'est à lui de se remonter les manches.

Oui, mais pour se remonter les manches, il faut juste que tu lui
permettes de le faire.

D'abord, il faut que quoiqu'il arrive, l'absence de possibilité
d'écrire tes logs ne puisse pas empêcher ton appli de tourner. Ça veut
dire que dans ton code tu dois prendre en compte une mauvaise
installation ou un mauvais lancement.

>
aucun pb, en ada il suffit de rattraper toutes les exceptions.
>
la seule question qui me tracassait était de savoir dans quelle mesure
ces erreurs là avaient besoin d'être rapportées à leur tour, parce qu'il
y a un risque de tomber dans une boucle infinie.

Je ne suis pas sûr d'avoir été clair. Imaginons que la seule possibilité
de configuration soit le fichier « /etc/monprog.config » qui est donc à
la main de l'intégrateur et de l'admin système. Imaginons toujours que
par erreur, la ligne correspondant à l'écriture des logs soit définie à
« /bin/monprog.log ». T'as beau catcher toutes tes exceptions, tu les
envoies où tes erreurs ?

mais si on n'a pas besoin de les rapporter, aucun pb :-)

En fait, c'est ton programme, c'est toi qui doit savoir ce qui doit être
rapporté. C'est toi qui dois savoir quels problèmes doivent être traités
ou pas. Si le fichier de conf n'est pas trouvé, est-ce que tu as des
valeurs par défaut qui lui permettent de fonctionner ou pas ? Est-ce que
c'est un problème ou pas ? C'est toi qui dois le savoir.

Le disque est saturé, tu ne peux pas écrire de logs. Soit. Mais est-ce
que la saturation du disque peut poser d'autres problèmes à ton
programme ? Pareil, je n'en sais rien, c'est à toi de le savoir.

Ensuite, il y a le packager qui doit pouvoir choisir le répertoire de
logs par défaut lors de l'installation. Puis, l'admin système doit
pouvoir en choisir un autre pour l'ensemble de ses utilisateurs. Puis,
un utilisateur particulier doit pouvoir choisir où il met les logs pour
lui. Avec la possibilité de changer les logs par une option lors du
démarrage s'il veut faire un test.
 
C'est pour ça qu'il faut bien que tu fasses attention à la préséance
dans le choix des possibilités si c'est défini à plusieurs endroits. Il
faut absolument que ce qui est écrit en dur dans ton code ne soit utilisé
que si rien d'autre n'est trouvé. Il faut aussi que l'option en ligne de
commande prenne le dessus sur toutes les variables d'environnement et
fichiers de conf. De même que l'utilisateur final peut écrire dans son
$HOME et pas dans /etc et donc /etc va être réservé à l'admin système ou
au packager et être moins prioritaire que $HOME.

>
tout ça me parait un peu compliqué (pour l'instant),

Je ne vois pas en quoi c'est plus compliqué que ce que tu écrivais en
cherchant dans les variables systèmes ou les répertoires différents.
Je te dis juste qu'il faut que tu fasses attention à l'ordre dans lequel
tu vas chercher tes fichiers.

mais ce qui me parait simple c'est :
- de tout balancer sur stdout et stderr en plus des fichiers,

Ça me semble suttout faire double emploi.

Pour la séparation de stdout et stderr, c'est pas forcément très utile.
Il me semble préférable de tout mettre au même endroit avec un niveau de
log qui contient un tag et qui est paramétrable. Par exemple, tu mets du
DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un niveau
d'activation faible en temps normal pour avoir moins de lignes et tu
affiches tout quand tu veux comprendre ce qu'il se passe.

>
j'aime bcp l'idée :-)
>
je ne sais pas si c'est facile à faire très rapidement, parce que :
- il faut que je définisse des règles pour catégoriser les logs
(auj dans mon code les logs ne sont divisés qu'en 2 catégories : DEBUG
et ERROR)
- il faut que je réfléchisse à comment j'organise une ligne, pour que ça
soit agréable à la fois
  - à utiliser en traitement automatique (c'était ça ton idée ?),
  - quand on l'affiche dans un terminal, en évitant de mettre des
caracteres de contrôle qui vont fiche le bazar ...

Mon idée (enfin, c'est pas vraiment la mienne, c'est quand même assez
classique), c'est que tu te programmes une fonction genre
« sendlog(niveau,message) »
Et qu'à chaque fois que tu veux envoyer un log, tu passes ton message à
cette fonction avec le niveau de logs voulu. Par exemple, en mode debug,
tu vas envoyer toutes les valeurs de tes variables lors d'appels de
fonction dans les logs. Par contre, en mode nominal, ça va surtout te
polluer tes logs et tu n'affiches que les erreurs (éventuellement les
warnings).

Et c'est ta fonction sendlog qui va choisir quoi faire de tes logs :
poubelle si c'est pas le bon niveau de logs et envoi dans le cas
contraire.

Je ne sais pas si tu utilises un framework, ou si tu définis toutes tes
fonctions, mais il doit bien exister quelque chose.

est-ce que ça convient, d'avoir tous ces tags qui s'affichent dans le
terminal quand on est en CLI (par ex au moment d'indiquer que les
arguments sont mauvais) ?

Si c'est une application qui tourne dans un terminal, faut pas que les
logs la rendent inutilisable. Par exemple, la commande find, si tu
cherches toto.txt avec « find / -name toto.txt » en tant que simple
utilisateur, tu vas avoir l'écran rempli d'erreurs des répertoires que
tu n'as pas le droit de lire. et s'il y a une réponse positive, tu ne
vas pas la voir. Alors tu vas plutôt faire ta recherche avec un
« find / -name toto.txt 2> /dev/null ». C'est pareil pour ton
application, il faut qu'elle soit souple.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io