Re: gérer des fichiers log

Liste des GroupesRevenir à fco unix 
Sujet : Re: gérer des fichiers log
De : fantome.forums.tDeContes (at) *nospam* free.fr.invalid (Thomas)
Groupes : fr.comp.os.unix
Date : 02. Jan 2022, 01:54:25
Autres entêtes
Organisation : Guest of ProXad - France
Message-ID : <fantome.forums.tDeContes-E3C660.00542502012022@news.free.fr>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
User-Agent : MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
In article <slrnssmcu2.hi0.sc@scarpet42p.localdomain>,
 Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:

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

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.

pour ça il faut qu'il s'aperçoive du pb, puis qu'il redémarre
l'application avec les bons paramètres.
c'est pour ça (je crois) que tu m'avais dit que c'était pas bien
d'ignorer les erreurs.


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 le disque est plein,
- il faut le logguer ou ?
- tu trouves que ça ne convient pas de signaler ce pb dans l'interface
graphique ?
ça ne convient pas de considérer que ce pb doit être résolu
immédiatement pour que le logiciel puisse continuer à fonctionner
correctement ?

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

et si le disque est plein ?


 
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.

c'est comme ça que je suis parti pour l'instant.

 
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.

a priori c'est une idée que je trouve pas mauvaise.

mais il y a des questions non répondues, dans mon msg du 22 Oct 2021,
qui font que je n'y vais pas pour l'instant.


 
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.

en ada, on a à ma connaissance toutes les bibliothèques nécessaires pour
avoir toutes les possibilités de développement à disposition,
mais il n'y a pas autant de bibliothèques qu'en c quand même.

je suppose que c'est pour ça que mon prédécesseur avant démarré
l'écriture d'une telle bibliothèque.

je l'ai immédiatement "améliorée" en ajoutant la génération de
fichiers log, parce que c'était un besoin et que je ne savais pas que
c'était mal vu.
et là, je continue de l'améliorer, par ex en rendant ces fichiers log
facultatifs, et en permettant de choisir leur nom.

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

Date Sujet#  Auteur
19 Sep 21 * Re: gérer des fichiers log18Thomas
20 Sep 21 `* Re: gérer des fichiers log17Marc SCHAEFER
24 Sep 21  `* Re: gérer des fichiers log16Thomas
24 Sep 21   +* Re: gérer des fichiers log4Marc SCHAEFER
26 Sep 21   i`* Re: gérer des fichiers log3Thomas
26 Sep 21   i `* Re: gérer des fichiers log2Marc SCHAEFER
28 Sep 21   i  `- Re: gérer des fichiers log1Thomas
24 Sep 21   `* Re: gérer des fichiers log11Stéphane CARPENTIER
26 Sep 21    `* Re: gérer des fichiers log10Thomas
26 Sep 21     `* Re: gérer des fichiers log9Stéphane CARPENTIER
27 Sep 21      +* Re: gérer des fichiers log7Thomas
1 Oct 21      i`* Re: gérer des fichiers log6Stéphane CARPENTIER
22 Oct 21      i `* Re: gérer des fichiers log5Thomas
19 Dec 21      i  `* Re: gérer des fichiers log4Thomas
28 Dec 21      i   +- Re: gérer des fichiers log1Thomas
28 Dec 21      i   `* Re: gérer des fichiers log2Stéphane CARPENTIER
2 Jan 22      i    `- Re: gérer des fichiers log1Thomas
17 Sep 22      `- tags pour les logs1Thomas

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal