Deutsch English Français Italiano |
<slrnssmcu2.hi0.sc@scarpet42p.localdomain> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!2.eu.feeder.erje.net!feeder.erje.net!fdn.fr!usenet-fr.net!agneau.org!nntpfeed.proxad.net!proxad.net!feeder1-1.proxad.net!cleanfeed1-a.proxad.net!nnrp1-1.free.fr!not-for-mail Newsgroups: fr.comp.os.unix From: =?UTF-8?Q?St=C3=A9phane?= CARPENTIER <sc@fiat-linux.fr> 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> <fantome.forums.tDeContes-BF832B.23415822102021@news.free.fr> <fantome.forums.tDeContes-B2A88C.19191319122021@news.free.fr> Organization: Mulots' Killer User-Agent: slrn/1.0.3 (Linux) Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-ID: <slrnssmcu2.hi0.sc@scarpet42p.localdomain> Date: 28 Dec 2021 15:56:50 GMT Lines: 88 NNTP-Posting-Date: 28 Dec 2021 16:56:50 CET NNTP-Posting-Host: 78.201.248.7 X-Trace: 1640707010 news-1.free.fr 4997 78.201.248.7:55214 X-Complaints-To: abuse@proxad.net Bytes: 5832 Le 19-12-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit : > > - on peut tout ignorer en cas de pb avec l'interface graphique, parce > que ça ne peut pas arriver uniquement à cet endroit, ça arrivera > forcément ailleurs. Ben justement voilà justement une bonne raison de ne pas chercher à logguer à plein d'endroits différents en fonction du contexte. Imagine, ton application elle tourne nickel en terminal. Ton utilisateur veut l'utiliser avec l'interface graphique. Sauf que comme tu n'as pas exactement les mêmes librairies avec Wayland et Xorg, ça peut marcher sur l'un et pas sur l'autre. Si tu veux analyser tous les cas possibles, ça va être très délicat. Si tu te contentes de balancer les logs et de laisser l'utilisateur en faire ce qu'il veut ça te simplifie la vie. > en cas de pb avec stdout / stderr, Ce qui est bien avec stdout/stderr, c'est que s'il y a un problème, l'utilisateur le redirige vers un autre endroit où il n'y a pas de problème. > - si l'interface graphique est disponible, on affiche ça dedans, > parce que dans ce cas c'est probable que stdout et stderr ne soient pas > lus (redirigés ou jetés). L'affichage dans l'interface graphique, c'est pour afficher une information qui demande une intervention de l'utilisateur à un moment. C'est pas forcément une erreur. Par exemple, si l'utilisateur n'a pas choisi la couleur de son fond d'écran mais que tu as une couleur par défaut, c'est pas très important. Lorsqu'il change la couleur de son fond d'écran mais qu'il y a un problème et que tu gardes la couleur par défaut, il faut l'informer que son action s'est mal passée. Si par contre, ton application exécute une action en tâche de fond toutes les minutes, si l'action plante une fois sur deux, il faut le logguer mais ne pas lui afficher la pop-up toutes les deux minutes. Ce n'est pas forcément grave si stdout et stderr ne sont pas lus. Si l'utilisateur veut chercher à comprendre après coup, il les lira. > - si non, on l'envoie sur stdout, > parce que dans ce cas c'est probable que stderr ne soit pas lu > (redirigé), > mais c'est probable que stdout le soit (directement dans un terminal). En fait, l'intérêt de sdout et de stderr, c'est que tu t'en cognes de savoir si c'est lu ou pas, redirigé ou pas. Tu donnes une information et l'utilisateur en fait ce qu'il veut. La différence entre les deux, c'est que le stdout, c'est pour l'information normale et le stderr c'est pour l'erreur. Par exemple, si ton application exécute une tâche de fond toutes les minutes, dans ton stdout, tu vas logguer le début et la fin de l'action. Et s'il y a un plantage, tu loggues l'erreur dans le stderr. Comme ça, si l'utilisateur redirige tout dans le même fichier, il aura le contexte : le plantage aura eu lieu pendant la tâche de fond. Mais s'il veut se concentrer sur les erreurs, il ne regarde que stderr. Tu le laisses choisir le niveau d'information qu'il veut afficher. Et si dans tes logs, tu précises ce que c'est (avec un timestamp devant) : INFO: début de la tâche de fond INFO: 42 informations à mettre à jour WARNING: 1 mise à jour est vide, utilisation de la valeur TOTO ERROR: enregistrement impossible, droits insuffisants INFO: fin de la tâche de fond Là, comme en général, tu vas avoir des centaines de lignes d'info pour quelques lignes d'erreur, il va pouvoir faire des recherches faciles. >> > >> >> Par exemple, tu mets >> > >> >> du >> > >> >> DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un >> > >> >> niveau >> > >> >> d'activation faible en temps normal > > est-ce que je numérote dans cet ordre de 0 à 3 ? En général, le plus simple est d'utiliser un framework qui fait déjà tout ça et de suivre la doc. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io