Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!cleanfeed3-a.proxad.net!nnrp1-2.free.fr!not-for-mail
From: Thomas <fantome.forums.tDeContes@free.fr.invalid>
Newsgroups: fr.comp.os.unix
Mail-Copies-To: nobody
Subject: Re: =?UTF-8?Q?g=C3=A9rer?= des fichiers log
References: <fantome.forums.tDeContes-AD48E3.21414905072021@news.free.fr> <scubs2$u25$2@shakotay.alphanet.ch> <fantome.forums.tDeContes-F23835.20444917072021@news.free.fr> <sd0l91$b4m$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-130E7D.23050920072021@news.free.fr> <sd8faa$8ac$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-433B13.01575723072021@news.free.fr> <sddoan$flh$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-5442BA.19235419092021@news.free.fr> <si9urh$mad$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-D7C707.17401124092021@news.free.fr> <slrnsks8om.83t.sc@scarpet42p.localdomain> <fantome.forums.tDeContes-AD18A9.03233926092021@news.free.fr> <slrnsl18t8.29t.sc@scarpet42p.localdomain> <fantome.forums.tDeContes-CB5B35.17330627092021@news.free.fr> <slrnslefar.16n.sc@scarpet42p.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
Date: Fri, 22 Oct 2021 23:41:58 +0200
Message-ID: <fantome.forums.tDeContes-BF832B.23415822102021@news.free.fr>
Lines: 200
Organization: Guest of ProXad - France
NNTP-Posting-Date: 22 Oct 2021 23:41:59 CEST
NNTP-Posting-Host: 91.175.52.121
X-Trace: 1634938919 news-3.free.fr 1329 91.175.52.121:8228
X-Complaints-To: abuse@proxad.net
Bytes: 10272

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
========== REMAINDER OF ARTICLE TRUNCATED ==========