Re: gérer des fichiers log

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

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

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.

>
et pour Windows,
je vais sur un forum Windows pour demander comment faire, et ensuite je
transmet à l'utilisateur la réponse qu'on me donne sans l'avoir
pratiquée.
ou alors je lui répond "vas sur un forum Windows pour demander comment
on fait ça, moi je sais pas".

Oui, bon, alors effectivement, Windows, je ne connais pas, je ne sais
pas comment ça marche et c'est pas mon problème. Mes réponses sont
orientées unix. Dans les grandes lignes ça doit pouvoir s'adapter sur
Windows mais je ne sais pas comment.

En fait, c'est ton programme, c'est toi qui doit savoir ce qui doit être
rapporté.

>
je crois qu'on s'est entendu avec Marc sur le fait qu'il n'y avait pas
de nécessité à cet endroit.
et si qqn d'autre me fais changer d'avis plus tard ... tant pis, on
pourra tjr l'améliorer plus tard.

Ce que je veux dire, c'est que tu peux apporter une nouvelle
fonctionnalité à ton programme et que cette fonctionnalité va nécessiter
va nécessiter 10Go d'espace disque libre et que du coup, ça peut devenir
important de se mettre à le logguer.

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)

>
(y a-t-il des règles pour déterminer la catégorie de chaque message ?)

Ce que je te dis, c'est que c'est toi qui voit ce qui est important pour
ton programme. Est-ce que c'est une erreur grave qui l'empêche de
tourner ? Est-ce que c'est juste une précision du fichier de conf que tu
as choisis ? Est-ce que c'est parce que ton programme a un comportement
bizarre alors il faut tout logguer pour comprendre ce qu'il fait
vraiment ligne par ligne ?

Mon idée, c'est que tu te programmes une fonction genre
« sendlog(niveau,message) »

>

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.

>
ok, je comprend mieux :-)
>
je croyais que tu disais de mettre un tag dans le fichier de log, pour
pouvoir ensuite le relire en filtrant (par ex avec grep), et
éventuellement le répartir en plusieurs fichiers par la suite.

Tu as les deux en fait. À partir du moment où tu reçois le niveau de log
pour savoir s'il faut l'envoyer ou pas, tu mets le tag qui va bien dans
tes logs. Quand tu es en mode debug, ça permet de chercher les erreurs
graves au milieu des centaines de lignes d'information.

De même qu'il faut mettre l'heure à laquelle tu loggues le message. Le
tag et l'heure ne sont pas plus compliqués à ajouter mais tu en verras
l'utilité le jour où tu auras des milliers de lignes de log à analyser.

en fait tu dis juste de sélectionner ce qu'on affiche, et que c'est
suffisant au niveau de l'ergonomie pour ne générer qu'un seul fichier de
log.
(dis moi si je me trompe à nouveau)

Ce que je dis, c'est qu'en faisant les deux, tu peux tout mettre dans le
même fichier de logs. Parce que des fois, tu as un log normal informatif
qui arrive systématiquement juste avant une erreur grave et de faire la
corrélation entre les deux va être dur si tu as des fichiers différents.

En temps normal, tu regardes juste si tu as des erreurs pour savoir si
tout est normal. En débuggage, tu cherches tes erreurs et tu lis le
contexte autour.

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.

>
mais si j'ai bien compris, les tags ne sont pas censés se retrouver sur
l'affichage. donc tout va bien :-)

En quoi ça te gêne d'afficher les tags ? C'est pas plus compliqué, c'est
juste un mot défini à rajouter. Et lorsque les sorties sont mélangées,
c'est la seule façon de voir rapidement si c'est de l'affichage normal
ou une alerte à traiter.

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 ».

>
(je n'avais pas encore eu le temps de demander comment faire ça,
merci :-)) )

Pour le /dev/null c'est parce que tu ne veux mettre les messages
d'erreurs directement à la poubelle. Mais si tu veux les envoyer par
mail, tu mets un nom de fichier à la place. Sous Linux.

Si tu veux, on peut s'arrêter là, tu poses des questions, moi je
réponds. Ce que je te donne comme réponses, ce sont surtout les
questions à te poser pour comprendre l'impact de ce que tu vas mettre en
place.

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