Re: gérer des fichiers log

In article <slrnslefar.16n.sc@scarpet42p.localdomain>,
 Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:

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.

moi non plus je ne sais pas comment,
et j'ai expliqué à Marc pourquoi j'en faisais mon problème quand même.

d'où la solution de fabriquer les fichiers de log directement par
l'exécutable, que je trouve la moins mauvaise,

et la contrainte de te déranger le moins possible vient juste après ça,
en termes de priorités.

 

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.

en fait quand je voyais le nb de cas de figures possibles, qui
s'approche de 27,
s'il fallait rapporter sur toutes les interfaces qui ne posent pas de pb
tous les pbs des interfaces qui en posent,
je me disais que c'était plus simple de tout ignorer.

mais s'il n'y a que qqes cas particuliers dans lesquels c'est préférable
de rapporter les pbs d'une interface sur une autre, ça devient bcp plus
simple. :-)

 

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 ?

ok.
je devine que je trouverai l'usage au fur et à mesure que j'en aurai
besoin.
il faut que j'ai à l'idée qu'on peut ajouter autant de niveaux qu'on
veut.
en attendant, ça ne dérange personne que je reste à 2. :-)

 

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.

C'est pas très compliqué à ajouter, surtout si on se contente de
l'ajouter et peu importe ce que ça devient.

C'est un tout petit peu plus compliqué que ça, si on veut se garantir de
faire les choses "bien comme il faut", ce qui implique qques questions
supplémentaires, même si à la fin on fait la même chose que sans se
poser de question.

par exemple :

- si le msg à rapporter s'étale sur plusieurs lignes ?
  - est-ce qu'on le découpe en tranches et on remet les metadonnées sur
chaque ligne ?
  - est-ce qu'on remplace le marqueur de fin de ligne par un autre
séparateur ?
- si on veut que ça soit exploitable en tableur il faut choisir un
séparateur :
lequel, et comment ça se passe si le msg à rapporter le contient ?

 

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.

je comprend bien l'intérêt :-)

en suivant les recommandations de Marc, on peut choisir de tout mettre
dans le même fichier de logs, soit en dirigeant les 2 sorties standards
au même endroit, soit en donnant le même nom aux 2 fichiers.

 

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.

C'est pas compliqué, le pb c'est tjr de savoir ce qui est bien.

je trouverais ça bizarre d'avoir le msg "ignoring unknown switch" ainsi
que le "usage: ..." qui suit, bardés de tags + horodatage !
est-ce que ça se pratique ?

 

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

Pour le /dev/null c'est parce que tu ne veux mettre les messages
d'erreurs directement à la poubelle.

je n'ai pas compris. "ne" est en trop ?

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.

merci :-)

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/