Path: ...!news.misty.com!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!cleanfeed1-b.proxad.net!nnrp1-1.free.fr!not-for-mail Newsgroups: fr.comp.os.unix From: =?UTF-8?Q?St=C3=A9phane?= CARPENTIER Subject: Re: =?UTF-8?Q?g=C3=A9rer?= des fichiers log References: 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: Date: 01 Oct 2021 16:54:51 GMT Lines: 130 NNTP-Posting-Date: 01 Oct 2021 18:54:51 CEST NNTP-Posting-Host: 78.201.248.7 X-Trace: 1633107291 news-1.free.fr 8880 78.201.248.7:41388 X-Complaints-To: abuse@proxad.net Bytes: 7717 Le 27-09-2021, Thomas a écrit : > In article , > Stéphane CARPENTIER 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